Heat pump experiment review after two years

Solar gain is the heat generated inside the house through glazing (AIUI). So heat loss as an absolute will be different on sunny days to dull days from the same starting point. A wall on the sunny side will be warmer than a wall in the shade for the same air temperature so affecting the heat loss.

It is true that in a perfect environment, heat loss is the difference, but in the real world, there are many other dynamics as well as many different materials between those 2 temperature which will also be different where in the building you are.


With a heat pump it isn’t necessarily the case that it’s more economic to have an oversized unit to reduce ramp up times. The CoP of the heat pump is the biggest factor in energy use, and that depends on a whole host of interacting variables. In a well controlled ASHP system, you would expect that the CoP would be higher when re-heating in the evening for example, because, typically, the ambient will be slightly higher than re-heating in the morning. However, in either case the heat pump is often operating at a lower CoP at full load than at part load (with inverter drive units) and the room temperature will also affect the return temperature from the radiators which impacts on heat delta T etc etc etc… In practice the ASHP will often deliver a higher SCoP when it’s operated almost continuously or with only a small overnight temperature set-back. I’ve seen this in data from other people, but have not had a full winter with mine yet, so yet to determine the optimum operating mode.


1 Like

As @Rachel says, we’ve seen some good results from people running their sensibly-sized pumps smoothly.

Mine is probably the most oversized one we’ve got on the forum and that leads me to:

So I have the luxury of mine always being able to deliver whatever heat I ask of it, but it only runs smoothly when it’s about -3 °C which is pretty rare in the UK. I simply replaced my oil boiler with an ASHP with the same output.

Here is 2022-01-15 and it wasn’t very impressive at all - that’s a lot of kWh:

For comparison here it is when it’s warmer outside and it modulated down, but the house was getting too warm with 6kW input. Similar situation even with 4.67kW delivered.

So if I were looking at a “too big” heat pump I’d want one that could modulate down much further (in the case of my house, to about 2kW delivered) so I could run it more smoothly.

Having said all that, I feel @Jimbo1 is saying something that I feel too. Having the heat pump on all the time may be unnecessary and leads to you spending money running it overnight when you could potentially let the house just cool down gently if you have enough thermal mass. The occupants are in bed, under duvets, and the house doesn’t need to be kept warm for it’s own benefit. In one of my friend’s passivhaus new-builds they purposefully added a core of a large mass of concrete to stop the temperature oscillating too wildly. I haven’t looked into the research enough to have an informed opinion though.


@MyForest I’m just starting out monitoring our Ecodan ASHP and have found this thread extremely useful - thank you!

I’m struggling with the energy consumed / produced figures and have read about using the data from the device vs the reports in MEL Cloud from various posts at various times.

What have you settled on? And how is this set up in Emoncms?

And am I right that you store all the data in files before posting it to Emoncms?



Ooh, hi Chris, I responded a bit on the other thread, but I’ll expand a bit more here.

My setup is all in Docker using Python scripts. I’ve not published the MELCloud interaction because I don’t want to upset Mitsubishi and have them block our access (as we’ve seen BMW do this week).

So my stuff goes like this:

MELCloud → JSON files → EmonCMS

Particularly this allows me to go back in history and replay old data when I realise there is something interesting in there that I hadn’t realised.

Similarly for my weather station:

pywws → files → EmonCMS

I have a “post to EmonCMS” script for each thing I do. It allows me to choose other ways to process my data in the future and also means my EmonCMS instance is re-buildable if I ever stupidly destroy it.

It also means I have resilience to problems. For example, I actually broke my script when re-formatting it to answer your other thread and that simply meant the data wasn’t uploaded to EmonCMS. I just fixed the script and it raced through all the missing data and uploaded it.

Here is what my feeds look like:

You can see how it’s all built by looking at the device I created (with @Timbones’s improvements):

You can even import that into your EmonCMS if you want to.

All those sad looking “inactive” ones are the things that broke in November that I haven’t been able to repair.

If you want lots of data that you control you’re going to need to hook up to the physical device. If you’re willing to just have what you are given then you can use MELCloud. I’m not touching the physical device because of the MMSP rebate and warranty I have which I don’t want to jeopardize.

Let us know how you get along.


I have a similar setup to @MyForest, though I pull data from MelCloud and push it directly to EmonCMS without any intermediate files. I find that the fields in User/ListDevices has everything I need, including power measurements and flow temperatures.

I can mostly poll it every minute, though sometimes Mitsubishi’s server misbehaves and I need to drop to 2 minutes for a few days.

If you don’t have heat meters connected (aka MMSP) then some power numbers may be missing or estimated. Multiply HeatPumpFrequency (%) by maximum input power to get a good approximation of consumption. If you’re measuring these separately, then use those inputs insteads.

1 Like

Oh no @Timbones !

Are you saying HeatPumpFrequency varies for you?

OM actual G.

