Mitsubishi Electric Kumo Cloud Binding (MHK2)

Add-ons Bindings
1

Hello all,

I’ve put together a first cut of a binding that integrates with Mitsubishi Electric’s MHK2 wireless controller for split systems. These are systems that allow access using Mitsubishi’s Kumo Cloud mobile app. I’ve been testing it out with the unit installed on my SVZ/MVZ series ducted air handler and the results are promising. It should work with other systems using this controller connected to the CN105 port on the air handler or indoor unit.

Supported features include fetching current mode, set points, temperature, humidity, fan speed and vane direction. Mode, set points, fan speed and vane direction can be set as well.

The binding discovers devices by connecting to a Kumo Cloud account. Internet access is only required for initial discovery, all control happens over a local API. The binding can be configured on a per-account basis to keep associated device ip addresses synced if they happen to change, such as a DHCP server handing out a different address. I do recommend, however, that each device be given a static address using a DHCP reservation. As a good IOT security practice, I also suggest blocking internet communication with the device at a firewall once everything is set up, for extra access control (though obviously this would prevent using the Kumo Cloud app for control).

Different Mitsubishi units support different features, and the binding currently discovers and accomodates most of those supported by a given unit (ie, is heat mode available, fan speeds, etc). There are a few TODO items related to this but they are mostly related to hiding channels and limiting temperature ranges and should not affect basic operation. These devices commonly have somewhat sketchy reliability, so the binding does attempt to retry requests in case the WIFI signal is poor or the module is restarting itself.

I’ve prepared a test release (tested on openhab 4.0.2) if anyone would like to try it out. Comments and suggestions are always welcome!

Download location:

http://bill.welliver.org/dist/openhab/mitsubishikumocloud/

Installation and setup:

Simply drop the jar in your openhab addons/ directory. The binding should install itself automatically.

Add a Mitsubishi Kumo Cloud Account thing from the inbox and provide your Kumo Cloud username and password. The binding should then log in and discover any devices associated with your account.

If your devices do not have static (reserved) addresses, you should make sure the option to keep addresses updated is turned on. This will cause the binding to periodically check the cloud account to see if a given device’s address has changed.

Any discovered devices will be added to your inbox. Simply create things and then use whatever process you normally would to set up your things for your home.

Notes:

  • I’ve not tested this binding on any of the vast array of split systems that Mitsubishi supports for Kumo Cloud. I’m hopeful that things will work, but your mileage may vary. I’m certainly commited to getting things working wherever possible.

  • The API this binding uses was reverse engineered by a number of people, and has not been made officially public by Mitsubishi Electric. It could be changed in the future and may not be possible keep the binding working. For this reason, it’s probably a smart idea to not allow your devices to communicate with the “mother ship” in case a future update breaks things.

  • Because of the way the authentication information is provided for each device, its not really possible to use config files to create individual devices.

Current TODO list:

  • handle station (headless) devices properly
  • confirm working with devices other than MVZ/SVZ
  • dynamic channel creation based on supported features
  • handle temperature limits advertised by device
  • RSSI channel for signal strength
2

Installed and everything is working great. I have been using Home Assistant and MQTT to control my units, but this great. Thanks for the work, and I’ll continue to watch and provide feedback as necessary.

I noticed that the Humidity Channel is not populating. I believe that is only available with the remote sensor Mitsubishi sells (PAC-USWHS003-TH-1). I have one connected to one of my thermostats (it works in the HA integration). No big deal, small price to pay to have a working binding.

The HA binding has a regular disconnect cycle, and the general consensus over there was that the Mitsubishi WiFi implementation was garbage. I’ll watch for that as well. But so far this is very stable!

This is on 4.1.0.M1.

3

Hi-

