[GH-ISSUE #1425] if wifi is initially not available, but becomes available, autoConnect() still fails, even if we try again

kerem commented

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

Owner

Originally created by @DaleSchultz on GitHub (Jun 3, 2022).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1425

Basic Infos

Hardware

WiFimanager Branch/Release: 0.16.0

Esp8266

Hardware: Wemos D1 mini

Description

After a power failure, when power returns, my ESP devices boot up and attempt to join the network before the wifi router has started up. This means that after a power failure, all the ESP devices have to be restarted to get them on the network.

My expectation was that if the wifi network is absent, and the AP is started, that WifiManager would keep looking for the network, and connect to it if it appeared during the AP session. OK it does not do that, perhaps for technical reasons.

OK, so I thought what I will do is attempt a second call to autoConnect() if the first one times out. (I set the timeout to 180 seconds.)
To test the code I ran a wifi router that was powered off initially. During the first call to autoConnect() I powered the wifi router on. The network was thus present for the second call.
This also fails and the second call to autoConnect() prints a debug message that the credentials are not present. This is not true.

In case the credentials were being somehow 'hidden' by the first call, I ensured that the wifiManager object went out of scope and I created a second WifiManager object for the second call to autoConnect() so there could be no caching issues. Still does not work! (Code is below)

If I reset the ESP, leaving the router powered on WifiManager connected with the stored credentials on the first call.

It appears that WifiManager cannot connect to a wifi network that was not present when the ESP started.

I expect the second call after a 3 minute delay to work just like an initial call.

What can one do to make an ESP join the network if the network comes online after the ESP starts?

Settings in IDE

Module: Wemos D1

Code

{
	  WiFiManager wifiManager;	

	  Serial.print(F("Trying wifi manager with AP:"));
	  Serial.println(APName);
	  wifiManager.setConfigPortalTimeout(timeout);  
	//  wifiManager.setDebugOutput(false);
	  wifiManager.autoConnect(APName);
		// wifi manager wait here until they connect or timeout expires
	 
	}	
	if (WiFi.status() != WL_CONNECTED) {
		// try once more with a new wifi manager
		Serial.println(F("Trying wifi manager again"));
		WiFiManager wifiManager2;
		wifiManager2.setConfigPortalTimeout(10);  // seconds
	//  wifiManager.setDebugOutput(false);
		wifiManager2.autoConnect(APName);
	} // not connected

Ouput

And here is the debug output from the serial monitor:

19:18:35.473 -> Trying wifi manager with AP:RemoteSign
19:18:35.473 -> *WM: 
19:18:35.473 -> *WM: AutoConnect
19:18:35.473 -> *WM: Connecting as wifi client...
19:18:35.507 -> *WM: Status:
19:18:35.507 -> *WM: 0
19:18:35.507 -> *WM: Using last saved values, should be faster

Switched router on at this stage

19:18:42.219 -> *WM: Connection result: 
19:18:42.219 -> *WM: 1
19:18:42.254 -> *WM: 
19:18:42.254 -> *WM: Configuring access point... 
19:18:42.254 -> *WM: RemoteSign
19:18:42.792 -> *WM: AP IP address: 
19:18:42.792 -> *WM: 192.168.4.1
19:18:42.792 -> *WM: HTTP server started
19:21:42.243 -> *WM: freeing allocated params!
19:21:42.243 -> Trying wifi manager again
19:21:42.243 -> *WM: 
19:21:42.243 -> *WM: AutoConnect
19:21:42.243 -> *WM: Connecting as wifi client...
19:21:42.243 -> *WM: Status:
19:21:42.243 -> *WM: 0

19:21:42.243 -> *WM: No saved credentials


19:21:42.243 -> *WM: Connection result: 
19:21:42.243 -> *WM: 0
19:21:42.243 -> *WM: 
19:21:42.243 -> *WM: Configuring access point... 
19:21:42.243 -> *WM: RemoteSign
19:21:42.773 -> *WM: AP IP address: 
19:21:42.773 -> *WM: 192.168.4.1
19:21:42.773 -> *WM: HTTP server started
19:21:52.264 -> *WM: freeing allocated params!

I then reset the ESP module and it connect the first try, proving that the credentials are in fact present.

19:22:32.659 -> Trying wifi manager with AP:RemoteSign
19:22:32.659 -> *WM: 
19:22:32.659 -> *WM: AutoConnect
19:22:32.659 -> *WM: Connecting as wifi client...
19:22:32.659 -> *WM: Status:
19:22:32.659 -> *WM: 0
19:22:32.659 -> *WM: Using last saved values, should be faster
19:22:40.163 -> *WM: Connection result: 
19:22:40.163 -> *WM: 3
19:22:40.163 -> *WM: IP Address:
19:22:40.163 -> *WM: 192.168.2.100
19:22:40.163 -> *WM: freeing allocated params!

Originally created by @DaleSchultz on GitHub (Jun 3, 2022). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1425 ### Basic Infos #### Hardware WiFimanager Branch/Release: 0.16.0 Esp8266 Hardware: Wemos D1 mini ### Description After a power failure, when power returns, my ESP devices boot up and attempt to join the network before the wifi router has started up. This means that after a power failure, all the ESP devices have to be restarted to get them on the network. My expectation was that if the wifi network is absent, and the AP is started, that WifiManager would keep looking for the network, and connect to it if it appeared during the AP session. OK it does not do that, perhaps for technical reasons. OK, so I thought what I will do is attempt a second call to autoConnect() if the first one times out. (I set the timeout to 180 seconds.) To test the code I ran a wifi router that was powered off initially. During the first call to autoConnect() I powered the wifi router on. The network was thus present for the second call. This also fails and the second call to autoConnect() prints a debug message that the credentials are not present. This is not true. In case the credentials were being somehow 'hidden' by the first call, I ensured that the wifiManager object went out of scope and I created a second WifiManager object for the second call to autoConnect() so there could be no caching issues. Still does not work! (Code is below) If I reset the ESP, leaving the router powered on WifiManager connected with the stored credentials on the first call. It appears that WifiManager cannot connect to a wifi network that was not present when the ESP started. I expect the second call after a 3 minute delay to work just like an initial call. What can one do to make an ESP join the network if the network comes online after the ESP starts? ### Settings in IDE Module: Wemos D1 ### Code ```cpp { WiFiManager wifiManager; Serial.print(F("Trying wifi manager with AP:")); Serial.println(APName); wifiManager.setConfigPortalTimeout(timeout); // wifiManager.setDebugOutput(false); wifiManager.autoConnect(APName); // wifi manager wait here until they connect or timeout expires } if (WiFi.status() != WL_CONNECTED) { // try once more with a new wifi manager Serial.println(F("Trying wifi manager again")); WiFiManager wifiManager2; wifiManager2.setConfigPortalTimeout(10); // seconds // wifiManager.setDebugOutput(false); wifiManager2.autoConnect(APName); } // not connected ``` ### Ouput And here is the debug output from the serial monitor: ``` 19:18:35.473 -> Trying wifi manager with AP:RemoteSign 19:18:35.473 -> *WM: 19:18:35.473 -> *WM: AutoConnect 19:18:35.473 -> *WM: Connecting as wifi client... 19:18:35.507 -> *WM: Status: 19:18:35.507 -> *WM: 0 19:18:35.507 -> *WM: Using last saved values, should be faster Switched router on at this stage 19:18:42.219 -> *WM: Connection result: 19:18:42.219 -> *WM: 1 19:18:42.254 -> *WM: 19:18:42.254 -> *WM: Configuring access point... 19:18:42.254 -> *WM: RemoteSign 19:18:42.792 -> *WM: AP IP address: 19:18:42.792 -> *WM: 192.168.4.1 19:18:42.792 -> *WM: HTTP server started 19:21:42.243 -> *WM: freeing allocated params! 19:21:42.243 -> Trying wifi manager again 19:21:42.243 -> *WM: 19:21:42.243 -> *WM: AutoConnect 19:21:42.243 -> *WM: Connecting as wifi client... 19:21:42.243 -> *WM: Status: 19:21:42.243 -> *WM: 0 19:21:42.243 -> *WM: No saved credentials 19:21:42.243 -> *WM: Connection result: 19:21:42.243 -> *WM: 0 19:21:42.243 -> *WM: 19:21:42.243 -> *WM: Configuring access point... 19:21:42.243 -> *WM: RemoteSign 19:21:42.773 -> *WM: AP IP address: 19:21:42.773 -> *WM: 192.168.4.1 19:21:42.773 -> *WM: HTTP server started 19:21:52.264 -> *WM: freeing allocated params! ``` I then reset the ESP module and it connect the first try, proving that the credentials are in fact present. ``` 19:22:32.659 -> Trying wifi manager with AP:RemoteSign 19:22:32.659 -> *WM: 19:22:32.659 -> *WM: AutoConnect 19:22:32.659 -> *WM: Connecting as wifi client... 19:22:32.659 -> *WM: Status: 19:22:32.659 -> *WM: 0 19:22:32.659 -> *WM: Using last saved values, should be faster 19:22:40.163 -> *WM: Connection result: 19:22:40.163 -> *WM: 3 19:22:40.163 -> *WM: IP Address: 19:22:40.163 -> *WM: 192.168.2.100 19:22:40.163 -> *WM: freeing allocated params! ```

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Jun 17, 2022):

