Mitsubishi MelCloud Binding: looking for testers


Hi, I developed the binding for Melcloud. I’m looking for testers.

You can download the .jar at the following repo:

Let me know !!

Thanks, Luca

N.B. The binding it’s functional but missing optimizations and code cleanup, so anyone who wants to collaborate (especially developers) is welcome.



First thank you for creating the binding. I was waiting for a long time :slight_smile:
Anyway I installed the binding. I have two ecodan heat pumps. One local and one as guest access.


  • It instantly finds only 1st device in melcloud app(happens to be guest access pump). I removed guest access and I see only local heat pump now. (Needed to restart binding).

  • Added the Thing and created Items shown below

Event Log - from binding to trying to power Off as Power is only operation available:

OpenHab log - repeting every minute:

If you need any other help/info would be glad to help.


Hi !

It’s so difficult troubleshooting with so few informations…

The best option should be to have access to your melcloud and debug the messages.

Otherwise start openhab in debug mode (or lower the log level in debug mode the binding ) and send me it.

Let me know.!


Thank you Luca for this.
I have 4 AC units with wifi module, I can use Mitsubishi Mel Cloud app to manage them
I installed the binding and configured the thing " MELCloud main bridge". it’s show up “online” in the PaperUI page.
Then, from PaperUI I did a search for items, but found nothing. There I can’t see an option to add them manualy.
Now what? What can I do to add items?
Thank you.


binding should be auto discover AC devices…

But i need major info .

Can you send me detailed debug log file ?

Or, more better (if you want and if you can) give me a temporary access to your melcloud account (which you’ll delete when i’ll fix the problem) to know what happen and why it not detect your devices


Is this locally hacked or using the Mitsi servers?
I own an Airconditioning / refrigeration company and have recently put in to my house 5 zen wall mounts and was going to go down this route for local control :

However if you have done this then great

This binding is for use it with melcloud (much simpler !) , not locally

Hi luca

I completely get that, don’t want to rely on cloud servers though, especially in this trade when they obsolete things so fast.
Great work though.

1 Like

Initially was my thoughts… too…

But now, i must say no problem with mitsubishi cloud and, probably there are more pro thans cons.

Good luck !

Hello Luca, sorry for delay, I was “out of home” :smile:
No problem, please be carefully when access my devices.
send me a private message with your email to get the melcloud invitation.

Hi Luca,

thanks for providing this binding!
I installed it, added the bridge and entered my account.
The bridge shows online but no items are added to the inbox.

I enabled DEBUG for your binding and got following (these are 2 parts from 2 different tries):

