Closed jbfuzier closed 5 months ago
Instead of using break, shouldn’t you use reset? Since you went through 10 loops with no avail.
On the face of it this could be fixed by changing this line to read:
if s.status() not in (network.STAT_CONNECTING, network.STAT_IDLE):
break
However I need to check whether this occurs on the reference board running the latest firmware (V1.22.1). I have never seen this behaviour in the past.
I can't replicate this. The following is a traceback of the range_ex.py
demo over a WiFi outage. Hardware is the ESP32 reference board running 1.22.1, and recovery is normal:
Topic: "foo_topic" Message: "gordon bennett" Retained: False
publish 25
RAM free 128400 alloc 24560
publish 26
WiFi or broker is down.
Checking WiFi integrity.
Got reliable connection
Connecting to broker.
Connected to broker.
Reconnect OK!
We are connected to broker.
Topic: "foo_topic" Message: "pete was here" Retained: False
On the face of it this could be fixed by changing this line to read:
if s.status() not in (network.STAT_CONNECTING, network.STAT_IDLE): break
However I need to check whether this occurs on the reference board running the latest firmware (V1.22.1). I have never seen this behaviour in the past.
Good point, much simpler and makes more sense this way.
I am building the same project on another board, I will check if I have the same behavior with this board. Maybe the 1st board is not good.
I build the same project with two other board, same code (but esp32 S3 instead of esp32) and did not run into the same issue.
Looking back at the first board, it is working but is experiencing much more deconnection / instability than others. So there is likely something wrong with the board. Howerver it is still kind of working with the fix.
OK, thanks for letting me know. I think we've resolved this one.
Others have reported problems with firmware V1.20 and later (e.g. #132 and #133). We have figure out the reason and I have pushed an update which addresses this.
Hello,
Firstly, thanks for this great project.
I ran into an issue on an ESP32 with micropython v1.21.1. When a disconnection occured, mqtt_as tries to reconnect forever but fails. After adding some debugging, I think I have pinpointed the root cause :
During a successful connection, my ESP32 goes through the following status : CONNECTING (1001)-> IDLE (1000) -> GOT_IP (1010).
The idle status causes the break on line 603 :
Which triggers OSError :
Which is caught on line 749 and result in a infinite disconnect / reconnect cycle (line 743) :
Here is some debug log commented to tell where the print are placed in the code :
For my previous project, I was using mp 1.19 with mqtt_as and I am pretty sure there was no issue. I see several plausible explanations :
Anyway, I think the mqtt_as code should handle the worst possible scenarios and as such should take into account this ESP32 behavior.
(The fix I am using which totally solved the issue for me is not very elegant but looks like that. Arround line 602) :