-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integration Failed to Setup when no internet #165
Comments
Hmm that's odd. It should not contact Kumo Cloud at all, ever, once initially set up, if "prefer cache" is turned on. If that's no longer true, we should definitely fix it. I suppose it's possible Mitsubishi has changed something such that the indoor units lose their IP address if they can't phone home. If that's what's going on here, not much we can do about it. |
Yeah, our internet will remain down until Saturday, so if there is something I can pull from the logs that could help here, let me know. |
If you're willing, follow the procedure on the pykumo README, supplying it with your kumo_cache.py rather than having it prompt you. Then see if you can talk to your indoor unit(s). That should tell us if the problem is with hass-kumo or if they're just inaccessible when offline. |
I will give that a shot. In the meantime, here is the exception that is getting logged when trying to reload the integration. It looks like it may have something unhandled in the flow that throws when internet connectivity is down:
|
Ok, so I dug into my core.config_entries file, and I did not have prefer_cache set to true. I changed that and rebooted, and everything is back online. This may be an opportunity for a fallback mode when perfer_cache isn't turned on to prefer the cache still when the internet can't be reached. Also, there isn't a way to set prefer_cache from the UI after initial setup, from what I can find. Is that true? |
I'm glad it's working for you now, and I hope your Internet comes back w/o issue. The behavior here is the result of evolution of control, and also choosing strategy in the face of unreliability. Originally it was in YAML and people could override the IP address, which units to control, even the "password" that's used at a low level. But discoverability is better for the majority of folks so now it gets those things from the cloud -- which usually works. But yeah, some different behavior might be preferable:
|
I recently had a significant internet outage and in the past this integration worked fine in that instance, 100% locally. This time around it is showing a “failed to setup” message and all my units are “unavailable”. There is probably an opportunity to test under these circumstances and ensure setup doesn’t rely on the cloud platform.
The text was updated successfully, but these errors were encountered: