Calling delete every ~220 seconds

[DanielMajoinen]

I'd like to understand the logic behind the connection loop eventually calling delete. From my understanding of hub.py a discovery is called, which loops on failure to connect until a connection is made, at which point it waits 220 seconds and then forces a disconnect. Why is a disconnect necessary once a connection is established? This is causing instability to the point I had to comment out the code to get it working reliably. Is this intentional?

[bremor]

Hello! Thanks for raising this issue.

On my system, the wifi module will disconnect the open session after about 240 seconds. I found it to be more reliable to control exactly when this disconnect occurs, rather than waiting for the wifi module to close the connection. I would love to take a look at your logs (maybe you have a different hardware version?) and for you to share what changes you have made to the code to see how my system behaves.

I'm also happy to help you troubleshoot your stability issues. I have found that every 6 months or so I need to power cycle the wifi-module in my ceiling, it seems to have some weird memory leak issues where it will stop responding to discovery broadcasts and ignore the commands I am sending.

[DanielMajoinen]

Ah okay, thanks for the insight, I knew there had to be a reason for it!

I've taken some time to do my own testing as I found my connection was too unstable for use with this force disconnect then reconnect pattern. I've noticed the TCP connection times out after 5 minutes, but I haven't been able to force a disconnect and successfully reconnect reliably.

I've taken to looping a 10 second interval after connection, requesting zone info. Once the TCP connection is lost by the server timeout, this then triggers and repeats the discovery loop which seems to connect as reliably as forcing it, but by not forcing a disconnect I at least have a longer active connection.

I've noticed my router version is 1.2.3, is that the same as yours? I am getting fairly high latency when pinging the router, around ~200ms, is that what you get? I've also noticed the official app does nothing to combat this 5 minute timeout, with the logs showing exceptions being thrown which doesn't give me much hope.

[bremor]

My hardware verison is also 1.2.3. I have had high response times just like that. The device eventually becomes unresponsive after a period of months, I feel like it has some kind of memory issue. I have found that a power cycle will get it running back to normal for a while and I will go back to getting normal ping response times. It was a while ago, but I actually found initiating a disconnect with a delete request helped with long term stability, rather than letting the connection be terminated by the device. I felt that triggering a delete request, ensured the device did some kind of 'cleanup'. This is all speculation though and not backed up with actualy evidence. You should definately power down your whole unit, wifi module and heating/cooling system for a couple of minutes to see if that helps.

You shouldn't have to poll it every 10 seconds, if you change the settings using the navigator remote, it will publish the changes pretty quickly through the wifi module. I also experimented with polling, hoping that it would act as a 'keepalive', but no such luck.

[mikz-t]

I've taken to looping a 10 second interval after connection, requesting zone info. Once the TCP connection is lost by the server timeout, this then triggers and repeats the discovery loop which seems to connect as reliably as forcing it, but by not forcing a disconnect I at least have a longer active connection.

@DanielMajoinen could you share your modified hub.py? I'm having similar issues and would like to see if your changes improve my setup.

Thanks,