Seems unrelated, also not enough debugging or not using dev version

@tablatronix commented on GitHub (Jun 17, 2022): Seems unrelated, also not enough debugging or not using dev version

kerem commented

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

Author

Owner

@jeroenst commented on GitHub (Sep 26, 2022):

Imo wifi manager should try to reconnect, even when the access point has started. When the connection succeeds the access point should be stopped.

@jeroenst commented on GitHub (Sep 26, 2022): Imo wifi manager should try to reconnect, even when the access point has started. When the connection succeeds the access point should be stopped.

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Sep 26, 2022):

It is more complicated than that, leaving sta on when ap is on causes issues since they share channels. I have considered adding background ap scanning and if stored ssid shows up reconnect.

@tablatronix commented on GitHub (Sep 26, 2022): It is more complicated than that, leaving sta on when ap is on causes issues since they share channels. I have considered adding background ap scanning and if stored ssid shows up reconnect.

kerem commented

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

Author

Owner

@jeroenst commented on GitHub (Sep 27, 2022):

Good point. Scanning is a very good idea. But prevent retrying to fast because when the key of the ap has changed it would be impossible to connect to the esp in ap mode. Also maybe pausebor slow down retrying when a client is connected.

@jeroenst commented on GitHub (Sep 27, 2022): Good point. Scanning is a very good idea. But prevent retrying to fast because when the key of the ap has changed it would be impossible to connect to the esp in ap mode. Also maybe pausebor slow down retrying when a client is connected.

