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
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.
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
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.
1 Like
Thanks for the feedback. The hostname should have stayed the same, so we will look into that issue.
1 Like
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
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.)
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.
1 Like
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.
Status changes of the Smart Lock are signaled to the bridge and it updates its cache as soon as it sees it (which should be more or less immediatly). So in any case where there is no doubt that the Smart Lock is online you can get the status from /list without any drawbacks. The only thing that could case any delay is the bridge finishing some other task before getting the changed state from a Smart Lock.
1 Like
Feedback to 2.4.1:
For testing, I temporary removed our sleep and the serialization code (mentioned here Random "HTTP 503 Unavailable") from our implementation, and I don’t get any HTTP 500/503 anymore.
Therefore, it’s working much more stable now with asynchronous requests.
2 Likes
1 Like