MelCloud plugin

[harrykausl]

Now I wanted to include the kWH devices to be shown in the counters tab. In the devices tab, the kWh are shown correctly, in the counters tab the value is not correct.

[Bastien13]

@Harry: thanks for reporting this.

The plugin was reading the energy counter from two different places, straight from the unit over the local network, and through MELCloud. These are two separate counters. The cloud one lags behind, because the unit only uploads its data every so often, and the local one is rounded to the nearest 100 Wh. Both were being written into the same Domoticz device, so every cloud refresh pushed the counter backwards. The Devices tab wasn't affected, since it simply shows the last value received, but the Counters tab works out the daily total from how much the counter has grown, and a backwards step wipes that out.

In version 2.2.4 of the plugin, each unit now has a single energy source. The local connection takes priority, the cloud only feeds the units the local one can't reach (cloud-only setups, or an unreachable Wi-Fi adapter). And the plugin no longer publishes a raw reading, it keeps a running total and only ever adds the active source's increases, so the counter can't go backwards any more. A final guard prevents any write below the total already stored.

To get it, you need to grab the latest version then restart the "MelCloud" hardware in Setup → Hardware, or restart Domoticz. Your existing counters are kept, the plugin picks up from the value already stored (as a reminder, the plugin's GitHub: https://github.com/Bastien1307/domoticz-python-melcloud).

[janvdberg]

I just got my airco yesterday and noticed there are two apps: MELCloud (looks old) en MELCloud Home (looks newer).

I installed and registered my unit with MELCloud Home but I now gather from this topic that these apps have two different API's.

I.e. this plugin doesn't work with MELCloud Home, that is correct?

[Bastien13]

I just got my airco yesterday and noticed there are two apps: MELCloud (looks old) en MELCloud Home (looks newer).

I installed and registered my unit with MELCloud Home but I now gather from this topic that these apps have two different API's.

I.e. this plugin doesn't work with MELCloud Home, that is correct?

@janvdberg: yes, that's correct. MELCloud and MELCloud Home are two separate platforms, with different APIs. This plugin only talks to the legacy MELCloud API, it does not work with MELCloud Home.

As for hardware, here's where the plugin stands. The local layer, which drives the units directly over the network, talks to the MAC-577IF-2E Wi-Fi adapter, the standard interface fitted on many MSZ units. Other adapters (MAC-567IF-E, MAC-587IF-E…) haven't been tested locally, but they work through the cloud path, and the plugin falls back to it automatically if the local one doesn't answer. In every case the unit has to be registered on the legacy MELCloud: that's how the plugin discovers the units on first start.

Making the plugin fully independent from the API, by detecting the units on the network by itself, is something I have in mind. It's doable, but it isn't done yet and I can't give a date. And even once it's in place, it won't change anything for adapters that don't speak this local HTTP protocol — which is most likely the case for the newer ones, the ones that go with MELCloud Home. I'd rather be clear about that than have you wait for a solution that may never come for your hardware.

What's the model of your Wi-Fi adapter? If it's a MAC-577IF-2E or something from that generation, you can simply create an account on the legacy MELCloud and use the plugin right away, whichever app you use day to day.

[janvdberg]

Thanks for the quick reply!

I have a MAC-597 IFB-E Wi-Fi interface.

[andrehj]

Hi,

I've been using the MELCloud plugin for a while (gysmo38's, later picked up by schurgan) and I've changed quite a bit of it for my own needs. It started as a couple of small fixes and ended up with me adding local control.

Basically the plugin now talks to the units directly over the network, through the MAC-577IF-2E adapter, without going through the Mitsubishi cloud. The cloud is still there as a backup if a unit stops answering locally, but it means it keeps working even when the internet is down, and commands are almost instant instead of waiting on the servers.
If you try it I'd be glad to hear how it goes, especially on multi-split setups or hardware different from mine, I only have two units to test with.

Hi Bastien13,

Thanks for the hard work!

I have a multisplit setup with
1x MXZ-2F42VF3 outdoor unit
2x MSZ-LN25VG2 indoor units
2x MAC-567IFB-E Wifi adapters (in the indoor units, both connected to the old Melcloud).

I would really like to have a non-cloud solution to control these AC's. At the moment I do not control them via Domoticz at all.

I do have a Melcloud script which logs into Melcloud every 5 minutes to retrieve info (a large json with lots of data), from which I only use some temperatures at the moment (this script was used to control my A2W Heatpump, but that one is now already controlled locally).

Two questions:
1. Will it be possible to use the MAC-567IFB-E for local (non-cloud) access?
2. Will the dual-split solution be supported?

If you want I can help you make the script work for the 567 adapter and/or multisplit. Maybe my json file can already help you? Please contact me via DM if that suits you.

[Bastien13]

Hi,

