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.
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?
Update: Mitsubishi customer service has confirmed their kumo cloud server is down, they currently do not have any ETA for it being back up.
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?
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.
1 Like
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…
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 
).
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.
1 Like
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.
Doug, I created a PR for adding a method to fetch sensor temp to pykumo following your suggestion.
I wanted to keep it simple, so didn’t add support for multiple sensors at this point.
Do you have any advice for how to setup a development environment to test the HA integration in the next step, by any chance (beyond what’s on https://developers.home-assistant.io/docs/add-ons)?
(This is my first public github PR, apologies for any and all mistakes. :))
This PR has been merged to pykumo and I’ve made a beta release of the kumo integration to pick it up (along with some reformatting changes in support of possible eventual submission as an official HA integration).
What I do for development & testing is to install a minimal HomeAssistant on my laptop (using the virtualenv method) and work on my development kumo code there. Put your code under test in its custom_components/kumo folder by hand, not with HACS, so you can more easily use your own code. Edit to add: The Kumo indoor units don’t seem to mind being talked to by two HomeAssistant instances, which makes this work OK. Obviously there’s no synchronization between them except for polling (same as if you control the indoor unit thru the KumoCloud app etc.) so it’s not recommended for regular use, but for development it’s been fine for me.
What you’ll want to do to add sensor temperature as a property:
- Add it to _update_properties here: L186
- Implement getter/setter for the new property following the example of battery_percent: L435
- Add an ATTR_SENSOR_TEMPERATURE here: L40
- Use that ATTR_SENSOR_TEMPERATURE in the device_state_attributes function here: L496
I think that’s enough but I haven’t tried it so this could be missing a piece.
-Doug
You link to the development of an add-on, don’t you mean integration:
Also, after playing around with it a bit, visual code studio does a great job at creating a VM and is super easy for testing, they have instructions on how to set that all up. One suggestion which took me forever to figure out (my fault because I didn’t read in depth) is you have to run:
python3 -m script.scaffold config_flow_discovery
So that it picks up the new integration and config flow…
Hi… With this change are you able to use a Home Assistant temperature sensor entity as the temp sensor for Kumo instead of one of the kumo remote sensors that you can buy from Mitsubishi? I think Kumo only allows the use of one remote sensor per indoor unit, and it would be nice to be able to average 2-3 sensors from different rooms instead. If HA can act as the remote sensor to Kumo wouldn’t that averaging be possible?
No, it’s an output not an input. There’s no way I’ve seen in the Mitsubishi API to do what you’re asking. But you knew this from the discussion on the Github issue you opened with the same question.
@parkercat - have you used the integration with Google Assistant? One of the changes in the latest Home Assistant build is: “The Google Assistant integration now has support for fan speed percentages and preset modes.”
I resynced my HA setup w/ Google Assistant. The ability to control “Fan Speed” now appears as a slider… but doesn’t work. Any thoughts on this?
I’m not on the latest build yet (maybe this weekend). And my HA is not exposed to the outside world so I can’t use Google Assistant with it. But my guess is that a Kumo unit has fan speeds but is not a fan entity itself. If other climate entities work with Google Assistant, their code would be a good place to look for the required changes.
In other news: a friend of mine has installed a new Kumo system with the mysterious additional central WiFi adapter, the kind that shows up as “Station 1” in the list of indoor units. We’re planning to examine what data might be available from it; I’m hoping for power consumption or other system-wide info.
Relatively new to Home Assistant. Can’t install Kumo integration in HASS after installing it with HACs.
Clean install of Home Assistant 2021.7.2 and then HACs on Raspberry Pi 4B. Installed Unifi Protect through HACs rebooted. Installed Mitsubishi Kumo Cloud in HACs and rebooted. Installed Unifi Protect using HASS configuration → integrations and that worked. Attempted to add HASS configuration → integrations for Kumo and Kumo doesn’t appear in the list of supported options.
/config/custom_components/kumo exists.
What is next on the troubleshooting?
After waiting a few hours, I came back to the system and Kumo appeared in the integrations list. I have a new problem: when I try to install the integration, I get an invalid user credential response. I logged on to my smartphone using the credentials, the web interface, and I installed the app on an iPad and also used the credentials to verify them. However, those solutions were all using app.kumocloud.com. The integration seems to be using geo-c.kumocloud.com and my PiHole DNS server is showing that no data is being returned from that DNS A record.
Is this sort of a recurring problem?
I’m currently experiencing the same issue as you as well @spurpura . My login works everywhere else but the integration. Did you ever find a solution or workaround?
@geoff_lowery the issue was resolved without a solution or an investigation. I still have the problem.