OpenEnergyMonitor Community

An app to review heat pump experiments

Here you go @moojuiceuk

Notably the demand shaper app in Emoncms should allow me to do that agile tariff/ CO2 bit. That’s part of the reason I’m doing all this work to integrate, such as this app


1 Like

For an indirect tank (i.e. the DHW is heated via a coil the potable water flows through within the tank), this is not really necessary as you never come into contact with the water in the tank. It could impact a heating engineer if they come into contact with the water in the tank, but is that not their risk they should take precautions against?

If the HSE state landlords have a responsibility, I would say that any private owner would want the same level of precaution taken. Regardless of the tank being an indirect coil heated tank, Legionella can grow in the tank (ie the stored hot water side), in the outlet pipework to the taps and in dead legs of the system. The primary way legionella infects people is when water droplets containing legionella become airborne (ie via a shower head).

Given legionella bacteria are killed at 60C, it is generally accepted that doing this once a week would cover the risk well. For the sake of a few extra pence of 'leccy, its worth doing IMO.

Agree - in indirect systems this is unnecessary but heating engineers beware!!

Nope, there is no HSE requirements on a private individual.

Never said there was. But, if a regulation forces a landlord to do something - it is generally worth doing yourself too. Bit like making your home has smoke alarms. Not a legal requirement for private owners but mandatory for landlords.

You are conflating two issues. There is no risk to a householder from legionella when using an indirect tank except from dead legs in the DHW supply pipework.

The legislation is an HSE requirement on Landlords to Tennants not heating engineers (or any other trade). It is up to the engineers to make a relevant risk assessment if they are likely to come into contact with such water.

Hi David,

Sorry to keep on about this but I’d like to really understand how the useful heat can be that much higher. Your comment about it being a feature of the way you’re controlling the heat pump makes me think the very high COP reading might be simply be due to the timing of the measurements you are taking.

For example on our gas boiler, the pump keeps running for some time after the boiler has stopped firing to prevent the fluid in the heat exchanger from boiling die to the residual heat, i.e. it runs to cool things down.

So I can imagine that in a HP you have exactly the same problem. Which means that if your temperature reading is just after the pump has turned off it will be very high giving a false COP ratio. Would it be possible to do the readings in a different order, or are you taking this data from the interface with the HP?

I’m not physicist, but surely thermodynamics would tell us that the ratio is impossible. Any physics PhDs out there? If this is the case then the software should be making sure that such an impossible ratio is impossible to generate from the data.

Hi @Bramco

You’re right about all the things you say. It is physically impossible and it is a result of the system measuring things with a bit of a delay.

As you say, I’m getting the values from the vendor’s system so can’t alter how that works. Notably it’s a bog standard MMSP system so you’ll see lots of people with behaviours like this as heat pumps get fitted in more properties.

There is another slightly unusual situation that is occurring as I type this. When the hot water is finished it’s hot and I pump that round the radiators which gives me some space heating in the way this vendor’s system measures it. That gives insanely an high instantaneous CoP because it’s just pump electricity being used. I’ve described it with examples in this post.

I’m not troubled by it because I tend to look at the CoP over the time of an event rather than the instantaneous CoP. That’s partly why I want this type of application in Emoncms, it allows you to look at the experiment’s outcome more easily by reviewing what makes sense to the experimenter.

BTW I should mention that Emoncms’ ability to return data “at intervals” is incredibly useful. My home-grown web-app tries to load all the data from every minute since October. As time goes by it’s getting harder and harder to do that. Of course Emoncms using PHPFINA can show an “all time” view relatively easily which is rather wonderful.

1 Like

I guess from my perspective if it isn’t physically possible, it would be better not to register that reading - if it is a single reading - and to replace it with an average of the one before and the one after. If it’s more, then lose the ‘impossible’ ones and again replace with an average.


1 Like

@TrystanLea I’ve uploaded the app and a relevant device file to MyForest/mmspheatpump on github so you can take a look.

1 Like

Thanks @MyForest this looks great, nice work! I will see if I can get your app running with my heatpump data here. Interesting wider discussion too!

1 Like

Thanks for the kind words @TrystanLea

I’m not going to say it’s bullet-proof, but I think I coded it fairly well to cope with missing feeds so it should just take advantage of what you can give it.

Come to think of it, I suspect there might be some bits that might try and divide by “undefined” if things aren’t set. I’ll go see. You can of course just be sure to assign pairs of feeds ( used + produced) to stop that.

Feel free to nudge me if it’s tripping you up. You know far more about this than me anyway :slight_smile:

[edit] Fixed the bug that I thought might be in there.

