[GH-ISSUE #140] Continuing running the server to allow reconfiguration #106

New issue

Closed

opened 2026-02-28 01:23:27 +03:00 by kerem · 3 comments

kerem commented

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

Owner

Originally created by @datacute on GitHub (Mar 27, 2016).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/140

Thanks for this project.

I'm struggling with trying to figure out how I can do what I want to do.

I want to allow configuring an MQTT server (and perhaps a topic or two) along with the Wi-Fi SSID & password, which this library seems to provide for (though I've not yet tried additional parameters).

However I also want the server to keep running and respond to requests after the Wi-Fi is configured, which I guess means when auto-connect succeeds after a reboot. The reason is in case the MQTT settings have been entered incorrectly, or need to change, or I wish to change which of the available Wi-Fi APs to connect to.

I think that the closest I can get at the moment is using the startConfigPortal method, but I don't want to switch to AP mode, and I don't want to block for long. I would also like the contents of the while loop in startConfigPortal to be callable from my main loop.

I think I could possibly add a flag and make a few small rearrangements to the code to support this. Do you think I should give it a go?

The other option I'm considering is to not use WiFiManager for my non-Wi-Fi configuration, and instead spin up a configuration server of my own, which seems like quite a bit of duplication.

Originally created by @datacute on GitHub (Mar 27, 2016). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/140 Thanks for this project. I'm struggling with trying to figure out how I can do what I want to do. I want to allow configuring an MQTT server (and perhaps a topic or two) along with the Wi-Fi SSID & password, which this library seems to provide for (though I've not yet tried additional parameters). However I also want the server to keep running and respond to requests after the Wi-Fi is configured, which I guess means when auto-connect succeeds after a reboot. The reason is in case the MQTT settings have been entered incorrectly, or need to change, or I wish to change which of the available Wi-Fi APs to connect to. I think that the closest I can get at the moment is using the startConfigPortal method, but I don't want to switch to AP mode, and I don't want to block for long. I would also like the contents of the while loop in startConfigPortal to be callable from my main loop. I think I could possibly add a flag and make a few small rearrangements to the code to support this. Do you think I should give it a go? The other option I'm considering is to not use WiFiManager for my non-Wi-Fi configuration, and instead spin up a configuration server of my own, which seems like quite a bit of duplication.

kerem closed this issue

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

kerem commented

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

Author

Owner

@tzapu commented on GitHub (Mar 28, 2016):

i think keeping the config portal along, would need quite a few different things to be done, most likely a completly different path to take.

there s actually another discussion here somewhere (that i can t find...) that outlines some potential "risks" when keeping portal around forever.. to name a few potential issues
-memory
-startup of webserver/dns server not working properly
-people having a webserver in their own sketch

@tzapu commented on GitHub (Mar 28, 2016): i think keeping the config portal along, would need quite a few different things to be done, most likely a completly different path to take. there s actually another discussion here somewhere (that i can t find...) that outlines some potential "risks" when keeping portal around forever.. to name a few potential issues -memory -startup of webserver/dns server not working properly -people having a webserver in their own sketch

kerem commented

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

Author

Owner

@tzapu commented on GitHub (Mar 29, 2016):

maybe for configuration, there should be a separate library, it would be a bit of duplication, but, it would cater for more people s projects... just throwing ideas

@tzapu commented on GitHub (Mar 29, 2016): maybe for configuration, there should be a separate library, it would be a bit of duplication, but, it would cater for more people s projects... just throwing ideas

kerem commented

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

Author

Owner

@datacute commented on GitHub (Mar 29, 2016):

Yeah, maybe. I've pushed what I'm currently trialling:
github.com/datacute/WiFiManager@efc2fb2ec6

I haven't spent long considering what that loop method should do - I think separation of Wi-Fi and other parameters would be a good idea, since now I can't change the MQTT server without also re-entering Wi-Fi details, and reconnecting.

@datacute commented on GitHub (Mar 29, 2016): Yeah, maybe. I've pushed what I'm currently trialling: https://github.com/datacute/WiFiManager/commit/efc2fb2ec672a7c2e19d0f017d1f814ed637065e I haven't spent long considering what that loop method should do - I think separation of Wi-Fi and other parameters would be a good idea, since now I can't change the MQTT server without also re-entering Wi-Fi details, and reconnecting.