OpenEnergyMonitor Community

Don't apply the firmware update to your Ecodan FTC5 (yet)

Yesterday I was running:

“FirmwareAppVersion”: 17000,

and I took the update today and am now running:

“FirmwareAppVersion”: 19000,

This is the first time I was offered a firmware update.

I can still alter settings on my heatpump using the API, but the usage data is looking stale.

Hopefully I can prove this is a false alarm.

ofc this is a really good reason not to rely on external parties (in this case the WiFi module on the heat pump).

I’ve tried a lot of things and none of them are helping.

I’ve lost access to most of the useful data in the payload and when it does appear it stays stale for huge amounts of time.

Ironically it seems the device itself is responding to MELCloud commands faster than it was before.

At this point it looks as though they’ve stopped updating the superfluous parts of the datagram which they don’t need for their UI. However, those things were the interesting parts to my algorithms.

To give you and idea of how bad it gets if you update the firmware, I can no longer see the flow and return temps.

@TrystanLea be careful out there.

O no, that’s a pain!

Have you seen by any chance all the work out there by others reading from and controlling their mitsubushi equipment including the Ecodan via the CN105 connector that the Melcloud box uses? Im going to try this on my heat pump very soon, looks really promising!

Here are various github repositories and discussion threads on the topic:

GitHub - SwiCago/HeatPump: Arduino library to control Mitsubishi Heat Pumps via connector cn105

Hacking a Mitsubishi Heat Pump / Air Conditioner - nicegear blog

Mitsubishi-CN105-Protocol-Decode/community - Gitter

GitHub - m000c400/Mitsubishi-CN105-Protocol-Decode: Documentaion of Mitsubishi CN105 Protocol of Ecodan Air Source Heat Pumps

GitHub - BartGijsbers/CN105Gateway: ESP32 based MQTT gateway for the CN105 protocol based Mitsubishi Heat Pumps (FTC5)

MiniSplitPi — The Mini-Split Raspberry Pi Web Controller

Thanks @TrystanLea , John Cantor pointed me to those too (because you pointed him to them :slight_smile: )

As I’m on the RHI thing I’m trying to do this without tinkering with the hardware at the moment.

I was also hoping that folks such as @muhrix would be able to do this via the web too.

I’ve looked around all the other open source interactions with MELCloud and they are all impacted in the same way. Most of them aren’t bothered because they don’t go after the minutiae that I’m chasing in the data structure.

I’ve contacted Mitsubishi and haven’t got anything back yet.

I’m trying to go via my installer now.

I have looked into the data from the “Reports” section of MELCloud. That is giving me per-minute flow and return which is lucky because that’s the backbone of my algorithm, but everything else is per-hour which is practically useless.

On the bright side, the heat pump is tootling along and keeping us warm, it’s just running far too much of the time and is clearly using more energy than it should. Yesterday it used 30kWh / £4.80 whereas a similar day like that early in the month used 20kWh / £3.00.

1 Like

Oh that’s annoying - but not the first time manufacturer changes affect an unsupported API (I had similar issues on at least two other, unrelated, platforms).

I haven’t got my ASHP yet (because Mitsubishi are struggling with supply), but I’m trying to do the prep work.

I was already concerned about having to go via Melcloud because that would rely on my internet connection (which is unreliable).

I came across this repo:
I loved the level of reverse engineering the author went through, though not sure if the repo is actively maintained or if the code works (I can’t test anything yet).

A local serial communication would be preferable to me in the longer term, but the convenience of using the system out-of-the-box as @MyForest does, makes that my number 1 choice too.

If the per-minute data appears on the dashboard/live data/report with per-minute granularity, then there is hope.

1 Like

Thinking about it, surely the EMP3 (MMSP) kit is streaming per-minute data to Melcloud servers, so sniffing the stream (like in the meldec repo) may be one way to consume the data locally.

Question to @MyForest whilst you cannot get per-minute readings, does the writing still work? As in, are you still able to change target temp (for CH and DHW) and flow temp?