Nice work, got it running! I don’t have all the feeds, so it’s not all showing as you have it of course. Here’s a heating run from yesterday with a nice efficiency of 433% just look at that stable run, no cycling at all :slight_smile:

It’s doing the DHW at the moment hence higher flow temp.

Im wondering if for the time being it would be better for you to keep this under your own repository, users can just drop it in to use it and you can keep pushing new developments as you work on them without having to wait for my review and pull request merges?

I’m planning on overhauling the heat pump monitoring documentation soon and I would be happy to feature this app as part of the documentation.

It might be worth adding installation instructions to your readme, in particular the installation path needing to be MyForest/mmspheatpump which tripped me up for a bit:

cd /var/www/emoncms/Modules/app/apps
mkdir MyForest
cd MyForest
git clone

I see that you have used a different naming convention to the ‘My Heatpump’ app. Would you object to changing the expected feeds to:

  • heatpump_elec (electricity consumption in watts)
  • heatpump_elec_kwh
  • heatpump_heat (heat output in watts)
  • heatpump_heat_kwh
  • heatpump_flowT
  • heatpump_returnT

Thanks again for sharing this and your wider experimentation, really interesting.

1 Like

Gosh that’s some smooth running. Here’s ours bobbing up and down over the same time window (on purpose).

Yep, I’m fine with that. As you can see development is still moving at a hectic pace.

Thanks, that would be very kind.

Yep, will do. Sorry it caused you to stumble. I’m used to being able to get resources from “…/images/icon.png” for example, so I’m not making a good job of jumping around the folder hierarchy at the moment.

Yep, I generally try to follow the house-style when doing stuff like this. Clearly I’ve gone off-piste to make it explicit that my stuff is “different” when I’m thinking about it at the moment.

Specifically I need to ponder what I’m going to call all the finer-grain things like “HotWaterEnergyProducedRate1”. It’s easy to see how to map the totals to the existing feed names but I’ll have to work out what’s best for the rest. As you saw, there were rather a lot of them.

@TrystanLea Can you think of an inspiring place to look at in the existing code / apps to help stop me re-inventing the wheel?

You’re very welcome. The work that you and the community have done is really inspiring and is making it easy for me to share. I’m loving the feedback too.

1 Like

Now we’ve decided what to do I’ll take “release news” about the app over to this other topic and I’ll mostly consider this topic to mostly about massaging the app to make it work nicely with Emoncms.

@TrystanLea bump ^ :slight_smile:

I can take some guidance from “My Heatpump”.

I’ve got these inputs at the moment which would map to existing things:

FlowTemperature => heatpump_flowT
ReturnTemperature => heatpump_returnT
solar => solar
TotalEnergyConsumed1 => heatpump_elec_kwh
TotalEnergyConsumedRate1 => heatpump_elec
TotalEnergyProduced1 => heatpump_heat_kwh
TotalEnergyProducedRate1 => heatpump_heat

Common Resources
HeatPumpFrequency (the amount it intends to use on the next cycle)
OutdoorTemperature (at the heatpump)
WaterPump1Status (the main pump from the ASHP)
CoP (real time)
RenewableHeatEnergy (will probably remove)

Space Heating (zone1) things


(I could add some sort of Room Temperature here)


Domestic Hot Water




Looking at those clumps it looks like we have generic heating targets (which just happen to be heated by a heat pump).

Something like:


I’m wondering if you have any good existing common language that you’d like to use for “zone” and “X”. Also, is the concatenation reasonable?

Of course you could argue this is too generic and vague and will confuse people anyway. It’s not as though they can go to the app configuration screen and click “add zone” so I’d be hard-coding number of zones in the app.

As you’ve seen with my graphs being driven by “data-config-key-…” I could merrily render oodles of graphs, but in practice I’m assuming:

  • one heat pump source
  • one space heating zone
  • one hot water zone

is all we really want to target.

Anyway, let me know what you think. If you’re busy that’s fine, I’ll just proceed with something that looks somewhat like the “heatpump_*” idea.


David Bowen

1 Like

Sorry for the delay @MyForest.

Im not sure that I follow what the following mean?


are they:


It would be nice to reuse the heatpump_flowT naming as it will mean users can easily switch between both of our apps if they have used the same naming. But at the same time… selecting feeds is not a big deal at the end of the day, so its not really that important of an issue… if you have your own preferences re naming.

Yep, the “energy in” represents “elec in”.

I was leaving the door open to some of the folks using solar thermal or other exciting things where the energy coming in might not be from electricity.

Arguably I should even have called it power_in and energy_in_kwh but that looks like snake casing of “energy expressed in kilowatt hours” which is totally confusing.

I’ll have a ponder and see what inspires me.