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.
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!)
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 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.
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.
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 dataonly 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.
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.
