Could very well be, I’ve noticed it only recently about the 503, I have no idea how long ago the callbacks stopped though.
O.k., I will try to reproduce this here with my setup with FW 2.2.12.
1 Like
@bluewalk - is your bridge LAN-only or is it connected to the internet? I experience the 503 errors, when the bridge has no internet connection and is behind a router firewall.
It’s connected to the internet as LAN-only gives me too many errors/quirks.
Hi there,
I have the exact same problem.
I randomly get 503 errors when using the http API.
Even worse: some requests take ages and subsequently time out.
After weeks of testing I can’t figure out any pattern.
Sometimes I can successfully request five times a second, sometimes even the first request times out.
It seems to be no difference if I call /info or the information about the lock.
My Setup:
bridgeType: 1,
ids: {
hardwareId: 406XYXYXYXY,
serverId: 112XYXYCXYXYXYXY
},
versions: {
firmwareVersion: “2.2.12”,
wifiFirmwareVersion: “2.0.0”
},
uptime: 1381,
currentTime: “2019-07-18T08:50:45+00:00”,
wlanConnected: true,
serverConnected: true,
scanResults: [
{
deviceType: 0,
nukiId: 407XYXYXYXYXYX,
name: “Nuki_18XYXYXYXYXYXY”,
rssi: -51,
paired: true
}
]
}
Update: I’d also like to add the information, that I can Ping the device without any problems at any time. So the problem seems to be software related on the bridge itself.
I am a new Nuki User from germany and I have similar problems / questions. Unfortunately, API calls to the bridge are very unstable in my environment. I actually try and test with Curl, Loxone Virtual HTTP Input and Chrome.
Sometimes I get a “HTTP 503 unreachable” or the connection is temporarily not possible and curl writes after a few seconds “Empty reply from server”. It is a mix of working API Calls, Error 503 and no or empty respond.
My hardware:
Nuki Bridge (ID 18xxxxxx) Firmware Version 2.2.12
Nuki Smart Lock 2.0 Firmware 2.5.4
The quality of the Wi-Fi and Bluetooth connection is good
The same problem for me.
Lot of time for this command : http://192.168.0.129:8080/list?token=XXXXX, I Have HTTP 503.
I plug and I replug it’s good but after few minutes HTTP 503.
It’s a shame because there is still 1 month back I had almost no problem with the Bridge, since a few weeks it is simply more reliable at all.
Its absolute garbage at the moment!!!
Please do something about it or at least let us know you are into this issue
Just got back from vacation and trying to catch up with open issues here.
You are all on FW 2.2.12? This is strange as the last changes should not affect the HTTP API (and I also couldn’t reproduce this yet with my setup). We ran long term tests calling in certain intervalls. Do you see a difference in behaviour for very short intervalls or I combination with manual lock actions and/or App usage?
@SNikolaus Testing with Chrome will definitly throw errors for the way calls are handled by the browswer (prefetching, retries).
My setup that has same issue:
- Nuki Lock v2 fw.2.5.4 (same also on previous versions)
- Nuki Bridge v2 - has connection to internet.
- home-assistant v0.96.5 with Nuki integration. (http api)
When I lock/unlock via home-assistant I’m getting 503 error in 100% cases.
PS: Stop updating bridge firmware during the day time or allow user to specify at what time it firmware update is allowed. Last week it was second time when I couldn’t lock/unlock door and see status remotely (via Android application) for approximately 20 minutes… In both cases it was exactly when you release new bridge firmware.
1 Like
Same problem here, I receive a 503 or the GET never have response.
I have the 2.2.12FW.
Seems like the bridge can only manage one thread at same time and easily gets stuck.
This is completelly useless and this is not a cheap product to have this type of errors.
| bridgeType | 1 |
|---|---|
| ids | |
| hardwareId | xxxxx |
| serverId | xxxxx |
| versions | |
| firmwareVersion | “2.2.12” |
| wifiFirmwareVersion | “2.0.0” |
| uptime | 1048 |
| currentTime | “2019-08-08T23:44:25+00:00” |
| wlanConnected | true |
| serverConnected | true |
| scanResults | |
| 0 | |
| deviceType | 0 |
| nukiId | xxxxx |
| name | “Nuki_xxxx” |
| rssi | -70 |
| paired | true |
To be honest this is kind of unacceptable.
the V1 of a product of works well
and all the sudden basic functionality stops working on V2 version of the product.
people this is not rocket since.
I buyd a V2 bridge
because the old was not compatible.
I got an defect product
they exchanged the bridge
it still did not work
i had to download beta app
it still did not paired with my Samsung S10
they upgraded the firmware and all the sudden it worked
Now i get 503 all the time
and I am not able to pair with my samsung again
jees guys this is not a space shuttle
and we don’t need to land a rocket
it is bluetooth and http protocol not even https
even i can program arduino chip not to hang on http requests
get your sh*t together and fix this none sense.
people paid for a product that should work, we are nor alpha nor beta testers.
1 Like
I’m using Perl (LWP::UserAgent) and the processing is:
/callback/list?token=<token> --> OK (response with one callback with id 0)
As I detect, that “my” callback is missing, I fire:
http://192.168.0.21:8080/callback/add?url=http%3A%2F%2Floxberry-dev.brunnenweg.lan%3A80%2Fplugins%2Fnukismartlock%2Fcallback.php&token=<token>
–> Getting a HTTP 500
After this, the Bridge dies with all further requests leading to HTTP 503 Unavailable or not answering anymore.
Unplugging and re-plugging will bring it back to normal operation, until the next try.
It turns out that all the requests are working with a sleep 1 (second) in between, despite the processing is not asynchronous.
This should be inspected, as in other languages like in browsers JavaScript this is quite difficult to implement sleeps, especially in asynchrounus requests.
I mean sorry the fact that this problem is going on from January gives me no confident that they take the there product very seriously…
it is a lock… if a lock is not reliably, why needing a lock anyway…
again this is not something we should be bug tracking, there are enough examples and to make this case stand, this should have been solved months ago…
Just put a real programmer on it is solved in a matter of hours…
No, it’s not solved in a matter of hours because the bridge can handle only one connection at a time and if you don’t serialize at your end the API will always throw 503 errors (or timeouts if we restrict the HTTP server to just one HTTP connection). This is something that’s not going to go away, ever. If you can not properly serialize you’re better off using the Nuki Web API, where we do the serialization at our end.
I reduced the already serialized requests to a sleep of 0.1 seconds and it’s still working.
For our unserialized AJAX WebIf->Server->Bridge requests we will implement some kind of blocking locks on the server side, saving a hires timestamp of „Bridge request Running since“ and „Last Bridge request finished at“ to slow down and serialize the Ajax requests. It‘s tricky to implement (also to handle filesystem locks and deadlocks on the server side).
Would be great to accept eg 5 concurrent http connections and queue them on the bridge side, making everything more easy.
And at least after sending the Bridge response, the current single connection should be available again, to not play around with delays/sleeps.
There is a simple solution to this problem then.
throw this garbage out of the window.
There is no way in 2019 a device should only have one connection available…
this is utterly useless for a product like this.
this kind of of problems should not be solved at the end users level.
either make the choice to remove the API, or just make one that works.
and the fact that your V1 did not have this problem and your V2 has,
makes it the more not understandable.
And indeed I am better of using an other lock if this can not be fixed.
Yes, would be great, but is not feasible because of hardware restrictions.
We’re planning to further improve the behavior in a future firmware update. But this requires structural changes to the bridge firmware which take some time to develop and test and will not be available before Q4.
1 Like
Why not just implement MQTT support? And all concurrent connections will not be your headache?
1 Like