I've been using the MELCloud plugin for a while (gysmo38's, later picked up by schurgan) and I've changed quite a bit of it for my own needs. It started as a couple of small fixes and ended up with me adding local control.

Basically the plugin now talks to the units directly over the network, through the MAC-577IF-2E adapter, without going through the Mitsubishi cloud. The cloud is still there as a backup if a unit stops answering locally, but it means it keeps working even when the internet is down, and commands are almost instant instead of waiting on the servers.
If you try it I'd be glad to hear how it goes, especially on multi-split setups or hardware different from mine, I only have two units to test with.

Hi Bastien13,

Thanks for the hard work!

I have a multisplit setup with
1x MXZ-2F42VF3 outdoor unit
2x MSZ-LN25VG2 indoor units
2x MAC-567IFB-E Wifi adapters (in the indoor units, both connected to the old Melcloud).

I would really like to have a non-cloud solution to control these AC's. At the moment I do not control them via Domoticz at all.

I do have a Melcloud script which logs into Melcloud every 5 minutes to retrieve info (a large json with lots of data), from which I only use some temperatures at the moment (this script was used to control my A2W Heatpump, but that one is now already controlled locally).

Two questions:
1. Will it be possible to use the MAC-567IFB-E for local (non-cloud) access?
2. Will the dual-split solution be supported?

If you want I can help you make the script work for the 567 adapter and/or multisplit. Maybe my json file can already help you? Please contact me via DM if that suits you.

Hi @andrehj, thanks for your message, and for the offer to help.

To your second question: yes, multi-split is supported, it's my own setup. I have two indoor units on a single outdoor unit, and the plugin handles them separately while grouping consumption per outdoor unit. So you'd get one set of devices per indoor unit, plus one energy counter for the group.

To your first one, I don't know. The MAC-567IFB-E has never been tested locally, I only have MAC-577IF-2E adapters here. But it can be measured, and I've written a small script for exactly that: it looks for the units on your network and tests whether they answer the protocol the plugin uses locally. I'll send it to you by PM.

Good news either way: your adapters are registered on the legacy MELCloud, so the plugin will work for you right now through the cloud path, whatever the local test says. That's the case it was originally written for.

And yes, I'm interested in your help. If the local test comes back positive on the 567, I'll need someone to put it through its paces for real, since I can't do that here. Your MELCloud JSON could be useful too, mainly to check that I'm reading the right fields on a setup that differs from mine.

[manjh]

quick question, hoping for a simple answer.
I installed the plugin (the Bastien1307 version) and got it to work, I can control the unit, I tried switching on and off by changing the mode in "Off" and "Cold". The airco unit reponds accordingly.

But next step is to control it from a simple LUA script.
I update the selector switch while the unit is on, but when I switch it to level 00 it almost immediately goes back to status "Cold"

Code: Select all

commandArray['UpdateDevice'] = otherdevices_idx[testdev]..'|1|00'

variable testdev contains device name of the mode selector switch.

What am I missing?

[Bastien13]

quick question, hoping for a simple answer.
I installed the plugin (the Bastien1307 version) and got it to work, I can control the unit, I tried switching on and off by changing the mode in "Off" and "Cold". The airco unit reponds accordingly.

But next step is to control it from a simple LUA script.
I update the selector switch while the unit is on, but when I switch it to level 00 it almost immediately goes back to status "Cold"

Code: Select all

commandArray['UpdateDevice'] = otherdevices_idx[testdev]..'|1|00'

variable testdev contains device name of the mode selector switch.

What am I missing?

I don't do plain LUA anymore (I moved to dzVents), but in my old scripts I used to change a selector like this:

Code: Select all

commandArray[testdev] = 'Set Level: 0'

