peterhinch / micropython-mqtt

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

wifi is treated as internal details only #122

Open karlp opened 8 months ago

karlp commented 8 months ago

mqtt_as assumes control of the wifi interface. I don't really mind this, but I do want to get information back out of it. I want to find out my dhcp assigned IP address for instance, for other parts of my application to use.

I can reach into the MQTTClient's _sta_if property directly, but it's "marked private" with that leading underscore

Either a wrapper for ifconfig, or .... something else? would be nice?

beetlegigg commented 8 months ago

Just a suggestion - I always connect to wifi before starting the mqtt_as mainly because the mpy_as connection will not continue if an initial connection cannot be made, whereas I want to have some continual wifi connection attempts to cater for power cuts where the microcontroller will be back up and running well before the router has fired up. Maybe you could consider connection to the wifi first as I do. And the leading underscore is just a convention to show its considered to be private, but theres nowt to stop one directly accessing it :-)

karlp commented 8 months ago

that's somewhat viable, and what I'd obviously prefer, but lines like https://github.com/peterhinch/micropython-mqtt/blob/master/mqtt_as/mqtt_as.py#L169-L170 show that mqtt_as is going to trample over whatever you have done anyway, including a 60 second loop attempting to connect, so it's kinda deeply internalized that mqtt_as owns the interface. The 5 second block to decide that the connection is "reliable" is... non-ideal as well. I'm using the _sta_if access right now, it just feels prone to future failure.

beetlegigg commented 8 months ago

Not too sure what you mean by 'trample over whatever you have done'. I connect to the network in my connection code where I use the name of 'wlan'. (wlan = network.WLAN(network.STA_IF). The code you link to in mqtt_as shows the code using its own name for the same connection so that it can readily re-connect on a subsequent outage. If I wanted to I could create yet another name for to use as well as wlan somewhere else in in my code, say 'zlan = network.WLAN(network.STA_IF); zlan.active(True)' and I would still be referring to the same network connection and thus could now use wlan or zlan. But I not making any claims to be a expert though I remember doing some tests to make sure my attempts to pre-connect to the network was not upsetting mqtt_as, and mqtt_as was not just trying to disconnect my wifi connection just to re-connect to it. So a simple pre-connection to your wifi, grabbing all the network info like the allocated network address would seem to give you what you want. If you give it a go and find something amiss then do let me know I've been wrong in my analysis.

peterhinch commented 8 months ago

If initial connection fails, mqtt_as throws. This is because it is likely that there is a config error requiring human intervention. There seemed little point in re-trying endlessly if (say) the password were wrong. It is valid to pre-connect the WiFi before starting mqtt_as.

On reconnection the check for reliable WiFi has been subject to discussion. It resulted from testing when at the very limit of WiFi range and is redundant if signal strength is good. It can be skipped by setting quick=True - see docs.