adafruit / Adafruit_IO_Arduino

Arduino library to access Adafruit IO from WiFi, cellular, and ethernet modules.
Other
209 stars 108 forks source link

Don't crash on network disconnect #100

Closed sellensr closed 4 years ago

sellensr commented 4 years ago

Reference: https://github.com/adafruit/Adafruit_IO_Arduino/issues/99

Scope: Enable run() to return under an appropriate status instead of hanging if the wifi connection dies. Enable mqttStatus() to return an error code without waiting for a long timeout.

Limitations: User code that doesn't check return status may assume a save succeeded when it failed and returned a code without waiting for timeout.

sellensr commented 4 years ago

took a while to get back on track -- my example was using local files.

brentru commented 4 years ago

@sellensr Looks great, thank you for taking the time to fix this issue with AIOA :)

I will test this today or tomorrow with the examples within the examples directory to make sure everything in the package still works correctly.

brentru commented 4 years ago

@sellensr Great work on this PR, works like a charm on a Huzzah ESP32! This will help a lot of people using this library.

Ok - to prepare for release, please change the version in this file (https://github.com/adafruit/Adafruit_IO_Arduino/blob/master/library.properties#L2) to 3.3.0


Connected Feather Huzzah32 to an iPhone WiFi Hotspot, allowed it to tx/rx with Adafruit IO 3x times. Then, I disabled the hotspot, waited a second, and re-enabled the hotspot. The Feather Huzzah32 did not hang, and automatically re-connected to the network.

Test Setup: iPhone Hotspot, Feather Huzzah32 Red: Active Connection Black: Inactive Connection with Adafruit IO Blue: Active Connection _dev_cu_SLAB_USBtoUART_and_brubell_on_Adafruit_IO

sellensr commented 4 years ago

Changed the version number to 3.3.0

I also have some additional changes in the pipe that I think will facilitate fast response to connection faults without changing the behaviour for any existing code. It will still provide the long delay inside the run() call while everything times out, unless user code explicitly asks it to fail fast. I'll play with it a little more before sending it along.