Yep, I’m still able to alter the settings, but the algorithm was using the per-minute data to decide which commands it wanted to send. Seeing things at hour-level granularity is pretty hopeless. In fact I was hoping to get faster updates, not slower!

Yep, I could hack the traffic like meldec, but I’m trying to keep it simple (and failing).

I had already cracked open Wireshark in desparation on Monday and then put it away again.

I’ve contacted my installer and they are going to put me in touch with the Mitsubishi representative to see if we can get some progress.

Clearly I can do a bunch of things to help myself here, but I’m trying to get to a point where this is easy for other people too so I’d prefer Mitsubishi supported what we’re trying to do, especially in the spirit of the MMSP intention.

I’m in touch with the Mitsubishi representative now and they sound keen to understand my problem.

Unfortunately I had to phone a landline for the helpdesk and I got stuck in a queue and had to go to work so couldn’t hang on to talk to the technicians.


The per-minute energy consumption data is back.

I don’t know why.

Things are working beautifully again.

I’ll keep chatting to Mitsubishi and see if the new world we find ourselves in makes them more amenable to supporting these types of use cases.

If I were a cautious person I’d still hold off the firmware update if I were you. Maybe devices on the old firmware will stop working at some point? I don’t know at the moment.


As a gift of schadenfreude, here’s what a debacle looks like.

I updated my firmware around noon on the 22nd.

After a while I was able to patch in the flow and return temps at minute-granularity by getting them from another part of the website.

You can see my lovely ebb-and-flow pattern changed into some more grisly cycling on and off about 5 times an hour versus my typical 15 times per day. Admittedly the flow temp was too low, but that was all part of my algorithm being a bit daft and me having stupid amounts of work to get done elsewhere at the moment so not getting it fixed.

Even with the total chaos, the humans still didn’t make any comments about being uncomfortable and there was sufficient hot water.

I can’t tell exactly how the efficiency changed because I lost the power readings. From the MELCloud interface you can see the CoP went below 3 for the first time on Monday when I lost control.

It seems unfair to say that though because the weather also got colder this week.

However, even when it was colder on the 3-5th November the well-informed algorithm’s behaviour delivered a CoP above 3.


Maybe I should trip the algorithm up again by making it less well-informed but also carry on capturing the detailed energy usage. Oh to have more time to play.

Anyway, hopefully this will encourage people (including me) to double-down on resiliency and graceful degradation.

1 Like

Well, the adventure continues.

This is news…I honestly don’t know if this is good or bad.

We had a power cut around 08:20 and my daughter turned the power back on at 08:40.

It looks as though we’re back to missing the detailed data again. I honestly don’t know why. Of course I’m going to see what’s up with the WiFi interface. If it simply wasn’t working we’d get no data, so that’s not the problem.

I could make all sorts of wild speculations about the servers only choosing to expose the detailed data after 2 days of solid inputs or all sorts of things. I can’t provide any evidence to back up any wild theories so far so I’ll keep them to myself.

[Edit: Seeing those steps at exactly 09:00, 10:00, 11:00…suggests that the communication is working, but the data being returned from the server has gone back to hourly. Notably, I can see the per-minute changes on the MELCloud reports website, just not in the ListDevices endpoint]

[Edit2: So potentially the “use hourly granularity” is a consequence of “the interface stopped reporting” (which could be an upgrade or a power cut). We’ve had power cuts before and I haven’t seen this behaviour, but it might be independent of the firmware upgrade, it could just be some server behaviour they implemented at some time in the last few months]

1 Like

Thanks for the updates @MyForest interesting following along!

Catching up with the latest messages…

I got excited with the good news, but I’m now puzzled by this behaviour.

@MyForest if you can see the data in Melcloud, your WiFi interface is working (sending the data).

For some reason, their servers are not responding to your API queries.

The power cut is an interesting data point. The fact that it started working again is also relevant.

I’m glad that you are in touch with Mitsubishi - I’d expect they should be able to share an explanation.

IIRC you are using your own implementation to fetch data. Have you tried the pymelcloud code to see if it makes a difference?

Until I have my own hardware, I don’t think I can be much help other than speculating.