search

peterhinch / micropython-mqtt

A 'resilient' asynchronous MQTT driver. Recovers from WiFi and broker outages.
MIT License
549 stars 116 forks source link

Consider making wifi pw/ssid optional or removed ? #111

Closed zcattacz closed 11 months ago

zcattacz commented 1 year ago

I have multiple AP to connect at different locations, some of them use hidden SSID (requires scan and compare BSSID to confirm their existence), some of them are open. I have them handled in boot.py. I notice that provided with one fixed SSID+pw, the mqtt_as code still connect regardless of which AP is connected. It seems that mqtt_as is most of the time just toggling the WiFi active state of ESP32/-S2. I think it reasonable, since in my past month experience toggling WiFi state is enough the fix most WiFi connection issues. With the same logic, it seems more reasonable to make ssid+pw optional or simple removed, for user code to handle Initial connection to a AP.

Plus, the connect(quick=True), flag really helps in the following case, with the default quick=False, the WiFi connection recovery to hidden SSID sometimes become painful to impossible. I didn't realize this until the signal got poor. After the debug output reached Got reliable WiFi and later always followed by a OSErr for connection. If I interrupt the script in serial REPL and e.g. do a ntp settime(), it always fail too. Setting quick=True, make the connection recovery work as expected.

Every time this happens, if the initial connect(quick=False) call failed, the script never manage to reconnect regardless of how long it waited. And I not sure what to do, should the user script manage WiFi on itself ? or .close() and .reconnect()? or keep waiting?

peterhinch commented 1 year ago

If the ESP32-S2 has problems connecting to hidden SSID's that would seem to be a bug in the S2 port of MicroPython rather than in this module.

The purpose of quick=False is to avoid problems at the limit of reception where connectivity could be lost as soon as it was achieved. Some users complained that this introduced a needless delay in situations where RSSI was guaranteed to be good. We therefore introduced the option to disable the check. However I would check the behaviour of the ESP32-S2 with a simple connect script and something such as a ping: it sounds like something is wrong with the port, which is quite recent.

zcattacz commented 1 year ago

I gave up using the MqttClient class, it certainly has its use case, but seems too invasive: everytime, it can't connect to mqtt server, WiFi will be reset, this based on the assumption that mqtt_client is the only network user code (this can be verified by killing the broker instance, then the client will report WiFi error and start toggling WiFi).

The MqttBase seems a good lightweight candidate, but it also have sta_if involved, and coupled with MqttClient in .isconnected(), _kill_tasks() etc, maybe they can be moved to MqttClient ?

peterhinch commented 1 year ago

I am currently busy with other things. Performing surgery on mqtt_as is nontrivial as any changes to the connection protocol require time consuming testing, notably of behaviour at marginal RSSI. I'm only likely to undertake such changes if a feature is requested by multiple users.

Feel free to experiment.