starred/WiFiManager

Fork 0

mirror of https://github.com/tzapu/WiFiManager.git synced 2026-04-27 09:05:56 +03:00

[GH-ISSUE #256] Possibility, to have the captive portal server all the time up? #211

New issue

Closed

opened 2026-02-28 01:24:06 +03:00 by kerem · 5 comments

kerem commented

2026-02-28 01:24:06 +03:00

Owner

Originally created by @kunosee on GitHub (Nov 30, 2016).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/256

Is there a plan, to have the configuration server all the time up? From my point of view, it would make sense for many applications, just to use this server for controlling the application as well.

Even when connected to one Accesspoint, it should be possible to change the configuration to another one.
The configuration/management part of the application has not to wait, till configuration is done to bring up its own server

Maybe I have missed some options allowing that for me. I realized, that Custom Parameters are already possible, but only during the period of configuration.

Originally created by @kunosee on GitHub (Nov 30, 2016). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/256 Is there a plan, to have the configuration server all the time up? From my point of view, it would make sense for many applications, just to use this server for controlling the application as well. * Even when connected to one Accesspoint, it should be possible to change the configuration to another one. * The configuration/management part of the application has not to wait, till configuration is done to bring up its own server Maybe I have missed some options allowing that for me. I realized, that Custom Parameters are already possible, but only during the period of configuration.

kerem closed this issue

2026-02-28 01:24:07 +03:00

kerem commented

2026-02-28 01:24:07 +03:00

Author

Owner

@pieman64 commented on GitHub (Nov 30, 2016):

@kunosee you can read and write to the custom parameters at any time without the Captive portal server.

@pieman64 commented on GitHub (Nov 30, 2016): @kunosee you can read and write to the custom parameters at any time without the Captive portal server.

kerem commented

2026-02-28 01:24:07 +03:00

Author

Owner

@kentaylor commented on GitHub (Dec 1, 2016):

@kunosee, it sounds like you want to start WiFiManager on a button press.

Do you want to use WiFi Manager for controlling your application or a web server. Have you considered controlling your application from the cloud.

@kentaylor commented on GitHub (Dec 1, 2016): @kunosee, it sounds like you want to start WiFiManager on a [button press](https://github.com/kentaylor/WiFiManager/tree/master/examples/ConfigOnSwitch#why-have-a-button-to-initiate-configuration). Do you want to use WiFi Manager for controlling your application or a web server. Have you considered controlling your application [from the cloud](http://configure.urremote.com/).

kerem commented

2026-02-28 01:24:08 +03:00

Author

Owner

@kunosee commented on GitHub (Dec 1, 2016):

@pieman64: I know that, but I need an alway running webserver, to contrl my application.
@kentaylor: Cloud is no option, as that needs internet connection, which is not always given.

From my point of view it would be enough, to control the application from a client, connected to the ESP-AP. As this behaviour is not user friendly in all cases, where users are using WiFi for internet or other local connectivity, the application should have the possibility to join that network.

So my idea is, that WiFi Manager could be used as a kind of framework for all web controlled applications.
So the webserver should be up all the time, and only the nameserver is needed, when in AP mode.

Right now it is quiet uncomfortable in AP mode, to wait till the configuration server is down, before the application server can start on that port. Furthermore are restarts necessary, when you wish to change the network mode.

@kunosee commented on GitHub (Dec 1, 2016): @pieman64: I know that, but I need an alway running webserver, to contrl my application. @kentaylor: Cloud is no option, as that needs internet connection, which is not always given. From my point of view it would be enough, to control the application from a client, connected to the ESP-AP. As this behaviour is not user friendly in all cases, where users are using WiFi for internet or other local connectivity, the application should have the possibility to join that network. So my idea is, that WiFi Manager could be used as a kind of framework for all web controlled applications. So the webserver should be up all the time, and only the nameserver is needed, when in AP mode. Right now it is quiet uncomfortable in AP mode, to wait till the configuration server is down, before the application server can start on that port. Furthermore are restarts necessary, when you wish to change the network mode.

kerem commented

2026-02-28 01:24:08 +03:00

Author

Owner

@kentaylor commented on GitHub (Dec 1, 2016):

@kunosee asked for

the application should have the possibility to join that network

With this version of WiFi Manager the web server will be visible on the network to which the ESP is connected.

@kunosee suggests

WiFi Manager could be used as a kind of framework for all web controlled applications.

and I also thought WiFi manager is in part like a web application framework.

@kentaylor commented on GitHub (Dec 1, 2016): @kunosee asked for > the application should have the possibility to join that network With [this version](https://github.com/kentaylor/WiFiManager/) of WiFi Manager the web server will be visible on the network to which the ESP is connected. @kunosee suggests > WiFi Manager could be used as a kind of framework for all web controlled applications. and I also thought WiFi manager is in part like a [web application framework](https://github.com/tzapu/WiFiManager/pull/157#issuecomment-261151047).

kerem commented

2026-02-28 01:24:08 +03:00

Author

Owner

@kunosee commented on GitHub (Dec 1, 2016):

@KenTaylor: That looks really looks like that, what I meant! I will dig into it!

@kunosee commented on GitHub (Dec 1, 2016): @KenTaylor: That looks really looks like that, what I meant! I will dig into it!