Nice! What we need from a debug perspective is just reports of anomalies, specific indoor unit models showing wrong options, that sort of thing.
So for the record, the thing that you couldn’t figure out is the HACS install? That doesn’t surprise me; it’s entirely untested.
Roger that, i’ve been a kid in a candystore with this, changing temperatures all across the house, might get divorce papers served if I keep going.
It was even more basic than this - I didnt know what HACS was and couldnt find a proper link at the time, so didnt even get around to try the HACS installation.
Figured that one out now.
Is this integration available on HACS now?
I made some changes that might make it suitable but ran out of time to do any testing whatsoever (I don’t even have HACS installed). So I have not made a request to get it included in the official lists.
Evidently there’s a way to add an unofficial repo to your own HACS and try it out / use it that way, which is the next step in testing. But I’m out of HA hacking time for this holiday break.
Ah yes, it appears to be straight forward to point at your repository. I just tried it, so the next time you have an update I should be able to test the upgrade path.
I just ran into an issue trying to change the swing mode of my unit from “auto” to “horizontal”. Below is a screenshot of the error as well as details from the log file.
2019-12-31 18:02:34 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection.1816052080] name 'get_vane_directions' is not defined
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 133, in handle_call_service
connection.context(msg),
File "/usr/src/homeassistant/homeassistant/core.py", line 1235, in async_call
await asyncio.shield(self._execute_service(handler, service_call))
File "/usr/src/homeassistant/homeassistant/core.py", line 1260, in _execute_service
await handler.func(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 205, in handle_service
self._platforms.values(), func, call, service_name, required_features
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 336, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 358, in _handle_service_platform_call
await getattr(entity, func)(**data)
File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 413, in async_set_swing_mode
await self.hass.async_add_executor_job(self.set_swing_mode, swing_mode)
File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/kumo/climate.py", line 364, in set_swing_mode
response = self._pykumo.set_vane_direction(swing_mode)
File "/usr/local/lib/python3.7/site-packages/pykumo/pykumo.py", line 355, in set_vane_direction
valid_directions = get_vane_directions()
NameError: name 'get_vane_directions' is not defined
Sure enough. Good catch. Will fix later. Line 355 needs to be self.get_vane_directions() not just get_vane_directions()
I pushed a fix for this just now, as well as merged your HACS fixes @gregorymartin . This version also trims down the fan speeds when the unit reports that it supports only 3, which may fix @rbarbero’s issue with fan speeds.
Greg beat me to it.
Same issue with the vane directions.
Will manually edit the file.
Question though - how do we update this currently?
Manually pull and refresh?
If you update the kumo folder in custom_components from GitHub it’ll pull the new version of pykumo on next restart. Or if you install HACS and add the hass-kumo repo to it and (re)install through HACS, theoretically it should offer to upgrade.
Has anyone gotten Google Assistant integration to work with the ‘fan speed’ control? From best I can tell, it was implemented in HA here: https://github.com/home-assistant/home-assistant/pull/18373
I have confirmed a few things with the latest push:
One thing I dont see yet - My units allow for a “Hybrid” mode, keeping a room at a temperature through heating and cooling, I never use it as i find it silly but it does exist as a mode which I dont see as an option.
Anything I can provide on this? Not really urgent in any way, but someone may use this.
@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…