@James_Huang I suspect the names of the fan speeds don’t line up with what Google Assistant is expecting. Mitsubishi’s choices are a little odd.
I would accept a PR to map the Kumo names to more standard names, analogous to the existing HA_STATE_TO_KUMO / KUMO_STATE_TO_HA in climate.py. Someone would need to research what those standard names should be, too.
@KaiserKai Is this distinct from Heat/Cool (which Mitsubishi calls Auto) mode, the one with upper and lower setpoints? There’s a way to enable/disable Auto in the installer settings in the KumoCloud app.
Yes - Thats it - Its available directly via the Remote Control.
And you are are right, it needs to be enabled in the app - Hidden in the installer settings.
Once I changed it, the app pulled it in.
You are a genius!!!
Hey guys,
The HACS install method is working well now. In fact it’s so smooth I am re-thinking whether it’s worth the effort to try to get Kumo included natively in HomeAssistant, at least in the short term. The biggest drawback is it’s one more thing to have to install and configure HACS, and requires a (free) GitHub account which could dissuade some users.
What this means is that, for now, any documentation updates or clarifications should be made to https://github.com/dlarrick/hass-kumo/blob/master/README.md . So if anything was confusing, unclear, or incorrect, please make a PR there (or just open an issue on GitHub if it’s something simple).
I now recommend new users should install using HACS if at all possible. In another week or so I’ll make a PR to try to get it included in the default HACS list. Once that’s done I will recommend to everyone to switch over.
Also: I pushed an update today to fix fallback to the cached kumo_cache.json server file, which was not working properly if you didn’t set ‘prefer_cache’. If you’re using HACS it should offer an update; otherwise it’s just __init__.py that changed. I am pretty amazed at the poor uptime of the KumoCloud service, especially during non-business hours.
Hey, I mentioned this to the kumojs developer but he hadn’t seen this issue. Randomly, my hass instance gets “blocked” from accessing the kumo controller. When this happens, I can’t even ping the kumo device from my hassio instance. The odd thing is that other devices are able to ping the device without a problem. The only way I have been able to get the communication back is if I restart the network (I have google wifi). I initially thought that the kumo controller was blocking it, possibly because of some bad packet. But rebooting the kumo device doesn’t enable the communication again. If I just reboot the AP it is connected to, no luck either. Just restarting the entire network seems to resolve this. I don’t have any other issues with google wifi and as I mentioned, I can ping the kumo device from any other computer. Was wondering if anyone else was seeing this?
More relevant, when this just happened to me, Hassio was unable to start, it was stuck trying to setup the kumo component and wouldn’t proceed so I couldn’t get the hassio UI up. Maybe you can set a timeout when the component is being set up? I am using the cache and the issue was not with kumo cloud as that was working and the cache file was regenerated without a problem. But if the local device is not responding then hassio just doesn’t load while trying to get this up.
I have seen something similar; not in quite a while though. It seems to maybe be an issue in the networking stack of the Kumo adapter, maybe at layer 2 (ARP layer). Rebooting the WiFi access point seemed to resolve it for me. The symptom is exactly as you describe: I can ping the indoor unit from some nodes on my network but not from others. Having the HA host (a Pi 4 in my case) on wired network seems to have helped a lot.
I will be doing some work to more gracefully handle the case where the local indoor unit is not available, because I’d like to be able to shut down my whole system in the dead of winter (when heating with a mini-split in New England cold is not cost effective) without HA freaking out. The outdoor unit consumes a non-insignificant amount of power when idle, keeping itself ready to operate. I make no promises as to timeline, however. As always, patches welcome.
Thought I was going nuts, glad it wasn’t just me! It’s odd as I haven’t seen that in a few months but it just happened and I figured I would ask here. Also New England but I have the hyper heat and it’s actually easier for me to heat just the bedroom with the split and leave the rest of the house cooler. It’s not a big deal, it just always takes me by surprise and takes me hours to remember to reboot the network…
Things have been going haywire the last couple of days, probably due to my tinkering…
I ran two different HA on my network in an attempt to get away from the Pi.
Saw some weird behavior of some of my units turning on and off randomly.
Now I dropped the second instance and kumo doesnt work at all anymore.
I tried deleting kumo_cache,json but it wont start at all when I do that.
With the kumo_cache.json available it now ends with this error message
2020-01-10 14:13:02 ERROR (MainThread) [homeassistant.components.climate] Error while setting up platform kumo
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 150, in _async_setup_platform
await asyncio.wait_for(asyncio.shield(task), SLOW_SETUP_MAX_WAIT)
File "/usr/local/lib/python3.7/asyncio/tasks.py", line 442, in wait_for
return fut.result()
File "/config/custom_components/kumo/climate.py", line 75, in async_setup_platform
name = data.get_account().get_name(unit)
File "/usr/local/lib/python3.7/site-packages/pykumo/pykumo.py", line 464, in get_name
self._fetch_if_needed()
File "/usr/local/lib/python3.7/site-packages/pykumo/pykumo.py", line 417, in _fetch_if_needed
response = requests.post(self._url, headers=headers, data=body)
File "/usr/local/lib/python3.7/site-packages/requests/api.py", line 116, in post
return request('post', url, data=data, json=json, **kwargs)
File "/usr/local/lib/python3.7/site-packages/requests/api.py", line 60, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/local/lib/python3.7/site-packages/requests/sessions.py", line 519, in request
prep = self.prepare_request(req)
File "/usr/local/lib/python3.7/site-packages/requests/sessions.py", line 462, in prepare_request
hooks=merge_hooks(request.hooks, self.hooks),
File "/usr/local/lib/python3.7/site-packages/requests/models.py", line 313, in prepare
self.prepare_url(url, params)
File "/usr/local/lib/python3.7/site-packages/requests/models.py", line 387, in prepare_url
raise MissingSchema(error)
requests.exceptions.MissingSchema: Invalid URL 'None': No schema supplied. Perhaps you meant http://None?
I think you have a bad (or unreadable? permissions?) copy of your kumo_cache.json which it can’t get data from, so then it tries to read from the server but doesn’t have a URL in that codepath. That’s clearly a bug, but the more relevant question is why can’t it read from the cache?
What’s more, I think it’s having trouble contacting the KumoCloud servers. Either they’re down (all too common unfortunately, and the reason for the kumo_cache.json), or your username/password is not right, or there’s some other reason for it.
Next time I’m making changes I’ll try to make these error paths more resilient, but (assuming my remote clairvoyant debugging skills are correct) even if my code were perfect here all it could do is not hang but not create climate units either.
I have tried uninstalling and re-installing a couple of times, with or without the kumo_cache.json file present same result every time.
I think (armchair quaterback) there should be a check for the kumo_cache.json and if its not there re create it.
For now Ill be messing around with some chmod etc.
Eejit that I am I changed 2 things, so cant pin it down to a single one.
I changed prefer cache to “true” and did a brute force chmod 777 on kumo_cache.json
That brought it back.
After changing prefer_cache to false again it overwrote the kumo_cache.json and its still working.
So my assumption is that the script kumo uses didnt have access to the json, which is weird but I aint a unix guy…
EDIT - Further testing revealed that simply switching prefer_cache back and forth does the trick as well.
Prefer_cache will insulate you against KumoCloud outages on HA restarts, but requires that your network won’t reassign indoor unit IP addresses. It’s also a different codepath, of course.
I suspect the real problem was ownership/permissions of the cache file and I can certainly beef up error reporting in that area. I’ve made an Issue on GitHub to remind me.
@KaiserKai I’ve pushed an update which should have better error handling and logging around loading the server config (from server or from cache).
@omriasta this version also adds a pretty quick timeout when talking to the indoor units, so an offline or unreachable unit should not cause HomeAssistant hangs. If people are seeing timeouts in normal operation I’ll have to make it configurable.
I also added a battery_level attribute to the climate component, if an indoor unit has a remote sensor. You can turn this into an actual battery level sensor with a template sensor like
sensor:
- platform: template
loft_kumo_battery:
value_template: '{{ states.climate.loft.attributes["battery_level"] | float }}'
unit_of_measurement: '%'
device_class: battery
Hey all,
Kumo has been merged into the default store list in the HACS store. See https://github.com/hacs/integration for how to set up HACS in your Home Assistant, then search for “Kumo” in integrations.
For support / debugging, please continue to post in this thread. If you find a legitimate bug, feel free to create an issue on GitHub.
It’s been an interesting project for the last 9 months or so, and I’m glad others are finding it useful. I don’t have any immediate plans for improvements, though I’m sure some ideas will come up.
Awesome, there was no action necessary, HACS automatically recognized and cleared my prior custom repository.
The issue with empty setpoints being displayed has been fixed by HomeAssistant as of 0.106. No other updates from me; everything seems to be working fine. Carry on.
Something blew up for me - Not working for a few days now. Have tried all kinds of config changes.
It tells me “Connection Refused” - Across all my Units. Sample below.
Nothing has changed in my config, password etc all the same.
2020-03-08 21:18:08 WARNING (MainThread) [pykumo.pykumo] Error issuing request http://192.168.1.10/api: HTTPConnectionPool(host=‘192.168.1.10’, port=80): Max retries exceeded with url: /api?m=8cf708e5e3d1ce3aa40722f4b294a822c7acc772f32986b99bb44bff0b45f083 (Caused by NewConnectionError(’<urllib3.connection.HTTPConnection object at 0x7f7be0aed0>: Failed to establish a new connection: [Errno 111] Connection refused’))
Most likely, your units have either lost WiFi connection to your router, or have been assigned new DHCP leases.
I’d say either move the kumo_cache.json out of the way or temporarily turn off prefer_cache, and restart.
Got it working again.
It was the counterintuitive option of deleting kumo_cache.json and having prefer cache = true
I had this happen before, next time I’ll know 
Thanks Again
Hey all,
Novice here… please excuse my ignorance. I’ve installed kumo using HACS and added the following to my configuration.yaml. When I restart, I get the error further below:
kumo:
username: !secret kumo_username
password: !secret kumo_password
prefer_cache: false
Invalid config
The following integrations and platforms could not be set up:
- kumo
Please check your config.
I’ve checked my username/password and my HACS and kumo install went through without a hitch… until, of course, the restart. Your help is greatly appreciated!