Ok, I test it.
With this script:
curl -s http://192.168.XX.XX:8080/list?token=XXXXXX 2>/dev/null | jq -r ‘.[].lastKnownState.stateName’
I have sometimes the good state and sometimes: “parse error: Invalid numeric literal at line 1, column 5” even with my domotic Jeedom or with putty.
Only with curl -s http://192.168.XX.XX:8080/list?token=XXXXXX : HTTP 503 Unavailable
Another idea?
Schlew.
Another thing I just noticed:
I see a value of RSSI =-79 in your output above. That is a suboptimal value which means that the bridge is barely reaching the Smart Lock via BLE and could be sometimes blocked for a longer timeframe trying to connect to it. Could you try again with a setup where the bridge is nearer to the Smart Lock?
In the last couple of days unfortunately I see the same behavior with my nuki bridge. In this morning two lockstatements received a http error 503 with 3 seconds between them.
I tried to call the bridge-api with curl and get this behaviour:
$ curl http://192.168.178.68:8080/info\?token\=XXXXXXXXXXXXXXXX
HTTP 503 Unavailable
$ curl http://192.168.178.68:8080/info\?token\=XXXXXXXXXXXXXXXX
HTTP 503 Unavailable
$ curl http://192.168.178.68:8080/info\?token\=XXXXXXXXXXXXXXXX
HTTP 503 Unavailable
$ curl http://192.168.178.68:8080/info\?token\=XXXXXXXXXXXXXXXX
HTTP 503 Unavailable
$ curl http://192.168.178.68:8080/info\?token\=XXXXXXXXXXXXXXXX
HTTP 503 Unavailable
$ curl http://192.168.178.68:8080/info\?token\=XXXXXXXXXXXXXXXX
HTTP 503 Unavailable
$ curl http://192.168.178.68:8080/info\?token\=XXXXXXXXXXXXXXXX
HTTP 503 Unavailable
$ curl http://192.168.178.68:8080/info\?token\=XXXXXXXXXXXXXXXX
HTTP 503 Unavailable
$ curl http://192.168.178.68:8080/info\?token\=XXXXXXXXXXXXXXXX
HTTP 503 Unavailable
$ curl http://192.168.178.68:8080/info\?token\=XXXXXXXXXXXXXXXX
HTTP 503 Unavailable
$ curl http://192.168.178.68:8080/info\?token\=XXXXXXXXXXXXXXXX
HTTP 503 Unavailable
$ curl http://192.168.178.68:8080/info\?token\=XXXXXXXXXXXXXXXX
HTTP 503 Unavailable
$ curl http://192.168.178.68:8080/info\?token\=XXXXXXXXXXXXXXXX
HTTP 503 Unavailable
$ curl http://192.168.178.68:8080/info\?token\=XXXXXXXXXXXXXXXX
{"bridgeType": 1, "ids": {"hardwareId": XXXXXX, "serverId": XXXXXX}, "versions": {"firmwareVersion": "1.11.4", "wifiFirmwareVersion": "1.2.0"}, "uptime": 3756353, "currentTime": "2019-01-09T08:06:29+00:00", "serverConnected": true, "scanResults": []}
$ curl http://192.168.178.68:8080/info\?token\=XXXXXXXXXXXXXXXX
{"bridgeType": 1, "ids": {"hardwareId": XXXXXX, "serverId": XXXXXX}, "versions": {"firmwareVersion": "1.11.4", "wifiFirmwareVersion": "1.2.0"}, "uptime": 3756496, "currentTime": "2019-01-09T08:08:52+00:00", "serverConnected": true, "scanResults": []}
$ curl http://192.168.178.68:8080/info\?token\=XXXXXXXXXXXXXXXX
{"bridgeType": 1, "ids": {"hardwareId": XXXXXX, "serverId": XXXXXX}, "versions": {"firmwareVersion": "1.11.4", "wifiFirmwareVersion": "1.2.0"}, "uptime": 3756498, "currentTime": "2019-01-09T08:08:54+00:00", "serverConnected": true, "scanResults": []}
$ curl http://192.168.178.68:8080/info\?token\=XXXXXXXXXXXXXXXX
{"bridgeType": 1, "ids": {"hardwareId": XXXXXX, "serverId": XXXXXX}, "versions": {"firmwareVersion": "1.11.4", "wifiFirmwareVersion": "1.2.0"}, "uptime": 3756499, "currentTime": "2019-01-09T08:08:55+00:00", "serverConnected": true, "scanResults": []}
$ curl http://192.168.178.68:8080/info\?token\=XXXXXXXXXXXXXXXX
{"bridgeType": 1, "ids": {"hardwareId": XXXXXX, "serverId": XXXXXX}, "versions": {"firmwareVersion": "1.11.4", "wifiFirmwareVersion": "1.2.0"}, "uptime": 3756500, "currentTime": "2019-01-09T08:08:56+00:00", "serverConnected": true, "scanResults": []}
$ curl http://192.168.178.68:8080/info\?token\=XXXXXXXXXXXXXXXX
{"bridgeType": 1, "ids": {"hardwareId": XXXXXX, "serverId": XXXXXX}, "versions": {"firmwareVersion": "1.11.4", "wifiFirmwareVersion": "1.2.0"}, "uptime": 3756501, "currentTime": "2019-01-09T08:08:57+00:00", "serverConnected": true, "scanResults": [{"nukiId": XXXXXX, "name": "XXXXXX", "rssi": -61, "paired": true}]}
As you can see the first couple of requests gets a 503 and the the bridge-info shows no nuki. A only on the last request you can see a paired nuki?
I have homekit activated.
The nuki bride is about 1.5m from the nuki…
Will try at 5cm…
I have exactly the same Problem.
The API does not work:
HTTP 503 Unavailable[22:33:51] openhabian@openHABianPi:~$ curl -s http://192.168.250.232:8080/info?token=XXXXXXX
Hey Chris,
maybe you got the new hardware revision of the nuki bridge where the api is not yet available at this time?
Have a look here:
Greetings,
Niklas
I recently built a Nuki app for a home domotica controller which uses the Bridge API as well and I’m seeying the same behaviour. A lot of the endpoints return the #503 error ocassionaly. It seems the bridge is slow in responding to request and is not able to handle more than one request at the time. The combination of these issues causes the #503 error. If you for instance have the Nuki smartphone app open (without being connected with Bluetooth) and try to use the Bridge API you often end up with #503 errors.
I have the old Bridge hardware, the Bride is about 1M away from the Nuki lock and connection is always looking good (green). I access the Bridge API using node-fetch, a nodejs module based on window.fetch.
I would appreciate it if Nuki would investigate this and improve the performance from the Bridge to avoid this issue.
Yes, this is a known issue, that the Bridge can only really handle one request at a time and we are working on improvements there from different angles, but ressources are limited so this will still take some noticeable time.
Hi,
i experience the same issue.
In my case, after the Bridge executed a action (lockAction) it needs some “recovery time” (about a minute) with HTTP 503, after that the bridge responds with HTTP 200. it this a normal behavior?
Nuki Bridge (new HW) with 2.1.37
13:55:43.076839 IP CLIENT.55277 > NUKI BRIDGE.8080: Flags [P.], seq 1:200, ack 1, win 29200, length 199: HTTP: GET /lockAction?nukiId=NUKIID&action=2&token=GEHEIM HTTP/1.1
13:55:49.527871 IP NUKI BRIDGE.8080 > CLIENT.55277: Flags [P.], seq 1:148, ack 200, win 5545, length 147: HTTP: HTTP/1.1 200 OK
13:55:54.190946 IP CLIENT.55304 > NUKI BRIDGE.8080: Flags [P.], seq 1:168, ack 1, win 29200, length 167: HTTP: GET /list?token=GEHEIM HTTP/1.1
13:55:55.964556 IP NUKI BRIDGE.8080 > CLIENT.55304: Flags [P.], seq 1:96, ack 168, win 5577, length 95: HTTP: HTTP/1.1 503 Service Unavailable
13:56:09.190994 IP CLIENT.55333 > NUKI BRIDGE.8080: Flags [P.], seq 1:168, ack 1, win 29200, length 167: HTTP: GET /list?token=GEHEIM HTTP/1.1
13:56:09.287919 IP NUKI BRIDGE.8080 > CLIENT.55333: Flags [P.], seq 1:96, ack 168, win 5577, length 95: HTTP: HTTP/1.1 503 Service Unavailable
13:56:24.194952 IP CLIENT.55369 > NUKI BRIDGE.8080: Flags [P.], seq 1:168, ack 1, win 29200, length 167: HTTP: GET /list?token=GEHEIM HTTP/1.1
13:56:24.291353 IP NUKI BRIDGE.8080 > CLIENT.55369: Flags [P.], seq 1:96, ack 168, win 5577, length 95: HTTP: HTTP/1.1 503 Service Unavailable
13:56:39.192597 IP CLIENT.55410 > NUKI BRIDGE.8080: Flags [P.], seq 1:168, ack 1, win 29200, length 167: HTTP: GET /list?token=GEHEIM HTTP/1.1
13:56:39.324788 IP NUKI BRIDGE.8080 > CLIENT.55410: Flags [P.], seq 1:119, ack 168, win 5577, length 118: HTTP: HTTP/1.1 200 OK
13:56:39.444491 IP NUKI BRIDGE.8080 > CLIENT.55410: Flags [P.], seq 119:299, ack 168, win 5577, length 180: HTTP
13:56:54.193883 IP CLIENT.55445 > NUKI BRIDGE.8080: Flags [P.], seq 1:168, ack 1, win 29200, length 167: HTTP: GET /list?token=GEHEIM HTTP/1.1
13:56:54.318407 IP NUKI BRIDGE.8080 > CLIENT.55445: Flags [P.], seq 1:119, ack 168, win 5577, length 118: HTTP: HTTP/1.1 200 OK
[…]
A minute should definitly not be normal behaviour.
Only /lockState is calling the Smart Lock directly, so this can not be done in arbitrarily short intervals, but for everything else more than some seconds should not happen.
Do you have any other integrations running or callbacks which the Bridge could be processing?
Hello,
same problem for me here.
when I’m using curl and the locks/bridge is doing nothing its working 9 of 10 tries.
but when the lock is currently performing any lock action (even lock’n’ go where its doing nothing in the first 20s but waiting) its working 0 of 10 tries. so i am not able to ask the locks for the currrent lock state when they are performing any action (closing, opening, lockngo)
i also getting the 503 error.
any idea?
It’s not doing nothing while Lock & Go. In fact this is a tricky one to set activity log and trigger callbacks correctly.
What would be interesting: Do you notice any difference between /list and /lockState calls?
Hello,
yes i’ve already seen that @schlewitz mentioned that. So i already tried that but couldnt see any difference in the behaviour.
but is it normal that the api becomes unavailable EVERYTIME the lock is performing any lockaction (even lockngo)?
A shirt “busy time” after actions is normal due to status updates being pushed, but the described time-frames seem far to big.
We are currently running some additional duration tests with different setups to see if we can reproduce the problems.
Any further details about your specific setup and usage behavior will help us narrow down the search.
Hello, I’ve also gotten some problems with long “busy times” or “unavailable times”. Then I’ve seen that the Bridge is rebooting every few minutes (Firmware 2.2.9) (Uptime not longer than 600s).
Is that a known issue for that firmware version? What can cause a reboot of the bridge? Too much requests at same time?
Thanks!
I can’t reproduce this here with my bridge. Even within our stress-tests we never had such short uptimes. Only known problem is when your Brige is offline (can’t reach our server) and therefore restarts regularly.
OK, that’s strange. And how long is the reboot cycle if not connected to server?
Another strange thing is, that I’ve replaced the bridge with another one that’s on Firmware 2.2.9 and got the same reboots.
I’ve also tested both in another network and there were no reboots?!
But in the same network that causes reboots to Firmware 2.2.9, there is a bridge Gen1 with firmware 1.12.6 and that is running stable! Can this be related to the Router?! It’s an UPC router in Vienna (UPC Connect BOX)
This really sounds like the bridge thinks it needs to restart the Wifi module for some reason. (The older hardware revision - FW 1.x does not do this)
Could be router related, but I got an UPC Connect Box myself at home and don’t have these issues. Any special settings/setups you are using.
You can PM me with more details we can check with our FW developers if you want to.
curl -s http://nuki.lan:8080/info?token=xxxx,
list & lockstate, work fine,
curl -s http://nuki.lan:8080/log?token=xxxx
returns: HTTP 503 Unavailable
triyed either from Raspberry PI console and Windows 10 console and I get the exact same result