2019-05-17 08:22:30.961 [hingStatusInfoChangedEvent] - ‘melcloud:melCloudServerBridge:d29ed18d’ changed from ONLINE to REMOVING
2019-05-17 08:22:30.966 [DEBUG] [ternal.handler.MelCloudBridgeHandler] - handleRemoval() ‘melcloud:melCloudServerBridge:d29ed18d’: ServiceRegistration {org.eclipse.smarthome.config.discovery.DiscoveryService}={, service.bundleid=268, service.scope=singleton}
2019-05-17 08:22:31.012 [DEBUG] [org.openhab.binding.melcloud ] - ServiceEvent UNREGISTERING - {org.eclipse.smarthome.config.discovery.DiscoveryService}={, service.bundleid=268, service.scope=singleton} - org.openhab.binding.melcloud
at org.openhab.binding.melcloud.internal.handler.MelCloudBridgeHandler.handleRemoval( ~[?:?]
2019-05-17 08:22:40.100 [DEBUG] [l.discovery.MelCloudDiscoveryService] - Starting MelCloud discovery scan
2019-05-17 08:22:40.104 [DEBUG] [l.discovery.MelCloudDiscoveryService] - createResults()
2019-05-17 08:22:40.106 [DEBUG] [l.discovery.MelCloudDiscoveryService] - bridge type
2019-05-17 08:22:40.108 [DEBUG] [ternal.handler.MelCloudBridgeHandler] - got Device List…
2019-05-17 08:22:40.116 [DEBUG] [l.discovery.MelCloudDiscoveryService] - finish list of devices
2019-05-17 08:23:28.000 [DEBUG] [org.openhab.binding.melcloud ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={, service.bundleid=268, service.scope=singleton} - org.openhab.binding.melcloud
2019-05-17 08:23:28.031 [DEBUG] [loud.internal.MelCloudHandlerFactory] - registerMelCloudDiscoveryService(): Bridge Handler - org.openhab.binding.melcloud.internal.handler.MelCloudBridgeHandler@fa3250, Class Name - org.eclipse.smarthome.config.discovery.DiscoveryService, Discovery Service - org.openhab.binding.melcloud.internal.discovery.MelCloudDiscoveryService@f75cab
2019-05-17 08:23:28.036 [DEBUG] [loud.internal.MelCloudHandlerFactory] - createThing(): LOGIN_BRIDGE_THING_TYPE: Creating an ‘melcloud:melCloudServerBridge’ type Thing - melcloud:melCloudServerBridge:fdfc84fd
2019-05-17 08:23:28.051 [hingStatusInfoChangedEvent] - ‘melcloud:melCloudServerBridge:fdfc84fd’ changed from UNINITIALIZED to INITIALIZING
2019-05-17 08:23:28.051 [DEBUG] [ternal.handler.MelCloudBridgeHandler] - Initializing MelCloud main bridge handler.
2019-05-17 08:23:38.056 [DEBUG] [ternal.handler.MelCloudBridgeHandler] - Initializing connection to MelCloud from Bridge…
2019-05-17 08:23:38.064 [hingStatusInfoChangedEvent] - ‘melcloud:melCloudServerBridge:fdfc84fd’ changed from INITIALIZING to UNKNOWN
2019-05-17 08:23:38.400 [DEBUG] [binding.melcloud.internal.Connection] - loginPage={“ErrorId”:null,“ErrorMessage”:null,“LoginStatus”:0,“UserId”:0,“RandomKey”:null,“AppVersionAnnouncement”:null,“LoginData”:removed}
2019-05-17 08:23:38.427 [DEBUG] [binding.melcloud.internal.Connection] - LoginClientRes assigned
2019-05-17 08:23:38.512 [DEBUG] [binding.melcloud.internal.Connection] - get response for list devices
2019-05-17 08:23:38.582 [DEBUG] [binding.melcloud.internal.Connection] - get response for list devices in json class
2019-05-17 08:23:38.589 [hingStatusInfoChangedEvent] - ‘melcloud:melCloudServerBridge:fdfc84fd’ changed from UNKNOWN to ONLINE

2019-05-17 08:51:43.440 [DEBUG] [org.openhab.binding.melcloud ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={, service.bundleid=268, service.scope=bundle,,} - org.openhab.binding.melcloud
2019-05-17 08:51:43.444 [DEBUG] [org.openhab.binding.melcloud ] - BundleEvent [unknown:512] - org.openhab.binding.melcloud
2019-05-17 08:51:50.815 [DEBUG] [org.openhab.binding.melcloud ] - BundleEvent STARTING - org.openhab.binding.melcloud
2019-05-17 08:51:50.819 [DEBUG] [org.openhab.binding.melcloud ] - BundleEvent STARTED - org.openhab.binding.melcloud
2019-05-17 08:55:48.302 [DEBUG] [org.openhab.binding.melcloud ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={, service.bundleid=268, service.scope=singleton} - org.openhab.binding.melcloud
2019-05-17 08:55:48.330 [DEBUG] [loud.internal.MelCloudHandlerFactory] - registerMelCloudDiscoveryService(): Bridge Handler - org.openhab.binding.melcloud.internal.handler.MelCloudBridgeHandler@1df621d, Class Name - org.eclipse.smarthome.config.discovery.DiscoveryService, Discovery Service - org.openhab.binding.melcloud.internal.discovery.MelCloudDiscoveryService@1568553
2019-05-17 08:55:48.333 [DEBUG] [loud.internal.MelCloudHandlerFactory] - createThing(): LOGIN_BRIDGE_THING_TYPE: Creating an ‘melcloud:melCloudServerBridge’ type Thing - melcloud:melCloudServerBridge:932248eb
2019-05-17 08:55:48.344 [hingStatusInfoChangedEvent] - ‘melcloud:melCloudServerBridge:932248eb’ changed from UNINITIALIZED to INITIALIZING
2019-05-17 08:55:48.381 [DEBUG] [ternal.handler.MelCloudBridgeHandler] - Initializing MelCloud main bridge handler.
2019-05-17 08:55:58.411 [DEBUG] [ternal.handler.MelCloudBridgeHandler] - Initializing connection to MelCloud from Bridge…
2019-05-17 08:55:58.422 [hingStatusInfoChangedEvent] - ‘melcloud:melCloudServerBridge:932248eb’ changed from INITIALIZING to UNKNOWN
2019-05-17 08:55:58.787 [DEBUG] [binding.melcloud.internal.Connection] - loginPage={“ErrorId”:null,“ErrorMessage”:null,“LoginStatus”:0,“UserId”:0,“RandomKey”:null,“AppVersionAnnouncement”:null,“LoginData”:removed}
2019-05-17 08:55:58.850 [DEBUG] [binding.melcloud.internal.Connection] - LoginClientRes assigned
2019-05-17 08:55:58.939 [DEBUG] [binding.melcloud.internal.Connection] - get response for list devices
2019-05-17 08:55:59.118 [DEBUG] [binding.melcloud.internal.Connection] - get response for list devices in json class
2019-05-17 08:55:59.127 [hingStatusInfoChangedEvent] - ‘melcloud:melCloudServerBridge:932248eb’ changed from UNKNOWN to ONLINE

I did remove the login part details, if you need them I’ll send them to you by PM.

If you need specific info from my MELCloud account just let me know.
Binding debuggin is new to me so I’m not sure what more info I can provide so do let me know if you need anything else.

Thanks in advance!

Hi Luca,

I found following link which describes the MELCloud API quite well:

I created a C# console app and was able to log in, list my devices (I only have 1 for now), get the device info and set the device (turned power on).
If you want, I can send you the JSON response for each request so you can debug on your end.

Hi Luca,

I browsed through your code and while I don’t know any Java, I think I know why it didn’t list my device.
The device list is set with following line:
deviceList = connection.getListDevicesResponse().getStructure().getDevices()
so it lists the devices in the building.
My device is in an area on a floor in a building so in the response it’s on:


while the code looks at


after moving my device up to the building, removing the binding and adding it again my device showed up when adding a new in Inbox and selecting the MELCloud binding.
I was then able to power on and off my device.

Gooba indicates in an earlier post that only 1 device is listed, this might be because the 2 devices were in a different building and the code seems to take the first building here:
Connection.listDevicesResponse = gson.fromJson(response, ListDevicesResponse[].class)[0];

This is a nice binding you created Luca, thanks!

Next week we should receive 2 more units for 2 other rooms so can test some more.

1 Like

@thewiep Thanks for your precious debug ! I studied API , knowing them quite well for what my binding need :slight_smile:

But , according your tip i missed one thing: How the AC units are placed on the Structure…

So now i’ve two possibility: update doc forcing users to put AC at specific level of structure, or manage it in binding… At moment i’ve no su much time, but in near future i’ll update the binding.

Can you open an issue on github repo explaining the issue for future memory ? Otherwise i’ll do it…

Thanks in advance for now, very useful !!

1 Like

HI ! for the issues you described, follow the tip from thewiep user

Where do you have your ac device in structure ? Read the post… and probably the fix is in it :slight_smile:

1 Like

You’re welcome, I know how it is to create something according to your need and have it work nicely until tested in other environments ;).

Sure, I’ll create an issue this weekend.
I think for now it’s more than enough that we can already use it even with a small restriction of needing have units at a specific level.

1 Like

Thank you Luca, thanks a lot Thewiep!!.
Yes, moving the devices on the root positition (no floor, no area) is working, devices are discovered inthe inbox.
One more note: melcloud app on the smartphone must be also closed.
In the next few days I’ll try to use it to check if everything it is ok.
Thank again, good job!

Grazie Luca, much appreciate.
I have a heat pump Ecodan and I can read the energy usage and the external temperature on the MelCloud website. Is it possible to access this data with your binding?

Tante grazie;)

Hi Luca,

I just created the issue on GitHub:

It seems the devices only need to be on the specific level when running discovery.
Once configured in openHAB they can be moved to any level of choice in MELCloud and they’ll still work in openHAB.

1 Like

Hi Luca,

thanks for this binding.
I installed it and its looks like it working great.
it’s pity that Mitsubishi don’t provide direct access locally to the device to avoid the cloud delay.