WiFi Station Mode Confusion

[louislewis2]

Hi,

I have read the documentation around WiFi, I have also read numerous issues and could not work out from that what the "right" thing is, that I need to do.

I am using my own configuration file for storing WiFi credentials, along with many other system configuration values. I have my own process, of being able to change these from a configuration section. The units do deep sleep, and upon awakening they reconnect to the WiFi network configured.

What is the best way to call into the exposed api's for this kind of setup?

Do I need to call WiFi.persistant(false) after each boot?
I do at the moment use WiFi.begin("ssid","password") to connect to the network saved in configuration, is this right or is there a better way?

I am also seeing strange occurrences which can be best described by this issue. Where regardless that the WiFi network has not changed, and the units are using the correct credentials, that they at some point simply stop connecting to the network. Only doing a full power cycle restores it.

I also see that sometimes the WiFi returns that the password is incorrect, at this point I remove the credentials from configuration and then requires the user to enter new credentials, however this happens at multiple locations, where the stations have never had their password changed?

#5527

I have more than 50 of these devices, all showing the same issues.
Any help, guidance on the matter will be greatly appreciated.

[TD-er]

Do I need to call WiFi.persistant(false) after each boot?

As far as I know, yes that's needed to make sure WiFi related information is not stored in flash and thus wear out that sector quite fast.

I do at the moment use WiFi.begin("ssid","password") to connect to the network saved in configuration, is this right or is there a better way?

Not sure if it's considered to be better, but there is also an option to include the last known channel and BSSID (MAC address of AP)
This allows for faster reconnect, but it may fail if the AP has changed channel or in some setups with a repeater (and thus same SSID) where the option without given channel and BSSID may be able to connect.
Another issue which may be fixed with giving the last known channel and BSSID is that the node may start 'hopping' from AP to AP if it can see both the repeater and AP.

I am also seeing strange occurrences which can be best described by this issue. Where regardless that the WiFi network has not changed, and the units are using the correct credentials, that they at some point simply stop connecting to the network. Only doing a full power cycle restores it.

I do see the same behavior every now and then.
In my project I have a setting to let the node perform a reboot after N failed connect attempts (connecting to a host, not AP) This does at least make the nodes available again.
I have tried several things to fix this. For example:

• Destruct and recreate WiFi object
• Set WIFI_OFF and restart again (often leads to a WDT reboot)
• Send gratuitous ARP packets (does seem to fix issues where the node is not reachable anymore)
• Send pings from another host to the node
• Set the channel on the AP to a fixed number (in general a must do with these ESP modules)
• Switch to B/G only mode on the ESP nodes (does improve signal-noise-ratio and thus connection stability)
• Add some delay after setting the WiFi mode to STA. (does improve chance to connect)

And several other steps to try and fix these issues.
If you have so many nodes, it may also be useful to introduce some semi-random offset to the nodes so they will not reconnect all at the same time if the AP disconnected all (e.g. after channel change)
For example add some delay like 100ms times the last 3 bits of the MAC address to the reconnect process.

[louislewis2]

@TD-er

Hi, thank you for the detailed reply, it is greatly appreciated.
Sorry for the delay in my reply, but I have been fairly busy and could not do checks on my side.

I have implemented 1 suggestion so far and on the single test device I have seen a great improvement on the initial connection. Using the bssid and channel method. Before this change,
I was seeing connections go between 8 and 45 seconds. On the single test device, I have not seen more than 3 seconds, though generally it connects on second two.

I am doing final checks and will then push the bin file to my server, where all the devices will grab the update. Once this is done, I will give it a few days and let you know how things are going.

[TD-er]

Please, also have a look at my recent findings I linked here: #6266 (comment)

[devyte]

@louislewis2 Closing for the same reasons as #5527 .