starred/WiFiManager

Fork 0

mirror of https://github.com/tzapu/WiFiManager.git synced 2026-04-27 00:55:52 +03:00

[GH-ISSUE #1693] Is it possible to retry the stored wifi SSID/PW after the Config portal has been activated? #1435

New issue

Closed

opened 2026-02-28 01:30:04 +03:00 by kerem · 6 comments

kerem commented

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

Owner

Originally created by @sprior on GitHub (Dec 31, 2023).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1693

Sometimes the Wifi my device is configured to connect to is down temporarily, for example after a power outage my ESP8266/32 devices might boot faster than my wifi access points. In that situation I'd like for the WifiManager config portal to come up in case the device needs to be reconfigured, but if no client connects to the config portal after a timeout the device would reboot and try the stored SSID/pw configuration again and repeat alternating between the config portal and retrying the last working value until the issue is resolved.

So my first question, is this even possible - does just starting the config portal wipe out the previous ssid/pw stored in flash? Or is this possible and I'm just not calling things correctly (in which case I'd love an example)?

Originally created by @sprior on GitHub (Dec 31, 2023). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1693 Sometimes the Wifi my device is configured to connect to is down temporarily, for example after a power outage my ESP8266/32 devices might boot faster than my wifi access points. In that situation I'd like for the WifiManager config portal to come up in case the device needs to be reconfigured, but if no client connects to the config portal after a timeout the device would reboot and try the stored SSID/pw configuration again and repeat alternating between the config portal and retrying the last working value until the issue is resolved. So my first question, is this even possible - does just starting the config portal wipe out the previous ssid/pw stored in flash? Or is this possible and I'm just not calling things correctly (in which case I'd love an example)?

kerem

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

closed this issue
added the
Question
label

kerem commented

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

Author

Owner

@HowardsPlayPen commented on GitHub (Jan 27, 2024):

The problem resonates with me - as I have an ESP32 tucked away in our attic and it has the same problem. Sometimes it just doesn't manage to reconnect to the WIFI it is configured for so it happily opens the access point and sits there until I notice it has gone rogue.

A quick scan of wifi would show that the stored details are for an available wifi so as mentioned above, periodically retrying this wifi rather than defaulting to access point would be amazing.

I am changing my code to use PsychicHttp for OTA updates and storing the wifi credentials in a json file that I bundle into the updated firmware - and removing use of this library for now.

@HowardsPlayPen commented on GitHub (Jan 27, 2024): The problem resonates with me - as I have an ESP32 tucked away in our attic and it has the same problem. Sometimes it just doesn't manage to reconnect to the WIFI it is configured for so it happily opens the access point and sits there until I notice it has gone rogue. A quick scan of wifi would show that the stored details are for an available wifi so as mentioned above, periodically retrying this wifi rather than defaulting to access point would be amazing. I am changing my code to use PsychicHttp for OTA updates and storing the wifi credentials in a json file that I bundle into the updated firmware - and removing use of this library for now.

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Jan 27, 2024):

Make sure you have a configportaltimeout set and bump your connectreries and conecttimeouts.
Most people just reboot if not connected after portaltimeout

@tablatronix commented on GitHub (Jan 27, 2024): Make sure you have a configportaltimeout set and bump your connectreries and conecttimeouts. Most people just reboot if not connected after portaltimeout

kerem commented

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

Author

Owner

@sprior commented on GitHub (Jan 27, 2024):

@tablatronix Since I'm the one who asked the question I'm not sure what the answer was. So are you saying that if I reboot after portaltimeout that it'll retry again with the previously saved wifi credentials or at that point are those credentials gone and someone will have to connect through the portal and reconfigure the wifi?

@sprior commented on GitHub (Jan 27, 2024): @tablatronix Since I'm the one who asked the question I'm not sure what the answer was. So are you saying that if I reboot after portaltimeout that it'll retry again with the previously saved wifi credentials or at that point are those credentials gone and someone will have to connect through the portal and reconfigure the wifi?

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Jan 28, 2024):

credentials are never reset automatically

@tablatronix commented on GitHub (Jan 28, 2024): credentials are never reset automatically

kerem commented

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

Author

Owner

@sprior commented on GitHub (Jan 28, 2024):

So you're saying that once WifiManager goes into portal mode it's still possible to reboot after timeout and attempt to reconnect using the previously working credentials?

@sprior commented on GitHub (Jan 28, 2024): So you're saying that once WifiManager goes into portal mode it's still possible to reboot after timeout and attempt to reconnect using the previously working credentials?

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Jan 28, 2024):

Yeah of course

@tablatronix commented on GitHub (Jan 28, 2024): Yeah of course