Nuki Bridge Timeout Error

[kloibs]

Hi there! I recently replaced my router and have a my IoT devices (Homebridge and the Nuki Bridge included) on their own VLAN.

My other HomeKit devices respond to Homebridge without issue, but my Nuki Bridge does not. In Homebridge, I get a warning like this:

[09/06/2024, 11:23:331 [Nukil Nuki -_Bridge XXXXXXXX: warning: request 1: error: timeout after 15 seconds

Any ideas? User error? Thanks in advance!

[ebaauw]

Try and power-cycle the Nuki bridge. I probably needs to re-register with the Nuki server with its new IP address, before Homebridge NB can reach it.

[kloibs]

Hi @ebaauw and thanks for the usual quick response! I’ve tried power cycling the bridge with no success, but I’ll give it another shot when I’m back home later this week. Thanks again!

[kloibs]

I’ve tried power cycling the bridge and unfortunately get the same error in Homebridge.

[ebaauw]

What's the output of nb discover? Does that actually list the new IP address in the VLAN? And of nb info?

Note that the Nuki bridge and Homebridge NB need to use the same public IP address for discovery to work.

[kloibs]

nb discover returned the following: "bridgeId": [bridge ID], "dateUpdated": "2024-06-14T10:29:082", "ip": "10.0.1.168", "port": 8080

nb info returned the following: nb:fatal:Missing host. Set NB_HOST or specify -H.

[ebaauw]

As instructed, use nb -H 10.0.1.168 info. It will complain about the token missing, so you need to press the bridge button and run nb -H 10.0.1.168 auth to get it.

[kloibs]

I’ve tried completing per your instructions. It comes back with nb auth: press button on Nuki bridge to obtain token

Upon pressing the button on the bridge, Terminal shows the six digit token, but after using nb -H 10.0.1.168 info it cycles back and says no token is found.

[ebaauw]

So issue nb -H x.x.x.x -T xxxxxx info, substituting the ip address and token. Are you running nb from the server running Homebridge NB?

[kloibs]

Yeah, running on the same server. Returned the following:

"bridgeType": 142024-06-14T16:32:45+00:00*, "currentTime": "ids": { "hardwareId": XXXXXXXXX, "serverId": XXXXXXXXX "scanResults": ( "deviceType": 0, "name": "Nuki XXXXXXXX", "nukild": XXXXXXXXX, "paired": true, "rssi": -62 1. "deviceType": 2, "name": "Nuki_Opener_XXXXXXXX", "nukild": XXXXXXXXX, "paired": true, "rssi": -72 "serverConnected": true, "uptime": 21771, "versions": { "firmwareversion"： "2.18.0". "wifiFirmwareVersion": "2.4.0" 1. "wlanConnected": true

[ebaauw]

Looks like the Nuki bridge is responsive alright to the Homebridge NB server. Maybe the cached Homebridge accessory still links to the old IP address of the bridge (although I would expect Homebridge NB to pick up the new IP address through its equivalent of nb discovery.

Could you check the accessories/cachedAccessoires.* file for Homebridge NB to see if the bridge accessory still holds the old IP address? It's a JSON text file. The file extension is the Mac address (or username) of the child bridge, or no extension when Homebridge NB runs in the main Homebridge. If that's too complex, you could also delete the cached accessory for the Nuki bridge using the Homebridge UI and let Homebridge NB re-discovery your bridge. Note however, that this will remove any associations with HomeKit groups, scenes, rooms, and automations.

[kloibs]

More than happy to check the JSON file, but not exactly sure how to 🥲

I was hoping to avoid re discovery for precisely the reason you mentioned, but unfortunately I may have to go that route.

[ebaauw]

I might be able to see what's happening If you could set Log Level on the bridge accessory to 2 (using Eve or another decent HomeKit app), run Homebridge in DEBUG mode, and capture a full log from Homebridge restart to 5 - 10 minutes running.

Alternatively, attach (!) the cachedAccessories file here (or PM it to me on Discord), so I can have a look.

[kloibs]

I appreciate your help with this, truly! I took another look and I overestimated how many automations I had. Thank you regardless! Reinstalled and back up and running 👍🏼