I have an Ecodan 14kW fitted on 2019-09-30. It has the MMSP package installed which allows me to monitor it in detail.
The data is visible in MELCloud which is very useful because it means I do not need to physically open up the heat pump control unit to read the data.
I want to know how the heat pump is behaving so I can try out different control mechanisms. For example, when it's particularly windy I'd like the flow temperature to be a bit higher. I can achieve this by using my weather station to determine an effective temperature and then using that instead of the on-board weather compensation on the heat pump (which doesn't know it's windy.)
On 2021-11-26 I applied the firmware update to bring it up to "FirmwareAppVersion": 19000 but unfortunately that caused me some problems. Most notably the HeatPumpFrequency value became stuck. That field indicates what the heat pump is going to do in the next minute. I use that to tell me what the heat pump had been thinking in code such as was_demand.
Now, it's difficult to explain what I mean by "stuck", so I'll explain...
I normally poll MELCloud every minute using the User/ListDevices API endpoint. This is important because I want to see the most up to date information to make the most accurate decisions about what to do in my experiments. I do a lot of experiments, in fact I wrote an application to review experiments with a heat pump.
One example of an experiment I'm running is to turn the heat pump off so it uses less energy. That's quite important for my over-sized heat pump because it can't modulate down to my heat demand and so it cycles a lot if I don't intervene. In order to turn it off at a good time I need to know how the heat pump is behaving. In my non-MELCloud electricity monitoring systems I get updates every six seconds. When MELCloud is working well I can only get information every minute. I've created algorithms that can cope with that granularity. Here's an example where I turn off the hot water, and in fact the entire heat pump, if it's done a good job.
After I applied the firmware update I noticed that the fields in the JSON were not changing as they used to. In fact it appeared they were showing whatever the value was as time ticked past the hour. They showed the same value until the next hour when they would change to a new value for the next whole hour.
As you can imagine, that caused my control algorithms to become a bit upset. In fact it also meant the values I was uploading to EmonCMS were inaccurate so I got a misleading view of how much energy the heat pump was using. Although I can see the per-minute temperatures in MELCloud's reports, I can only see the energy usage aggregated per hour which is too coarse for interesting experiments. I really benefit a lot from the per-minute fresh data in the API when it's working.
After stumbling a bit and eventually realising things were going to stay broken I had to pare back my control algorithms to stop using HeatPumpFrequency which is why you don't see it in the heatpump-act scripts. Fortunately I had built up the control algorithms to be increasingly sophisticated so I was able to go back a number of generations and de-evolve it to just look at the flow and return temperatures. That's actually very similar to how my old oil boiler control used to work.
The energy usage calculations had to change too. I'm now using the EnergyCost/Report API endpoint and comparing how the energy usage changed from my previous record. It's rather clunky and my code trips up as it wraps around each hour.
Recently my friend Tim indicated that he's seeing values changing more reliably. As you can see, that would be very exciting for me. Unfortunately it didn't work out because going back to looking at those values each minute showed they were still mis-behaving after a while.
Right now I'm polling every two minutes. That is giving me varying numbers, but I'm missing the accurate energy consumption and so my review of the heat pump behaviour is still broken. When I try to increase the polling to be every minute the numbers returned by the API break after some time and become stuck for the whole hour.
Here's a clear demonstration of the gaps in the data - the green bars should not have gaps between them. Those gaps are caused by me not being able to poll more frequently.
This is very hard to say. I believe the heat pump is sending updated values to the MELCloud servers every minute. That makes me think it's not related specifically to the firmware update, but actually a change to the server-side code that went live around the same time.
As it happens I help run the Internet as my day job, so I have some ideas of the sorts of things that can go wrong. It's not really sensible to speculate much when I don't know how the services behind MELCloud are built. I feel it's impolite of me to poke at your servers to see what might be going on in there so I have not tried.
As a wild guess I'd speculate that the problem is in some caching in a service where it is trying to reduce the load by sending back the same data as before rather than going back to look for new data. I'd guess that my frequent polling is stopping the cache timing out so I keep getting the same value until the new hour causes a new cache key to be used or the cache hits a hard timeout. Here's a simple example where I've seen caching like this used, but it will very much depend on the technology stack you are using.
The most helpful thing for me would be to enable polling at a regular cadence to work smoothly with the firmware we're all running in the field.
I don't think it would make any sense for us to try and revert the firmware update, it happened almost a year ago, it's widely deployed and in fact I don't even think it's the cause of the problem - this still feels very much like a server-side problem.
In an ideal world we'd have a publicly supported API. It's actually a good design to have the MELCloud app and other clients use the same API. It also means you only have one API to support. The crux of the change would be to have support from Mitsubishi (or the third-party creating / running MELCloud).
Now that electricity prices are rising so severely in the UK it's become even more important that we help everyone get the best from their heat pump. I'm not suggesting for one moment that everybody will want to run these experiments in the way I'm doing, but results from these types of experiments will help people feel more comfortable using heat pumps in diverse ways. I'm doing my experiments in the open so everyone (potentially including Mitsubishi) can benefit, I'm not looking to monetize my work or to offer a service or device that interacts with the MELCloud API.
I'm also sharing this analysis here so it's clear what I'm asking for and so I don't overload your inbox with lots of image files.
David Bowen, 2022-09-27 00:18UTC
Update 2022-09-27 12:50UTC: I've been experimenting with altering the polling. It very much appears that the polling frequency alters the way the data behaves irrespective of all other variables.