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

Nuki APIs Bridge HTTP-API
1

I am currently experiencing huge problems accessing the (local) bridge HTTP-API when the bridge can’t access the internet. The firmware version is 2.4.21 (wifi: 2.1.13).

-Judging by the logs of my access points, the bridge constantly disconnects and reconnects from the wifi. The readings are inconclusive though, might also be power saving.
-From the perspective from the API client, there is either no route to the bridge or the connection to the api times out.
-These issues only happen if serverConnected is false.
-The bridge uptime does not reset, so it doesn’t seem to reboot.
-After a successful connection during the serverConnected-false-period it takes between minutes to hours till the client is disconnected again. From disconnect to connect it takes up to 10 minutes.
-Currently, the last disconnect was about 7 hours ago.

Patrick

2

Hey,
i can confirm this with the Android Software API.
If i block WAN Traffic to the SW Bridge then only the Commands /list and /info are working.

A /lockAction or /lockState call is running endless without any action happening.

When i unblock the WAN Traffic to the Phone eveything is working again.

Best
Paul

3

Noticed the same here as my internet was down las weekend. Please explain why this is the case, I have explicitly not set up cloud control.

Maybe a bug due to the unavailability of NTP? (Please make it configurable, my router also provides local NTP)

4

@thex: I don’t think that ntp is the problem. At least judging by the relentless hammering of the bridge towards sse{1…9}.nuki.io:443. I can’t see any NTP attempts in the firewall logs. The nuki bridge seems to update the time after a successful connection to the sse-servers, i. e. poor man’s ntp over https :wink:

Patrick

5

{“timestamp”: “2020-01-29T17:21:25+00:00”, “type”: “HTTP-Info”},
{“timestamp”: “2020-01-29T17:20:55+00:00”, “type”: “HTTP-Info”},
{“timestamp”: “2020-01-29T17:20:25+00:00”, “type”: “HTTP-Info”},
{“timestamp”: “2020-01-29T17:19:55+00:00”, “type”: “HTTP-Info”},
{“timestamp”: “2020-01-29T17:19:25+00:00”, “type”: “HTTP-Info”},
{“timestamp”: “2020-01-29T17:19:02+00:00”, “type”: “HTTP-Info”},
{“timestamp”: “2020-01-29T17:19:02+00:00”, “type”: “WLAN-Connected”, “ipAddr”: “$LOCAL_IP_REDACTED”},
{“timestamp”: “2020-01-29T17:18:57+00:00”, “type”: “WLAN-Disconnected”},
{“timestamp”: “2020-01-29T17:18:57+00:00”, “type”: “WLAN-Connect”},
{“timestamp”: “2020-01-29T17:18:57+00:00”, “type”: “WLAN-Init”},
{“timestamp”: “2020-01-29T17:18:55+00:00”, “type”: “WLAN-WiFi Restart”},
{“timestamp”: “2020-01-29T17:18:55+00:00”, “type”: “WLAN-ERROR”, “unconn-cnt”: 181, “unans-msg”: 0, “lastmsg”: 2, “pings”: 0},
{“timestamp”: “2020-01-29T17:18:24+00:00”, “type”: “HTTP-Info”},
{“timestamp”: “2020-01-29T17:17:54+00:00”, “type”: “HTTP-Info”},
{“timestamp”: “2020-01-29T17:17:24+00:00”, “type”: “HTTP-Info”},
{“timestamp”: “2020-01-29T17:16:54+00:00”, “type”: “HTTP-Info”},
{“timestamp”: “2020-01-29T17:16:24+00:00”, “type”: “HTTP-Info”},
{“timestamp”: “2020-01-29T17:16:02+00:00”, “type”: “WLAN-Connected”, “ipAddr”: “$LOCAL_IP_REDACTED”},
{“timestamp”: “2020-01-29T17:15:56+00:00”, “type”: “WLAN-Disconnected”},
{“timestamp”: “2020-01-29T17:15:56+00:00”, “type”: “WLAN-Connect”},
{“timestamp”: “2020-01-29T17:15:56+00:00”, “type”: “WLAN-Init”},
{“timestamp”: “2020-01-29T17:15:54+00:00”, “type”: “WLAN-WiFi Restart”},

Judging by the bridge logs above, there are 5 to 6 tries every 30 seconds (“HTTP-Info”) to verify that the wifi is good before the bridge decides to pull the plug and restart the wifi connection. In a related thread, @MatthiasK mentioned that the bridge considers the wifi connection healthy if the gateway is pingable which seems to be only part of the truth.

Patrick

6

„pings:0“ in your log means that the bridge was not able to ping the gateway.

7

@Juergen, I verified the firewall configuration once again. The gateway is pingable which I - again - verified with a test client in the subnet.

  • The log does not show any ping attempts (they might not get logged though)
  • If a make the single change to allow packets to be forwarded from the bridge to the internet everything works.

So the assumption is that the bridge doesn’t ping the gateway prior to a successful connection to the sse servers. It might help if a developer looked into the case.

Patrick

8

Thanks. We found a bug regarding the pings. There will be a bridge beta available soon, which fixes this. Please make sure that yours is in the beta pool.

4 Likes
9

sounds good … how about the SW Bridge App ?

10

I have currently version 2.4.25 installed. Should the issue be fixed in this release?

/edit: Wifi firmware: 2.1.15

Patrick

11

No. It’s going to be part of wifi firmware 2.1.16 beta, which will be released sometime later this week.

2 Likes
12

My wifi firmware just updated to 2.1.17 (beta channel). Let’s see.

Patrick

13

I tested the wifi 2.1.17 for over 24hours now and it’s a huge improvement, the disconnects are gone. However, in 24 hours I get about 3 ‘HTTP/1.1 503 Service Unavailable’. Is it possible that this happens when two clients try to connect simultaneously?

Patrick

14

Hello, I don’t know if I’m on the right discussion. But I have a few questions regarding the local API and the web API.
I have 9 smartlocks and I control them via the local API on 3 bridges. Each bridge is between 2 and 3 meters from a smartlock. I am a jeedom user.
Everything works perfectly and it’s very responsive.
However I need the web API to be able to work properly.
Of the 9 locks I only have 3 that are online. The rest are offline.

1 / Can you tell me how to get them online?
Another thing, I have a notification that tells me several “Firmware update”

2 / Question: if I make these updates, does that have an impact on the bridge json? If so can you tell me what is changing?

3 / As I am going to use the api nuki web does that have an impact on the json of the bridge in local?

Thank you in advance for your answers.
Cordially.
Remi

15

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

Patrick

16

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

1 Like
17

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?

18

Get beta here:

The issue is not fully fixed yet.

Patrick

19

@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

20

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