Random "HTTP 503 Unavailable"

[zoli]

I am also thinking about switching. Is there a API for Dana-Lock and is it stable?

[locke987]

Just a few thoughts without any emotions…I would really appreciate a clear and honest answer.
…

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.

[parsaria (SeyedGH)]

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.

[zoli]

Especially when they fix security flaws at the same pace. Let‘s hope not.

[zoli]

Thanks. Sounds good!

[Juergen (Jürgen Pansy)]

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).

[zoli]

Thanks for responding. Even though a timeline would be nice, good to hear you are working on it.

[bluewalk (Délano)]

Thanks, looking forward to the fixes. Now have limited my requests to the bridge to hopefully have less 503 errors

[Stephan (Stephan Lendl)]

See also:

Early Access: Bridge Beta 2.4.0

Our internal tests show good results for the new Bridge firmware version. So we want to invite interested users to an early access to the new Beta version (as soon as available). Why not use the existing Beta channel? This is a complete rework of the firmware and though we only release versions as Beta we think are stable enough to provide without any risk, we see that many users may currently use a beta enabled bridge in productive environments. So we want to give you the choice if you want e…

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.

[darkwinter (Vincent)]

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

[christianTF (Christian Fenzl)]

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

[elpaso (Kuba)]

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

[christianTF (Christian Fenzl)]

Would you remember it’s IPv6 address? Or do you enter IP address when searching at Google, or accessing a file share in your network?
Bridge uses DHCP, IP is not static by default.

[elpaso (Kuba)]

in general valid argument, but in this case not really relevant… I dont know how everyone maintans their DNS record on home network… I have 2 DNS servers within active directory and even in this case I use IP only in all loxon integrations, except for the ones needed to be available from both int/ext networks, there I use DNS-split for internal and external access to have same FQDN for both int/ext. but this is the ONLY usecase making sense

I believe you do not depend on netbios names without domain suffix

[christianTF (Christian Fenzl)]

I just wanted to mention, that the hostname changes, and this shouldn’t happen.
I’m not here about a discussion how to set up a network.

[Stephan (Stephan Lendl)]

with the Bridge 2.4.0 beta update, the Bridge changed it’s hostname

Thanks for the feedback. The hostname should have stayed the same, so we will look into that issue.

[Fritz]

With beta 2.4.0 I get no response with lockState. In few cases I get one, but most the response ist like below.

curl -vvv ‘http://IP-ADDRESS:8080/lockState?nukiId=ID&token=TOKEN’
Expire in 0 ms for 6 (transfer 0x1d7d880)
Trying IP-ADDRESS…
TCP_NODELAY set
Expire in 200 ms for 4 (transfer 0x1d7d880)
Connected to IP-ADDRESS (IP-ADDRESS) port 8080 (#0)
GET /lockState?nukiId=ID&token=TOKEN HTTP/1.1
Host: IP-ADDRESS:8080
User-Agent: curl/7.64.0
Accept: /

Empty reply from server
Connection #0 to host IP-ADDRESS left intact
curl: (52) Empty reply from server

[Stephan (Stephan Lendl)]

With beta 2.4.0 I get no response with lockState. In few cases I get one, but most the response ist like below.

Thanks for your feedback.
Yes, I can reproduce an issue with repeating /lockState commands. If I call /list in between or wait some time it works again for one usage.
We are looking into that issue.

Note that we missed that in our tests because we highly recommend to not repeatedly call /lockState in short time frames, as this will drain the batteries of your devices quite fast. (/list gets the cached state from the bridge instead)
(Be assured we still consider this unexpected empty reply an issue which will be addressed.)

[Fritz]

Thanks for your answer.
If I reboot the bridge, the first query works well. After then, there is always an empty response.
Same issue if I wait 30 seconds and more.
The firmware is now 2.4.1.

[Phuturist]

I did not know this but am interested to know how often the bridge refreshes its cache. I have built an alternative app for Homey that communicates over the bridge API (the official app uses the web API) but I’m now calling lockState. Although I dont do this very often I might as well use list if there is not much delay due to caching.