If @omriasta doesn’t chime in I may have a chance to look at this issue over the weekend. If you’re able, please open an issue on GitHub.
@parkercat I think this might be an issue with homeassistant. If you do not touch the prefer cache checkbox at all when installing the integration, the error comes up. But if you check the box and then uncheck it, works fine…
I see. Replacing the failing line with something like the following would work around:
"prefer_cache": user_input["prefer_cache"] if "prefer_cache" in user_input else False,
Needs to be formatted to fit in 80 chars etc. of course.
Looks like progress has been made on pykumo to pull in the mac address. I guess my next question is whether that can work in the setup yet?
For whatever reason (I’m stumped) my kumo cloud json file always gets delivered without an address. The kumo app on my phone doesn’t let me specify a particular address (as in static) but I have reserved IP addresses for the HVAC units and they work just fine. I don’t know if the problem is with my kumo app set up or what, but it would be nice if the kumo cloud server would deliver complete json…
What are the potential issues with resolving a MAC address to an IP?
@parkercat I submitted a PR to fix the issue with the default value of prefer_cache, I looked at a few other config flows and used their method to set the default value. https://github.com/dlarrick/hass-kumo/pull/39
@sambyrne I just closed that option since when I tested it looks like the arp cache doesn’t get refreshed very often and even trying to force it didn’t give a timely update. This would just add another option to retain stale settings longer. From my understanding the json file should be complete except for this address, if you manually update the json file for now by adding the ip it should work and since you are on reserved IP’s you won’t need to do it more than once. I can try to figure out a way to do this from the gui but it will probably take me a while…
Also, we know that when an IP address changes for a unit, kumo cloud servers are not notified directly from the device of this change, it appears that only the phone app detects the new ip and then updates the cloud servers. So, my question would be, if you completely blocked the internet on your LAN and also made sure that your phone was only connected to the LAN (no cellular) technically the app should be doing something to detect this new ip. I’m not sure if the app broadcasts a message on the local LAN or maybe the device broadcasts something on the local LAN and that way the app finds the new ip for communication. Unfortunately my setup at home is pretty bare so I can’t really run these kind of diagnostics but I think if we could find out what this broadcast message is we could try to listen for it…Also this is way beyond my knowledge of how to do all this in python but i really can’t think of any other way that the kumo app would find the changed local IP
@sambyrne I think the best advice for now is to set the “prefer_cache” option and hand-create or hand-edit your kumo_cache.json to insert the known addresses in the proper spot. The kumo_cache.json is just the file returned by the KumoCloud service, so it’s exactly the ‘response’ that is printed out by kumo_cloud_setup.py (in your custom_components/kumo) (minus “response:”).
Not ideal, of course, but would get you going. With prefer_cache set, it’ll never re-fetch the cache unless it’s missing. The only fields we read are: ‘serial’, ‘label’, ‘address’, ‘password’, ‘cryptoSerial’, and ‘mac’. So if you fill those in for each of your units you should be good unless your configuration changes. See example kumo_cache.json files at https://github.com/dlarrick/pykumo/tree/master/examples .
Longer term, I think it might be possible to do one of a few things:
- Look for a file alongside kumo_cache.json with some supplemental JSON to override what’s found in the cache file (keyed by ‘label’ (name) most likely, or possibly by MAC if it’s desirable to override the label). This is pretty hacky and hard to support.
- Require users whose addresses aren’t being fetched to use configuration.yaml, and allow supplying such override information in there. This idea is basically what we used to do before I wrote the code to read the config from the KumoCloud service.
- Figure out a way to provide such overrides via the GUI. As @omriasta said, this is much harder. If we can’t talk to the unit, we can’t set up the entity (it needs to know things like # of supported fan speeds). And if there’s no entity it can’t be configured. So the config options would need to be the equivalent of the other two bullets here, but implemented in the GUI. A fair amount of work.
I’m unlikely to do any of this myself. But I’d accept pull requests to do any of the above, or to add a utility to make it easier to create/edit kumo_cache.json.
Maybe one more idea, we could move the whole process of saving the cache file to the config flow, then add a second step to the config flow with one more form where the user sees the units in the json and have the opportunity to enter an IP if it’s missing… Again this is quite advanced for my level but I can give it a shot… This way we can have all the info before homeassistant tries to setup the device initially but it still doesn’t resolve the issue of ip changes. Maybe best to add a message to the form that tells users that they should set static ips for all units.
I’m curious how many HA users there are who would be unable to determine the IP address for each of their units? Honestly, I feel like the configuration.yaml approach would be comfy, but I’m just talking (can’t back it up with actual coding…)
So far as I know you’re the only one for whom the normal download-from-KumoCloud procedure isn’t working 
but maybe if there are more folks they’ll speak up.
Yep, after looking through the option for second step doesn’t look like that is an option either. I wouldn’t want to even try for an IP override in yaml because of the way the component works with multiple units (and I only have one to test on).
In case anyone else needs to do this as well, you’ll need to run the response dictionary through the save_json method that is demonstrated in the custom components directory. I figured it out, but it took a bit of digging.
Is the integration no longer on HACS? My search turned up nothing for KUMO.
Still there for me, yes.
You’re clicking the red “+” at the bottom right and searching from there, right? Searching from the “Search for repository” box up top searches in your installed repositories. I’ve made that mistake once or twice.
It’s still there in HACS sources: https://github.com/hacs/default/blob/c329ac549c04604affc407f6107bdc3d6dd9b23e/integration#L82 . I don’t know what to tell you. Maybe ask the HACS folks?
tl;dr Is this integration compatible with MHK2 equipment?
I am getting a Mitsubishi system installed and desperately want to make sure it is HA compatible. The Githup repo lists compatibility with the PAC-USWHS002-WF-2, which looks like a MHK1 system. My HVAC installed just told me that MHK1 is hard/impossible to get now and everything has moved to MHK2. If I get a MHK2 system will I be able to use this integration?
Thanks,
Omen
The MHK1 or MHK2 by themselves are not compatible (does not provide KUMO Cloud Access). The WiFi adapter PAC-USWHS002-WF-2 is still required for KUMO Cloud. and would need to be added to the MHK2 receiver.
Awesome, thank you for the info. I am double checking with HVAC to make sure that WiFi adapter is what they will use.
Just to be clear on configuration
MHK2 only…wall controller but no KUMO access
WiFi Adapter only…No wall controller, KUMO access only
MHK2 and WIFI adapter…Wall controller and KUMO access
Hope this helps to get what you want.
1 Like