It’s working again!!!

I just watched it as I turned the heat pump on and off and the values changed each minute.

This is terribly exciting. I’m going to re-enable all my more exciting control algorithms that used that more fine-grained data.

Oh happy day!

1 Like

Well, that was short-lived.

It’s broken again now. MELCloud is returning whatever the value was as the hour changed.

I’ve been talking to multiple people at Mitsubishi last week:

Homeowner helpline

All of whom say they don’t know what to do about MELCloud.

I’m going to keep chasing them.


Thanks @MyForest and @Timbones.

There’s some more doors for thought for me here! I definitely like the idea of the intermediate files and then being able to reprocess them.

@MyForest does that mean all the energy data is back to being junk too?

The numbers for energy rates x60 > kWh still don’t look right for me:

Also, I do seem to have HeatPumpFreq but am only sampling every 5min:

How often are you requesting data from MELCloud? Sometimes, if you poll too often, they’ll only ever return stale data. I sometimes have to back off for a few days, as I described here in this other thread.

Chris, yep, the pump and energy consumption data is nonsense at the moment.

Tim, I’ll slow down my polling and let you know how it goes. The snag is that I’m using the up-to-date data to driving my “act” decisions. Hmm. Pondering.


Ah Tim that worked. I can see HeatingEnergyConsumedRate1 and HeatPumpFrequency changing for example.

Unfortunately those numbers are for the preceeding minute so if I don’t poll each minute I’ll only get a partial picture of what energy was consumed. Of course I could go back to looking at the aggregate number and doing a diff on that but it’s rather tedious.

At least now I’ll know a bit more about what to say to Mitsubishi.

I think I’ll try every two minutes and see what happens.

(if I sound exasperated it’s because I get data from my power usage every six seconds!)

Yep, that seems to be working but it’s clearly wrong. I’ll keep it running at two minutes and see if that runs smoothly.

I could concoct all sorts of theories about how it might be OK if I skip polling exactly on the hour or all sorts of nonsense. Let’s see.

OK, time to get some help. I’ve been chatting to Mitsubishi so this is my post for them to see what’s going on.

Hopefully they’ll take this news in the collaborative spirit we’re all espousing here, but I’ll apologise right here, right now if this ends up with the API being shut down.


As I’ve been able to get per-minute data for almost all of 2022, I wonder if there’s a difference in how we drive it?

This could be a wild herring, but is your script logging in to MELCloud once and using the ContextKey for the following requests?

Also, how often are you sending commands back to MELCloud? I’ve noticed that whenever I update heat pump settings via /Device/SetAtw, the following request for data from /User/ListDevices is sometimes stale. I think this is because SetAtw is returning the same data as ListDevices, tripping over the internal cache. With some clever programming, these could be combined into a single operation to set something and read the new state.

While I have been able to successfully control the flow temperature of the heat pump minute-by-minute with my own scripts, I’ve decided to leave most of the logic to the FTC. I’m only setting SetHeatFlowTemperatureZone1 (for refined weather compensation) and OperationModeZone1 (turns heating on/off based on whole house temperature). This means I’ve sending commands to MELCloud less often, and the heating will still work if my scripts break for some reason. (I’ve moved hot water control to a separate script).


I’ve been looking into this very deeply.

I have disabled the part of my scripts that send commands. The heat pump just ran and ran!

You can see my analysis. Specifically it appears it’s just the polling interval that changes the behaviour. I can’t find anything else that correlates with the troublesome behaviour.

@Timbones I’m going to have to dig into your script in more detail. Can I just confirm you are sure it’s actually getting per-minute data or are you scheduling it to run each minute? I ask because you’ve got that sleep in there which will shuffle it along a bit (but maybe the same bit each time).

This could be a wild herring, but is your script logging in to MELCloud once and using the ContextKey for the following requests?

I grabbed my context key a few years ago and have never changed it.

1 Like

Yes, it runs every minute, and almost always returns fresh data. I can’t remember why I added a 15 second pause before requesting the data. I think it was to allow fresh data to be sent from my heat pump to Mitsubishi. The data I get is a minute later than claimed anyway.

Thanks Tim.

It’s actually sorta fun seeing the 15-second offset in your graphs :slight_smile:

The data I get is a minute later than claimed anyway.

I assume you mean “older” which is what I’m seeing forever too. You can see it in the analysis results.

  • Your polling interval is often very short, often 10s or less. I would recommend at least waiting until 60s after Last Timestamp or after your previous request. Even without this server-side caching issue, you won’t get data any more frequently than 1 minute.
  • My script skips any data where Last Timestamp hasn’t changed. This doesn’t correlate with stale data though, so don’t rely on it for detecting outages.
  • There’s no data only one bit in your analysis where the polling interval was consistently between 60s and 120s: 12:23 to 12:26. It would be interesting to see how well it works with a minimum polling of 1 minute…