I notice the ioBroker adapter mentioned simply relies on this API for reconnecting when the Miniserver reboots. OK, no problem there.
However, shortly after installing this I saw one occurrence where the Miniserver didn't fully boot after a config upload. It got stuck and I had to power cycle it. This is the one and only time that has happened. While this could have just been bad luck, I find it highly suspicious this was just after I installed software using this API (I quickly disabled the ioBroker adapter, believing it to have caused the reboot to get stuck).
Looking at the Loxone web interface one can see that when the WS connection is lost (the Miniserver reboots) it polls the following URL every second or so:
Where '192.168.x.x' is the Miniserver IP and '1581433669271' is clearly just a timestamp to bypass browser caching.
Even if a TCP connection can be created, if the Miniserver is not yet ready to handle connections a 503 error is instantly returned. When the Miniserver is ready, then a small JSON response is returned with the Miniserver serial number, software version, and couple of other things.
I don't know if not waiting for the Miniserver to be fully available is what caused the issue I saw, but do know that it does not have a very sophisticated network stack, so if Loxone's own implementation uses this check then it would likely be prudent for third parties to do the same.
Ie. I think it would be prudent to add a check to read this same URL (in a loop) and wait until at least HTTP code 200 were returned before trying to open a web socket.
Stumbled across this API via an ioBroker adapter (https://github.com/UncleSamSwiss/ioBroker.loxone) and found a potential issue.
I notice the ioBroker adapter mentioned simply relies on this API for reconnecting when the Miniserver reboots. OK, no problem there.
However, shortly after installing this I saw one occurrence where the Miniserver didn't fully boot after a config upload. It got stuck and I had to power cycle it. This is the one and only time that has happened. While this could have just been bad luck, I find it highly suspicious this was just after I installed software using this API (I quickly disabled the ioBroker adapter, believing it to have caused the reboot to get stuck).
Looking at the Loxone web interface one can see that when the WS connection is lost (the Miniserver reboots) it polls the following URL every second or so:
http://192.168.x.x/jdev/cfg/api?_=1581433669271
Where '192.168.x.x' is the Miniserver IP and '1581433669271' is clearly just a timestamp to bypass browser caching.
Even if a TCP connection can be created, if the Miniserver is not yet ready to handle connections a 503 error is instantly returned. When the Miniserver is ready, then a small JSON response is returned with the Miniserver serial number, software version, and couple of other things.
I don't know if not waiting for the Miniserver to be fully available is what caused the issue I saw, but do know that it does not have a very sophisticated network stack, so if Loxone's own implementation uses this check then it would likely be prudent for third parties to do the same.
Ie. I think it would be prudent to add a check to read this same URL (in a loop) and wait until at least HTTP code 200 were returned before trying to open a web socket.