@parkercat Bless you, going to see if I can get it running this week.
So last night I spent some time playing around with this and discovered a very easy way to include the python module without having to fight docker or wait for it to get added to python. Within the customer_component/kumo folder, I created a new folder called pykumo and dropped the pykumo.py and the __init__.py file into it. I then change line #16 in the climate.py file to
from .pykumo import pykumo
After I made that change and restarted everything, my Kumo controlled items appeared. I did test completely restarting the server which would destroy and rebuild the docker instance and it carries over because the module is part of the component.
Hope that helps!
Awesome! I’ve updated the install instructions on GitHub. Thanks!
I need a little bit more help… I’m getting a “Platform error climate.kumo - Integration kumo not found.”
My Configuration.yaml reads as:
climate:
- platform: kumo
name: “Therm5”
host: 192.168.1.###
config: "{‘w_param’: 'xxxxxxxxxxx
I’ve created a custom_components\kumo\pykumo folder.
What isn’t clear to me is where to pull what from. I’ve tried different permutations, but the one that made the most sense to me (without looking at the code too much) was pulling in the files as such:
pykumo-master\pykumo.py --> \custom_components\kumo\pykumo
pykumo-master\pykumo_init_.py --> \custom_components\kumo\pykumo
hass-kumo-native\kumo\* --> \config\custom_components\kumo
Can you see where I went wrong?..
I’ve pushed new versions of the components this evening.
NOTE: This is a BREAKING CHANGE:
The Kumo component now fetches setup information directly from the KumoCloud servers. So instead of listing your indoor units with address, config params, etc., you now simply set up the kumo platform and provide it with your KumoCloud username and password. The climate entities will be auto-created.
The syntax to pull the pykumo library from a local directory (as suggested by @landrysplace above) is now the default, as well. This will change, of course, when pykumo is submitted to PyPI, but we’re a ways away from that still.
I’ll update the documentation on the hass-kumo GitHub shortly.
Tried the new build @parkercat . Got the following error message when starting up:
2019-09-22 20:55:41 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 50, in async_setup_platform
names = data.get_account().get_indoor_units()
File “/config/custom_components/kumo/pykumo/pykumo.py”, line 272, in get_indoor_units
for child in self._kumo_dict[2][‘children’]:
TypeError: ‘NoneType’ object is not subscriptable
One last thing - it might be obvious to more seasoned vets, but the instructions should say to restart HASS.IO after copying the components into the proper directories. Without the restart, adding the configuration.yaml yields an error indicating that the component cannot be found.
Thanks @parkercat cat - I know this is hard work and it’s very much appreciated.
@parkercat It’s working!!! Tried your new instructions on Hassio (thanks @landrysplace as well), restarted the server, and it auto-detected and created entities for all five of my units. They respond way faster than the official Mitsubishi app, too.
Will start testing and reporting back. Two notes so far after a quick test of one of my FH-series units: there doesn’t seem to be an option for “fan mode”, and the “vertical” vane setting isn’t working there. Other vane settings all seem to be working.
Please tell me where you accept donations. 
… and I’m an idiot. Mistyped my username in the config file. Thanks @parkercat - it’s working!
2 Likes
I need to add some better error checking in this section of code, because if anything goes wrong (like wrong username, or a problem with the KumoCloud server) it’ll hit here first. But I’m glad it’s working for you!
I suspect there may be some differences in the commands supported by the different model units. The most straightforward way to figure this out would be with some packet captures. If you have a Linux laptop you could follow instructions here: https://www.cellstream.com/reference-reading/tipsandtricks/335-capturing-wi-fi-wlan-packets-in-wireshark-on-linux , or alternatively install a packet capture app on your phone – I have used one on Android. Then use the KumoCloud app to control the aspects that aren’t working, and share the captured communications – probably on GitHub would be easier than here.
I used a quick & dirty Python program to test out different commands – that’s how I discovered how to retrieve the humidity (and battery level) from a remote sensor. I should clean that up and add it to the pykumo repo.
The amount of work I’ve done here is not worthy of donations. If anything, send some bucks or recognition to Sushil Singh, who did the original hard reverse-engineering work for kumojs.
I don’t have the vertical vane issue, but I am missing fan functionality. I’ve created a GitHub issue for it and have a link to the packet sniffing output for it. Please let me know if it’s missing what you need and I’ll take a harder look at getting the data you need.
I use Google Assistant to control my thermostat (most of the time). The OEM Kumo Cloud Google Assistant integration appears to set the thermostat based on the previous state (if it was AC, it turns it on to AC… if it was heat, it turns it on heat mode). With the current implementation, it appears to default to heating when I turn it on with Google Assistant. Is this something that the component can control (to default to the previous heating/cooling setting)?
Minor quibble I know. My wife’s gotten used to saying “Turn the thermostat on” and it just picking up from where it left off.
Ignore my previous question. It looks like it’s a HASS issue and not confined to Kumo
@James_Huang @Sean_Hollister I’ve pushed an update with support for Fan mode, which Mitsubishi calls “vent”. With this update, the code reads the supported operation modes from your units. So if your hardware doesn’t support (or your installer disabled) dry (dehumidifier) or auto heat/cool etc., it will auto-adapt. There are a few more configuration details that could be read this way (min/max setpoints, whether the unit supports auto fan speed, and a couple others) but I have not done so yet.
Sean, I have seen some difficulty switching vent to Vertical on my own unit, but I could not reproduce the issue with further testing. I suspect it might be a bug in the WiFi controller itself. If you reliably can’t switch to Vertical vane, a packet capture of the failure (uploaded to GitHub please) – and of KumoCloud app doing so successfully – would be most helpful.
The new fan setting works @parkercat! Thanks for the hard work. I’ll continue using this custom integration and let you know if I see any issues with the component. So far so good!
@parkercat, thanks for putting so much work into this (and of course sushilks for the reverse engineering)!I sent a pull request with dual setpoints for heat/cool modes and moved network i/o out of the selectors. It’s working great for me.
Thanks! These changes look good, merged, though I won’t get a chance to test them myself until tomorrow. I don’t use heat/cool mode myself. I’m hopeful your status-fetching changes will get rid of the “Updating state for [this stuff] took 0.621 seconds” messages I occasionally see.
If you have knowledge or experience in getting modules into PyPI, please stick around – we’re getting pretty close with pykumo. I think the majority of the basic functionality is there.
I’d love to get the actual calling / not-calling status from the indoor unit (to fill in the graph in the HA thermostat card, and maybe also to get some estimate of run costs) but I’ve yet to find a Kumo API call that returns anything like that.
Hi there, this is great, I just got around to testing this out on a clean environment. I’m running into an error with the component setup, traceback below. I have a zone setup in the Kumo app (a group of units) and I wonder if that is causing this. I had to submit a PR into the KumoJS library to handle the recursive nature of this setup before.
2019-11-03 08:02:13 ERROR (MainThread) [homeassistant.components.climate] Error while setting up platform kumo
Traceback (most recent call last):
File "/Users/gregm/Source/home-assistant/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/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/asyncio/tasks.py", line 442, in wait_for
return fut.result()
File "/Users/gregm/.homeassistant/custom_components/kumo/climate.py", line 75, in async_setup_platform
names = data.get_account().get_indoor_units()
File "/Users/gregm/.homeassistant/custom_components/kumo/pykumo/pykumo.py", line 361, in get_indoor_units
for child in self._kumo_dict[2]['children']:
TypeError: 'NoneType' object is not subscriptable