starred/WiFiManager

Fork 0

mirror of https://github.com/tzapu/WiFiManager.git synced 2026-04-27 09:05:56 +03:00

[GH-ISSUE #1165] QUESTION: how to handle ESP device that boots faster than the wifi access point #997

New issue

Closed

opened 2026-02-28 01:28:03 +03:00 by kerem · 10 comments

kerem commented

2026-02-28 01:28:03 +03:00

Owner

Originally created by @sprior on GitHub (Dec 11, 2020).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1165

Basic Infos

I have a bunch of ESP8266 devices (a mix of nodemcu, wemos, and feather) which have been set up with my code using WifiManager. We also had a bunch of power glitches this year. It has appeared that if the power goes out and then comes back on the ESP devices then boot faster than the wifi access point they were set up to connect to. They then can't connect and then go into access point mode to be set up again. I then have them time out if not connected to and reboot to try again. But at this point even when the wifi access point comes back on the ESP devices no longer try to connect to it and just keep looping into access point setup mode. Since there are a lot of these devices in my house it takes quite a while to connect to each one and then configure them again.

My theory is that since the wifi connection SSID and password is stored not in the filesystem config file but a special place as soon as the device can't connect and wifimanager makes it go into access point mode that config is lost, so even if wifimanager then times out and reboots the device it is no longer configured to just connect to the existing access point anymore.

So I'm looking for advice on whether there is a better way to handle this. I assume storing the wifi credentials in the filesystem config file isn't idea for security reasons. What I would like to have happen is:

on boot the ESP tries to connect to the wifi SSID/password that it previously connected to
if it can't connect to that it invokes wifimanager to set up an AP config portal with some timeout
2a) if someone connects to that AP config portal and configures new wifi SSID/pw then connect to it and proceed
2b) if the timeout happens with no connection, then reboot and try again with the previously configured wifi SSID/pw

Currently if the ESP device is rebooted and the wifi AP was not affected the device connects to it just fine, but if the ESP device goes into config portal mode it will never reconnect to the existing AP (once it becomes available again) without being manually configured through the config portal.

I can provide existing code if it sounds like I've done something wrong and the above should already be happening. If there is an existing example of the above then a pointer would be appreciated. If this isn't something currently supported then it would be a very useful enhancement.

Originally created by @sprior on GitHub (Dec 11, 2020). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1165 ### Basic Infos I have a bunch of ESP8266 devices (a mix of nodemcu, wemos, and feather) which have been set up with my code using WifiManager. We also had a bunch of power glitches this year. It has appeared that if the power goes out and then comes back on the ESP devices then boot faster than the wifi access point they were set up to connect to. They then can't connect and then go into access point mode to be set up again. I then have them time out if not connected to and reboot to try again. But at this point even when the wifi access point comes back on the ESP devices no longer try to connect to it and just keep looping into access point setup mode. Since there are a lot of these devices in my house it takes quite a while to connect to each one and then configure them again. My theory is that since the wifi connection SSID and password is stored not in the filesystem config file but a special place as soon as the device can't connect and wifimanager makes it go into access point mode that config is lost, so even if wifimanager then times out and reboots the device it is no longer configured to just connect to the existing access point anymore. So I'm looking for advice on whether there is a better way to handle this. I assume storing the wifi credentials in the filesystem config file isn't idea for security reasons. What I would like to have happen is: 1) on boot the ESP tries to connect to the wifi SSID/password that it previously connected to 2) if it can't connect to that it invokes wifimanager to set up an AP config portal with some timeout 2a) if someone connects to that AP config portal and configures new wifi SSID/pw then connect to it and proceed 2b) if the timeout happens with no connection, then reboot and try again with the previously configured wifi SSID/pw Currently if the ESP device is rebooted and the wifi AP was not affected the device connects to it just fine, but if the ESP device goes into config portal mode it will never reconnect to the existing AP (once it becomes available again) without being manually configured through the config portal. I can provide existing code if it sounds like I've done something wrong and the above should already be happening. If there is an existing example of the above then a pointer would be appreciated. If this isn't something currently supported then it would be a very useful enhancement.

kerem closed this issue

2026-02-28 01:28:03 +03:00

kerem commented

2026-02-28 01:28:04 +03:00

Author

Owner

@EgHubs commented on GitHub (Dec 11, 2020):

I think this might help.

If trying to connect ends up in an endless loop, try to add setConnectTimeout(60) before autoConnect();. The parameter is timeout to try connecting in seconds.

also maybe in a different way a delay of a certain time that you should try at the first line of void setup() function might help you.
For the things you want as far as I know that all you need I faced and found in AutoConnectWithFSParametersAndCustomIP example but except the last line which is 2.2b.

