nonblocking approach is indeed blocking

[glebv]

I used example pubsubclient/examples/mqtt_reconnect_nonblocking/mqtt_reconnect_nonblocking.ino as base and added work with a button. Thus, If it calls client.connect(...) my script is unable to read button state in that moment. It's short period about 1-2s but it's weird. Is it possible to handle it in some way?

There's example of important part of my app
https://gist.github.com/glebv/4b79298fc7ac23f342a42017cb77e6cd

[knolleary]

The point of the example is that it doesn't block the app the entire time the client is disconnected - so if it loses its network connection for 5 minutes, the sketch can continue running.

But of course there is work involved in getting connected and that can take a little bit of time. The current API assumes connect returns true/false based on whether it got connected or not. If we changed it to be non-blocking, such that it would connect eventually, that would break a lot of sketches. An alternative would be to add an alternative connect function that wasn't blocking. But that isn't the quick solution you're looking for - I don't know when I'll get a chance to add such a function to the library.

[glebv]

I see, I guess I will be very helpful! Am I right that only one chance to reduce the effect of the connection delay is to increase the time between the reconnections?

[Argon-]

Stumbled upon the same problem recently. I've used this library to send sensor values for quite some time now but now I've changed the sensor and its corresponding library. This one requires me to perform sensor readings within fixed deadlines (3 seconds). It works most of the time* but sometimes connect blocks for too long. Missing a deadline makes the sensor reset its calibration so that's a critical problem.

@knolleary do you think a timeout for connect specifically would be a feasible short-term solution? I realize there is MQTT_SOCKET_TIMEOUT but this one applies to all connections and while I think that a 2 second timeout might work for establishing a connection (correct me if I'm wrong), larger messages might suffer.

* In fact I had a lot of connection drops actually and they are gone since I applied PR #472

[Findus76]

Hello
Have the same problem.
Due to some bug between WiFi or pub subclient, the device can be locked. It stops executing the loop routine. But it seems to continue kicking on the internal watchdog. In an attempt to solve this without having to dig into the WiFi or pubsubclient I try with an external watchdog. But then got a direct problem, those times that the pubsubclient should make connection and get timeout. Then the execution of the loop stops for a few seconds. The external watchdog that has about 1.2s of timeout jumps in and resets.
Should try version 6 soon, see if there remains the same problem (bug and timeout).
Using default settings for Timeout, 15s.

[atuline]

While not perfect, it's the best workaround for the blocking effects of the library that I've seen. Anything that makes my ESP8266 based animated LED displays stutter is immediately noticeable and this library has indeed been a killer if I lose connection to the broker. Connection, dis-connect and re-connect to wifi as well as the broker ALL need to be non-blocking. . . . The loop must flow.

[bobcroft]

The solution shown by Spatnynick looks helpful. Are there things one can do to ensure the broker responds as fast as possible? The delay associated with MQTT reconnect messed up an application where I was trying to use rs485 to achieve control in an area where WiFi wasn't available. I wasn't successful in trying to control when the mqtt reconnect attempt happened in order to better control the rs485 side.

[mattie47]

For reference, #583 (comment) is the example by @spatnynick alluded to by @bobcroft above.