-
Notifications
You must be signed in to change notification settings - Fork 27
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
Could not connect to discovered hub: got tired of waiting - Causing Homebridge Loop Restart #10
Comments
Thanks for the report. If you discover anything more than what we discussed on Discord, please let me know. I'm continuing to look into this. |
This still has me totally flummoxed. I've stuck trace logging in the code, and my hunch is right: the PicoRemote constructor is awaiting the bridge, and throwing when it times out, but for some reason the try-catch block around the |
Not a huge deal as long as your plugin is put in a child bridge so it's not restarting all of homebridge. |
Okay, so I get this now. I'm using an IIFE inside the constructor to enable awaiting the bridge. This detaches the constructor context from the timeout that happens. In short: trying to do complicated things in the constructor is a code smell anyway, and I should probably refactor this to not be fake-OOP with classes I instantiate and then throw away. Fixing this is going to require a refactor to clean up the above. It bugs the shit out of me that the plugin crashes, though. :) |
Same issue here, just installed this plugin today with all of the credentials and getting the same response in Homebridge. Tried switching Homebridge to insecure as mentioned in another issue but did not fix. I am using a non-pro version of the Lutron Caseta hub.
|
Can you please enable debug logging and attach a complete log? |
@khowell20454 , I got this when there was no internet going to homebridge. I would guess yours is different. You may want to open another issue and attach logs as @thenewwazoo has requested. |
I was having a similar issue on 2.2.1 with homebridge 1.4 running on a raspberry pi 0w. I switched to a raspberry pi 3b on LAN and now it's working just fine. Not sure if it's the LAN or increased computing power that helped but I can play with it tomorrow. |
This is what it does when using Hoobs as well (which I know is not currently supported unfortunately) |
This change refactors the startup code so that filtered devices are removed from HomeKit. This is done by storing cached accessories, and then unregistering them when they're detected on the bridge. Cached accessories that are *not* discovered on the bridge won't be removed, however. Cache invalidation is hard. Anyway, this should also make startup a lot less brittle, as constructors are now synchronous and initialization is async, and we treat future things in the future. Fixes #10 Fixes #65
Describe The Bug:
When using internet and homebridge restart... this can happen.
To Reproduce:
disconnect internet and network, restart homebridge.
Expected behavior:
catch error and just log, not cause homebridge to restart.
Logs:
Plugin Config:
Screenshots:
Environment:
The text was updated successfully, but these errors were encountered: