fix: doesn't reconnect to wifi if wifi goes off and comes back on - not saving the wifi config? about sensesp

[joelkoz]

Line 51 of net/networking.cpp calls the wifi manager's autoConnect() method to connect to wifi. In that call, there is an optional parameter to specify the number of retries before falling back into access point mode. The default number of retries is 1. So, that is the reason for the current behavior.

I'm thinking we should have user configurable option that would allow the max retries to be set. A max retry of "1" should ALWAYS be used if the sensor has NEVER been configured before. If it HAS been configured before, the the user should be able to set the number of retries, and the delay between each retry (both are parameters to that call).

Of course, we need to be careful about what happens if the user wants to change the Wifi on purpose, or for whatever reason, loses the old setting permanently. If the gauge is configured to continously retry, you'd lose communication with it all together.

Maybe a better approach is to retry a certain number of times, and if that fails, go into AP mode, but if no configuration occurs in X number of minutes, the system restarts and tries to retry again? I think the SensESP configuration IS in fact saved - its just that the wifi manager goes into AP mode upon first failure and then just waits there.

[joelkoz]

Upon further review...

It appears that the behavior of "if no AP config occurs in X number of minutes, reboot and retry" is already implemented.

Line 42 of networking.cpp has this:

wifi_manager->setConfigPortalTimeout(WIFI_CONFIG_PORTAL_TIMEOUT)

and WIFI_CONFIG_PORTAL_TIMEOUT is currently set at 180 seconds.

So, it does appear that somewhere in this process, SensESP is losing the previous configuration. If it had kept it, after the 180 second timeout, it should have reconnected.

[ba58smith]

Exactly. I'll try what you suggested (using a debug message to display the SSID just before it tries to connect), and see if that reveals anything.

[ba58smith]

I added some debug messages in networking.cpp, and once the ESP was up and running properly, I turned the wifi off and back on. The two problems seem to be:

1. Even after the wifi network becomes visible again in the scan, ESP doesn't connect to it, and eventually times out and restarts. This could be my network - on my own computer, I can see the network SSID, but it takes my computer several attempts to finally connect to it. (The router takes a long time to fully boot up.)
2. After the first timeout-and-start over, the network SSID is no longer known, so it will never reconnect at that point.
   I'm going to make my WIFI_CONFIG_PORTAL_TIMEOUT really long - 5 minutes - and see if problem #1 isn't really a SensESP problem. But problem #2 certainly seems to be, unless I'm trying to display a value that hasn't been set it memory yet because the wifi hasn't restarted. Maybe my debug message needs to be pulling directly from the configuration file stored on the device?

[ba58smith]

I set my WIFI_CONFIG_PORTAL_TIMEOUT to 420 (seven minutes) and got the same problem in #1, above - it knows the SSID it's supposed to connect to, and it sees the network, but it never connects. My computer was able to connect long before the timeout period. Now I'll look into #2, above.

[ba58smith]

I added some more debug messages, and now I can see (in the attached file) that the wifi SSID is still known by SensESP before the ESP.restart(), but I'm guessing the wifi SSID is somehow lost during the ESP.restart(), because although the network is found, it doesn't connect, and when it times out, just before it restarts again, it no longer knows the wifi SSID.

At this point, I don't know what to try next.

SensESP loss of network issue2.txt