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:
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.
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.
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.
Why not just implement MQTT support? And all concurrent connections will not be your headache?
There have been no changes to the wifi hardware. The restriction is not new and has always been there.
Theoretically possible after the structural change. But HTTP API needs to remain because of backwards compatibility. You should post this request in the feature request section and start collecting votes for it. https://developer.nuki.io/c/feature-requests
I need to defend the nuki team here. I am the developer of the homebridge nuki plugin and have worked with the api from the very beginning. The problem always existed and was always clearly communicated by the team. I am so happy that there is a http api available at all, so dont blame them for restrictions. And since this is a developer forum I think there should not be a problem to implement the api respecting its restriction. Of course it would be better without this restriction.
well I did not have the problem with V1, in fact no one has.
Who made those restrictions, president trump?
I am glad there is an clear answer, you might as well close the topic , “works as intended”
so why wait almost 9 month to come to this conclusion?
For me it is also solved throw this sh*t out of the window, never advise any one to buy it.
Is there any better solution for EU locks? Except local control (via Web API) everything else works pretty well and stable for all of my two v2 locks that I have.
After we installed Nuki Lock it was first time when my wife said that smart lock is one of the best and useful smart device she ever get in touch with.
Right now we have a confirmation that Web API is not 100% reliable/predictable and nothing can be done in that area…