An app to review heat pump experiments

Here’s me reviewing the four hours in the daytime from 14:00 to 16:00.

We can see that it’s about 7 degrees outside and the efficiency has improved from 305% to 365%.

The heat pump vendor gives lots of CoP figures and I’ve interpolated them for every combination of flow and outdoor temperature. I include that as a series on the graph in my home-grown app but haven’t implemented that in Emoncms yet.

If we take a flow temp of 40 °C (I have over-sized radiators) then the CoPs are:

Overnight (5°C): achieved 3.05 versus vendor suggested 3.43

Daytime (7°C): achieved 3.65 versus vendor suggested 3.81

Part of the reason for this good performance is the control algorithms I’m using to drive the heat pump. Of course I know the details of those and I can see them playing out in the graphs.

1 Like

So now on to the technical parts.

Gathering Data

Use the vendor’s “API” to get readings every minute.

Store them on disk (yes, very old-fashioned).

Push them to Emoncms using “/input/post”

Arguably the thing hoovering up the readings could just post them to Emoncms or perhaps a scheduled job in Emoncms could hoover them in. I don’t know if the vendor would be happy with me exposing that capability.

Setting up the Feeds

The most critical thing we need to do is accumulate Wh so we have to have all the inputs setup to do that. I’ve used the “device” module to create a comprehensive set of inputs, processes and feeds. It’s well beyond the six heatpump_* feeds in “My Heatpump” because it’s trying to do so much more of course. I do also generate the feeds that “My Heatpump” uses as a courtesy.

Emoncms Application

I’ve spent quite a few days learning how you do things and building stuff that tries to follow your conventions whilst I re-implement all my logic.

I’ve got a sensible-sized PHP file that looks much like the other apps you already have.

I’ve extracted out the CSS and Javascript out to other files to help keep my brain straight (and to take advantage of formatting tools!)

I did bump out the app configuration to a JSON file and extended the source with a “displayOptions” section just as a place to house meta data for graphing. Here’s an example (notably not using the heatpump_ prefix):

