MQTT on ESP32 reconnection issue

[mmliam]

I'm using MQTT on an ESP32, It serves as a client to a broker running on a Node-Red server. I've found an issue when trying to reconnect the client after the server has gone down, then restarted.

On loss of connection to the server my software first makes sure it's still connected to the network, and re-establishes if necessary.
Next the it recreates a client object and tries to connect. If the TRY connect fails it retries every 15secs.

Here's the issue it will reconnect to the MQTT broker if the server returns during tries 1 thru 9. For the 10th try and beyond, even when the server returns it fails to connect; it just keeps trying not throwing any errors, other than it not being connected. Is there some timeout limiting the number of connection re-tries, or has some data stack overflowed. I've even modified the code to test for network connection, client object creation and client connection each 15 sec interval without success. However, with the server running, if I simply reboot the ESP32 it connects.

Does, anyone have suggestions as to why there seems to be a MQTT client connection TRY limit?

MM

UPDATE: I believe I solved the issue.

In the re-connection loop I printed the OSError codes, thru loop 10 the code was "[Errno 113] ECONNABORTED"; after loop 10 it changed to simply "23". On investigation error 23 refers to too many open sockets. Simply placing a myclient.disconnect() in the loop should correct the problem.

MM

FOLLOW_UP: Unfortunately putting myclient.disconnect() in the loop throws an error. Also, tried myclient.init(); that throws a confusing error saying the attribute "init" doesn't exist, but it is listed as a function for "myclient".
Right now the only solution that works is a machine.reset().

MM

[peterhinch]

You might like to look at mqtt_as which offers a resilient MQTT solution.

[mmliam]

Ok, I understand your approach. Mine is different in that the server does not communicate to the module. The module knows the server is down when it receives an error after trying to send it a message.

Right now my approach is working quite well, but I will review having the server send essentially an "I'm alive" message to the module. But, as it's been said, 'if it ain't broke, don't fix it'.

Thanks for the clarification,
MM

P.S. BTW your "see code" link is broken.

[peterhinch]

I don't know what went wrong there. The code is here.

[mmliam]

Good link now, thanks

[mmliam]

BTW Peter,

It's my understanding that umqtt.simple only supports qos 0, or 1; not 2. Does your mqtt_as support qos 2 for publish & subscribe?

[peterhinch]

No, 0 and 1 only. In most cases the need for qos==2 can be addressed at application level. The sender assigns a unique message ID with the receiver rejecting dupes.