Mitsubishi Kumo Cloud Integration

parkercat · January 23, 2021, 6:33pm

All communication with the indoor unit is in celsius. The Kumo component advertises to HA that its native temperature unit is celsius, so HA itself (the base climate component) handles all conversion.

I already attempted to fix this by rounding the temps to 1 decimal place without success. It’s possible that rounding to the closest 2/10ths or 5/10ths would do it. Or switching to truncation rather than rounding.

The most likely full fix, though, is for someone to add some logging to the Kumo integration (or pykumo) of the celsius setpoint reported by the unit, then step through the allowable range with the remote or app and record what the unit reports for each fahrenheit step, for use as a conversion table. Then either advertise fahrenheit and handle all conversion ourselves using this lookup table, or quantize the celsius setpoint temperatures to those in the table.

Or switch your locale to use celsius, in both HA and KumoCloud app

Or stop using the KumoCloud app. As I said I’d be happy to look at a pull request but I’m not motivated to do this work myself.

masaq · February 28, 2021, 3:59pm

Hola, newbie to homeassistant here with some (basic) questions about this integration. I have a bunch of mitsubishi heatpumps. I was able to use an arduino (https://chrdavis.github.io/hacking-a-mitsubishi-heat-pump-Part-1/) to control my wall unit, but this solution unfortunately doesn’t seem to work with my ceiling SLZ-KA09NA units (of which I have 3).

Therefore I am looking at your kumocloud integration. It appears that my SLZ-KA09NA units should be compatible with the PAC-USWHS002-WF-2 wifi adapter ($150/unit), which should allow me to hook them to kumocloud. Before I spent $450 I wanted to make sure I understood exactly how this works?

Questions:

Does anyone here have any of these SLZ-KA09NA units working with the above adapters?
The github readme says that it is all local except for setup - once the initial setup is complete no data goes to outside servers? I would love to avoid sending data to someone elses cloud (if that is possible).
Any other considerations I should think about before taking the plunge?

Thanks for any input…

Ted

golovorub · March 2, 2021, 1:07am

Hello there!

Question - what to do it no address field is returned from https://geo-c.kumocloud.com/login (although there are tons of other fields, so the data is loaded) ?
The integration works on the phone, although it still recommends me to “Enable WiFi for faster connection”.

Update Turns out having the cloud controller to the guest network, with mixed 2.4/5 mode is bad. Today reconnected to a 2.4 only network, without guest restrictions (i.e. devices can see each other in the same WLAN), it started to work properly.

One more thing - when adding the integration, it didn’t ask me for any rooms, and it required HA restart to detect any entities. For the record, I have a single ducted unit.

Thanks!

masaq · March 5, 2021, 8:20pm

Well, I took the plunge and have the integration working well with an SLZ-KA09NA, which is very exciting for me.

I am curious about whether there is away to see when the unit is actually running. In the history tab for my other climate devices the green shading is only present when the device is actively heating and cooling. From some searching around the HA forums, it seems like MQTT climate entities can have an “action_topic” which shows whether they are actively heating, cooling, idle, etc. Does the Kumo Cloud integration expose an “action_topic” or have some way to show when the unit is actually actively heating or cooling?

Thanks for any insight, and thanks to Doug for writing and maintaining this integration!

parkercat · March 6, 2021, 6:15pm

I have searched for the ability to read the indoor unit’s current state (actual fan speed, calling for heat/cool, coil temperature, etc.) to no avail. The mobile app doesn’t display anything of the sort even under the installer section. If it’s under some other REST endpoint on the indoor unit’s webserver I haven’t guessed it.

masaq · March 6, 2021, 7:23pm

I suspected that might be the case, as it seems like something that would have been implemented if it were straightforward. It’s clearly available from the unit via the CN105 connector, as the unit I have hooked up via an arduino is able to provide it, but clearly Mitsubishi didn’t expose it through their API. Well, nonethless, thanks for this great integration - it’s truly exciting to have finally have HA able to control my heatpumps! And, my wife will be happier insofar as using your kumocloud integration the MHK1 wall units will remain functional (even as I secretly implement various schedules, etc, using HA…)

masaq · March 14, 2021, 8:07pm

I just added 2 new PAC-USWHS002-WF-2 wifi adapters to my other 2 heat pumps (for a total of 3). However, the integration isn’t picking up the new heatpumps, though they are visible in the Kumocloud app and controllable through the kumocloud app.

I have deleted and reinstalled the integration a couple of times, but is not creating any entities when installed - my original heatpump which had been set up and working fine is not being re-created by the integration on re-install either.

The cache file (/config/kumo_cache.json) is being created, and looking in there I can see the names of the heatpumps, and even the correct local IP addresses. So the issue appears to be on the HA side in the creation of the heatpump entities, rather than in downloading the data from kumocloud.

Any ideas how to fix this? Should I manually create the entities in HA somehow? Thanks for any guidance…

parkercat · March 14, 2021, 8:24pm

You’re likely the first person to add new indoor units to an existing installation

When you’re removing & re-adding the integration, before you re-add it make sure you (a) restart HA and (b) remove the kumo_cache.json.

If you have the technical skills, examine the structure of the kumo_cache.json and see if the JSON paths to the new units are similar to the old one. Note: it keys off the indoor unit’s serial number so if that’s not there, that’s the issue.

Try adding or removing the units from “changeover groups” in the Installer section of the KumoCloud app.

Again if you have the technical skills, try to use pykumo.py directly in an interactive Python shell (using account=KumoCloudAccount.Factory(), and calling account.get_indoor_units() on the resulting account object). That would at least tell you if the library is finding the units or not.

masaq · March 15, 2021, 1:11am

The joys of blazing a new trail!

I did find the serial numbers in the kumo_cache.json, so that’s not the issue. I wasn’t sure exactly what the json path was, but the entries looked substantively similar to me and seem to have all the same info in them.

I did try add and remove all 3 units from changeover groups in the kumocloud app.

I removed the integration, uninstalled via HACS, rebooted, reinstalled via HACS, rebooted, and reinstalled the integration

Still having the same issue. kumo_cache.json is created, but no homeassistant entities.

Sadly I have not used python before; though I do know how to open a python shell on the host; if you tell me what the commands are I can certainly try running them and let you know what the output is.

I realize that supporting people like me isn’t in your job description - but I really appreciate your help.

Ted

masaq · March 15, 2021, 10:54pm

Well, not sure what was different, but I just tried one more time today and it recreated all three heatpumps correctly. I did create a new changeover group again, and didn’t check “prefer cache” when I reinstalled the integration.

In any case, I’m really glad to be up and running! I guess my only remaining question would be whether there is any easy way to change it back to prefer the local cache (I installed via HACS so I don’t have that option in my configuration.yaml), as I’d rather not be pinging mitsubishi servers if I don’t need to (and I already have all 3 heatpumps on static ips, so I shouldn’t need to).

Thanks again for your help!

Ted

parkercat · March 15, 2021, 11:13pm

Great! I’m glad it’s working for you now. I’m sure there’s a bug in there somewhere. It’s also possible the KumoCloud service finally picked up some crucial piece of info that was missing before.

I would have thought prefer_cache could be set in Options on the Integrations page, but it’s not there. (I didn’t write the UI part – patches to fix this up would be welcome.) But you should be able to (carefully) edit it in .storage/core.config_entries under your configuration directory. Shut down HomeAssistant while you make the edit.

gregorymartin · March 17, 2021, 6:01am

This week I’ve been making some changes to my home network which has resulted in my units getting new IP addresses in the process. I’ve noticed that when that happens, the units go unavailable for some time, and after some combination of time, reboots, and integration reloads, they come back to life. This feels somewhat related to the issue above, maybe some sort of issue with device discovery after initial setup? I don’t yet have more detail on what incantation does the trick for me, but will share if I get more clarity.

gregorymartin · March 17, 2021, 6:08pm

Time is definitely a factor, reloading the integration after a few hours brings them back online.

parkercat · March 17, 2021, 11:24pm

Definitely. KumoCloud service is not quick to update.

AlmtyBob · May 2, 2021, 6:45pm

In case anyone runs into the same issue I did:

Problem: I added a new unit and the new unit never showed up after two days of trying. During that process I changed the IPs of my existing units (reserving them in my router) at which point none of the units showed up in HA at all even after deleting and re-adding the integration. The Kumo Cloud phone app worked fine for all the units the whole time.

Solution: I had to re-add the integration with “Prefer Cache” checked. Next I edited kumo_cache.json in my Home Assistant config dir, changing the IP addresses for my older units as needed (just search for “address”). Then, I saw that my new unit was in the file but didn’t have an address, so I manually added an “address” entry with the correct ip address below the “label” entry for that unit in the json. I knew it was the correct unit because the unit’s kumo adapter had the mac address listed on a sticker and I searched for & found that mac address in the json.

grandamemt · May 18, 2021, 12:46pm

Question about “History”

Note: I am a relative n00b at HA, a complete newbie to HACS, and my Mitsubishi hyperheat minisplit was installed just the day before I installed this integration, so please understand I have essentially zero baseline to work from.

How do I “read” the history in the intergration? Is there a way to see history longer than the previous 24hrs? Is there a way to increase the resolution so I can more-closely see what time events happen? I see green and red, with green spiking into the red (system set to heat right now), but I don’t understand what it is showing and the history is too small to get a precise time as to when it happened.

I’m trying to figure out why my system is running at certain times. I have the heat set to 62deg. I found yesterday it was running while the integration and ap said the room temperatyre was at 64deg. I’m trying to understand both ap control and how the system handles temperature set points and the “deadband” (allowed temperature range for any particular set point).

James_Huang · May 18, 2021, 1:59pm

Just to be clear, the integration just really allows HA to communicate to the minisplit. It is NOT in charge of logging. If you more detailed logging, you can try clicking on the “Logbook” button on the left side and narrow down to the datetime ranges for the entities you want to monitor. In many cases, it will tell you what triggered changes to state.

This integration out of the box is a bit ‘dumb’ with regards to temperature regulation. Once you set a temperature and heat/cooling status, it stays that way regardless of the temperature. So if you set the room to heat to 62 degrees… it will still stay in heat mode even if the temperature is 77 degrees. At that point, though, the system just blows air. I would say that the integration emulates what you would get with the remote… so if this doesn’t make sense, you may want to refer to the owner’s manual.

parkercat · May 19, 2021, 12:02pm

There are a number of things going on with HA controlling HVAC:

HA tells the indoor unit(s) what mode to be in, setpoint, and (if you so desire) things like fan speed, vane direction, etc. though I suspect most leave these at “auto” (as do I). HA’s primary benefit here is being able to change mode & setpoint based on schedule or other factors (such as outdoor temperature, window sensor state, etc.).
The indoor units maintain their setpoint to the best of their ability, adjusting the load presented to the outdoor unit, their own fan speed & direction, etc. Note that the fan is usually running whether the unit is calling for heat/cool or not. Sadly, we do not have direct visibility into whether a unit is calling for heat/cool via the API. Or at least I have not found it. It’s somewhat telling that the KumoCloud app doesn’t show this info.
The outdoor unit adjusts its own compressor and fan speeds (and thus its power consumption) to meet the indoor units’ demands to the best of its ability.

The control algorithm for mini-splits across the industry seems to be to try to run at a steady, low level as much as possible, avoiding cycling. They’re at their most power efficient when this can happen.

So for the information you want – “is my system running” the answer is generally “yes”, with an asterisk. Almost certainly, the fan is running. This is good because it stirs the air in the room and reduces hot/cold spots. And it’s very likely the outdoor unit is doing something too, unless you’re far away from the setpoint.

The best way to get a handle on such things is to monitor the power consumed by the outdoor unit. There are whole-house power monitors (Sense and its competitors) which can do some of this job (you can use Sense’s “solar” sensors to monitor a single 240V circuit if you don’t have solar power), as well as some standalone monitors (I’m using a Shelly EM).

Once you have that data, HA keeps it for only a short time. As James points out you can see a few days in the “history” tab on the left. But for long-term storage you could set up something like InfluxDB and Grafana, which is well-supported and works fine.

grandamemt · May 19, 2021, 12:59pm

Thank you very much for the detailed explanation. I have attached the “history”, HA does obtain basic activity of the unit.

I see two issues here, both of which I believe are relative to the unit, not HA.

They are:

The unit never actually reaches my set temp of 62, it turns on at 63 and off at 64
The unit is short-cycling by just one degree. This isn’t an issue with heat, but in the summer this will not effectively remove the humidity and mugginess from the room; it needs to run in much longer cycles to do that.

I am working with the installer to determine the unit’s “deadband” settings and other things to see if it is operating in spec and if it can be changed.

knoblich05 · May 23, 2021, 8:24pm

First of all, thank you for creating and maintaining this, it’s been really helpful.

Second, this is most likely not a hass-kumo issue, but like others before I’m hoping someone else here might have had similar issues and can help.

I have 3 units with Wifi adapters (and additional wireless sensors) that have been working fine for a bit over a year.

I’ve seen two issues that I suspect might be connected (based on the temporal proximity):

A couple of days ago (without anything changing to my knowledge), I noticed all 3 units were starting to exhibit a pattern were they’d turn on (heat mode) despite the current temp being above the usual temp they turn on, and turn back off after 5-10 min. This happened about 1-2 times per hour on average. I tried re-pairing the wireless sensor, but that didn’t seem to change anything.
Then last night I wanted to use the kumo app to reset/re-add a unit to help with debugging, and noticed that it’s showing a connection error (from router to cloud). A little later, and I’m not at a point where none of the units communicate correctly with the app or kumo-hass (or my own python script inspired by kumo-hass). When I try to add a unit as new zone, the app is stuck at “reading unit” or something like that and after several minutes shows a connection error. The wifi unit blinks slowly twice.

I can ping all units from the hass machine. When I used Python to try to connect with a unit manually, I get “_api_error”: “device_authentication_error” (which I presume is because the wifi interfaces tried to set themselves up with the cloud server and failed.

I’ve tried power-cycling and resetting pretty much everything, even using another phone as a hotspot to rule out WiFi/ISP issues.

I’ll try Mitsubishi customer service tomorrow morning, but based on past interactions I don’t have too much hope. I’d be grateful for any advice anyone can provide.

Thank you!

UPDATE: Looks like my wifi interface units are all trying to connect to various IPs associated with geo-b.kumocloud.com, and if I try that with my python script (instead of the geo-c we all use usually), I’m getting this:

SSLError: (“bad handshake: Error([(‘SSL routines’, ‘tls_process_server_certificate’, ‘certificate verify failed’)],)”,)

So it looks like they’re having some SSL cert trouble…?

UPDATE2: Having disconnected the Wifi interface units, I’m seeing relatively short cycles, as well (though somewhat longer and more regular). That makes sense since the units are now the built-in sensors, whereas the Wifi sensors were at a good distance away. So in conclusion the weird irregular super-short cycling described in (1) above is likely the result of the Wifi interface disconnecting intermittently, causing the unit to fall back to the internal sensor that’s colder, starting to heat, and a few minutes later the Wifi sensor is coming back and reporting it’s warm, so the unit turns off again.

Is anyone else having similar connection issues to kumocloud (and has anyone ever tried connecting to geo-b, or has that never worked)?