[GH-ISSUE #215] How to configure to go to config mode on every startup #176

Closed
opened 2026-02-28 01:23:50 +03:00 by kerem · 5 comments
Owner

Originally created by @lawrence-jeff on GitHub (Aug 13, 2016).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/215

The behavior I would like to see is similar to the example where the config page is enabled via GPIO input, however I don't want to burn an input and would rather my ESP just present the config AP for 2 minutes each time it boots and then if the wireless info isn't changed just use the previously saved credentials... so if I want to tweak a config value just reboot the device and hit the page (within the first 2 minutes), if an unexpected reboot it should wait 2 minutes and then use the previously saved values and wireless config.
I can't seem to get it to do this - when wifiManager.startConfigPortal times out it doesn't seem to then fail to saved credentials... any advice to get my desired behavior?

Originally created by @lawrence-jeff on GitHub (Aug 13, 2016). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/215 The behavior I would like to see is similar to the example where the config page is enabled via GPIO input, however I don't want to burn an input and would rather my ESP just present the config AP for 2 minutes each time it boots and then if the wireless info isn't changed just use the previously saved credentials... so if I want to tweak a config value just reboot the device and hit the page (within the first 2 minutes), if an unexpected reboot it should wait 2 minutes and then use the previously saved values and wireless config. I can't seem to get it to do this - when wifiManager.startConfigPortal times out it doesn't seem to then fail to saved credentials... any advice to get my desired behavior?
kerem closed this issue 2026-02-28 01:23:50 +03:00
Author
Owner

@gordonthree commented on GitHub (Aug 13, 2016):

You don't have to "burn" an input to use the On Demand config portal... In the example, a input is compared and the startConfigPortal method is invoked there after.

Somewhere in setup() you can invoke startConfigPortal, without comparing an input.

Used in conjuctuon with setTimeout, you will achieve the desired effect.

Question is, it's not clear that WiFiManager will "fall back" on saved settings if the portal times out. You may have to invoke autoConnect after?

<!-- gh-comment-id:239643310 --> @gordonthree commented on GitHub (Aug 13, 2016): You don't have to "burn" an input to use the On Demand config portal... In the example, a input is compared and the startConfigPortal method is invoked there after. Somewhere in setup() you can invoke startConfigPortal, without comparing an input. Used in conjuctuon with setTimeout, you will achieve the desired effect. Question is, it's not clear that WiFiManager will "fall back" on saved settings if the portal times out. You may have to invoke autoConnect after?
Author
Owner

@lawrence-jeff commented on GitHub (Aug 14, 2016):

After some testing wifi manager does not fail back to saved settings, and I couldn't get calling autoconnect directly after to do what I wanted either (the reference guide also indicates that both should not be used in the same sketch). One odd thing about the portal function is that it starts the client in STA_AP mode so if you have saved settings the device is actually also conencted to your default network - so if you change the network settings in the portal it tries to connect to the new SSID and hits some code intended to prevent a race condition and sees you are already connected and fails to connect to the new network. In my use case I have multiple networks running and I want to switch between them so as is won't allow that.. I ended up forking the code and creating a new function that addresses the issue so now I can call the portal in setup with a 2 minute timeout and if the settings aren't changed it will then just use the prior saved defaults...seems to work ok. If there is a way to get the original code to fail back to saved settings and also allow you to successfully change networks when your saved one is available I would be happy to ditch my hacked up version

<!-- gh-comment-id:239654080 --> @lawrence-jeff commented on GitHub (Aug 14, 2016): After some testing wifi manager does not fail back to saved settings, and I couldn't get calling autoconnect directly after to do what I wanted either (the reference guide also indicates that both should not be used in the same sketch). One odd thing about the portal function is that it starts the client in STA_AP mode so if you have saved settings the device is actually also conencted to your default network - so if you change the network settings in the portal it tries to connect to the new SSID and hits some code intended to prevent a race condition and sees you are already connected and fails to connect to the new network. In my use case I have multiple networks running and I want to switch between them so as is won't allow that.. I ended up forking the code and creating a new function that addresses the issue so now I can call the portal in setup with a 2 minute timeout and if the settings aren't changed it will then just use the prior saved defaults...seems to work ok. If there is a way to get the original code to fail back to saved settings and also allow you to successfully change networks when your saved one is available I would be happy to ditch my hacked up version
Author
Owner

@tzapu commented on GitHub (Aug 14, 2016):

hi,

i m aware about the startConfigPortal and the already connected issues, i have a planned fix, just didn't get anymore hobby time this period to do anything meaningful.

@gordonthree is correct, you could trigger the config portal on any condition you would like, but as things currently stand, what @lawrence-jeff applies, and the bug that s there won t let you access the portal if already connected.

if you do a WiFi.disconnect(); before startConfigPortal then that would get you in, but you would loose previous settings, no fallback if it times out.

in the next couple of weeks i hope to get a few hours and rectify some of these issues

<!-- gh-comment-id:239664497 --> @tzapu commented on GitHub (Aug 14, 2016): hi, i m aware about the startConfigPortal and the already connected issues, i have a planned fix, just didn't get anymore hobby time this period to do anything meaningful. @gordonthree is correct, you could trigger the config portal on any condition you would like, but as things currently stand, what @lawrence-jeff applies, and the bug that s there won t let you access the portal if already connected. if you do a WiFi.disconnect(); before startConfigPortal then that would get you in, but you would loose previous settings, no fallback if it times out. in the next couple of weeks i hope to get a few hours and rectify some of these issues
Author
Owner

@lawrence-jeff commented on GitHub (Aug 14, 2016):

You are welcome to take a look at what I did in my fork - I am more of a hack coder so you might not find it ok but I created a new portal function that fails back to the saved values and handles network switch. I also wanted to move the app parameters to a new page so I created some new functions to handle that. I left all the existing code alone so it shouldn't really impact any existing functionality. Great work on this by the way its a very nice and very needed library

<!-- gh-comment-id:239682932 --> @lawrence-jeff commented on GitHub (Aug 14, 2016): You are welcome to take a look at what I did in my fork - I am more of a hack coder so you might not find it ok but I created a new portal function that fails back to the saved values and handles network switch. I also wanted to move the app parameters to a new page so I created some new functions to handle that. I left all the existing code alone so it shouldn't really impact any existing functionality. Great work on this by the way its a very nice and very needed library
Author
Owner

@kentaylor commented on GitHub (Sep 26, 2016):

The @lawrence-jeff solution looks good to me. It goes into WiFi.mode(WIFI_AP) https://github.com/lawrence-jeff/WiFiManager/blob/master/WiFiManager.cpp#L218 rather than WiFi.mode(WIFI_AP_STA) when going into configuration mode and goes back to WiFi.mode(WIFI_STA) when it exits https://github.com/lawrence-jeff/WiFiManager/blob/master/WiFiManager.cpp#L276 ends configuration mode without connecting.

This example https://github.com/kentaylor/WiFiManager/blob/master/examples/ConfigOnStartup/ConfigOnStartup.ino also goes into configuration mode on every start up. It needs the https://github.com/kentaylor/WiFiManager/ version of WiFi Manager to work.

<!-- gh-comment-id:249485865 --> @kentaylor commented on GitHub (Sep 26, 2016): The @lawrence-jeff solution looks good to me. It goes into WiFi.mode(WIFI_AP) https://github.com/lawrence-jeff/WiFiManager/blob/master/WiFiManager.cpp#L218 rather than WiFi.mode(WIFI_AP_STA) when going into configuration mode and goes back to WiFi.mode(WIFI_STA) when it exits https://github.com/lawrence-jeff/WiFiManager/blob/master/WiFiManager.cpp#L276 ends configuration mode without connecting. This example https://github.com/kentaylor/WiFiManager/blob/master/examples/ConfigOnStartup/ConfigOnStartup.ino also goes into configuration mode on every start up. It needs the https://github.com/kentaylor/WiFiManager/ version of WiFi Manager to work.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/WiFiManager#176
No description provided.