startConfigPortal can leave the Config AP running and also fail to connect to a new ssid if an old connection already exists

[PeteBa]

I am using WiFiManager to establish an on-demand config portal whenever my device is powered on or reset. I set a three minute timeout to allow the user to specify a new wifi access point and set some custom parameters. In the majority of circumstances, I am expecting WiFiManager to timeout without any user interaction and to use previously saved values. Only in exceptional cases (e.g. the device is moved to a new location) would I expect the user to access the Config portal.

I really like this library and it has saved me time and effort but I have seen two inconsistent behaviours that might be worth looking at:

1. WiFiManager does not shutdown the Config Portal AP when wifiManager.startConfigPortal() exceeds _configPortalTimeout. It appears that startConfigPortal() will only call WiFi.Mode(WIFI_STA) if a new access point is selected via the portal but not after a timeout. If the user powers up the device and does not go to the config portal then the timeout expires but the Config AP remains. I think this is inconsistent and a WiFi.mode(WIFI_STA) statement should be included before any return statement from startConfigPortal(). I can work-around this by calling WiFi.mode(WIFI_STA) once control has passed back to my setup() call but it doesn’t feel intuitive.

2. WiFiManager will not connect to a newly selected access point if a connection to another access point already exists. You can see in connectWiFi() that the “auto fix for race condition” section will bail out whenever an existing connection has already been established even if the newly selected ssid/psk from the config portal is different to the existing connection. I think the user should be able to select a new access point even if the old one is connected. This would be useful if moving the device to a new location that has a weak signal from the old access point but a strong signal from the new access point. The only work-around I have found for this is to relocate the device to a location out-of-range of the old access point so that no prior connection exists but this feels sub-optimal.

Again, I think this is a great library and very useful but wonder if the above two cases are expected behavior or things to fix. Happy to try and modify the code and register a pull request if that would be of benefit?

[tzapu]

hi,

this seems to be an issue introduced by the "fix for race condition" indeed.

unfortunately taking that out, causes massive amounts of issues in other sketches.

in your scenario where you might be in the range of two AP's and start config manually, i d sugges you also call WiFi.disconnect() beforehand. You would of course loose connection, but everything would work as it should.

I will look into issue no 1 as soon as i can

cheers