Closed mikeygnyc closed 3 years ago
That is extremely odd. If you go into the KumoCloud app on your phone, does it show as being successfully connected to WiFi? As far as I know the app gets the units' IP address from the exact same query against the KumoCloud servers.
So it shows them connected but always gives me this odd popup about "Enable Wi-Fi for Faster Connection" while loading settings. I tried playing around and disabling bluetooth on the phone and still get the same message but they connect anyway. I also tried zapping my setup from the app and completely redoing it from scratch and no change. My Unifi network management page shows them happily connected to WiFi and programming them through the cloud also is successful (albeit slooooow). I'm not really sure what's going on.
Two other thoughts:
I could add a config option to override the IP address from configuration.yaml . I'm not planning any other Kumo work, though, so it'd be a while. A pull request to do so would be welcomed.
The interfaces are PAC-USWHS002-WF-1 (not the older design but the first rev of the newer design). I wonder if that’s a quirk of them?
If I get the time and can get my python up to snuff I can try and submit a PR.
hey @mikeygnyc I ran some tests on updating the ip in the json file and it looks like it works regardless of the ip. Maybe a better way would be to resolve the IP from the arp table and that way it could update dynamically without user intervention, see my idea here https://github.com/dlarrick/hass-kumo/issues/32 Not sure if you could send in a sample of your json file (please redact the sensitive info (username, password, serial crypto etc.) just so I can see if your file is identical and how to write the ip address to it.
@omriasta I re-ran the setup from scratch with v0.2.1 and the IPs fill and everything auto-discovers like magic. I don't know if there was a firmware update since I last tried or what. Either way, I'm attaching kumo_cache.json.txt what is essentially my config looks like without the IPs (plus redactions of course; I noticed that some of the keys in the JSON file are actually the SNs so I made sure to redact them but add a unique ID to each). I had to rename it a .txt file since for some reason GitHub doesn't like JSON.
Wow...that's much larger than mine..probably because you have schedules in kumo cloud which I don't. If it's working for you that's great....still might pursue this because it will help whenever the IP changes.
Well, this one got me now too. I curious if anyone figured out any fixes since last year. I'm happy to provide any details from my system if it helps debug. Basically, I think this is a Kumo Cloud problem though, they are not providing the local IP addresses (hence all the attempted tricks to get them from ARP based on MAC). What I'm curious of though, is how to force a reset or something with them. I had a power outage, two of my devices broke. I decided to finally setup static reservations, so they all changed IP addresses, and now NOTHING works :(
For what it is worth, I just did a quick console check to see what is happening at app.kumocloud.com
Asking cloud for any news about devices: 9634P0086100122F,9534P0085100069F,9634P0086100123F,9634P0086100131F No IP address known for 9634P0086100131F Sent command to Studio A Kumo via cloud.
So yeah, even their app is not using direct to device access using a local IP. I'm going to keep digging but welcome anyone's thoughts on this!
The quick fix is to edit the IP addresses (which you know, since you set up static DHCP) into the kumo_cache.json file. Or just wait; past evidence is that the KumoCloud service will eventually catch up. A long term nicer fix might be to offer an input in the setup GUI for the user to provide an override IP address for each unit. Pull requests welcome :-)
Oh, I tried that, for some reason, but it kept updating the cache file overwriting my manual change, I'm not sure why. I also just deleted the cache file a bunch too trying to get it to refresh from the kumo service, nothing. I've completely wiped out and reset and re-added all my units a couple times too. I think I might just be losing my mind. It's like the harder you try with kumo, the worse you make it. Now, when I try to add to HA, it says bad username / password. I know it's good though, I can log into the app on my phone and app.kumocloud.com too. I think perhaps I locked myself out or something from messing around so much. I dunno, I'm going to do just what you say. Not touch it for a while, and see if things calm down.
You need to set "prefer_cache" or it'll do as you're seeing, overwrite the kumo_cache.json with a new one from the service. It would be a good enhancement to do a little more validation of the downloaded JSON (at least verifying IP addresses are present) before overwriting.
Something strange is going on with Kumo Cloud. After blowing everything up, I was unable to even log back in via HA. As I posted about before, I know my username / password are good as I could log in via my phone and the app.kumocloud.com page. I did some tracing, and then manually updated the kumo integration. I don't know if this was just timing, and whatever problem with kumo cloud cleared up, or if this fixed the problem. I would have thought that if this was a problem, it would be affecting tons of people though! Anyway, I added Origin and Referer headers, bam, I could log in again. Well, sort of working, I can connect now, but same problem as state above in the original part of this thread, I'm not getting an IP address in the config from kumo cloud. That part I'm going to wait a few more days to see if it clears up. @mikeygnyc did this ever clear up for you?
url = "https://geo-c.kumocloud.com/login" headers = { "Accept": "application/json, text/plain, */*", "Accept-Encoding": "gzip, deflate, br", "Accept-Language": "en-US,en", "Content-Type": "application/json", "Origin": "https://app.kumocloud.com", "Referer": "https://app.kumocloud.com/", }
In an interactive Python shell I did:
>>> from pykumo import KumoCloudAccount
>>> account = KumoCloudAccount.Factory()
Kumo Cloud username: <my-email>
Password: <my-password>
>>> account.try_setup()
True
>>> conf = account.get_raw_json()
And at that point conf
has the expected information. So it doesn't appear additional headers are needed, at least not for everyone.
This one is killing me! I've spent way to much time messing around trying to get this resolved. I have to though, as we rely on HA for all our home climate control, and the wife is starting to get grumpy with me :( I welcome any further thoughts here, as I have reached a new end. I'm going to try to call Mitsubishi today too, and probably have to dig into the pykumo library a bit also to see if I can manually figure out what's happening there. Here is what I know:
2021-07-09 06:27:23 INFO (MainThread) [custom_components.kumo] Loaded config from local cache
2021-07-09 06:27:23 INFO (MainThread) [homeassistant.components.climate] Setting up climate.kumo
2021-07-09 06:27:23 INFO (MainThread) [pykumo.pykumo] Use timeouts=(10.0, 30.0)
2021-07-09 06:27:24 WARNING (SyncWorker_1) [pykumo.pykumo] Error retrieving status
2021-07-09 06:27:24 WARNING (MainThread) [custom_components.kumo.climate] Kumo Greatroom Kumo could not be set up
2021-07-09 06:27:24 INFO (MainThread) [pykumo.pykumo] Use timeouts=(10.0, 30.0)
2021-07-09 06:27:24 WARNING (SyncWorker_3) [pykumo.pykumo] Error retrieving status
2021-07-09 06:27:24 WARNING (MainThread) [custom_components.kumo.climate] Kumo Guestroom Kumo could not be set up
2021-07-09 06:27:24 INFO (MainThread) [pykumo.pykumo] Use timeouts=(10.0, 30.0)
2021-07-09 06:27:24 WARNING (SyncWorker_2) [pykumo.pykumo] Error retrieving status
2021-07-09 06:27:24 WARNING (MainThread) [custom_components.kumo.climate] Kumo Bedroom Kumo could not be set up
2021-07-09 06:27:24 INFO (MainThread) [pykumo.pykumo] Use timeouts=(10.0, 30.0)
2021-07-09 06:27:24 WARNING (SyncWorker_4) [pykumo.pykumo] Error retrieving status
2021-07-09 06:27:24 WARNING (MainThread) [custom_components.kumo.climate] Kumo Studio A Kumo could not be set up
2021-07-09 06:27:24 WARNING (MainThread) [custom_components.kumo.climate] Kumo could not set up any indoor units (try 1 of 10)
2021-07-09 06:27:24 WARNING (MainThread) [homeassistant.components.climate] Platform kumo not ready yet: None; Retrying in background in 30 sec
onds
I'll keep at it, but boy, if anyone has I suggestions, I'll take 'em! :) Thanks!
One thing I ran into in the past is kumo devices would block traffic from specific ips on the local network. When you tested ping, are you testing from your HA box? What happened to me is that only the HA box was being blocked by the controller, so when I pinged from my laptop no problem would appear....but any traffic coming from HA was not getting through.
On Fri, Jul 9, 2021, 6:55 AM Daniel Goepp @.***> wrote:
This one is killing me! I've spent way to much time messing around trying to get this resolved. I have to though, as we rely on HA for all our home climate control, and the wife is starting to get grumpy with me :( I welcome any further thoughts here, as I have reached a new end. I'm going to try to call Mitsubishi today too, and probably have to dig into the pykumo library a bit also to see if I can manually figure out what's happening there. Here is what I know:
- Confirmed the object I get back from kumo cloud does not contain the local IP addresses of my units. I confirmed this three ways, first manual curl command, second the pykumo commands provided by Doug above and finally by using the app.kumocloud.com in chrome and looking at the console. All three show no local IPs. The app however will then send the instructions to the cloud service, and the devices will pick up the change eventually.
- Confirmed the devices are online and working. I have removed them all completely (a couple times now actually) and put them all back in. My network management app shows them online no problem, I can hit them with curl and get a 200 OK, ICMP ping, and they are checking in with the services and picking up changes from there just fine.
- I have manually added the address into the cache file directly, and updated the setting to prefer local cache. This does change the error! But, it's still not loading them up. Now I get:
2021-07-09 06:27:23 INFO (MainThread) [custom_components.kumo] Loaded config from local cache 2021-07-09 06:27:23 INFO (MainThread) [homeassistant.components.climate] Setting up climate.kumo 2021-07-09 06:27:23 INFO (MainThread) [pykumo.pykumo] Use timeouts=(10.0, 30.0) 2021-07-09 06:27:24 WARNING (SyncWorker_1) [pykumo.pykumo] Error retrieving status 2021-07-09 06:27:24 WARNING (MainThread) [custom_components.kumo.climate] Kumo Greatroom Kumo could not be set up 2021-07-09 06:27:24 INFO (MainThread) [pykumo.pykumo] Use timeouts=(10.0, 30.0) 2021-07-09 06:27:24 WARNING (SyncWorker_3) [pykumo.pykumo] Error retrieving status 2021-07-09 06:27:24 WARNING (MainThread) [custom_components.kumo.climate] Kumo Guestroom Kumo could not be set up 2021-07-09 06:27:24 INFO (MainThread) [pykumo.pykumo] Use timeouts=(10.0, 30.0) 2021-07-09 06:27:24 WARNING (SyncWorker_2) [pykumo.pykumo] Error retrieving status 2021-07-09 06:27:24 WARNING (MainThread) [custom_components.kumo.climate] Kumo Bedroom Kumo could not be set up 2021-07-09 06:27:24 INFO (MainThread) [pykumo.pykumo] Use timeouts=(10.0, 30.0) 2021-07-09 06:27:24 WARNING (SyncWorker_4) [pykumo.pykumo] Error retrieving status 2021-07-09 06:27:24 WARNING (MainThread) [custom_components.kumo.climate] Kumo Studio A Kumo could not be set up 2021-07-09 06:27:24 WARNING (MainThread) [custom_components.kumo.climate] Kumo could not set up any indoor units (try 1 of 10) 2021-07-09 06:27:24 WARNING (MainThread) [homeassistant.components.climate] Platform kumo not ready yet: None; Retrying in background in 30 sec onds
I'll keep at it, but boy, if anyone has I suggestions, I'll take 'em! :) Thanks!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dlarrick/hass-kumo/issues/14#issuecomment-877098616, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2GPSD2FLGHK2K7OP22BSLTW3IQZANCNFSM4KN7CEIQ .
One thing to try: in your own copy of pykumo.py (nested deep in the virtualenv directory) change the code around line 108 to look like:
try:
print(f"raw_status for {self._name}: {raw_status}")
self._status = raw_status['r']['indoorUnit']['status']
self._last_status_update = now
except KeyError as e:
_LOGGER.warning(f"Error retrieving status: {e}")
return False
(the 2 print statements and as e
being new). This will give you more info about what's going wrong.
It seems like, even with the proper IP, it's not getting the expected response from the indoor units.
As always, very useful help here :) I got it working, for now. Kumo Cloud is definitely still broken. But, using the instructions above:
raw_status for Studio A Kumo: {'_api_error': 'device_authentication_error'}
Well, that's no good. I compared the cache to a fresh config pull from Kumo Cloud, and sure enough the passwords changed. I don't know what causes or when these passwords change, but they did. I manually updated the passwords for all my units, in the cache file, and BAM!
2021-07-09 07:22:58 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new climate.kumo entity: climate.greatroom_kumo
2021-07-09 07:22:58 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new climate.kumo entity: climate.guestroom_kumo
2021-07-09 07:22:58 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new climate.kumo entity: climate.bedroom_kumo
2021-07-09 07:22:58 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new climate.kumo entity: climate.studio_a_kumo
Now, I guess this will work until the cache tries to update, and wipes out all my IPs.
Thanks again for the help.
If prefer_cache is set to true it should not overwrite, you can always make a copy of the file or change permissions to make sure you don't lose it.
On Fri, Jul 9, 2021, 7:29 AM Daniel Goepp @.***> wrote:
As always, very useful help here :) I got it working, for now. Kumo Cloud is definitely still broken. But, using the instructions above:
raw_status for Studio A Kumo: {'_api_error': 'device_authentication_error'}
Well, that's no good. I compared the cache to a fresh config pull from Kumo Cloud, and sure enough the passwords changed. I don't know what causes or when these passwords change, but they did. I manually updated the passwords for all my units, in the cache file, and BAM!
2021-07-09 07:22:58 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new climate.kumo entity: climate.greatroom_kumo 2021-07-09 07:22:58 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new climate.kumo entity: climate.guestroom_kumo 2021-07-09 07:22:58 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new climate.kumo entity: climate.bedroom_kumo 2021-07-09 07:22:58 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new climate.kumo entity: climate.studio_a_kumo
Now, I guess this will work until the cache tries to update, and wipes out all my IPs.
Thanks again for the help.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dlarrick/hass-kumo/issues/14#issuecomment-877119589, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2GPSHASVGY325QJHM6XTDTW3MTDANCNFSM4KN7CEIQ .
@omriasta Ah, I would have figured that prefer cache would just favor cache, but not lock it down forever. I know @dlarrick is busy and probably won't change that any time soon, but I think that would be a good place for improvement. I keep meaning to dig into the code of this project more...I just need to get inspired and stop banging my head with problems that turn out to be the service not the software ;) Yes, I take a nightly backup anyway, so I'm pretty much covered if things change, it would just be annoying again...but at least I know now what I think I would need to do. Thanks for the info.
I originally wrote the config_flow for this with his help and I am pretty sure that "prefer_cache" will not overwrite the cache ever unless the file is not there to begin with....
On Fri, Jul 9, 2021 at 9:29 AM Daniel Goepp @.***> wrote:
@omriasta https://github.com/omriasta Ah, I would have figured that prefer cache would just favor cache, but not lock it down forever. I know @dlarrick https://github.com/dlarrick is busy and probably won't change that any time soon, but I think that would be a good place for improvement. I keep meaning to dig into the code of this project more...I just need to get inspired and stop banging my head with problems that turn out to be the service not the software ;) Yes, I take a nightly backup anyway, so I'm pretty much covered if things change, it would just be annoying again...but at least I know now what I think I would need to do. Thanks for the info.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dlarrick/hass-kumo/issues/14#issuecomment-877188315, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2GPSCTSP3FHB4YKZUEQWDTW32THANCNFSM4KN7CEIQ .
-- Omri Asta
Should be fixed (worked around) in v0.2.7-beta released today. If not, feel free to reopen.
I'm not sure if this is a quirk of my particular system or something else entirely, but the "address" field is missing when the system config gets downloaded from KumoCloud. There are still MAC addresses listed but no IP. I have two indoor units so it was pretty trivial to manually add the IPs to the config but this seems like an extra step.