starred/WiFiManager

Fork 0

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

[GH-ISSUE #1311] AutoConnectWithFSParameters with OnDemandConfigPortal? #1123

New issue

Closed

opened 2026-02-28 01:28:37 +03:00 by kerem · 8 comments

kerem commented

2026-02-28 01:28:37 +03:00

Owner

Originally created by @cds333 on GitHub (Nov 11, 2021).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1311

I want to be able to reopen the full config portal from AutoConnectWithFSParameters, at any time so the user may change the stored additional parameters JSON data.

However following the OnDemandConfigPortal example (using wm.startConfigPortal()) only gives us the basic config portal for SSID and password.

For AutoConnectWithFSParameters, if we try to re-run setup() of course it will not give us another portal unless the wifi settings are reset, which we don't want to do.

What is the correct way to do this?

Thank You

Originally created by @cds333 on GitHub (Nov 11, 2021). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1311 I want to be able to reopen the full config portal from AutoConnectWithFSParameters, at any time so the user may change the stored additional parameters JSON data. However following the OnDemandConfigPortal example (using _wm.startConfigPortal()_) only gives us the basic config portal for SSID and password. For AutoConnectWithFSParameters, if we try to re-run setup() of course it will not give us another portal unless the wifi settings are reset, which we don't want to do. What is the correct way to do this? Thank You

kerem closed this issue

2026-02-28 01:28:37 +03:00

kerem commented

2026-02-28 01:28:38 +03:00

Author

Owner

@tablatronix commented on GitHub (Nov 11, 2021):

Sounds like you are starting a new instance of wifigmanager in scope, use a global wm object, you can also modify the menu now and put your inputs under setup and remove wifi

@tablatronix commented on GitHub (Nov 11, 2021): Sounds like you are starting a new instance of wifigmanager in scope, use a global wm object, you can also modify the menu now and put your inputs under setup and remove wifi

kerem commented

2026-02-28 01:28:38 +03:00

Author

Owner

@cds333 commented on GitHub (Nov 13, 2021):

When I try to use a global instance it still does not work properly.

When bringing up the config portal on demand, it works great as long as I enter the SSID and password again, but if I attempt to change the additional parameters and click "save", without re-entering the SSID/password, it will say "*wm:[2] No ssid, skipping wifi save ", despite the correct SSID and password populating the top two fields (they are greyed).

It then times out and tries to reset.

Here is the serial dump after clicking save:

*wm:[2] processing save
*wm:[2] No ssid, skipping wifi save
*wm:[2] Disabling STA
*wm:[2] Portal Timeout In 106 seconds
*wm:[2] Portal Timeout In 76 seconds
*wm:[2] Portal Timeout In 46 seconds
*wm:[2] Portal Timeout In 16 seconds
*wm:[1] config portal has timed out
*wm:[2] shutdownConfigPortal
*wm:[2] restoring usermode STA
*wm:[2] wifi status: WL_CONNECTED
*wm:[2] wifi mode: STA
*wm:[2] configportal closed
*wm:[1] config portal exiting
failed to connect and hit timeout

It does autoconnect again after it resets, so clearly nothing is wrong with the saved credentials.

How do I make it reconnect, using the previously saved credentials, after changing only the additional parameters?

Thanks!

(Run on NodeMCU v1.0 ESP-12E)

AutoConnectWithFSParametersAndCustomIP_Test2.ino.txt

@cds333 commented on GitHub (Nov 13, 2021): When I try to use a global instance it still does not work properly. When bringing up the config portal on demand, it works great as long as I enter the SSID and password again, but if I attempt to change the additional parameters and click "save", without re-entering the SSID/password, it will say "**_*wm:[2] No ssid, skipping wifi save_** ", despite the correct SSID and password populating the top two fields (they are greyed). It then times out and tries to reset. Here is the serial dump after clicking save: *wm:[2] processing save *wm:[2] No ssid, skipping wifi save *wm:[2] Disabling STA *wm:[2] Portal Timeout In 106 seconds *wm:[2] Portal Timeout In 76 seconds *wm:[2] Portal Timeout In 46 seconds *wm:[2] Portal Timeout In 16 seconds *wm:[1] config portal has timed out *wm:[2] shutdownConfigPortal *wm:[2] restoring usermode STA *wm:[2] wifi status: WL_CONNECTED *wm:[2] wifi mode: STA *wm:[2] configportal closed *wm:[1] config portal exiting failed to connect and hit timeout It does autoconnect again after it resets, so clearly nothing is wrong with the saved credentials. How do I make it reconnect, using the previously saved credentials, after changing only the additional parameters? Thanks! (Run on NodeMCU v1.0 ESP-12E) [AutoConnectWithFSParametersAndCustomIP_Test2.ino.txt](https://github.com/tzapu/WiFiManager/files/7531425/AutoConnectWithFSParametersAndCustomIP_Test2.ino.txt)

kerem commented

2026-02-28 01:28:38 +03:00

Author

Owner

@tablatronix commented on GitHub (Nov 13, 2021):

you can use shouldbeakafterconfig to always return on save.

and there is the new callback for params to flag that params saved

/**
 * setSaveParamsCallback, set a save params callback on params save in wifi or params pages
 * @access public
 * @param {[type]} void (*func)(void)
 */
void WiFiManager::setSaveParamsCallback( std::function<void()> func ) {
  _saveparamscallback = func;
}

I agree this is probably not the best, maybe we can add a way to exit cp automatically if no wifi and wifiissaved and params exist...

@tablatronix commented on GitHub (Nov 13, 2021): you can use shouldbeakafterconfig to always return on save. and there is the new callback for params to flag that params saved ``` /** * setSaveParamsCallback, set a save params callback on params save in wifi or params pages * @access public * @param {[type]} void (*func)(void) */ void WiFiManager::setSaveParamsCallback( std::function<void()> func ) { _saveparamscallback = func; } ``` I agree this is probably not the best, maybe we can add a way to exit cp automatically if no wifi and wifiissaved and params exist...

kerem commented

2026-02-28 01:28:38 +03:00

Author

Owner

@tablatronix commented on GitHub (Nov 13, 2021):

also try

// add params to its own menu page and remove from wifi, NOT TO BE COMBINED WITH setMenu!
void          setParamsPage(bool enable);

and see if you like that better to avoid wifi cred confusion

@tablatronix commented on GitHub (Nov 13, 2021): also try // add params to its own menu page and remove from wifi, NOT TO BE COMBINED WITH setMenu! void setParamsPage(bool enable); and see if you like that better to avoid wifi cred confusion

kerem commented

2026-02-28 01:28:38 +03:00

Author

Owner

@cds333 commented on GitHub (Nov 14, 2021):

setParamsPage fixes the problem! Thank you very much!

One last issue- so the static ip/gw/sn fields from http://192.168.4.1/wifi populate automatically every time the page is loaded, with the custom values I entered. This is working as intended. This persists even after a reboot.

The params fields however, only show the new saved values until you reboot, and then after the reboot, the fields show the default values ("";"8080";"YOUR_APITOKEN").

The new params values I entered before the reboot are saved however, and persist through the reboot, and are displayed in the serial output- they just aren't visible on the page.

How would I make the fields from http://192.168.4.1/param show the saved values after reboot, like the wifi page does?

@cds333 commented on GitHub (Nov 14, 2021): setParamsPage fixes the problem! Thank you very much! One last issue- so the static ip/gw/sn fields from _http://192.168.4.1/wifi_ populate automatically every time the page is loaded, with the custom values I entered. This is working as intended. This persists even after a reboot. The params fields however, only show the new saved values until you reboot, and then after the reboot, the fields show the default values ("";"8080";"YOUR_APITOKEN"). The new params values I entered before the reboot are saved however, and persist through the reboot, and are displayed in the serial output- they just aren't visible on the page. How would I make the fields from _http://192.168.4.1/param_ show the saved values after reboot, like the wifi page does?

kerem commented

2026-02-28 01:28:38 +03:00

Author

Owner

@tablatronix commented on GitHub (Nov 14, 2021):

You will have to load them from where you stored them and setvalue or use the argument when you declare your params. Are you using littlefs?

wifi is saved automatically nothing else is saved by wm

@tablatronix commented on GitHub (Nov 14, 2021): You will have to load them from where you stored them and setvalue or use the argument when you declare your params. Are you using littlefs? wifi is saved automatically nothing else is saved by wm

kerem commented

2026-02-28 01:28:38 +03:00

Author

Owner

@cds333 commented on GitHub (Nov 14, 2021):

I am still using SPIFFS from the example code.

@cds333 commented on GitHub (Nov 14, 2021): I am still using SPIFFS from the example code.

kerem commented

2026-02-28 01:28:38 +03:00

Author

Owner

@cds333 commented on GitHub (Nov 14, 2021):

OK! Now it is starting to make sense.

The main problem I think is that I was trying to use the example code which was written for a single instance of the configportal, so trying to make it on-demand as well, caused some serious problems.

I think I managed to get it working pretty well. It now allows re-opening the portal as many times as you want; it populates the fields with the data from the json, and it saves the parameters independently, immediately upon clicking save.

Changes:

-Added a second callback function for wifiManager.setSaveParamsCallback() that also calls stopConfigPortal() to close the portal (because setBreakAfterConfig(true) still waits for the portal to timeout for some reason)

-Added a .setValue call for each custom_ WiFiManagerParameter, to set the saved value I got from the json

-Moved if(shouldSaveConfig){} block down to loop()

AutoConnectOnDemandWithFSParametersAndCustomIP_v1.ino.txt

@cds333 commented on GitHub (Nov 14, 2021): OK! Now it is starting to make sense. The main problem I think is that I was trying to use the example code which was written for a single instance of the configportal, so trying to make it on-demand as well, caused some serious problems. I think I managed to get it working pretty well. It now allows re-opening the portal as many times as you want; it populates the fields with the data from the json, and it saves the parameters independently, immediately upon clicking save. Changes: -Added a second callback function for wifiManager.setSaveParamsCallback() that also calls stopConfigPortal() to close the portal (because _setBreakAfterConfig(true)_ still waits for the portal to timeout for some reason) -Added a .setValue call for each _custom__ WiFiManagerParameter, to set the saved value I got from the json -Moved _if(shouldSaveConfig){}_ block down to loop() [AutoConnectOnDemandWithFSParametersAndCustomIP_v1.ino.txt](https://github.com/tzapu/WiFiManager/files/7533268/AutoConnectOnDemandWithFSParametersAndCustomIP_v1.ino.txt)