starred/WiFiManager

Fork 0

mirror of https://github.com/tzapu/WiFiManager.git synced 2026-04-28 01:25:49 +03:00

[GH-ISSUE #86] OnDemand Portal unresponsive when also running webserver #63

New issue

Closed

opened 2026-02-28 01:23:11 +03:00 by kerem · 5 comments

kerem commented

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

Owner

Originally created by @knight-of-ni on GitHub (Jan 30, 2016).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/86

I'm not convinced the cause of this issue is in the WiFiManager, but this environment seems to be the best place to get a better understanding of what is going on here.

The following test was done with an ESP-01.

Take the OnDemandConfigPortal example sketch and load it as-is into the ESP8266. Observe that it works as intended. Pushing a button wired to GPIO0, causes the OnDemand portal to start, and one can access the portal from a wireless client device and set the wifi parameters.

Next, modify the sketch to create and configure an ESP8266WebServer object. Then call server.begin() in setup(). Assuming the sketch also has the necessary logic added to attach to your local wifi network as a client and obtain an ip address, observe that one can successfully ping the ESP8266 and the webserver responds when pointing a browser to the device's ip on the local wifi network.

Now press the button wired to GPIO0. One can see the serial monitor report the OnDemand portal has successfully started, the monitor reports the ip address changed to 192.168.4.1, and one can connect to the ESP8266 Access Point from a wireless client device. The client device receives an ip address (usually 192.168.4.2), but the ESP8266 does not return a ping to 192.168.4.1 and naturally one cannot access Config Portal.

To remedy this, I modified the sketch to delete the former server object before starting the WiFiManager (tried both delete &server; and server.~ESP8266WebServer();. This made some progress as I now get a response when I ping 192.168.4.1, but the web portal is still unresponsive when I point my browser to that ip address. Additionally, the serial monitor does not indicate it is serving pages to a client like it normally does when things are working.

This is where I became totally befuddled. Deleting the server object should have fixed this. At least that is what I thought.

To continuing troubleshooting (guessing at this point), I have tried several combinations of the following, in different orders, before starting the WiFiManager:

    server.~ESP8266WebServer();
    delete &server;
    WiFi.softAPdisconnect(true);
    delay(500);
    WiFi.mode(WIFI_STA);
    WiFi.disconnect();
    delay(500);
    WiFi.disconnect();

Other than deleting the server object, none of the other commands appeared to make any difference.

Note that if I comment out the call to server.begin() in my sketch, then the On Demand portal works correctly. So logically it would seem that starting the initial web server is changing something external to the server object, which isn't getting reset when I attempt to start the OnDemand portal. I just don't know what that could be.

Incidentally, I can successfully accomplish the same thing using the AutoConnect portal. Everything works as intended, but of course in that scenario the AutoConnect portal is called before I start my web server so everything works as expected.

For reference, here is the sketch I am using:
https://gist.github.com/knnniggett/6268b575e05236372196

Originally created by @knight-of-ni on GitHub (Jan 30, 2016). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/86 I'm not convinced the cause of this issue is in the WiFiManager, but this environment seems to be the best place to get a better understanding of what is going on here. The following test was done with an ESP-01. Take the OnDemandConfigPortal example sketch and load it as-is into the ESP8266. Observe that it works as intended. Pushing a button wired to GPIO0, causes the OnDemand portal to start, and one can access the portal from a wireless client device and set the wifi parameters. Next, modify the sketch to create and configure an ESP8266WebServer object. Then call `server.begin()` in setup(). Assuming the sketch also has the necessary logic added to attach to your local wifi network as a client and obtain an ip address, observe that one can successfully ping the ESP8266 and the webserver responds when pointing a browser to the device's ip on the local wifi network. Now press the button wired to GPIO0. One can see the serial monitor report the OnDemand portal has successfully started, the monitor reports the ip address changed to 192.168.4.1, and one can connect to the ESP8266 Access Point from a wireless client device. The client device receives an ip address (usually 192.168.4.2), but the ESP8266 does not return a ping to 192.168.4.1 and naturally one cannot access Config Portal. To remedy this, I modified the sketch to delete the former server object before starting the WiFiManager (tried both `delete &server;` and `server.~ESP8266WebServer();`. This made some progress as I now get a response when I ping 192.168.4.1, but the web portal is still unresponsive when I point my browser to that ip address. Additionally, the serial monitor does not indicate it is serving pages to a client like it normally does when things are working. This is where I became totally befuddled. Deleting the server object should have fixed this. At least that is what I thought. To continuing troubleshooting (guessing at this point), I have tried several combinations of the following, in different orders, before starting the WiFiManager: ``` C server.~ESP8266WebServer(); delete &server; WiFi.softAPdisconnect(true); delay(500); WiFi.mode(WIFI_STA); WiFi.disconnect(); delay(500); WiFi.disconnect(); ``` Other than deleting the server object, none of the other commands appeared to make any difference. Note that if I comment out the call to `server.begin()` in my sketch, then the On Demand portal works correctly. So logically it would seem that starting the initial web server is changing something external to the server object, which isn't getting reset when I attempt to start the OnDemand portal. I just don't know what that could be. Incidentally, I can successfully accomplish the same thing using the AutoConnect portal. Everything works as intended, but of course in that scenario the AutoConnect portal is called before I start my web server so everything works as expected. For reference, here is the sketch I am using: https://gist.github.com/knnniggett/6268b575e05236372196

kerem closed this issue

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

kerem commented

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

Author

Owner

@tzapu commented on GitHub (Jan 31, 2016):

hi, it must surely be a conflict between the internal webserver and yours.

somebody told me that calling server.reset(); on the webserver should clean up after it, may wanna try that before delete..

@tzapu commented on GitHub (Jan 31, 2016): hi, it must surely be a conflict between the internal webserver and yours. somebody told me that calling server.reset(); on the webserver should clean up after it, may wanna try that before delete..

kerem commented

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

Author

Owner

@knight-of-ni commented on GitHub (Jan 31, 2016):

Unfortunately, the ESP8266WebServer class does not have a member called reset. Neither does the WiFi class. Was it some other class perhaps?

Looks like being able to stop one webserver and start another was not part of the intent of the ESP8266WebServer class: https://github.com/esp8266/Arduino/issues/686

Unfortunately, destroying the object as the thread suggests does not quite get the new server working correctly, however.

@knight-of-ni commented on GitHub (Jan 31, 2016): Unfortunately, the ESP8266WebServer class does not have a member called reset. Neither does the WiFi class. Was it some other class perhaps? Looks like being able to stop one webserver and start another was not part of the intent of the ESP8266WebServer class: https://github.com/esp8266/Arduino/issues/686 Unfortunately, destroying the object as the thread suggests does not quite get the new server working correctly, however.

kerem commented

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

Author

Owner

@tzapu commented on GitHub (Feb 1, 2016):

hi,

it seems to be more a feature of smart pointers
http://en.cppreference.com/w/cpp/memory/unique_ptr

see how web server is defined in WiFiManager, it uses reset to allocate and deallocate.

As soon as I get some time for this, I will try to build a webserver example myself…

hope you can make something of the above, memory management really does my head in…

On 31 Jan 2016, at 17:32, Andrew Bauer notifications@github.com wrote:

Unfortunately, the ESP8266WebServer class does not have a member called reset. Neither does the WiFi class. Was it some other class perhaps?

—
Reply to this email directly or view it on GitHub https://github.com/tzapu/WiFiManager/issues/86#issuecomment-177527255.

@tzapu commented on GitHub (Feb 1, 2016): hi, it seems to be more a feature of smart pointers http://en.cppreference.com/w/cpp/memory/unique_ptr see how web server is defined in WiFiManager, it uses reset to allocate and deallocate. As soon as I get some time for this, I will try to build a webserver example myself… hope you can make something of the above, memory management really does my head in… > On 31 Jan 2016, at 17:32, Andrew Bauer notifications@github.com wrote: > > Unfortunately, the ESP8266WebServer class does not have a member called reset. Neither does the WiFi class. Was it some other class perhaps? > > — > Reply to this email directly or view it on GitHub https://github.com/tzapu/WiFiManager/issues/86#issuecomment-177527255.

kerem commented

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

Author

Owner

@knight-of-ni commented on GitHub (Feb 1, 2016):

Ah, thanks for the link. I will read up on that.

Previously, I did notice this in in WiFiManage::startConfigPortal
server.reset(new ESP8266WebServer(80));. I'll model what I do against that example.

@knight-of-ni commented on GitHub (Feb 1, 2016): Ah, thanks for the link. I will read up on that. Previously, I did notice this in in WiFiManage::startConfigPortal `server.reset(new ESP8266WebServer(80));`. I'll model what I do against that example.

kerem commented

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

Author

Owner

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

hi, may be of use to you, this is a way in which i could get webserver running after auto connect
https://gist.github.com/tzapu/ecc0759829d30d5a6152

@tzapu commented on GitHub (Feb 8, 2016): hi, may be of use to you, this is a way in which i could get webserver running after auto connect https://gist.github.com/tzapu/ecc0759829d30d5a6152