[GH-ISSUE #154] How do you effectively prevent going into config mode if the connection fails?

kerem commented

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

Owner

Originally created by @domingosl on GitHub (Apr 17, 2016).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/154

Upon calling .autoConnect() there is no difference in the way the code behave if there were or not a previous stored credentials.

If there was not previous successful connection (no wifi credential were register or incorrect ones) its ok to go in config mode, BUT, if there was a previous successful connection it will be a good idea to keep trying to connect to the stored ssid at least several times before going into config mode.

The scenario is this:

You setup wifiManager in the setup part of the code
run autoConnect and it fails
Config mode runs
The user inputs the wifi credentials
The ESP connects
In the loop you constantly check wifi.status
If the connection is lost (maybe someone resets the router) the ESP should try to reconnect to the stored wifi for at least 5 minutes before returning to config mode.

This is I think a very common scenario, can anyone provide some guide about how to approach this problem?

Originally created by @domingosl on GitHub (Apr 17, 2016). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/154 Upon calling .autoConnect() there is no difference in the way the code behave if there were or not a previous stored credentials. If there was not previous successful connection (no wifi credential were register or incorrect ones) its ok to go in config mode, BUT, if there was a previous successful connection it will be a good idea to keep trying to connect to the stored ssid at least several times before going into config mode. The scenario is this: 1. You setup wifiManager in the setup part of the code 2. run autoConnect and it fails 3. Config mode runs 4. The user inputs the wifi credentials 5. The ESP connects 6. In the loop you constantly check wifi.status 7. If the connection is lost (maybe someone resets the router) the ESP should try to reconnect to the stored wifi for at least 5 minutes before returning to config mode. This is I think a very common scenario, can anyone provide some guide about how to approach this problem?

kerem closed this issue

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

kerem commented

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

Author

Owner

@kentaylor commented on GitHub (Apr 24, 2016):

I think it is a "common scenario" but a little different to the way you describe it.

Where there is no previously stored credentials you can be confident config mode is required but because WiFi can be flaky it's absence at any moment can't be interpreted as necessarily requiring config mode.

WiFi may be temporarily off or out of range and you want the device to do it's best to connect to WiFi in the background. This is what the ESP8266 does by default if it has stored WiFi credentials and you do not use the WiFi Manager library.

A button press is the best way to be sure config mode is required. An example that demonstrates this is ConfigOnSwitch which currently requires a modified version of this library to run.

@kentaylor commented on GitHub (Apr 24, 2016): I think it is a "common scenario" but a little different to the way you describe it. Where there is no previously stored credentials you can be confident config mode is required but because WiFi can be flaky it's absence at any moment can't be interpreted as necessarily requiring config mode. WiFi may be temporarily off or out of range and you want the device to do it's best to connect to WiFi in the background. This is what the ESP8266 does by default if it has stored WiFi credentials and you do not use the WiFi Manager library. A button press is the best way to be sure config mode is required. An example that demonstrates this is [ConfigOnSwitch](https://github.com/kentaylor/WiFiManager/blob/master/examples/ConfigOnSwitch/ConfigOnSwitch.ino) which currently requires a [modified version](https://github.com/kentaylor/WiFiManager/) of this library to run.

kerem commented

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

Author

Owner

@battika commented on GitHub (Apr 25, 2016):

Hello @kentaylor, just wanted to let you know that I've just tested your modified version of this library and it runs flawlessly. I used to see intermittent issues with this library but your modifications seem to work fine. I guess you are right saying that we should let the ESP8266 manage WiFi credentials and we should not attempt overriding them from code. The only thing I find a bit inconvenient in your workflow is the portal needs to be closed manually once credentials have been verified, but it's not a big deal at all. Thank you for your efforts and sharing the results.

@battika commented on GitHub (Apr 25, 2016): Hello @kentaylor, just wanted to let you know that I've just tested your modified version of this library and it runs flawlessly. I used to see intermittent issues with this library but your modifications seem to work fine. I guess you are right saying that we should let the ESP8266 manage WiFi credentials and we should not attempt overriding them from code. The only thing I find a bit inconvenient in your workflow is the portal needs to be closed manually once credentials have been verified, but it's not a big deal at all. Thank you for your efforts and sharing the results.

kerem commented

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

Author

Owner

@kentaylor commented on GitHub (Apr 25, 2016):

The manual portal closure was implemented as an enhancement. It is interesting that you don't see it that way.

When the portal immediately disappeared after entering credentials the users I tested this with interpreted it as the ESP8266 failing. The browsing computer also switches automatically to another network in the background which users didn't realise. So they would restart the ESP8266, try to reconnect to it and fail because their computer was now on another network. At that point they would tell me it doesn't work and give up.

Keeping the server up and on both networks allows reporting whether it worked and allows reporting in the browser the IP number on the network to which it has connected. You can also connect to the server on the new network to test it is actually there. If the consensus is that the server should disappear immediately after entering the credentials, it can be made to do that again.

I've done some user testing with the current interface. It seemed to work much better but I only had a few test subjects. The biggest problem I've found with users currently is that the server can disappear for a minute or so while it is connecting to the new network which for some people is too confusing.

Ultimately I think an app that does all the network switching in the background would be the least confusing for users.

@kentaylor commented on GitHub (Apr 25, 2016): The manual portal closure was implemented as an enhancement. It is interesting that you don't see it that way. When the portal immediately disappeared after entering credentials the users I tested this with interpreted it as the ESP8266 failing. The browsing computer also switches automatically to another network in the background which users didn't realise. So they would restart the ESP8266, try to reconnect to it and fail because their computer was now on another network. At that point they would tell me it doesn't work and give up. Keeping the server up and on both networks allows reporting whether it worked and allows reporting in the browser the IP number on the network to which it has connected. You can also connect to the server on the new network to test it is actually there. If the consensus is that the server should disappear immediately after entering the credentials, it can be made to do that again. I've done some user testing with the current interface. It seemed to work much better but I only had a few test subjects. The biggest problem I've found with users currently is that the server can disappear for a minute or so while it is connecting to the new network which for some people is too confusing. Ultimately I think an app that does all the network switching in the background would be the least confusing for users.

kerem commented

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

Author

Owner

@battika commented on GitHub (Apr 25, 2016):

@kentaylor I'm probably too used to the old interface and that's why the new way was a bit peculiar for me. Nevertheless, I recognized many enhancements like the new layout, consolidated WiFi settings menu options and actual WiFi values being displayed on the main page. These changes I liked very much. What I need is saving few values to the file system so I will work on rewriting the original example and contribute to your repository through a pull request.

@battika commented on GitHub (Apr 25, 2016): @kentaylor I'm probably too used to the old interface and that's why the new way was a bit peculiar for me. Nevertheless, I recognized many enhancements like the new layout, consolidated WiFi settings menu options and actual WiFi values being displayed on the main page. These changes I liked very much. What I need is saving few values to the file system so I will work on rewriting the original example and contribute to your repository through a pull request.

kerem commented

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

Author

Owner

@kentaylor commented on GitHub (Apr 25, 2016):

It would be good to get some more feedback and code input from others so I look forward to your pull request.

I saw in #140 tzapu speculating on whether "maybe for configuration, there should be a separate library" . It could be simpler to do other configuration from within the sketch and restrict WiFi manager to network configuration. Network configuration is tricky and every application has the same requirements, capturing other parameters less so.

Not sure, but it is hard to cater for all possible parameter capture scenarios and not end up with something too complicated.

@kentaylor commented on GitHub (Apr 25, 2016): It would be good to get some more feedback and code input from others so I look forward to your pull request. I saw in #140 tzapu speculating on whether "maybe for configuration, there should be a separate library" . It could be simpler to do other configuration from within the sketch and restrict WiFi manager to network configuration. Network configuration is tricky and every application has the same requirements, capturing other parameters less so. Not sure, but it is hard to cater for all possible parameter capture scenarios and not end up with something too complicated.

kerem commented

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

Author

Owner

@datacute commented on GitHub (Apr 26, 2016):

I'll be trying out your code modifications @kentaylor

The "other configuration" I wanted to add is to specify an MQTT server name and port, and MQTT topics to use for various things. While these are essentially networking related, what I was envisaging was the kind of set-up that you find in modems/routers, where there are different pages to set up ADSL, WiFi, DHCP, etc. In my mind that is a natural extension of this project... with pages to configure WiFi, MQTT, firmware upgrade.

The existing support for additional parameters was a big step in this direction.

I was also considering creating a dependent library to abstract out most of the json loading and saving so that I don't need to repeat it all the time.

@datacute commented on GitHub (Apr 26, 2016): I'll be trying out your code modifications @kentaylor The "other configuration" I wanted to add is to specify an MQTT server name and port, and MQTT topics to use for various things. While these are essentially networking related, what I was envisaging was the kind of set-up that you find in modems/routers, where there are different pages to set up ADSL, WiFi, DHCP, etc. In my mind that is a natural extension of this project... with pages to configure WiFi, MQTT, firmware upgrade. The existing support for additional parameters was a big step in this direction. I was also considering creating a dependent library to abstract out most of the json loading and saving so that I don't need to repeat it all the time.

kerem commented

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

Author

Owner

@battika commented on GitHub (Apr 26, 2016):

@datacute I agree with you, the ability of adding additional pages would be nice. Adding additional parameters to the configuration page is a very nice addition but it can get very crowded as I want to configure my sensors on it too. I also looked into another solution written by John Lassen based on multiple pages but it seemed a little bit of an overkill.

@battika commented on GitHub (Apr 26, 2016): @datacute I agree with you, the ability of adding additional pages would be nice. Adding additional parameters to the configuration page is a very nice addition but it can get very crowded as I want to configure my sensors on it too. I also looked into [another solution written by John Lassen](http://www.john-lassen.de/index.php/projects/esp-8266-arduino-ide-webconfig) based on multiple pages but it seemed a little bit of an overkill.

kerem commented

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

Author

Owner

@cjamin commented on GitHub (Apr 26, 2016):

@kentaylor One of your commit says: "Access point becomes flaky if set in dual mode and not sucessfully connected to network so change to access point mode only when there is no network connection"

Is that why keeping the config portal always open is a bad option? Can you elaborate on this, please?

@cjamin commented on GitHub (Apr 26, 2016): @kentaylor One of your commit says: "Access point becomes flaky if set in dual mode and not sucessfully connected to network so change to access point mode only when there is no network connection" Is that why keeping the config portal always open is a bad option? Can you elaborate on this, please?

kerem commented

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

Author

Owner

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

This issue is getting off topic from "How do you effectively prevent going into config mode if the connection fails?" so I opened a new topic #160 to respond to @datacute, @battika and @cjamin.

@kentaylor commented on GitHub (Apr 26, 2016): This issue is getting off topic from "How do you effectively prevent going into config mode if the connection fails?" so I opened a new topic #160 to respond to @datacute, @battika and @cjamin.

kerem commented

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

Author

Owner

@scropion86 commented on GitHub (Jul 4, 2016):

help needed here,

i have an ESP8266 based Relay board and RGB LED strip driver More about it here

and usually controlled By Blynk app

i also hocked an IR receiver to receive IR remote signals to do some tasks , but if my Router is of or My connection failed . my device is always stuck in Config mode . which prevent the Board from doing regular thing in Loop()

any way to set an timeout if not connected to run normal code available in Loop().

@scropion86 commented on GitHub (Jul 4, 2016): help needed here, i have an ESP8266 based Relay board and RGB LED strip driver [More about it here](http://egyiot.xyz/pcb-design/egyiot-esp8266-pcb-iot-board/) and usually controlled By Blynk app i also hocked an IR receiver to receive IR remote signals to do some tasks , but if my Router is of or My connection failed . my device is always stuck in Config mode . which prevent the Board from doing regular thing in Loop() any way to set an timeout if not connected to run normal code available in Loop().

kerem commented

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

Author

Owner

@kentaylor commented on GitHub (Jul 4, 2016):

@scropion86, you do not want to call autoConnect(). See https://github.com/tzapu/WiFiManager/issues/154#issuecomment-213891270b .

You could try this example for the timeout you desire.

@kentaylor commented on GitHub (Jul 4, 2016): @scropion86, you do not want to call autoConnect(). See https://github.com/tzapu/WiFiManager/issues/154#issuecomment-213891270b . You could try this [example](https://github.com/kentaylor/WiFiManager/blob/master/examples/ConfigOnStartup/ConfigOnStartup.ino) for the timeout you desire.

kerem commented

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

Author

Owner

@kiralikbeyin commented on GitHub (Jul 13, 2016):

I tried example;


*WM: AP IP address: 
*WM: 192.168.4.1
*WM: HTTP server started
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Handle root
Not connected to WiFi but continuing anyway.
After waiting 66.87 secs in setup() connection result is 1
failed to connect, finishing setup anyway
0.0.0.0
5ccf7f138d7c
HTTP server started
handleFileRead: /
handleFileRead: /css/titatoggle-dist.css
handleFileRead: /js/jquery.js
handleFileRead: /css/ok.css
handleFileRead: /

My own http server and portal are trying to work together so i don't get a page on 192.168.4.1

How to kill portal and serve my own page?

@scropion86 Yesterday i tried IR lib but my remotes are UNKNOWN, do you have any success with UNKNOWN devices rx&tx ?
Can you share your code?

Thanks.

@kiralikbeyin commented on GitHub (Jul 13, 2016): I tried example; ``` *WM: AP IP address: *WM: 192.168.4.1 *WM: HTTP server started *WM: Request redirected to captive portal *WM: Handle root *WM: Request redirected to captive portal *WM: Handle root *WM: Request redirected to captive portal *WM: Handle root *WM: Handle root Not connected to WiFi but continuing anyway. After waiting 66.87 secs in setup() connection result is 1 failed to connect, finishing setup anyway 0.0.0.0 5ccf7f138d7c HTTP server started handleFileRead: / handleFileRead: /css/titatoggle-dist.css handleFileRead: /js/jquery.js handleFileRead: /css/ok.css handleFileRead: / ``` My own http server and portal are trying to work together so i don't get a page on 192.168.4.1 **How to kill portal and serve my own page?** @scropion86 Yesterday i tried IR lib but my remotes are UNKNOWN, do you have any success with UNKNOWN devices rx&tx ? Can you share your code? Thanks.

kerem commented

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

Author

Owner

@kentaylor commented on GitHub (Jul 13, 2016):

There is something different between your implementation and the example. In the example "Not connected to WiFi but continuing anyway" is a message from the loop() function and "connection result is ..." is a message from the setup() function so you would not see them in the order in your message output.

However, not being able to restart the web server is a problem which is dealt with in the example by rebooting the device see https://github.com/kentaylor/WiFiManager/blob/master/examples/ConfigOnSwitch/ConfigOnSwitch.ino#L88 .

@tzapu has another solution at https://gist.github.com/tzapu/ecc0759829d30d5a6152 which is on my list of things to implement.

@kentaylor commented on GitHub (Jul 13, 2016): There is something different between your implementation and the example. In the example "Not connected to WiFi but continuing anyway" is a message from the loop() function and "connection result is ..." is a message from the setup() function so you would not see them in the order in your message output. However, not being able to restart the web server is a problem which is dealt with in the example by rebooting the device see https://github.com/kentaylor/WiFiManager/blob/master/examples/ConfigOnSwitch/ConfigOnSwitch.ino#L88 . @tzapu has another solution at https://gist.github.com/tzapu/ecc0759829d30d5a6152 which is on my list of things to implement.

Rows
Columns

[GH-ISSUE #154] How do you effectively prevent going into config mode if the connection fails? #120