Hi @Andy_Co,
I’ve been analysing your logs and thinking this through. Its either likely something in the underlying jetty client the bindings using such as DNS failing, or more likely just a timing issue because the systems so busy, it cant hit the expected timings as its doing too many other things.
At the moment, I’ve tried several simulations limiting CPU, but have not yet replicated unfortunately with the GW-02. (I can see from your logs the FW didn’t change so I know at least it wasn’t due to a FW upgrade that got patched quickly).
I’ve raised a new PR for the binding to allow configuration for the timeouts to be changed by configuration. Previously it was 3 seconds, as the devices are much faster than that, from discussions with TapLink before. I suspect however the PI image / hardware may not behave the same way as my simulations even after I have slowed everything down as its x64 based here rather than ARM. (Unfortunately I have no PI4’s to use as they are all running critical bits I cant shutdown atm).
PR info for your reference: https://github.com/openhab/openhab-addons/pull/18679
After this is reviewed I’ll post a link to the build (so the build published has the naming’s that will be in the final build - in case it changes, I’m hesitant to push right now).
After this is used I there’s two bits in the log’s should this happen again:
If there is no: “Validating response from Gateway web UI” message after the “Local address for connectivity is” message, then the gateway didn’t reply in the expected timeframe from what the binding can see. If this is the case does the web UI work in a response fashion - e.g. appear within the timeout setting. (Just in case its the GW-01).
If the web ui does appear, then its likely just a overloading issue, so there is a new configuration option against the bridge hopefully it will be called: gatewayRequestTimeout (pending code review so it could change slightly), this can be increased from 3 to say 10 seconds - maybe worst case try 30 seconds, if 10 still doesn’t work. If after adjusting (reboot just to be sure), if it still doesn’t show that Validating response from Gateway web ui, then it could be something with the GW-01, or variables outside of the binding. If this is the case logs from jetty should hopefully help (I’ll have to investigate how to enable them, but I’m pretty sure I’ve used them last year at some point - I’m hoping however increasing this setting and the time the system waits to get something processed back should cover the scenario that your seeing there).
I need to do a few final checks tomorrow to ensure its working as expected, then will open it up for review, once naming conventions are agreed I’ll post a build).