Mitsubishi Kumo Cloud Integration

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)?

parkercat · May 24, 2021, 12:35am

I think the “device authentication error” occurs when the security token in the url (the “m” parameter) doesn’t match the payload, in other words if the password or cryptoSerial from the kumo_cache.json file is wrong or missing.

knoblich05 · May 24, 2021, 12:44am

Thanks for the reply, Doug.

That makes sense, since I could connect to the units (even after they started behaving weird) UNTIL I started messing with the app, which presumably caused them to try to sync to kumocloud and in the process invalidated the existing password without getting a valid new one or something like that…

Do you happen to know if the geo-b server is expected to work, or if that SSL issue might be a red herring?

knoblich05 · May 24, 2021, 9:48pm

Update: Mitsubishi customer service has confirmed their kumo cloud server is down, they currently do not have any ETA for it being back up.

knoblich05 · May 25, 2021, 8:53pm

FYI, the server(s) seem to be back up, I was able to reconnect everything.

Given this multi-day outage, has anyone tried cutting the local system off from the kumocloud servers completely (e.g., by blocking *.kumocloud.com on the router) to avoid similar issues?

parkercat · May 25, 2021, 9:54pm

I haven’t blocked KumoCloud servers, but if your IP addresses are stable, you don’t add any indoor units, and you set the “prefer cache” setting to true, HA doesn’t contact KumoCloud unless you delete the kumo_cache.json. All the interaction is strictly on your home LAN.

knoblich05 · May 25, 2021, 10:14pm

Thanks for the confirmation, Doug!

I suspect that the units acting wonky late last week is related to the server outage (though I can’t be 100% sure), so in addition to your confirmation that HA doesn’t rely on kumocloud servers, the question is whether the units themselves are ok being cut off from their servers. I’ve just set up the blocking and apart from a warning in the mobile app things seem to be working just fine so far…

knoblich05 · May 30, 2021, 10:13pm

Update on the connectivity issue: when I block the kumo servers, the Wifi units seem to restart every once in a while (which is probably meant to restore the connection), which means the unit falls back to its internal temp sensor for one reading (half a minute or so), creating weird behavior if that temperature is significantly different from the external sensor.

Small feature request: it would be great if we could get the sensor temp in HA, since it has higher resolution than the “current temp” reported from the main unit (~0.17C vs 0.5C). I see that the humidity is already being pulled from the sensor data, so adding a “sensor_temperature” field or something like that should be minimal work. (I’d be happy to contribute that change myself if you think it’s useful, though I’m new to HA development and I have the feeling making the change yourself would be less work for you than reviewing my PR ).

parkercat · May 31, 2021, 12:04pm

If there is a sensor attached, my observed behavior is that the unit reports the sensor’s temperature as its own rather than its internal measurement. You could be right that it’s doing rounding differently. I can do this next time I’m making changes for some more pressing reason. But don’t hold your breath, I have nothing planned, so if you’d like to make a PR feel free . You’d want to start in the pykumo library – and maybe add support for fetching from other than the first sensor, too – and once that’s ready move on to utilizing it in HA’s kumo integration.

Sean_Hollister · June 14, 2021, 5:29am

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.

Thank you SO MUCH. I had to re-add one of my units and had the exact same thing.

Additional recommendation: If you’ve ever manually installed this integration in the past… make sure you delete Kumo from your configuration.yaml first! I was tearing my hair out because my JSON kept getting overwritten each time I restarted HA, even if I selected “Prefer Cache”. Seems it’s because I effectively had a second copy of the integration overwriting my changes! Now everything works again.