kerem commented

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

Author

Owner

@DaleSchultz commented on GitHub (Sep 29, 2022):

I have considered adding background ap scanning and if stored ssid shows up reconnect.

That would be great. Since it is very common for the wifi stack to take longer than an ESP, a background scan makes sense, and if the stored SSID appears, do a single attempt to connect. I think it would be fine to terminate the AP mode if the stored SSID appears, and go back to AP mode if the single connection attempt fails.

@DaleSchultz commented on GitHub (Sep 29, 2022): > I have considered adding background ap scanning and if stored ssid shows up reconnect. That would be great. Since it is very common for the wifi stack to take longer than an ESP, a background scan makes sense, and if the stored SSID appears, do a single attempt to connect. I think it would be fine to terminate the AP mode if the stored SSID appears, and go back to AP mode if the single connection attempt fails.

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Sep 29, 2022):

I usually do this on my devices in user code, I do not automatically start captive portal everytime

@tablatronix commented on GitHub (Sep 29, 2022): I usually do this on my devices in user code, I do not automatically start captive portal everytime

kerem commented

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

Author

Owner

@DaleSchultz commented on GitHub (Sep 29, 2022):

I usually do this on my devices in user code, I do not automatically start captive portal everytime

well yes, can you show working code that does that? My finding was that it appears that WifiManager cannot connect to a wifi network that was not present when the ESP started. (Even when attempted again 'manually' in code - see code in original post)

It is as if the WiFiManager caches the list of SSIDs and does not refresh that list.

@DaleSchultz commented on GitHub (Sep 29, 2022): > I usually do this on my devices in user code, I do not automatically start captive portal everytime well yes, can you show working code that does that? My finding was that it appears that WifiManager cannot connect to a wifi network that was not present when the ESP started. (Even when attempted again 'manually' in code - see code in original post) It is as if the WiFiManager caches the list of SSIDs and does not refresh that list.

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Sep 30, 2022):

Nope you can turn off enableConfigPortal and use autoconnect over and over.

@tablatronix commented on GitHub (Sep 30, 2022): Nope you can turn off enableConfigPortal and use autoconnect over and over.

kerem commented

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

Author

Owner

@DaleSchultz commented on GitHub (Sep 30, 2022):

For those who say this all works, remember the debug statements include:

19:21:42.243 -> *WM: No saved credentials

Which is a clearly incorrect, since a reset allows the device to connect with the credentials it claimed were absent.

I am not sure if folk are ensuring that the SSID saved in the credentials is absent when WiFiManager is initially started.
Remember too, the SSID stored in the credentials is unknown to the code, and so it cannot be hard coded.

