Bridge HTTP-API only sporadically reachable when no internet connection is avaiable (firmware 2.4.21)

[PatrickR]

Since this thread covers the local API, your problem might be better discussed in a separate thread. Sorry.

Patrick

[PatrickR]

I’m afraid, the fix is incomplete. Even though there are no more disconnects, the bridge doesn’t fire the callbacks when the server is not connected. Is it possible that it needs the time of the sse servers or there is some other weird dependency?

Once I activated the internet connection for the bridge the callbacks started coming in:

{"timestamp": "2020-02-09T00:12:25+00:00", "nukiId": "<nukiIdRedacted>", "type": "BLE-Disconnected", "pairIndex": 0, "bleHandle": "0001"},
{"timestamp": "2020-02-09T00:12:25+00:00", "nukiId": "<nukiIdRedacted>", "type": "BLE-Disconnect", "pairIndex": 0, "bleHandle": "0001"},
{"timestamp": "2020-02-09T00:12:25+00:00", "nukiId": "<nukiIdRedacted>", "type": "BLE-ConnectionTimeout"},
{"timestamp": "2020-02-09T00:12:20+00:00", "type": "SSE-KeyturnerEventResp"},
{"timestamp": "2020-02-09T00:12:20+00:00", "type": "HTTP-Post", "nukiId": "<nukiIdRedacted>"},
{"timestamp": "2020-02-09T00:12:20+00:00", "nukiId": "<nukiIdRedacted>", "type": "SSE-KeyturnerEventReq"},
{"timestamp": "2020-02-09T00:12:20+00:00", "nukiId": "<nukiIdRedacted>", "type": "BLE-ReadStates", "pairIndex": 0},
{"timestamp": "2020-02-09T00:12:20+00:00", "type": "SSE-PushNukisResponse"},
{"timestamp": "2020-02-09T00:12:20+00:00", "type": "SSE-TimeResponse"},
{"timestamp": "2020-02-08T23:59:41+00:00", "nukiId": "<nukiIdRedacted>", "type": "BLE-TurnOnNotific", "pairIndex": 0},
{"timestamp": "2020-02-08T23:59:41+00:00", "nukiId": "<nukiIdRedacted>", "type": "BLE-Connected", "pairIndex": 0, "bleHandle": "0001"},
{"timestamp": "2020-02-08T23:59:41+00:00", "type": "BLE-Connect", "macAddr": "<macAddrRedacted>"},
{"timestamp": "2020-02-08T23:59:41+00:00", "nukiId": "<nukiIdRedacted>", "type": "BLE-Connect", "pairIndex": 0},
{"timestamp": "2020-02-08T23:59:41+00:00", "nukiId": "<nukiIdRedacted>", "type": "BLE-StateChanged", "pairIndex": 0},
{"timestamp": "2020-02-08T23:59:41+00:00", "type": "SSE-Connected", "serverNum": 3},
{"timestamp": "2020-02-08T23:59:41+00:00", "type": "SSE-PushNukisRequest", "count": 1},
{"timestamp": "2020-02-08T23:59:41+00:00", "type": "SSE-Gettime"},
{"timestamp": "2020-02-08T23:59:21+00:00", "type": "HTTP-Info"},

Note: serverConnected changed to true at exactly 0:12 UTC. So the time in the log jumped with SSE-TimeResponse

I sent a full log to the support (Ticket 1849).

/Edit: There are still disconnects but they also happen when the SSE servers are reachable.

Patrick

[stephan1 (stephan)]

I have a similar problem.
I am on bridge firmware 2.4.26 (wifi 2.1.15).
Without internet connection (block on firewall layer), the bridge api doesn’t deliver the last known state of the smartlock (with internet connection it does).
Additionally, using the app the “Verbindungsstatus” doesn’t indicate a connection between smartlock and bridge (bluetooth) without internet connection of the bridge?!?
How can I get beta firmware versions?

[PatrickR]

Get beta here:

How to become a Nuki Bridge beta tester

To become a Bridge Firmware beta tester send us a photo of the sticker on your Nuki Bridge via email to contact@nuki.io. Important Note Do not post private details like IDs of smartlocks, bridges or your Apple ID here, but only send these via E-Mail or as a private message to a Nuki team member.

The issue is not fully fixed yet.

Patrick

[PatrickR]

@Juergen
Is there any news for the fixed version for the callback issue?

Update: Didn’t receive a callback after locking the door this morning. (serverConnected was false since yesterday). After allowing the internet connection for the bridge, serverConnected jumped to true and the callback from the locking this morning fired.

Patrick

[Juergen (Jürgen Pansy)]