@EgHubs commented on GitHub (Dec 11, 2020): I think [this ](https://github.com/tzapu/WiFiManager#troubleshooting)might help. > If trying to connect ends up in an endless loop, try to add setConnectTimeout(60) before autoConnect();. The parameter is timeout to try connecting in seconds. also maybe in a different way a delay of a certain time that you should try at the first line of `void setup() `function might help you. For the things you want as far as I know that all you need I faced and found in AutoConnectWithFSParametersAndCustomIP example but except the last line which is 2.2b.

kerem commented

2026-02-28 01:28:04 +03:00

Author

Owner

@sprior commented on GitHub (Dec 11, 2020):

I don't mean an endless loop the way you thought I did, I just meant that it endlessly brings up the AP mode config web portal and then a few minutes later times out and restarts, but will never detect that the previously configured wifi access point has become available, connect to it, and exit the loop.

@sprior commented on GitHub (Dec 11, 2020): I don't mean an endless loop the way you thought I did, I just meant that it endlessly brings up the AP mode config web portal and then a few minutes later times out and restarts, but will never detect that the previously configured wifi access point has become available, connect to it, and exit the loop.

kerem commented

2026-02-28 01:28:04 +03:00

Author

Owner

@sprior commented on GitHub (Dec 11, 2020):

Another way to ask this question, does going into Wifimanager AP config mode erase the previously set wifi ssid/pw connection parameters used to connect to the last access point?

@sprior commented on GitHub (Dec 11, 2020): Another way to ask this question, does going into Wifimanager AP config mode erase the previously set wifi ssid/pw connection parameters used to connect to the last access point?

kerem commented

2026-02-28 01:28:04 +03:00

Author

Owner

@EgHubs commented on GitHub (Dec 11, 2020):

Another way to ask this question, does going into Wifimanager AP config mode erase the previously set wifi ssid/pw connection parameters used to connect to the last access point?

No, it doesn't, at least for me (I am using AutoConnectWithFSParametersAndCustomIP as a base for my code, you can check it's settings and compare it to your code). you can check your code for any line like thiswifiManager.resetSettings();
also, you can post the code and the serial output so that we can see what happens.

@EgHubs commented on GitHub (Dec 11, 2020): > Another way to ask this question, does going into Wifimanager AP config mode erase the previously set wifi ssid/pw connection parameters used to connect to the last access point? No, it doesn't, at least for me (I am using AutoConnectWithFSParametersAndCustomIP as a base for my code, you can check it's settings and compare it to your code). you can check your code for any line like this`wifiManager.resetSettings();` also, you can post the code and the serial output so that we can see what happens.

kerem commented

2026-02-28 01:28:04 +03:00

Author

Owner

@sprior commented on GitHub (Dec 11, 2020):

OK thanks, I'll investigate my issue a bit more and see what I find. I really thought the issue was the config portal overwriting the connect settings.

@sprior commented on GitHub (Dec 11, 2020): OK thanks, I'll investigate my issue a bit more and see what I find. I really thought the issue was the config portal overwriting the connect settings.

kerem commented

2026-02-28 01:28:04 +03:00

Author

Owner

@tablatronix commented on GitHub (Dec 11, 2020):

Increase your connecttimeout, or run a loop and wait in your own code first.

No configportal does not reset or erase anything you can keep rebooting and it will be exactly the same.

@tablatronix commented on GitHub (Dec 11, 2020): Increase your connecttimeout, or run a loop and wait in your own code first. No configportal does not reset or erase anything you can keep rebooting and it will be exactly the same.

kerem commented

2026-02-28 01:28:04 +03:00

Author

Owner

@sprior commented on GitHub (Dec 15, 2020):

I found the issue. A long time ago I found the Qrome/printer-monitor project and liked the way that code was written so I used it as the base for new projects of my own. I just checked and here's the Wifimanager invocation code there:
if (!wifiManager.autoConnect((const char *)hostname.c_str())) {// new addition
delay(3000);
WiFi.disconnect(true);
ESP.reset();
delay(5000);
}

So if autoConnect() times out then it's the Wifi.disconnect(true) that causes the ESP8266 to forget the previously configured connection settings. If I comment out that line my code works as desired. I'm not sure why Qrome included that line but I'll open an issue to mention that it should be reconsidered, and in the meantime remove it from my own projects.

Thanks for the help folks.

@sprior commented on GitHub (Dec 15, 2020): I found the issue. A long time ago I found the Qrome/printer-monitor project and liked the way that code was written so I used it as the base for new projects of my own. I just checked and here's the Wifimanager invocation code there: if (!wifiManager.autoConnect((const char *)hostname.c_str())) {// new addition delay(3000); WiFi.disconnect(true); ESP.reset(); delay(5000); } So if autoConnect() times out then it's the Wifi.disconnect(true) that causes the ESP8266 to forget the previously configured connection settings. If I comment out that line my code works as desired. I'm not sure why Qrome included that line but I'll open an issue to mention that it should be reconsidered, and in the meantime remove it from my own projects. Thanks for the help folks.

kerem commented

2026-02-28 01:28:04 +03:00

Author

Owner

@tablatronix commented on GitHub (Dec 15, 2020):

WiFi.disconnect(true); is bad

you can do non persistent disconnects with wm.disconnect();

@tablatronix commented on GitHub (Dec 15, 2020): `WiFi.disconnect(true);` is bad you can do non persistent disconnects with wm.disconnect();

kerem commented

2026-02-28 01:28:04 +03:00

Author

Owner

@sprior commented on GitHub (Dec 15, 2020):

Is there a good reason to do a wm.disconnect(); at all if autoConnect times out? It's not in your example code.

@sprior commented on GitHub (Dec 15, 2020): Is there a good reason to do a wm.disconnect(); at all if autoConnect times out? It's not in your example code.

kerem commented

2026-02-28 01:28:04 +03:00

Author

Owner

@tablatronix commented on GitHub (Dec 15, 2020):

not really, but it might help with reconnections

@tablatronix commented on GitHub (Dec 15, 2020): not really, but it might help with reconnections