@DaleSchultz commented on GitHub (Sep 30, 2022): For those who say this all works, remember the debug statements include: >19:21:42.243 -> *WM: No saved credentials Which is a clearly incorrect, since a reset allows the device to connect with the credentials it claimed were absent. I am not sure if folk are ensuring that the SSID saved in the credentials is _absent_ when WiFiManager is initially started. Remember too, the SSID stored in the credentials is unknown to the code, and so it cannot be hard coded.

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Oct 1, 2022):

This is an esp32 bug has since been fixed

@tablatronix commented on GitHub (Oct 1, 2022): This is an esp32 bug has since been fixed

kerem commented

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

Author

Owner

@DaleSchultz commented on GitHub (Oct 1, 2022):

I am using ESP8266, are you saying there was a WiFiManager bug on ESP32 or the bad message was due to a bug on ESP32?

@DaleSchultz commented on GitHub (Oct 1, 2022): I am using ESP8266, are you saying there was a WiFiManager bug on ESP32 or the bad message was due to a bug on ESP32?

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Oct 4, 2022):

oh hmm then nevermind.. hmm sounds like maybe creds are not actually saving or flash is corrupt.
I have not tested esp8266 in some time though

@tablatronix commented on GitHub (Oct 4, 2022): oh hmm then nevermind.. hmm sounds like maybe creds are not actually saving or flash is corrupt. I have not tested esp8266 in some time though

kerem commented

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

Author

Owner

@rogerio-azevedo commented on GitHub (Mar 1, 2023):

I have this same problem reported. At first I thought there was a problem with my code, because the ESP sometimes reconnected, and sometimes it didn't.

What I noticed, and was able to reproduce on the bench, is that if the Internet does not come back when the ESP is running the setup, it thinks that the internet does not exist, it generates an AP and is in an infinite loop waiting for connections on the AP. After a simple reset on ESP, everything is back to normal operation!

Has anyone managed to resolve this issue?

@rogerio-azevedo commented on GitHub (Mar 1, 2023): I have this same problem reported. At first I thought there was a problem with my code, because the ESP sometimes reconnected, and sometimes it didn't. What I noticed, and was able to reproduce on the bench, is that if the Internet does not come back when the ESP is running the setup, it thinks that the internet does not exist, it generates an AP and is in an infinite loop waiting for connections on the AP. After a simple reset on ESP, everything is back to normal operation! Has anyone managed to resolve this issue?

kerem commented

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

Author

Owner

@DaleSchultz commented on GitHub (Mar 1, 2023):

Since our code cannot access the WiFi manager stored credentials (which the debug code says does not exist) manual attempts to connect to the managed credentials are impossible.

I am only able to retry my default (hardcoded) creds in a loop if I find a matching SSID. As far as I can see there is no solution for WifiManager stored credentials, until this gets fixed. It means if WifiManager stored the wifi credentials, the ESP will not get onto the network after a power failure.

To reproduce:

Plug in a spare router. Lets call its SSID "Proof"
Remove any hard coded credentials from your sketch.
Boot the ESP. Let it start the wifi manager cred capture.
Enter creds for Proof, it should connect fine.
Reboot the ESP to prove the cred are stored OK, by it connecting to the router.
Now switch the router off.
Restart the ESP
Switch the router back on.
It won't connect without resetting the ESP first.

Net result: can't expect an ESP using wifi manager to reconnect right away after a power failure without manual intervention (reset or power cycle or enter creds again?).

Unappealing solution:

Make the ESP always wait, say 5 minutes, before trying to join the network.

@DaleSchultz commented on GitHub (Mar 1, 2023): Since our code cannot access the WiFi manager stored credentials (which the debug code says does not exist) manual attempts to connect to the managed credentials are impossible. I am only able to retry my default (hardcoded) creds in a loop if I find a matching SSID. As far as I can see there is no solution for WifiManager stored credentials, until this gets fixed. It means if WifiManager stored the wifi credentials, the ESP will not get onto the network after a power failure. To reproduce: 1. Plug in a spare router. Lets call its SSID "Proof" 2. Remove any hard coded credentials from your sketch. 3. Boot the ESP. Let it start the wifi manager cred capture. 4. Enter creds for Proof, it should connect fine. 5. Reboot the ESP to prove the cred are stored OK, by it connecting to the router. 6. Now switch the router off. 7. Restart the ESP 8. Switch the router back on. 9. It won't connect without resetting the ESP first. Net result: can't expect an ESP using wifi manager to reconnect right away after a power failure without manual intervention (reset or power cycle or enter creds again?). Unappealing solution: - Make the ESP **always** wait, say 5 minutes, before trying to join the network.

kerem commented

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

Author

Owner

@rogerio-azevedo commented on GitHub (Mar 1, 2023):

