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
1 Like
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.
1 Like
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.
Thanks. Sounds good!
Just a quick progress update:
The structural changes to the bridge firmware are progressing as planned. Internal testing is ongoing and things look very good so far. But, as we don’t want to overpromise, we can’t give a date for a final release or beta yet, nor do we want to comment on specific questions about functionality & stability before our internal testing has been concluded. Thus also the silence in this thread (which doesn‘t mean that we‘re not working on it. The opposite is the case).
2 Likes
Thanks for responding. Even though a timeline would be nice, good to hear you are working on it.
Thanks, looking forward to the fixes. Now have limited my requests to the bridge to hopefully have less 503 errors
See also:
If you are intersted in checking if this solves your issues you can apply for early access.
Note that some hardware-restrictions still take effect, but the connection handling is completely rewritten to improve connectivity and stability.
1 Like
With the 2.4.0 beta update it’s perfect it works fine. For the moment no error 503. Thank you very very very much
3 Likes
Hi Stephan,
with the Bridge 2.4.0 beta update, the Bridge changed it’s hostname, therefore it first was not reachable from my Loxone system.
Possibly you can figure out why it changed, and keep the old hostname, as this may also make trouble for others on update.
lg, Christian
Hello,
reason for using hostname? I believe bridge is on static IP anyway, so usage of hostname in loxone for access the API is IMHO just another potential problem in functionality.
Jakub