Heat pump experiment review after two years

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…

I wonder if a freshly acquired context key is needed to allow polling every 1 minute instead of 2 minutes. This might be what my script is doing without me realising, as it will randomly re-authenticate every few days… I’ll test this out next time the server misbehaves again.

Sadly I tried a new context key to no avail. Nice try though.

So many “well, it almost looks OK” :slight_smile:

I still think you’re polling too fast, even with a fresh key - 7 times in a minute in the middle there!

1 Like

I certainly am. It’s part of my chaos-monkey thing where I have to find the edge of the envelope of everything so I know how much I can rely on it. I lost my first two Lear jets that way.


OK @Timbones I’m going to put you on the hook here.

Mitsubishi have come back to me and indicated that the data is only updated every two minutes following the firmware update. They’ve shown me a screenshot from their spreadsheet with it being every two minutes.

Now that I’m polling every two minutes things are peachy.

However, it really genuinely looks to me as though you are getting data every minute:

I’m going to dig into what you are doing differently, but I wanted to check that you believe you really are getting different data each minute from User/ListDevices and that I haven’t just optimistically read your posts with rose-tinted glasses.

I should also purposefully ask which FTC you have.