Skip to content
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

Closed
donavanbecker opened this issue Jan 20, 2022 · 10 comments
Labels
bug Something isn't working

Comments

@donavanbecker
Copy link
Collaborator

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:

[Lutron] Could not connect to discovered hub: got tired of waiting
Error: Timed out waiting for bridge to appear
    at Timeout._onTimeout (/usr/local/lib/node_modules/homebridge-lutron-caseta-leap/src/BridgeManager.ts:23:31)
    at listOnTimeout (node:internal/timers:557:17)
    at processTimers (node:internal/timers:500:7)
[1/20/2022, 12:01:21 PM] [Lutron] Child bridge process ended

Plugin Config:

Screenshots:

Environment:

  • Plugin Version:
  • Homebridge Version: v1.4.0-beta.7
  • Node.js Version: v16.13.2
  • NPM Version: v8.3.1
  • Operating System: macOS
@donavanbecker donavanbecker added the bug Something isn't working label Jan 20, 2022
@thenewwazoo
Copy link
Owner

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.

@thenewwazoo
Copy link
Owner

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 new call just... doesn't work? I have nfi.

@donavanbecker
Copy link
Collaborator Author

Not a huge deal as long as your plugin is put in a child bridge so it's not restarting all of homebridge.

@thenewwazoo
Copy link
Owner

thenewwazoo commented Jan 27, 2022

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. :)

@khowell20454
Copy link

khowell20454 commented Jan 30, 2022

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.

[Lutron] Could not connect to discovered hub: got tired of waiting
Error: Timed out waiting for bridge to appear
at Timeout._onTimeout (/usr/local/lib/node_modules/homebridge-lutron-caseta-leap/src/BridgeManager.ts:23:31)
at listOnTimeout (node:internal/timers:557:17)
at processTimers (node:internal/timers:500:7)
[1/20/2022, 12:01:21 PM] [Lutron] Child bridge process ended

@thenewwazoo
Copy link
Owner

Can you please enable debug logging and attach a complete log?

@donavanbecker
Copy link
Collaborator Author

@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.

@HulacSt
Copy link

HulacSt commented Feb 3, 2022

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.

@readybeginn
Copy link

I'm having a similar issue. Rpi3B running homebridge 1.4.0. When opening settings for initial configuration, it times out trying to load them.

image

@BarnesGH
Copy link

This is what it does when using Hoobs as well (which I know is not currently supported unfortunately)

thenewwazoo added a commit that referenced this issue Dec 14, 2022
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

6 participants