Thank you @DaleSchultz! Very good point here! Your solution seems to be something will work most of time. There is any lib to deal with wifi without set the name and credential on code?

I thought of a solution, if I could create it in the AP's loot, that if no one connects to the AP, the module resets, for example after 5 minutes. Would it be possible?

@rogerio-azevedo commented on GitHub (Mar 1, 2023): Thank you @DaleSchultz! Very good point here! Your solution seems to be something will work most of time. There is any lib to deal with wifi without set the name and credential on code? I thought of a solution, if I could create it in the AP's loot, that if no one connects to the AP, the module resets, for example after 5 minutes. Would it be possible?

kerem commented

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

Author

Owner

@DaleSchultz commented on GitHub (Mar 1, 2023):

I am not sure what other libraries exists for managing the gathering of wifi credentials.

I don't now what you mean by 'loot' but yes, if the AP could have a timeout and do a reset if nobody connects after the timeout, that would be a reasonable fix for the problem. Scanning periodically for the saved SSID, and using it when it appears, would be better though.

@DaleSchultz commented on GitHub (Mar 1, 2023): I am not sure what other libraries exists for managing the gathering of wifi credentials. I don't now what you mean by 'loot' but yes, if the AP could have a timeout and do a reset if nobody connects after the timeout, that would be a reasonable fix for the problem. Scanning periodically for the saved SSID, and using it when it appears, would be better though.

kerem commented

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

Author

Owner

@rogerio-azevedo commented on GitHub (Mar 2, 2023):

I am not sure what other libraries exists for managing the gathering of wifi credentials.

I don't now what you mean by 'loot' but yes, if the AP could have a timeout and do a reset if nobody connects after the timeout, that would be a reasonable fix for the problem. Scanning periodically for the saved SSID, and using it when it appears, would be better though.

I meant loop. I think I "solved" my problem by following your advice. I set a timeout time: wifiManager.setConfigPortalTimeout(120); Something surprising happened, after the timeout the board simulated a connection to a network that doesn't exist. And since I have a deal with the connection with the MQTT, if it doesn't connect I reset the board. So I think I solved my problem.

@rogerio-azevedo commented on GitHub (Mar 2, 2023): > I am not sure what other libraries exists for managing the gathering of wifi credentials. > > I don't now what you mean by 'loot' but yes, if the AP could have a timeout and do a reset if nobody connects after the timeout, that would be a reasonable fix for the problem. Scanning periodically for the saved SSID, and using it when it appears, would be better though. I meant loop. I think I "solved" my problem by following your advice. I set a timeout time: **wifiManager.setConfigPortalTimeout(120);** Something surprising happened, after the timeout the board simulated a connection to a network that doesn't exist. And since I have a deal with the connection with the MQTT, if it doesn't connect I reset the board. So I think I solved my problem.

kerem commented

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

Author

Owner

@rogerio-azevedo commented on GitHub (Mar 2, 2023):

#include "SetupWifi.h"

void setup_wifi() {
  delay(10);

  WiFiManager wifiManager;

  wifiManager.setAPCallback(configModeCallback);
  wifiManager.setSaveConfigCallback(saveConfigCallback);
  wifiManager.setConfigPortalTimeout(120);
  wifiManager.autoConnect("MeuIOT", "meuiot123");

@rogerio-azevedo commented on GitHub (Mar 2, 2023): ``` #include "SetupWifi.h" void setup_wifi() { delay(10); WiFiManager wifiManager; wifiManager.setAPCallback(configModeCallback); wifiManager.setSaveConfigCallback(saveConfigCallback); wifiManager.setConfigPortalTimeout(120); wifiManager.autoConnect("MeuIOT", "meuiot123"); ``` ![image](https://user-images.githubusercontent.com/23322862/222441328-0fcf0d3b-78eb-48e9-8f04-9cb52db05616.png)

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Mar 3, 2023):

Yeah that is also a new esp bug it does eventually timeout for me, but by loop do you mean this #1563 or just the normal softap with no timeout set

you can maybe also set a connectTimeout to avoid using waitforconnectresult()

@tablatronix commented on GitHub (Mar 3, 2023): Yeah that is also a new esp bug it does eventually timeout for me, but by loop do you mean this #1563 or just the normal softap with no timeout set you can maybe also set a connectTimeout to avoid using waitforconnectresult()

Rows
Columns

[GH-ISSUE #1425] if wifi is initially not available, but becomes available, autoConnect() still fails, even if we try again #1221

Basic Infos

Hardware

Description

Settings in IDE

Code

Ouput