Random "HTTP 503 Unavailable"

Nuki APIs Bridge HTTP-API
105

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.)

106

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
107

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.

108

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
109

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
110
1 Like
111

Is this only for the Bridge rev2?

112

Yes. This whole thread was just about rev 2.

1 Like
113

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.

114

Anything changed in API that now differs to v1? Will the fix be ported to bridge v1, too?

115

20.2018 is rev 2.

1 Like
116

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.

117

Ah, got you. Thanks for the answer.

118

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
119

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
120

Got a dozen (meaningless) messages from Nuki Support and no solution yet…

Frustrating…

1 Like
121

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
122

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
123

Switching to danalock Z-Wave, Nuki API is unreliable with these random 503 errors.

124

Could the Nuki folks please do a feature freeze and solve the current problems first?
The Nuki Bridge “HTTP 503 unavailable problem” is not solved for a long time!