Zero Conf problems - second bridge detected

[mkunzmann]

Zero Config approach in the plugin causes some issues on my end.

First some background: I'm stuck behind a Carrier Grade NAT with multiple changing external IPs.

Usually the https://api.nuki.io/discover/bridges does not return anything, but sporadically it returns information about my bridge, but in the same reply there is a second bridge returned.

Now after many restarts of the homebridge to trigger the discovery mechanism I got my bridge detected and the plugin was able to connect after pressing the button on the bridge.

Everything works perfectly.

But since then the plugin also starts spamming the logs with complaints about the second bridge:

[9/27/2021, 6:33:03 PM] [Nuki] warning: Bridge_xxxxxxxx: request 2614: error: timeout after 60 seconds [9/27/2021, 6:33:03 PM] [Nuki] warning: timeout after 60 seconds [9/27/2021, 6:33:03 PM] [Nuki] Bridge_xxxxxxxx: press Nuki bridge button to obtain token [9/27/2021, 6:33:03 PM] [Nuki] Bridge_xxxxxxxx: request 2634: GET /auth [9/27/2021, 6:33:03 PM] [Nuki] warning: Bridge_xxxxxxxx: request 2634: error: timeout after 60 seconds [9/27/2021, 6:33:03 PM] [Nuki] warning: timeout after 60 seconds [9/27/2021, 6:33:03 PM] [Nuki] Bridge_xxxxxxxx: press Nuki bridge button to obtain token [9/27/2021, 6:33:03 PM] [Nuki] Bridge_xxxxxxxx: request 2584: GET /auth [9/27/2021, 6:33:03 PM] [Nuki] warning: Bridge_xxxxxxxx: request 2584: error: timeout after 60 seconds [9/27/2021, 6:33:03 PM] [Nuki] warning: timeout after 60 seconds

And the request are getting more and more every day.

Anything I can do to make the plugin forget that bridge?

[ebaauw]

I haven't looked into the details for Nuki, but usually these cloud-based discovery services work by devices registering themselves under the public IPv4 address. Clients querying the service receive the registrations under the public IPv4 address used by the client. If your public IPv4 address changes, it might take a while for the devices to renew their registrations, rendering the device invisible to clients. If your ISP shares "your" public IPv4 address with others, you might discover devices belonging to your Internet neighbours.

In homebridge-hue, I added a check wether the discovered bridges/gateways are actually reachable, discarding them if they aren't. I'll see if I can do something similar here.

Worse case, I need to introduce a hosts config.json setting to specify your Niki bridge(s) and disable automatic discovery. While that solves the issue of shared public IPv4 address, it will break if you bridge gets a new (local) IP address.

[ebaauw]

In v1.1.11.

[mkunzmann]

Thanks a lot for the quick fix. Discarding the unreachable bridge fixed the logging problem for me.

Autodiscover can always be problematic, but this would be not very urgent, since it is up and running now.