I detect disconnection by capturing exceptions in MQTTClient.check_msg(), and calling MQTTClient.connect() again on the same MQTTClient object. In the code I found the problem first, it runs in a busy loop (no sleeps) which calls check_msg() very often.
At least in my environment, it disconnects every ~30 minutes, the first disconnection always happens at 29th or 30th minute. Adding time.sleep() or sleep_ms() to the busy loop delays this first disconnectio to minute 45 or 50.
No other change avoids this periodic disconnection (I have tried disconnecting WiFi and/or MQTT on purpose every 15 min, the involuntary disconnection still happens). Perhaps this is an esp-idf connection timeout?
After a number of times it happens, it can't connect anymore.
It seems that socket objects are not being closed in time; adding a periodic gc.collect() seems to resolve this issue.
None of these happens in ESP8266 (does the garbage collection work differently in there?) so perhaps these differences should be documented. Another improvement could be explicit socket closure upon reconnection.
I detect disconnection by capturing exceptions in MQTTClient.check_msg(), and calling MQTTClient.connect() again on the same MQTTClient object. In the code I found the problem first, it runs in a busy loop (no sleeps) which calls check_msg() very often.
No other change avoids this periodic disconnection (I have tried disconnecting WiFi and/or MQTT on purpose every 15 min, the involuntary disconnection still happens). Perhaps this is an esp-idf connection timeout?
It seems that socket objects are not being closed in time; adding a periodic gc.collect() seems to resolve this issue.
None of these happens in ESP8266 (does the garbage collection work differently in there?) so perhaps these differences should be documented. Another improvement could be explicit socket closure upon reconnection.