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.
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.
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. Feature requests - Nuki Developers
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.
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…
I just bought a danalock V3 I have Z-Wave, but they also work with homekit, and bluetooth.
And there bridge will be coming soon.
Because I literally don’t care how much I spend on something as long I am getting the job done.
and the V1 got the job done.
But because of some battery started leaking in the device and the plates got oxidation.
I bought a V2, but then I noticed it was not compatible with my old bridge so i bought the new bridge.
and from there the real mess was starting…
For a product that says it need to be compatible it is damn not compatible in every common sense
such an answer is not only unacceptable but also rude.
the people in this forum are not only trying to help but are also trying to figure a way to fix a problem that is caused by a flawed implementation of yours. i am implementing APIs at my fulltime job and working with the nuki bridge is the worst experience i ever had. if you compare your implementation with the quite comparable API from philipps in the hue bridge you can see what propper error handling should look like!
After another night of debugging I am jumping ship.
Sorry girls and guys, but the following is going to be a bit of a rant.
When I had to find a solution to upgrade the doors in my company I chose Nuki because of one simple reason: the bridge with the local http API. I am simply not willing to sacrifice security by letting some third party server have full controll over my doors. Nuki promised to have an open API and while Nuki is not the cheapest solution on the market, I am willing to spend an extra buck for a good an open API.
We were planning to fully integrate the local Nuki HTTP API in our private app. The app is accessing several IOT bridges in the network directly. If two user choose to access one bridge at the same time, the two requests send the bridge on a long digital 503 hiatus. As the requests come from two different devices, there is no possibility for us to serialize the requests. And to be honest there should be no reason to serialize the request on our side. We have even built implementations with an ESP8266 (4$) and had no problems by simultaneous requests at all.
I am obviously not the only one who is fed up with the flawed implementation of the API. Your bridge is just too expensive to be such an unreliable piece of hardware. If you can’t handle GET requests from Chrome, which is ridiculous in its own, don’t implement GET requests.
And don’t even get me started about the static six digit token via GET in an unencrypted stream.
People in this forum are trying to help and asking for your colloboration - let them help you!
Sorry dudes for beeing honest but I have had it.