[GH-ISSUE #191] On Demand Portal issue ... no longer saving new settings?

kerem commented

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

Owner

Originally created by @Humancell on GitHub (Jul 7, 2016).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/191

I recently updated all of my code to the latest libraries. I'm seeing an issue that I can't resolve. This was all working fine with an older version of WiFiManager, but now with the latest I'm getting a failure. Here is my code:

  WiFiManager wifiManager;

  // The extra parameters to be configured (can be either global or just in the setup)
  // After connecting, parameter.getValue() will get you the configured value
  // id/name placeholder/prompt default length
  WiFiManagerParameter customEndpointHost("endpoint", "endpoint hostname", endpointHost, 40);
  WiFiManagerParameter customEndpointPort("port", "endpoint port", endpointPort, 5);
  WiFiManagerParameter customEndpointURL("path", "endpoint path", endpointURL, 128);

  //set config save notify callback
  wifiManager.setSaveConfigCallback(saveConfigCallback);

  //add all your parameters here
  wifiManager.addParameter(&customEndpointHost);
  wifiManager.addParameter(&customEndpointPort);
  wifiManager.addParameter(&customEndpointURL);

  // sets timeout until configuration portal gets turned off
  wifiManager.setTimeout(wifiManagerTimeout);

  //it starts an access point with the specified name
  //here  "AutoConnectAP"
  //and goes into a blocking loop awaiting configuration

  //WITHOUT THIS THE AP DOES NOT SEEM TO WORK PROPERLY WITH SDK 1.5 , update to at least 1.5.1
  //WiFi.mode(WIFI_STA);

  // we don't want it to connect after being configured ... just reset.
  wifiManager.setBreakAfterConfig(true);

  // now it's time to run the config portal
  sprintf(captivePortalSSID, "Wovyn_%06X", GUID);
  Serial.print("Captive Portal SSID: ");
  Serial.println(captivePortalSSID);
  wifiManager.startConfigPortal(captivePortalSSID);

  //if you get here you have connected to the WiFi
  //read updated parameters
  strcpy(endpointHost, customEndpointHost.getValue());
  strcpy(endpointPort, customEndpointPort.getValue());
  strcpy(endpointURL, customEndpointURL.getValue());

  //save the custom parameters to FS
  if (shouldSaveConfig) {
    Serial.print("Saving config ... ");
    if (saveConfig()) {
      Serial.println("Config saved");
    } else {
      Serial.println("Failed to save config");
    }
  }

  //reset and allow the loop to perform the connect ...
  delay(3000);
  //ESP.wdtDisable();
  ESP.reset();
  delay(5000);

The issue is that now - after the update - when I click the save button in my browser to save the Wifi settings I see the following on my debug log:

*WM: Adding parameter
*WM: endpoint
*WM: Adding parameter
*WM: port
*WM: Adding parameter
*WM: path
Captive Portal SSID: Wovyn_D80E88
*WM: SET AP STA
*WM:
*WM: Configuring access point...
*WM: Wovyn_D80E88
*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: Request redirected to captive portal
*WM: Scan done
*WM: Wovyn-x20131130
*WM: -54
*WM: http://80211.net
*WM: -56
*WM: http://80211.net-HVCHHE
*WM: -74
*WM: http://80211.net-HVCH
*WM: -80
*WM: myqwest6487
*WM: -90
*WM: Sent config page
*WM: Handle root
*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: WiFi save
*WM: Parameter
*WM: endpoint
*WM: host.domain.com
*WM: Parameter
*WM: port
*WM: 8880
*WM: Parameter
*WM: path
*WM: /emitter/test2
*WM: Sent wifi save page
*WM: Connecting to new AP
*WM: Connecting as wifi client...
*WM: Already connected. Bailing out.
Should save config
Saving config ... Config saved

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v3de0c112
~ld

Why am I see this: *WM: Already connected. Bailing out. ??

It acts like it's about to try the new settings, and then it aborts with that error. and now it's no longer saving the new settings ... it restarts and tries to connect to the old WiFi settings?

Originally created by @Humancell on GitHub (Jul 7, 2016). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/191 I recently updated all of my code to the latest libraries. I'm seeing an issue that I can't resolve. This was all working fine with an older version of WiFiManager, but now with the latest I'm getting a failure. Here is my code: > ``` > WiFiManager wifiManager; > > // The extra parameters to be configured (can be either global or just in the setup) > // After connecting, parameter.getValue() will get you the configured value > // id/name placeholder/prompt default length > WiFiManagerParameter customEndpointHost("endpoint", "endpoint hostname", endpointHost, 40); > WiFiManagerParameter customEndpointPort("port", "endpoint port", endpointPort, 5); > WiFiManagerParameter customEndpointURL("path", "endpoint path", endpointURL, 128); > > //set config save notify callback > wifiManager.setSaveConfigCallback(saveConfigCallback); > > //add all your parameters here > wifiManager.addParameter(&customEndpointHost); > wifiManager.addParameter(&customEndpointPort); > wifiManager.addParameter(&customEndpointURL); > > // sets timeout until configuration portal gets turned off > wifiManager.setTimeout(wifiManagerTimeout); > > //it starts an access point with the specified name > //here "AutoConnectAP" > //and goes into a blocking loop awaiting configuration > > //WITHOUT THIS THE AP DOES NOT SEEM TO WORK PROPERLY WITH SDK 1.5 , update to at least 1.5.1 > //WiFi.mode(WIFI_STA); > > // we don't want it to connect after being configured ... just reset. > wifiManager.setBreakAfterConfig(true); > > // now it's time to run the config portal > sprintf(captivePortalSSID, "Wovyn_%06X", GUID); > Serial.print("Captive Portal SSID: "); > Serial.println(captivePortalSSID); > wifiManager.startConfigPortal(captivePortalSSID); > > //if you get here you have connected to the WiFi > //read updated parameters > strcpy(endpointHost, customEndpointHost.getValue()); > strcpy(endpointPort, customEndpointPort.getValue()); > strcpy(endpointURL, customEndpointURL.getValue()); > > //save the custom parameters to FS > if (shouldSaveConfig) { > Serial.print("Saving config ... "); > if (saveConfig()) { > Serial.println("Config saved"); > } else { > Serial.println("Failed to save config"); > } > } > > //reset and allow the loop to perform the connect ... > delay(3000); > //ESP.wdtDisable(); > ESP.reset(); > delay(5000); > ``` The issue is that now - after the update - when I click the save button in my browser to save the Wifi settings I see the following on my debug log: > *WM: Adding parameter > *WM: endpoint > *WM: Adding parameter > *WM: port > *WM: Adding parameter > *WM: path > Captive Portal SSID: Wovyn_D80E88 > *WM: SET AP STA > *WM: > *WM: Configuring access point... > *WM: Wovyn_D80E88 > *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: Request redirected to captive portal > *WM: Scan done > *WM: Wovyn-x20131130 > *WM: -54 > *WM: http://80211.net > *WM: -56 > *WM: http://80211.net-HVCHHE > *WM: -74 > *WM: http://80211.net-HVCH > *WM: -80 > *WM: myqwest6487 > *WM: -90 > *WM: Sent config page > *WM: Handle root > *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: WiFi save > *WM: Parameter > *WM: endpoint > *WM: host.domain.com > *WM: Parameter > *WM: port > *WM: 8880 > *WM: Parameter > *WM: path > *WM: /emitter/test2 > *WM: Sent wifi save page > *WM: Connecting to new AP > *WM: Connecting as wifi client... > *WM: Already connected. Bailing out. > Should save config > Saving config ... Config saved > > ets Jan 8 2013,rst cause:2, boot mode:(3,6) > > load 0x4010f000, len 1384, room 16 > tail 8 > chksum 0x2d > csum 0x2d > v3de0c112 > ~ld Why am I see this: *WM: Already connected. Bailing out. ?? It acts like it's about to try the new settings, and then it aborts with that error. and now it's no longer saving the new settings ... it restarts and tries to connect to the old WiFi settings?

kerem closed this issue

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

kerem commented

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

Author

Owner

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

You see *WM: Already connected. Bailing out. ?? because it is already connected to the network with the same values. If you enter invalid WiFi values, reboot the device and then enter valid values you will not see that message.

@kentaylor commented on GitHub (Jul 8, 2016): You see *WM: Already connected. Bailing out. ?? because it is already connected to the network with the same values. If you enter invalid WiFi values, reboot the device and then enter valid values you will not see that message.

kerem commented

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

Author

Owner

@Humancell commented on GitHub (Jul 8, 2016):

This is actually not the case. I am selecting a completely different network ... and have tried numerous different networks. It will not allow me to change the network now. :-(

How can I force the disconnect? In the code above ... where do I do it?

Before: wifiManager.startConfigPortal(captivePortalSSID);

??

@Humancell commented on GitHub (Jul 8, 2016): This is actually not the case. I am selecting a completely different network ... and have tried numerous different networks. It will not allow me to change the network now. :-( How can I force the disconnect? In the code above ... where do I do it? Before: wifiManager.startConfigPortal(captivePortalSSID); ??

kerem commented

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

Author

Owner

@tzapu commented on GitHub (Jul 8, 2016):

if you do a one off wifiManager.reset() it should remove all your saved ssids.

you could also just put a wifi.disconnect() right before startConfigPortal. that should sort it.

why are you using startCOnfigPortal in the sketch above instead of simply autoConnect? that should behave ok.

there is a bug in startConfigPortal that doesn t let you change network if the network it s connected to exists and it can connect to. this was introduced when sorting other bugs for auto connect...

you might want to try ken taylor s branch in which he did things a bit differently i think...

@tzapu commented on GitHub (Jul 8, 2016): if you do a one off wifiManager.reset() it should remove all your saved ssids. you could also just put a wifi.disconnect() right before startConfigPortal. that should sort it. why are you using startCOnfigPortal in the sketch above instead of simply autoConnect? that should behave ok. there is a bug in startConfigPortal that doesn t let you change network if the network it s connected to exists and it can connect to. this was introduced when sorting other bugs for auto connect... you might want to try ken taylor s branch in which he did things a bit differently i think...

kerem commented

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

Author

Owner

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

Good to chat tzapu. I haven't answered your pull request query because I intended to update some other stuff first but this is an opportunity to discuss some of the issues. You say "there is a bug in startConfigPortal..." I dealt with that by always wiping out the old credentials before adding the new ones. There is then no chance it is already connected to a network when it is told to connect.

I don't think wifiManager.reset() removes the network credentials see https://github.com/tzapu/WiFiManager/blob/master/WiFiManager.cpp#L630. One of the changes I made was to add this line https://github.com/kentaylor/WiFiManager/blob/master/WiFiManager.cpp#L811 so that it would and if I remember correctly it should be WiFi.disconnect(true) rather than WiFi.disconnect() to wipe out WiFi credentials.

I'm confused by the @Humancell problem description but one possibility is corrupted Flash due to a soon to be fixed Espressif library bug. When it occurs the device fails in all sorts of strange ways. Corrupted flash will survive loading a new sketch. This sketch https://github.com/kentaylor/EraseEsp8266Flash will completely erase flash, including your network credentials.

I don't like autoconnect() for several reasons which is why I mark it as deprecated and it does nothing but wait for a network connection in my version. It appears it's primary purpose is to connect to WiFi but the module does that automatically, once it has credentials, so for that purpose it is superfluous. There is a second problem which will probably go away when the Espressif library bug is fixed but the Espressif bug is triggered by calling wifi.begin() and wifi.begin(ssid,password) with new parameters so that calling these functions unnecessarily increases flash corruption risk. Thirdly it puts up a configuration portal when it can't see the WiFi network for which it has credentials. This works well during development but not during deployment because there is lots of reasons a WiFi network is not visible at any particular time and because it will often be there again at some time in the future. Therefore, in most circumstances, putting up a configuration portal is not the appropriate response.

Having said that I can see that autoconnect() could be useful if done differently. The ESP8266 can store up to 5 sets of WiFi network credentials but switching between them is done manually. If autoconnect() did a scan, looked in the credential list and swapped to the one with the highest signal strength, then that would be useful. I, and presumably others, often move devices between networks and setting up new credentials each time is a pain. Modifying WiFiManager to collect and manage the 5 sets of credentials would be a bit of effort though.

@kentaylor commented on GitHub (Jul 8, 2016): Good to chat tzapu. I haven't answered your pull request query because I intended to update some other stuff first but this is an opportunity to discuss some of the issues. You say "there is a bug in startConfigPortal..." I dealt with that by always wiping out the old credentials before adding the new ones. There is then no chance it is already connected to a network when it is told to connect. I don't think wifiManager.reset() removes the network credentials see https://github.com/tzapu/WiFiManager/blob/master/WiFiManager.cpp#L630. One of the changes I made was to add this line https://github.com/kentaylor/WiFiManager/blob/master/WiFiManager.cpp#L811 so that it would and if I remember correctly it should be WiFi.disconnect(true) rather than WiFi.disconnect() to wipe out WiFi credentials. I'm confused by the @Humancell problem description but one possibility is corrupted Flash due to a soon to be fixed Espressif library bug. When it occurs the device fails in all sorts of strange ways. Corrupted flash will survive loading a new sketch. This sketch https://github.com/kentaylor/EraseEsp8266Flash will completely erase flash, including your network credentials. I don't like autoconnect() for several reasons which is why I mark it as deprecated and it does nothing but wait for a network connection in my version. It appears it's primary purpose is to connect to WiFi but the module does that automatically, once it has credentials, so for that purpose it is superfluous. There is a second problem which will probably go away when the Espressif library bug is fixed but the Espressif bug is triggered by calling wifi.begin() and wifi.begin(ssid,password) with new parameters so that calling these functions unnecessarily increases flash corruption risk. Thirdly it puts up a configuration portal when it can't see the WiFi network for which it has credentials. This works well during development but not during deployment because there is lots of reasons a WiFi network is not visible at any particular time and because it will often be there again at some time in the future. Therefore, in most circumstances, putting up a configuration portal is not the appropriate response. Having said that I can see that autoconnect() could be useful if done differently. The ESP8266 can store up to 5 sets of WiFi network credentials but switching between them is done manually. If autoconnect() did a scan, looked in the credential list and swapped to the one with the highest signal strength, then that would be useful. I, and presumably others, often move devices between networks and setting up new credentials each time is a pain. Modifying WiFiManager to collect and manage the 5 sets of credentials would be a bit of effort though.

kerem commented

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

Author

Owner

@Humancell commented on GitHub (Jul 8, 2016):

Thank you for the suggestions ... I'll do some testing today and see if I can get things working correctly. I do think the bug you mention is quite possibly what is impacting me, and hope to see it fixed. I have four APs in range, and my ESP is configured for one of them ... but not the one I want it to be connected to.

Per your question about autoconnect(), I don't want to use it for some of the same reasons as kentaylor. In my situation, the captive portal is only to be done upon direct user action during power-up. Once configured it is never used again, unless the user intentionally wants to move the device to a new network. The ESP then goes into a deep sleep/wake cycle where it wakes to perform data collection and threshold checks, then - once all of that is complete - attempts to connect to the configured network, POSTs the collected data to one or more servers, and returns to deep sleep.

I can't have anything alter this cycle, nor have it enter into AP/Configuration Mode, just because it could not connect to the configured network. Instead we log a count of the connection failures, and save that to flash.

Also, since everything is on battery, I've got to keep things as quick as possible, and eliminate any mode or behavior that would increase the time the device is awake.

For now I've reverted back to the old versions of the ESP code and your library ... but hope to find a combination that will work.

@Humancell commented on GitHub (Jul 8, 2016): Thank you for the suggestions ... I'll do some testing today and see if I can get things working correctly. I do think the bug you mention is quite possibly what is impacting me, and hope to see it fixed. I have four APs in range, and my ESP is configured for one of them ... but not the one I want it to be connected to. Per your question about autoconnect(), I don't want to use it for some of the same reasons as kentaylor. In my situation, the captive portal is only to be done upon direct user action during power-up. Once configured it is never used again, unless the user intentionally wants to move the device to a new network. The ESP then goes into a deep sleep/wake cycle where it wakes to perform data collection and threshold checks, then - once all of that is complete - attempts to connect to the configured network, POSTs the collected data to one or more servers, and returns to deep sleep. I can't have anything alter this cycle, nor have it enter into AP/Configuration Mode, just because it could not connect to the configured network. Instead we log a count of the connection failures, and save that to flash. Also, since everything is on battery, I've got to keep things as quick as possible, and eliminate any mode or behavior that would increase the time the device is awake. For now I've reverted back to the old versions of the ESP code and your library ... but hope to find a combination that will work.

kerem commented

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

Author

Owner

@tzapu commented on GitHub (Jul 9, 2016):

hi,

a wifi.disconnect() before calling startConfigPortal() should sort it for you.

for battery operated sensors, the newer version, with the fix above should be a lot better. it is a lot faster to connect usually, so less battery spent.

i didn t see from the posted code the conditional enter setup mode, hence my q about autoConnect.

bare in mind, if you don t explicitly disable RF when going to sleep, the esp will connect anyway (default setting afaik) even without wifi manager or any kind of wifi code

cheers

On 8 Jul 2016, at 20:19, Scott C. Lemon notifications@github.com wrote:

Thank you for the suggestions ... I'll do some testing today and see if I can get things working correctly. I do think the bug you mention is quite possibly what is impacting me, and hope to see it fixed. I have four APs in range, and my ESP is configured for one of them ... but not the one I want it to be connected to.

Per your question about autoconnect(), I don't want to use it for some of the same reasons as kentaylor. In my situation, the captive portal is only to be done upon direct user action during power-up. Once configured it is never used again, unless the user intentionally wants to move the device to a new network. The ESP then goes into a deep sleep/wake cycle where it wakes to perform data collection and threshold checks, then - once all of that is complete - attempts to connect to the configured network, POSTs the collected data to one or more servers, and returns to deep sleep.

I can't have anything alter this cycle, nor have it enter into AP/Configuration Mode, just because it could not connect to the configured network. Instead we log a count of the connection failures, and save that to flash.

Also, since everything is on battery, I've got to keep things as quick as possible, and eliminate any mode or behavior that would increase the time the device is awake.

For now I've reverted back to the old versions of the ESP code and your library ... but hope to find a combination that will work.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/tzapu/WiFiManager/issues/191#issuecomment-231419148, or mute the thread https://github.com/notifications/unsubscribe/AC2FkEwwUkrZQ8am-UNDJROMMtw6mce-ks5qToaugaJpZM4JHWWd.

@tzapu commented on GitHub (Jul 9, 2016): hi, a wifi.disconnect() before calling startConfigPortal() should sort it for you. for battery operated sensors, the newer version, with the fix above should be a lot better. it is a lot faster to connect usually, so less battery spent. i didn t see from the posted code the conditional enter setup mode, hence my q about autoConnect. bare in mind, if you don t explicitly disable RF when going to sleep, the esp will connect anyway (default setting afaik) even without wifi manager or any kind of wifi code cheers > On 8 Jul 2016, at 20:19, Scott C. Lemon notifications@github.com wrote: > > Thank you for the suggestions ... I'll do some testing today and see if I can get things working correctly. I do think the bug you mention is quite possibly what is impacting me, and hope to see it fixed. I have four APs in range, and my ESP is configured for one of them ... but not the one I want it to be connected to. > > Per your question about autoconnect(), I don't want to use it for some of the same reasons as kentaylor. In my situation, the captive portal is only to be done upon direct user action during power-up. Once configured it is never used again, unless the user intentionally wants to move the device to a new network. The ESP then goes into a deep sleep/wake cycle where it wakes to perform data collection and threshold checks, then - once all of that is complete - attempts to connect to the configured network, POSTs the collected data to one or more servers, and returns to deep sleep. > > I can't have anything alter this cycle, nor have it enter into AP/Configuration Mode, just because it could not connect to the configured network. Instead we log a count of the connection failures, and save that to flash. > > Also, since everything is on battery, I've got to keep things as quick as possible, and eliminate any mode or behavior that would increase the time the device is awake. > > For now I've reverted back to the old versions of the ESP code and your library ... but hope to find a combination that will work. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub https://github.com/tzapu/WiFiManager/issues/191#issuecomment-231419148, or mute the thread https://github.com/notifications/unsubscribe/AC2FkEwwUkrZQ8am-UNDJROMMtw6mce-ks5qToaugaJpZM4JHWWd.

kerem commented

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

Author

Owner

@fvpalha commented on GitHub (Jul 15, 2016):

I have the same problem. The new SDK (1.5.4) does not change the SSID and PASSWORD in STATION mode.

@fvpalha commented on GitHub (Jul 15, 2016): I have the same problem. The new SDK (1.5.4) does not change the SSID and PASSWORD in STATION mode.

kerem commented

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

Author

Owner

@Humancell commented on GitHub (Dec 29, 2016):

I did add the WiFi.disconnect() just before calling startConfigPortal() and it is working properly.

There are now additional issues that I have to account for, but it solved my issue in the short term.

@Humancell commented on GitHub (Dec 29, 2016): I did add the WiFi.disconnect() just before calling startConfigPortal() and it is working properly. There are now additional issues that I have to account for, but it solved my issue in the short term.

kerem commented

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

Author

Owner

@xsrf commented on GitHub (Sep 27, 2017):

Came across the same issue... Not being able to save new credentials while the ESP is already connected really is a bug. I use WiFi.enableSTA(false); before wifiManager.startConfigPortal() to solve the issue, because this does not wipe the credentials, as WiFi.disconnect(); does.
However, this renders WifiManager useless as a config page that can also be accessed from the LAN side.

@xsrf commented on GitHub (Sep 27, 2017): Came across the same issue... Not being able to save new credentials while the ESP is already connected really is a bug. I use `WiFi.enableSTA(false);` before `wifiManager.startConfigPortal()` to solve the issue, because this does not wipe the credentials, as `WiFi.disconnect();` does. However, this renders WifiManager useless as a config page that can also be accessed from the LAN side.

Rows
Columns

[GH-ISSUE #191] On Demand Portal issue ... no longer saving new settings? #151