Since this thread covers the local API, your problem might be better discussed in a separate thread. Sorry.
Patrick
Since this thread covers the local API, your problem might be better discussed in a separate thread. Sorry.
Patrick
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
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?
Get beta here:
The issue is not fully fixed yet.
Patrick
@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
It’s going to be part of the 2.4.30 beta which will be released within the next 2 weeks.
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
This is now fixed with the newest fw version 2.5.0 (Beta)
Just posted in the same moment.
Yes, see also:
Tested the current beta for several days now. The connection is stable, events keep coming in. Beautiful.
Patrick
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
Hi @PatrickR,
thanks for your provided feedback.
Can you please be a bit more specific about the applied steps and your setup?
Your input is highly appreciated - thanks.
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:
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:
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
Hi @PatrickR:
Thanks for your detailed response. Please check following points:
Thanks!
Hi!
See post #25 but don’t expect any useful debugging information from the log. But once again: A detailed(!) log would really help debugging.
The gateway is and always was pingable.
Patrick
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
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
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
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?
AFAICS, they fixed it. Blocking all internet traffic from the bridge and it works fine.
Patrick