Thanks for the fast reply! Glad to hear it’s working so far. I’ve got a wireless thermostat (an external thermostat is mandatory for ducted air handlers), and it’s got a humidity sensor, but the humidity doesn’t show up in the same place as the temperature, so it’s possible we need to look other places for yours. Also, it’s likely that there’s a temperature sensor in the unit itself (certainly for non-air-handler units. I’m sure we can get humidity working if you can give me a little more detail about what your setup looks like (assuming you /don’t/ have a wireless thermostat). If you set the logging of your binding to DEBUG or TRACE, you’ll get a bunch of output in the logs that shows the data from the unit. If you DM me with that (it’s potentially a lot of data), I might be able to figure out where to pull the info from.

log:set TRACE org.openhab.binding.mitsubishikumocloud

And yes, their software is pretty terrible. Send it a bad command, and it basically crashes and reboots, etc.

Thanks again for the feedback!

Bill

4

This is fantastic and I am thrilled to have automation on my new HVAC system. (My old furnace was controlled with an ecobee thermostat, and I had been very much missing the ability to integrate HVAC changes into my home automations.) Thank you so much!

Do you know if there is any way for the binding to see if a hold has been set on the thermostat? I’m moving all my programming off of the kumo app and onto my openHAB/Node-RED setup. But I would like to be able to allow the thermostat hold to override the automated schedule coming from Node-RED.

5

Hi!

Glad to hear it’s been useful. I imagine that if you’re able to see that status in the Kumo app, it should be possible to expose that in the binding. I’ve not set up any schedules (or really used the app in any meaningful way) myself, so I might need you to do a little legwork if I’m not able to figure this out on my own. Do you just want to know that a hold is active or is there more to it than that?

Looking around, I do see a section of data when querying the mhk2 (the actual box that plugs into your indoor unit):

                  "mhk2": ([ /* 7 elements */
                      "auto": ([ /* 4 elements */
                          "coolSetpoint": Val.null,
                          "heatSetpoint": Val.null,
                          "owner": "none",
                          "status": "inactive"
                        ]),
                      "connected": ([ /* 6 elements */
                          "indoorAir": Val.false,
                          "indoorAirBattery": "unset",
                          "outdoorAir": Val.false,
                          "outdoorAirBattery": "unset",
                          "thermostat": Val.true,
                          "thermostatBattery": "ok"
                        ]),
                      "dr": ([ /* 2 elements */
                          "event": "none",
                          "override": Val.false
                        ]),
                      "hold": ([ /* 2 elements */
                          "adapter": ([ /* 2 elements */
                              "cancelMHK2": Val.false,
                              "endTime": 0
                            ]),
                          "mhk2": ([ /* 2 elements */
                              "cancelAdapter": Val.false,
                              "endTime": 0
                            ])
                        ]),
                      "info": ([ /* 3 elements */
                          "firmware": "1.1.0",
                          "model": "MHK2",
                          "serial": "220LBL009090"
                        ]),
                      "schedule": ([ /* 2 elements */
                          "enabled": "disabled",
                          "owner": "adapter"
                        ]),
                      "status": ([ /* 3 elements */
                          "indoorHumid": 51,
                          "outdoorHumid": Val.null,
                          "outdoorTemp": Val.null
                        ])
                    ])

So my guess is that data will change if you’ve got a hold enabled. I’ll try to play around a bit and see if I can figure it out… might take a few days but ping me if I don’t update here by next weekend.

6

Thanks for looking into it! Having the thermostat still function as expected is going to be critical to maintaining the Family Acceptance Factor. Let me know if you need me to try anything out or pull any logs or something.

7

Ok, I was able to set up a schedule and there’s a flag that says a schedule is running. Once the clock passed an “event”, those settings kicked in and the wireless thermostat says that a schedule is running.

How are you initiating a “hold”?

I see that there’s a “holiday hold” option on the wireless thermostat, but nothing equivalent in the Kumo app. If I change a setting in the app while the schedule is running, it just changes and there doesn’t seem to be any indication that the schedule is being overridden (in fact it’s a bit more confusing because there’s an icon indicating a program is running but no indication that the current settings aren’t what the program specifies). That is, the data still says that the schedule is running, but also says that the mode is, say off, or whatever.

8

If a schedule is running and I change the setpoint on the thermostat, it automatically sets a temporary hold and says"hold until xx:xx"
I can then change the length of the hold if I want, or I can set it to “permanent hold”.
While the hold is active, scheduled events will be ignored.
I’d like to know if a hold is active so that I can also block other scheduled/programmatic changes coming from openHAB.

9

Perfect… thanks! I was able to put a hold on the program and it showed up in the Kumo app. I can also see in the app the “hold until” time. So that’s great. I haven’t played with “permanent” or “holiday” holds, but I’m hopeful that they show up as just longer time periods for the hold. I don’t have a lot of time right now to do more experimenting, but I think that’s a good starting point.

I guess the question now is how should we surface that information? A channel that’s a true/false for a hold and one for the hold until date? Or maybe something else?

Thoughts and suggestions are welcome!

10

Sweet! The true/false item for hold status is perfect. The item with the hold time could probably be useful, too, but is less important.

11

I’ll try to put together a new version of the binding with a few channels, “schedule running”, “hold active” and “hold until” or some such. Might be next week until I get some free time, but I’ll post here when I have something to test.

1 Like
12

Thanks, that’s great!
One off these days I should really look into learning coding well enough to help out with these things myself.

13

Hi-

I took a little time and put together a new version that exposes schedule and hold state through 3 new channels. I’ve done a little testing here and it seems to work. If you could take a look and see if it behaves as expected for you, that’d be great.

Note that you’ll need to delete your heat pump thing (from the Thing’s page in the UI) and allow it to be rediscovered in order for the new channels to be listed. If you make sure to name the recreated thing the same as the old one, your existing items should link back up automatically.

You can find a version compiled for 4.0 here:
http://bill.welliver.org/dist/openhab/org.openhab.binding.mitsubishikumocloud-4.0.1.jar

And a version compiled for 4.1 here:
http://bill.welliver.org/dist/openhab/org.openhab.binding.mitsubishikumocloud-4.1.2.jar

14

Nice. I’m in the middle of a construction project on my house this week, but when I have a enough time to make sure I don’t accidentally break my existing setup, I’ll give it a look!

15

I tried installing the new version, but it’s not starting. When I try to start it in the console I get this error:

Error executing command: Error executing command on bundles:
        Error starting bundle 292: Could not resolve module: org.openhab.binding.mitsubishikumocloud [292]
  Unresolved requirement: Import-Package: org.bouncycastle.util; version="[1.76.0,2.0.0)"
16

I went back to the previous version for now.

Another issue I’ve noticed over the last week or so is that I’m getting a LOT of Communication Errors.
The kumocloud device appears to have strong wifi signal, and it’s on a 2.4GHz-only Access Point. But even though I never notice connectivity issues in the kumocloud app, when I look at my openHAB logs, I see messages like this:

2024-05-28 16:53:26.410 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mitsubishikumocloud:device:KumoCloud-House:3634P0087100269F' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Request unsuccessful.

It goes offline about 3 to 6 times per hour, with no discernable pattern. It usually stays offline for 30 seconds to a couple of minutes.

This wouldn’t be too big of a deal, since I’m not constantly trying to change HVAC settings.

However, there is one major issue: When when it comes back online, the system temp gets reported as somewhere around 57F-59F, and then less than a second later updates to the correct temperature. And I’ve noticed that whenever this happens, the heat kicks on and runs through a cycle, even though it’s not actually needed. It sees that brief moment of “too cold” and starts the heat cycle, but then immediately ramps down the actual heating when the real temp gets reported, and just finishes whatever minimum cycle-length Mitsubishi has set for it.

Anyway, I’m not sure if this is a binding issue or a kumocloud issue, but I don’t think it was happening before I used this binding. I’ll have to do some experimenting to see for sure.

17

What version of openhab are you running? It’s likely a mismatch caused by a difference in the version I compiled the binding for and the one you’re running.

18

I’m running the 4.1.2 release build, and installed the 4.1.2 version that you posted.

Now I’m back to the older version of the binding, which looks like it’s for 4.0.2, but works other than the communication errors.

19

So, the problem you’re describing is pretty common. Apparently what happens is that after so many requests to the device, it runs out of memory and reboots. It probably doesn’t happen when you’re using the app because it’s only making requests of the device when you’re actually using it.

There isn’t really any rhyme or reason to it, I think it’s just that Mitsubishi did a bad job with the firmware.

One thing you could try doing is changing the refresh interval (the default is 30 seconds). This would cause it to make requests of the device less frequently, which /might/ avoid the problem at the expense of having the current values be less up to date (changes made in openhab are always sent immediately).

Frankly, if I’d known that my installer was going to go this route, I would have stepped in, as my ducted install has fairly regularly had problems with changes at the thermostat not registering (such as turning the thing off and it just keeps running). I looked into replacing it with a wired thermostat, but they’re incredibly expensive ($300).

An alternative approach would be to get a “CN105” splitter and then use that to plug the alternative controller that talks directly to the indoor unit via connector 105. If you search here, you’ll find lots of detail on that. You only need a splitter if you want to control the unit with more than one controller (wired thermostat, Kumo Cloud, or the diy setup I described before). If you have a unit that uses an IR remote like a wall mounted split, you could just swap the Kumo Cloud device with the diy unit and just control it via openhab completely.

I’ve noticed instances of odd temperatures being reported intermittently; I think it’s because it’s the default temperature and it reports that before it gets the actual temperature from the sensor. Again, I consider this the result of terrible firmware.

I’d be happy to collect more information from you in the hope that the problem can be worked around. If you send me more info about your installation (model numbers, etc), I can combine that with my own findings… I might do a little more digging around the CN105 based solutions and report back.

20

Thanks, I figured it might be a Kumocloud problem. Everyone says it’s terrible, but I was hoping the problem was just the awful app/interface and I could mostly bypass having to deal with that. (My installer actually recommended against it, said that Mitsubishi is working on a new version and I should probably wait for that.)

Anyway, I have the SVZ-KP36NA ducted system, with an additional mini-split head unit in the guest/rec room. I bought a kumocloud adapter for the mini-split head unit, but haven’t installed that one yet. So far, I’m only set up on kumocloud with the ducted unit.

The ducted system was initially installed with just the MHK2 thermostat, and it worked fine with that. I just added the kumocloud connector about six months after the install, when I decided I’d rather have some buggy/crappy WiFi control than no WiFi control at all. I had also considered the Aidoo unit, but I found the kumocloud adapter cheaper, and figured the native Mitsubishi solution was probably more reliable. Whoops!

Maybe the best option at this point is just to get by with what I have until Mitsubishi releases whatever updated hardware/software for kumocloud2 that they’re working on.
Until then, I’ll update the refresh interval and see if that changes anything.