(0 = Off, then 10, 20, ... for the other modes — the level values shown in the device's edit screen.)

That should actually send the command.

[manjh]

Thanks. I will try that when I get home tonight.

[manjh]

quick question, hoping for a simple answer.
I installed the plugin (the Bastien1307 version) and got it to work, I can control the unit, I tried switching on and off by changing the mode in "Off" and "Cold". The airco unit reponds accordingly.

But next step is to control it from a simple LUA script.
I update the selector switch while the unit is on, but when I switch it to level 00 it almost immediately goes back to status "Cold"

Code: Select all

commandArray['UpdateDevice'] = otherdevices_idx[testdev]..'|1|00'

variable testdev contains device name of the mode selector switch.

What am I missing?

I don't do plain LUA anymore (I moved to dzVents), but in my old scripts I used to change a selector like this:

Code: Select all

commandArray[testdev] = 'Set Level: 0'

(0 = Off, then 10, 20, ... for the other modes — the level values shown in the device's edit screen.)

That should actually send the command.

Success! Took me 2 minutes to implement, and it works great! Thanks for the help...

[manjh]

Implemented yesterday, but this morning I discovered an error:

Code: Select all

2026-08-21 11:07:56.342  Error: Airco: Call to function 'onMessage' failed, exception details:
2026-08-21 11:07:56.343  Error: Airco: Traceback (most recent call last):
2026-08-21 11:07:56.343  Error: Airco:   File "/home/pi/domoticz/plugins/domoticz-python-melcloud/plugin.py", line 825, in onMessage
2026-08-21 11:07:56.343  Error: Airco:     _plugin.onMessage(Connection, Data)
2026-08-21 11:07:56.343  Error: Airco:   File "/home/pi/domoticz/plugins/domoticz-python-melcloud/plugin.py", line 446, in onMessage
2026-08-21 11:07:56.343  Error: Airco:     if unit['id'] == response['DeviceID']:
2026-08-21 11:07:56.343  Error: Airco:                      ~~~~~~~~^^^^^^^^^^^^
2026-08-21 11:07:56.343  Error: Airco: KeyError: 'DeviceID'

Commands to switch on/off donot work, no error shown.
So I turned on all loglevels in the hardware entry. After this commands are processed again... problem disappeared. But I always learned that whatever problem disappears by itself, may return by itself at any moment...
Any ideas as to what may be the root cause?

[Bastien13]

Implemented yesterday, but this morning I discovered an error:

Code: Select all

2026-08-21 11:07:56.342  Error: Airco: Call to function 'onMessage' failed, exception details:
2026-08-21 11:07:56.343  Error: Airco: Traceback (most recent call last):
2026-08-21 11:07:56.343  Error: Airco:   File "/home/pi/domoticz/plugins/domoticz-python-melcloud/plugin.py", line 825, in onMessage
2026-08-21 11:07:56.343  Error: Airco:     _plugin.onMessage(Connection, Data)
2026-08-21 11:07:56.343  Error: Airco:   File "/home/pi/domoticz/plugins/domoticz-python-melcloud/plugin.py", line 446, in onMessage
2026-08-21 11:07:56.343  Error: Airco:     if unit['id'] == response['DeviceID']:
2026-08-21 11:07:56.343  Error: Airco:                      ~~~~~~~~^^^^^^^^^^^^
2026-08-21 11:07:56.343  Error: Airco: KeyError: 'DeviceID'

Commands to switch on/off donot work, no error shown.
So I turned on all loglevels in the hardware entry. After this commands are processed again... problem disappeared. But I always learned that whatever problem disappears by itself, may return by itself at any moment...
Any ideas as to what may be the root cause?

Which version are you running exactly? The line numbers in your traceback (onMessage at 446, the wrapper at 825) don't match my fork, it looks like you're on the original plugin rather than mine.

To check from the UI: I put the version number in the module name itself. Under Setup > Hardware, the hardware type dropdown should read "MELCloud plugin v2.2.11". If you only see "MELCloud" with no version number, you're most likely on the old plugin.

You can also check from the command line:

Code: Select all

grep -m1 'plugin key' /home/pi/domoticz/plugins/domoticz-python-melcloud/plugin.py
wc -l /home/pi/domoticz/plugins/domoticz-python-melcloud/plugin.py

My version shows name="MELCloud plugin v2.2.11" and is 2258 lines long. The original one is around 800.

To switch to my fork (both plugins share the same MELCloud key, so they must not coexist in plugins/). Back up your Domoticz database first, the old plugin folder is moved aside rather than deleted so you can always roll back:

Code: Select all

sudo systemctl stop domoticz
cp ~/domoticz/domoticz.db ~/domoticz.db.backup-$(date +%Y%m%d)
cd /home/pi/domoticz/plugins
mv domoticz-python-melcloud ~/melcloud-backup-$(date +%Y%m%d)
git clone https://github.com/Bastien1307/domoticz-python-melcloud.git
sudo pip3 install pycryptodome requests   # optional: local control
sudo systemctl start domoticz

On recent Raspberry Pi OS releases pip3 install fails with externally-managed-environment (PEP 668). In that case use:

Code: Select all

sudo pip3 install --break-system-packages pycryptodome requests

Your existing hardware and devices are kept (same plugin key), you don't have to recreate anything. pycryptodome and requests are only needed for local control of the Mitsubishi units, without them the plugin runs cloud-only.

[manjh]

You are quite right, the hardware entry did not show your version number! I donot understand how that happened, since when I installed yours, I physically removed the old plugin and installed the new...
But all right, some things are not necessary to fully understand.
I followed your instructions and now have MELCloud plugin v2.2.11.
Next step is to do some testing, but I am confident.

Edit: just noticed a quirk, the status messages are now in French....

[manjh]

OK, so beside the language of the logging messages, I tested the interface and commands work great!