It’s going to be part of the 2.4.30 beta which will be released within the next 2 weeks.

[PatrickR]

Just received 2.50 (wifi still at 2.1.17). Events seem to keep coming in even though serverConnected is false. Is the fix part of 2.50?

Patrick

[Stephan (Stephan Lendl)]

This is now fixed with the newest fw version 2.5.0 (Beta)

[Stephan (Stephan Lendl)]

@PatrickR

Is the fix part of 2.50?

Just posted in the same moment.

Yes, see also:

Firmware Update: Bridge Beta 2.5.x

Release notes: HTTP-API callbacks working if the bridge is used offline A bridge which can reach our server (and is in the Beta group) will automatically update (checking for an update 1 hour after restart and then all 24 subsequent ours).

[PatrickR]

Tested the current beta for several days now. The connection is stable, events keep coming in. Beautiful.

Patrick

[PatrickR]

After the update to 2.5.2 (wifi 2.1.17) a similar problem seems to be back. The bridge goes into some kind of boot/connect loop: It is pingable for several seconds and after about 15s it is not responding. Enabling the internet connection ended the loop.

{"timestamp": "2020-05-06T14:03:37+00:00", "type": "HTTP-Info"},
{"timestamp": "2020-05-06T14:03:22+00:00", "type": "SSE-PushNukisResponse"},
{"timestamp": "2020-05-06T14:03:22+00:00", "type": "SSE-TimeResponse"},
{"timestamp": "2020-05-06T14:03:16+00:00", "type": "SSE-Connected", "serverNum": 1},
{"timestamp": "2020-05-06T14:03:16+00:00", "type": "SSE-PushNukisRequest", "count": 1},
{"timestamp": "2020-05-06T14:03:16+00:00", "type": "SSE-Gettime"},
{"timestamp": "2020-05-06T14:03:12+00:00", "type": "WLAN-Connected", "ipAddr": "192.168.150.72"},
{"timestamp": "2020-05-06T14:02:21+00:00", "type": "WLAN-Connect"},
{"timestamp": "2020-05-06T14:02:21+00:00", "type": "WLAN-Init"},
{"timestamp": "2020-05-06T14:02:19+00:00", "type": "WLAN-WiFiRestart"},
{"timestamp": "2020-05-06T14:02:19+00:00", "type": "WLAN-Error", "unconnCnt": 181, "unansMsg": 0, "lastMsg": 0, "pings": 0},
{"timestamp": "2020-05-06T14:01:29+00:00", "type": "WLAN-Connect"},
{"timestamp": "2020-05-06T14:01:29+00:00", "type": "WLAN-Init"},
{"timestamp": "2020-05-06T14:00:24+00:00", "type": "WLAN-Disconnected"},
{"timestamp": "2020-05-06T14:00:24+00:00", "type": "WLAN-Connect"},
{"timestamp": "2020-05-06T14:00:24+00:00", "type": "WLAN-Init"},
{"timestamp": "2020-05-06T14:00:17+00:00", "type": "WLAN-Connected", "ipAddr": "192.168.150.72"},
{"timestamp": "2020-05-06T13:59:20+00:00", "type": "WLAN-Disconnected"},

Patrick

[Stefan_Reiterer]

Hi @PatrickR,
thanks for your provided feedback.

Can you please be a bit more specific about the applied steps and your setup?

• Is this the direct result after the firmware update? Or did anything else happened in between?
• Is any additional Nuki device paired with the Bridge (f.ex. a Smart Lock)? If yes, which firmware version is running there?
• Is the Internet connection properly set up on the Bridge?

Your input is highly appreciated - thanks.

[PatrickR]

Hi Stefan,

you are right, the issue might not be related to 2.5.2. Unfortunately, the situation is rather complex.

Before today my setup was as follows:

• Nuki bridge connected to a ssid in a separate vlan. In this vlan, DHCP is available, the DNS is reachable but the bridge is not routed to the internet.
• One Nuki Lock was connected to the bridge.
• A home automation system is connected to the local(!) bridge API including callbacks.
• Bridge version 2.5.1, wifi version 2.1.17
• The connection from the home automation system to the bridge was almost stable:
  2020-05-02 01:06:53 NUKIBridge NUKIBRIDGE state: connected state connected
  2020-04-28 13:46:06 NUKIBridge NUKIBRIDGE state: connected state connected
  2020-04-28 12:00:50 NUKIBridge NUKIBRIDGE state: not connected state not connected
  2020-04-24 14:29:18 NUKIBridge NUKIBRIDGE state: connected state connected
  2020-04-24 14:28:47 NUKIBridge NUKIBRIDGE state: not connected state not connected
  2020-04-21 20:39:11 NUKIBridge NUKIBRIDGE state: connected state connected
  2020-04-21 20:37:41 NUKIBridge NUKIBRIDGE state: not connected state not connected
  2020-04-21 17:24:19 NUKIBridge NUKIBRIDGE state: connected state connected
  2020-04-21 17:23:49 NUKIBridge NUKIBRIDGE state: not connected state not connected
  2020-04-20 22:02:12 NUKIBridge NUKIBRIDGE state: connected state connected
  2020-04-20 22:01:49 NUKIBridge NUKIBRIDGE state: not connected state not connected
  2020-04-11 05:25:49 NUKIBridge NUKIBRIDGE state: connected state connected
  2020-04-11 05:25:32 NUKIBridge NUKIBRIDGE state: not connected state not connected
  2020-04-10 18:51:01 NUKIBridge NUKIBRIDGE state: connected state connected

Because of a mechanical fault of the lock I received a replacement today. Since It took me quite a while to get everything to work again I might miss some steps:

• I added the new lock to the app, calibrated it and updated the firmware to 2.6.6.
• I tried to add the lock to the bridge via the app. Getting the bridge connected in maintenance mode failed several times. After about 10 attempts it worked.
• I deleted the old lock and added the new one. The app announced a bridge reboot.
• I noticed that the connection from the home automation system to the bridge didn’t work. I tried several things (enabling internet access to the bridge etc.) and finally got a connection. I forced a firmware update through the local API and updated to 2.5.2. I disabled the internet access again.
• After again failing to connect to the bridge via lan/wifi, I managed to get into maintenance mode again and reset the bridge to factory defaults. I configured everything again (ssid, psk, api key, enabled http api, disabled cloud api magic, added the lock). But the connection from the home automation system didn’t work. I pinged the bridge and received a bunch of unreachables then about 15 echo replies then a bunch of unreachables, 15 replies etc. So I activated the internet connection. After about half a minute, the lock was connected to the home automation system and pingable without packet loss.

As I said, It was a rather complicated process and I’m not sure I got it 100% right but I hope this helps. Definitely helpful would be a higher log level for the bridge logs.

Patrick

[Stefan_Reiterer]

Hi @PatrickR:

Thanks for your detailed response. Please check following points:

1. Please check the log of the Bridge, which is accessible through the HTTP API -> /log
   Please comment the results to the post here.
2. Make sure that the Gateway-IP is pingable by the Bridge, as the Bridge detects herewith whether or not the WiFi connection is up and running - this was actually introduced in Bridge 2.0 beta 2.5.1 and is therefore also featured in the lastest Bridge 2.0 beta 2.5.2.

Thanks!

[PatrickR]

Hi!

@Stefan_Reiterer

• Please check the log of the Bridge , which is accessible through the HTTP API -> /log
  Please comment the results to the post here.

See post #25 but don’t expect any useful debugging information from the log. But once again: A detailed(!) log would really help debugging.

@Stefan_Reiterer

• Make sure that the Gateway-IP is pingable by the Bridge, as the Bridge detects herewith whether or not the WiFi connection is up and running - this was actually introduced in Bridge 2.0 beta 2.5.1 and is therefore also featured in the lastest Bridge 2.0 beta 2.5.2.

The gateway is and always was pingable.

Patrick

[PatrickR]

Today, I had to reboot the access point the bridge was connected to. After reconnection, the bridge went into the connect/disconnect-loop again. I had to temporarily activate the internet access for the bridge and power cycle it.

I would really appreciate, if this problem could finally be solved. After all the time consuming problems with the bridge and I wonder if it’s possible to use Nuki products without a part time administrator.

Patrick

[PatrickR]

Since I just encountered an about 10 minute bridge reconnect-/boot loop: Are there any plans to work on a fix or is the strategy to wait if the broken code fixes itself?

Patrick

[Raimund_Scheiber]

I also have these problems. When deactivating internet access to the bridge, my bridge disconnect/connect about every 210 seconds. When activating internet access, the problem disappears.
Firmware of this bridge is 1.15.1
I’m not happy to let have the bridge internet access…

Raimund

[Junior (Robert)]

@Raimund_Scheiber

ot happy to let have the bridge internet access…

Raimund

any Updates to this topic? I hope this will be fixed in the future. It doesn´t make sense to have a local API when the architecture need a internet connection.

If the bridge needs a internet connection can anyone describe with ports / URLs/ IPs are nessasary?

[PatrickR]

AFAICS, they fixed it. Blocking all internet traffic from the bridge and it works fine.

Patrick