"HeatingEnergyConsumedRate1": {
    "displayOptions": {
        "label": "Space Heating Consumed",
        "color": "red",
        "precision": 2,
        "scale": 0.001,
        "scaledUnit": "kW"
    "type": "feed",
    "autoname": "HeatingEnergyConsumedRate1",
    "engine": 5,
    "optional": true,
    "description": "The power consumed by the heat pump for space heating in watts (W)"

One of the sections in the PHP might look like the following block. The Javascript uses it to feed the nominated data series from the Emoncms API into flot. It strangely ended up working a bit like the way dashboards work - I wish I’d looked at the dashboard code before I wrote all my code!

  <div class="placeholder_bound">
    <div data-label="Temperature" data-config-keys="FlowTemperature,ReturnTemperature,OutdoorTemperature,TargetHCTemperatureZone1" class="chart"></div>

I could go on, but I’m sure you get the gist of what it’s doing.

David Bowen

1 Like

Of course I’m fine with this being included or not with Emoncms. It’s really about what you would like to see happen Trystan.

1 Like

A question for @TrystanLea and @glyn.hudson. Seems like it to me.

Looks very interesting. If I ever get the chance to build another house it will definitely be powerd by a HP.

On a general level, what can you do to improve the COP?

Being able to control flow temperatures are an interesting thing, not just for HPs. Is this something built into the HP or something you have to control the temp to the HP?

I’d be interested in your method for the controlling algorithms. My UFH currently has a fixed flow temp. I’d love to be able to change that depending on outside temperature. AT the moment I have a very crude method of trying to prevent it overshooting and being warm enough by a specified time. SO far I have not found anything that is more sophisticated.

Hello david. Its interesting to hear about your work. I would be interested to know how you got your cop improvements. One really hard question to answer is that relating to intermittent/continuous heating. I have tried to get a better grip on the topic, but find that hard… when gauging ‘comfort’ rather than air temperature, it all gets more anecdotal. Anyhow, i feel that a lot of people are not aware that efficiency with HPs is so variable and that improvements are possible.

john cantor
01654 700115. 07894 431317

1 Like

Thanks for your comments Brian and John.

I’m building up to answering your questions by sharing my existing experiments but I’m also trying to build a platform for future experiments by myself and others, hence this question to Trystan. If it doesn’t become part of Emoncms, I’ll share it another way.

Somewhat teasingly, I do actually have hard data and algorithm implementations what will answer all your questions comprehensively.


Looking at the graphs, you seem to have some single data points for COP that are way out of range, hence the graph is basically flat, hiding the detail. These are surely anomalies and are maybe artefacts of the way the data is stored and processed? They only seem to occur when the pump is turning on or off. Would it be possible to remove these from the data, either as they are being stored (with some log warning) or before the data is displayed. That way, you’d be able to see much more detail from the COP graph.

Also, it looks as though you circulate your hot water, it gradually loses heat between operations of the HP. This seems to be a standard method for new builds with HPs. We are about to commission a new build and we’ve designed things so that all the bathrooms are close to the plant room, minimising any hot water runs. The kitchen sink is the only place hot water would be used that is some way from the plant room and we intend to put in a Quooker (instantaneous boiling/hot water) on the premise that with Solar PV and a battery system, this should be more cost effective than circulating the hot water to all points where it is needed with the inherent heat losses.

Not sure if anyone has experience of this with HP systems?

Having said all that, this looks like a great addition to the Open Energy arsenal. Thanks for posting.


1 Like

Thanks for your comments Simon.

single data points for COP that are way out of range

It does look that way, but they are correct - the amount of useful heat generated can sometimes be way higher than you’d expect. It’s a feature of the way I’m controlling the heat pump and helps me get a good average CoP. Of course it doesn’t help with the graphing which is why on my home-grown web-app I smooth it over five minutes. I haven’t done that in Emoncms yet.

it looks as though you circulate your hot water

Actually, one of the features of my new control algorithm is to not circulate the water because it wastes 200W driving the pump and sending heat outside. I actually turn everything off and let the radiators slowly emit the heat they’ve built up. After something like an hour I start everything back up. My control algorithm is working out when it’s a good time to do that. Notably I recently enhanced it to work out the “effective” outdoor temperature rather the actual one which is why Emoncms is interesting because I’ll be able to implement that more flexibly by consuming feeds for the weather station data rather than hard-coding the lookup that I have at the moment.

Your comment about the kitchen sink temp are quite valid. We’re having to wait a little longer for hot water to come through since we stopped using oil (temp=70C). However, our un-lagged DHW piping is helping to heat the house so I don’t mind those losses. In the Summer it will be pure waste, but by then we’ll have excess solar PV so it won’t bother me much.

1 Like

I suggest the sensors are close to the tank so the figure you are seeing ‘at rest’ is the temp of the tank - this is what I see on my boiler flow/return sensors. Mine are also a few degrees out - I’ll plumb in proper sensor pockets next time :grin:

I’ll open some more topics to chat about what’s actually happening with the heat pump.

I’m not ignoring you all but I’d like to keep this topic to be about adding the new app rather than what I’ve been doing with the heat pump.

Hope you don’t mind.

1 Like

Good point, I have the same on my heat bank - should have thought of that one! :expressionless:

1 Like

I’ll bite on this topic. Too juicy not to :grin:

I am impressed with the level of experimentation and monitoring that David has carried out so far. I personally don’t think enough work is carried out exploring heat pump control strategies but I know the reasons why though.

  1. Most people only care about heating if it’s not working, or if it’s costing them a fortune to run.
  2. Manufacturers’ want their ASHP box of tricks that performs as reliably as possible for as many types of installation as possible. It might not be the most efficient strategy they use, but it is often the most reliable.

With that in mind, and based on my day job as a tech support guy for a heating manufacturer, I’ll throw in my 5p worth :smiley: (All opinions my own). Whilst this may come across as negative, it is not meant to be. I just want to remind anyone wanting to experiment, to bear some important things in mind.

Now I did speak to @TrystanLea about this last year at the Fully Charged show where OEM had a stall. He mentioned how good it would be to be able to adjust the compressor running frequency / speed based on available excess solar PV energy, or to have an influence over the defrost cycle of an ASHP.

Whilst that would be great to be able to do this as an experimenter, no manufacturer would be happy doing this from a warranty point of view. Priority 1 of the software on a heat pump is to look after the heat pump. Priority 2 is to provide heat to the customer!

Every manufacturer has a different strategy around defrost cycles - it is their “secret sauce”, whether it be a time calculation around the time it took to complete the previous defrost, or based on ambient temp, evaporator temp and suction pressure or perhaps around CoP.

One thing for sure with a reverse cycle Air to Water heat pump, is that when the heat pump needs to do a defrost, it needs 2 things. Good water flow rates & sufficient thermal energy from the heating circuit & buffer tank. A lack of flow or insufficient thermal energy during a defrost cycle can cause water freezing & crystalisation in the condenser. Freezing water expands, potentially splitting the plate heat exchanger condenser. The software built into the machine will do everything it can to prevent this from happening. That might be faulting out with an error code if needed, or switching on a flow boiler / buffer tank immersion element to assist the defrost. Just be mindful of this if you are controlling a circulation pump controlling flow through the heat pump with your own on/off durations and pump speed. If the heat pump was expecting to control that pump, but in reality you are, it could cause trouble. A split condenser = a water filled refrigerant system. Not fun is an understatement!

Now I can see David has been experimenting by switching the heat pump demand on/off and slowly ramping up the water return set temperature rather than allowing the heat pump to do this quickly. I would imagine this results in the heat pump running the compressor at a lower RPM speed for longer and having a reduced cooling effect to the evaporator, potentially prolonging times inbetween defrosts & increasing CoP. What effect toggling demand on/off signals or altering the return temp set point on the fly to the heat pump makes to the defrost algorithm I don’t know (Never worked on Mitsi). One to perhaps think about.

On the topic of compressor running speeds and run times. The compressor manufacturer will specify a minimum and maximum running speed for inverter driven compressors as well as minumum run times. This is to ensure compressor longevity. Compressors contain oil and the compressor RPM and run time makes all the difference in making sure that oil gets to where it needs to go within the compressor. Generally speaking, compressor longevity is increased by reducing the number of starts per hour they have to perform. There is also a rule in the UK that should be followed to prevent upsetting the local DNO - no more than 3 compressor starts per hour. Most heat pumps have this inbuilt. Trying to override this may shorten the compressor lifespan and upset the DNO if they catch you (unlikely but still!)

Nevertheless, my inner heating geek rather likes seeing stuff like this. Would the gains in CoP efficiency be worth the time & effort spent seeking them? I would question it, but if you’re enjoying it and it doesn’t leave you with a broken heat pump, then I will enjoy seeing the fruits of your labour. :smiley:


Thanks for the kind words @moojuiceuk

There’s a lot of important points you mention there. You’ll see I’ve expanded on most of them over in the heat pump category:

For control I’m exclusively using commands their phone app can send. That way I can’t do anything they didn’t design for (and continue to support in the future). As a result my program just looks like a very very involved app user.

It would be nice to have finer-grain control, but (as someone who also supports other tech) I’m fine just using what they feel comfortable with.

Thanks again for taking time to think about these things and for sharing.

1 Like

I never realised you were using an API which is part of their app. Fair play :grinning:

For DHW prep, have you looked at taking an external weather forecast dataset for your area, then adjusting when DHW can be performed based on anticipated peak ambient temperatures that day? That might increase CoP figures a little bit for DHW prep. Of course this depends on when you have a demand for hot water, tank and pipe losses etc.

Also, are you heating your DHW tank to 60C every so often (say once a week)? I know of two different heating engineers who caught legionnaires and they wouldn’t wish it on their worst enemy. That hygiene cycle could be scheduled around the next highest forecast air temperature to aid efficiency perhaps?

I also wonder, from a CO2 national grid point of view what the merits would be to using a much larger thermal store and to heat that up based on when electricity is greener, by taking data from or charging the thermal store during periods of off-peak electricity. Yes, the air temperatures will likely be lower overnight when prices are lower = lower CoP, but would the CO2 output be reduced by using electricity that was greener to produce at those times? Just a thought :slight_smile:

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!!