Thanks for the feedback. The hostname should have stayed the same, so we will look into that issue.
1 Like
With beta 2.4.0 I get no response with lockState. In few cases I get one, but most the response ist like below.
curl -vvv ‘http://IP-ADDRESS:8080/lockState?nukiId=ID&token=TOKEN’
Expire in 0 ms for 6 (transfer 0x1d7d880)
Trying IP-ADDRESS…
TCP_NODELAY set
Expire in 200 ms for 4 (transfer 0x1d7d880)
Connected to IP-ADDRESS (IP-ADDRESS) port 8080 (#0)
GET /lockState?nukiId=ID&token=TOKEN HTTP/1.1
Host: IP-ADDRESS:8080
User-Agent: curl/7.64.0
Accept: /
Empty reply from server
Connection #0 to host IP-ADDRESS left intact
curl: (52) Empty reply from server
Thanks for your feedback.
Yes, I can reproduce an issue with repeating /lockState commands. If I call /list in between or wait some time it works again for one usage.
We are looking into that issue.
Note that we missed that in our tests because we highly recommend to not repeatedly call /lockState in short time frames, as this will drain the batteries of your devices quite fast. (/list gets the cached state from the bridge instead)
(Be assured we still consider this unexpected empty reply an issue which will be addressed.)
Thanks for your answer.
If I reboot the bridge, the first query works well. After then, there is always an empty response.
Same issue if I wait 30 seconds and more.
The firmware is now 2.4.1.
1 Like
I did not know this but am interested to know how often the bridge refreshes its cache. I have built an alternative app for Homey that communicates over the bridge API (the official app uses the web API) but I’m now calling lockState. Although I dont do this very often I might as well use list if there is not much delay due to caching.
Status changes of the Smart Lock are signaled to the bridge and it updates its cache as soon as it sees it (which should be more or less immediatly). So in any case where there is no doubt that the Smart Lock is online you can get the status from /list without any drawbacks. The only thing that could case any delay is the bridge finishing some other task before getting the changed state from a Smart Lock.
1 Like
Feedback to 2.4.1:
For testing, I temporary removed our sleep and the serialization code (mentioned here Random "HTTP 503 Unavailable") from our implementation, and I don’t get any HTTP 500/503 anymore.
Therefore, it’s working much more stable now with asynchronous requests.
2 Likes
1 Like
Is this only for the Bridge rev2?
Yes. This whole thread was just about rev 2.
1 Like
How do I know which one I have? Mine is saying Art.Type 020.218, is that rev 2? Furthermore it is saying 13/2019.
Anything changed in API that now differs to v1? Will the fix be ported to bridge v1, too?
20.2018 is rev 2.
1 Like
No. No functional changes to the API. This was just the proposed rewrite of the code which prevents erroneous 503 responses on rev 2. The basic limitation (only one http request at a time) did not change, which means that 503 replies can still happen if parallel requests are sent to the bridge.
Ah, got you. Thanks for the answer.
Short feedback for 2.4.13:
No probs so far. Seems much mor reliable than the old 2.3.0 fw.
The errors “HTTP 503 unavailable” are gone…
2 Likes
Hi,
it’s nice to read that newer Firmwares can handle better with error 503.
What about my v1 (?) bridge which came with a Nuki 2.0 Combo and has installed firmware 1.13.1?
Nearly unusable because of 503 while having 2 Nuki locks at 1 bridge…
2 Likes
Got a dozen (meaningless) messages from Nuki Support and no solution yet…
Frustrating…
1 Like
Would be interested as well. Have Nuki v1 Bridge and get this 503 error too every day. Every time when this happens the nuki entities in home assistant are gone and I have to manually restart the server. Is there as well a firmware update for the old bridge?
2 Likes
Same here. Bridge v1 and tons of 503 errors, no concurrent requests, just one at a time so it’s not a serialization problem. It just happens randomly. Fix was promised for 2019 Q4 and it’s 2020 Q4. This is just unacceptable.
You should make the bridge code open source, if you aren’t going to fix your broken features let us do it ourselves.
2 Likes