Show all opened sockets

[sebion]

Hi all,

In one of my IOT applicationq, I'm facing the following problem.
In the program, I've got an endless loop (kind of "While True:") which stops after several days without any warning signs.
Asynchronously with this main loop, I've got a routine which aims to maintain an active wifi connexion.

To try to find the root cause, I'd like to know if there's a way of listing all the opened sockets ?

Thank you i advance for your help.

S.

[pythoncoder]

I'd put each socket into a Python set, and remove it before you close it. Periodically print the contents of the set. It's also handy periodically to print the amount of free RAM: a good way to detect memory leaks caused by objects persisting after the need for them has passed.

A word of warning: developing this kind of resilient wireless application is massively time consuming. As you've discovered you'll find yourself chasing down faults which occur rarely, or only in consequence of unusual conditions like sporadic radio interference. Memory leaks due to unclosed sockets are merely the start of the potential issues. You need to ensure communications resume cleanly after events like WiFi failure, internet outages, gradual loss of WiFi signal, client and server outages; not all of these will apply in your application but I'm sure you get my drift.

I suggest you look at this repo and resilient MQTT for two instances of tested solutions.

[sebion]

Hi,

To be honest, I use your own MQTT robust library that I compiled in my own firmware, and I would like to thank you for this work.
I added some asynchronous routines.
I can see that periodically the ESP8266 reconnects to the Wifi and the MQTT broker, until it stops after some days.
Once stopped, it remains reachable via wifi and WebRepl, and I can connect to the micropython console, but the program is stopped without knowing why.

That is why I'm diving deeply in the code to try to find out any tracks to a solution.

Thank you for your help.

[pythoncoder]

The ESP8266 is less stable than other platforms. I am currently running a long term test of resilient MQTT running on two Pyboard D clients. One has run for 2 weeks 3 days and coped with two WiFi outages. The other (in an adverse -80dB RSSI location) has run for four days with one outage and 9 retransmissions. I started it later as it took me a while to fix up a power source. My conclusion so far is that the Pyboard D is rock-solid stable.

I never had > 2 weeks running on an ESP8266 without using a WDT. Outages seem much more frequent on ESP8266.

The range_ex.py demo program which I use in these tests publishes RAM usage: I'd be surprised if there is a memory leak.

[kevinkk525]

I have one esp8266 which ran since 5 weeks and one which ran since over 2 weeks. However no matter how close they are to the AP, they typically reconnect twice a day.
So I consider the esp8266 rock-solid too.

Making a resilient connection however isn't that easy as we have experienced and having more than one outgoing socket is not adviseable.

[pythoncoder]

It is odd that ESP8266 nodes experience far more WiFi outages than Pyboard D's. Compare several a day to two in over two weeks (in the same location). I started out on this journey because I couldn't keep official UMQTT running for more than an hour on an ESP8266.

The other factor (for @sebion's benefit) is power supply quality. Many USB "wall warts" are prone to emitting glitches. They are adequate for charging phones, but not for long term running of microcontrollers.

[sebion]

Hi Peter,

Since your last reply, I passed a long time trying to get the root cause of my problem.
I had a look of the amount of free memory, which was not the problem, and I succeeded in catching the error which causes my program to stop.
I let you guess ... queue overflow !

And now the question is, what is the solution to solve that issue.

If you can go on with guiding me a little, I would appreciate a lot.

Thanks in advance for your help.

Sebastien