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
Is it planned a new version of the bridge firmware to stop these problems of HTTP 503?
see above:
and also:
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.
Hi everyone, we recently bought a Nuki and want to use the Bridge API for automatisation.
I get that the bridge can handle only a single connection at a time (and it also seems to need a short delay of about 0.5s between subsequent connections, otherwise the second connection will almost always time out).
The real problem though is that it is apparently possible to crash the API by sending too much (or too frequent?) requests. If this happens (and we can reproduce it rather reliably), the API simply does not answer any more at all (all requests time out).
For now the only way we found to make the API responsive again is to restart the bridge by unplucking it for a short moment. This is simply unacceptable.
Is this a known bug? If so, is there a firmware update planned to fix it?
Bridge info:
{
"bridgeType": 1,
"ids": {
"hardwareId": 408214058,
"serverId": 1645843699
},
"versions": {
"firmwareVersion": "2.2.13",
"wifiFirmwareVersion": "2.0.0"
},
"uptime": 46,
"currentTime": "2019-09-16T08:09:16+00:00",
"wlanConnected": true,
"serverConnected": true,
"scanResults": [
{
"deviceType": 0,
"nukiId": 437814069,
"name": "Nuki_1A188335",
"rssi": -56,
"paired": true
}
]
}It is a known bug and it persists for at least a year now.
Sometimes even less frequent requests causes the bridge to stop working.
In a few days it is Q4, can you be more specific with your time planning? I think the community would appreciate a few more deails because this bug annoys people now for nearly a year. Thanks!
Sorry, but we can’t give a release date until we are 100% sure it will hold.
As soon as a beta is available it will be posted in this forum for interested users.
Honestly, I am seriously surprised that since I have reported this issue more then 8 months ago there is ABSOLUTELY NO IMPROVEMENT!
I would expect very different behavior from Austrian company, but maybe it is just a new Austrian standard very similar to what Loxone is providing now days.
When I remember how I was sending logs, spending time on obviously non-user-issue I wonna cry 
and guess what 8 months later still same story
Jakub
Just a few thoughts without any emotions…I would really appreciate a clear and honest answer.
From what I understand Nuki says there is no real difference between 1.0 and 2.0 Versions of the Bridge, and therefore the hppt 503 effect is the same with both locks and was always there, am I right?
I tested the behaviour with a Nuki 1.0 Combo and a Nuki 2.0 Combo - both with latest FW for the lock and bridge.
What I found out - 503 errors occurs on both version, that’s right. But one big difference is that the http api of the 1.0 bridge does not crash whe you are penetrating the api with lockaction commands. (which only means I send a curl lockaction -> lock, wait untl the lock has finished the action and send an new curl action to unlock, and again a few times). During the callback you get the 503 error when you send new action commands as long as the callback is finished. After finishing callback It executes the command again.
With the 2.0 Combo the bridge does not work as stable when penetrating it. The callback lasts a litle bit longer and sometimes the api does not react anymore and even the bridge reboots.
So from my point of view there is defenitly a difference.
So my question is: Can you confirm the described beahviour and because you are already working on a new FW to fix this problem for quite a long time will this new version be at least as stable as the Bridge 1.0?
Just to be clear: This is a lock - so it has to be 100% reliable. If it’s not nobody can trust it and it’s useless.
Yep and i am happy with my danalock…
it just works…
Only thing that is not implemented latch and unlock… are the same states…
but that is a compromise i want to make .
Hi, beta release for nuki bridge possible in October-November 2019?
I am also thinking about switching. Is there a API for Dana-Lock and is it stable?
hmmm-----3 weeks without any answer from Nuki is a little bit disapointing and gives everybody a good impression about NUKI’s attention to the problem and their willingness to solve it. Good for me that I’m still able to send the lock back and search for a better solution.
to be honest i am not using the danalock bridge. i use it completely as a Z-wave device.
but there is a API and SDK available.
Especially when they fix security flaws at the same pace. Let‘s hope not.