[GH-ISSUE #860] Dev tree onDemand mode problems #724

New issue

Open

opened 2026-02-28 01:26:46 +03:00 by kerem · 2 comments

kerem commented

2026-02-28 01:26:46 +03:00

Owner

Originally created by @Daemach on GitHub (Mar 29, 2019).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/860

AutoConnect serial port returns the following immediately after reset:

*WM: [2] WiFi Scan ASYNC started
*WM: [2] Config Portal Running, blocking, waiting for clients...
*WM: [2] WiFi Scan ASYNC completed in 3216 ms
*WM: [2] WiFi Scan ASYNC found: 11

Because the scan results are completed quickly, the portal is responsive and works smoothly

OnDemand says it started the scan but does not return the completion time or number found. This is useful information. Also, it starts another scan upon opening the portal which wastes time. Clicking on the configure wifi link does not return results at this point, because it's waiting on the scan to complete, I assume, which leads to confusion. I think you should complete the first scan and have the code look for a scan completed within 1 minute (or something) to avoid running another scan immediately after, or provide some kind of UI info that explains why poking the configure wifi button repeatedly isn't doing anything. It just looks broken.

Thanks for your hard work!

I used this code for the onDemand testing btw:

`/**
OnDemandConfigPortal.ino
example of running the configPortal AP manually, independantly from the captiveportal
trigger pin will start a configPortal AP for 120 seconds then turn it off.

*/
#include <WiFiManager.h> // https://github.com/tzapu/WiFiManager

// select which pin will trigger the configuration portal when set to LOW
#define TRIGGER_PIN 4

//for LED status
#include <Ticker.h>
Ticker ticker;
int LED = BUILTIN_LED;

void tick()
{
//toggle state
digitalWrite(LED, !digitalRead(LED)); // set pin to the opposite state
}

int timeout = 120; // seconds to run for

//gets called when WiFiManager enters configuration mode
void configModeCallback (WiFiManager *myWiFiManager) {
Serial.println("Entered config mode");
Serial.println(WiFi.softAPIP());
//if you used auto generated SSID, print it
Serial.println(myWiFiManager->getConfigPortalSSID());
//entered config mode, make led toggle faster
ticker.attach(0.2, tick);
}

void configWiFi(){

  WiFiManager wm;

//reset settings - for testing
wm.resetSettings();

// set configportal timeout
wm.setConfigPortalTimeout(timeout);
wm.setClass("invert");
wm.setMinimumSignalQuality(20);
//set callback that gets called when connecting to previous WiFi fails, and enters Access Point mode
wm.setAPCallback(configModeCallback);

if (!wm.startConfigPortal("_THCGuard Pro")) {
  Serial.println("failed to connect and hit timeout");
  delay(3000);
  //reset and try again, or maybe put it to deep sleep
  ESP.restart();
  delay(5000);
}
ticker.detach();
//keep LED on
digitalWrite(LED, LOW);
//if you get here you have connected to the WiFi
Serial.println("connected...yeey :)");

}

void setup() {
// put your setup code here, to run once:
Serial.begin(115200);
Serial.println("\n Starting");
//set led pin as output
pinMode(LED, OUTPUT);
pinMode(TRIGGER_PIN, INPUT_PULLUP);
}

void loop() {
// is configuration portal requested?
if ( digitalRead(TRIGGER_PIN) == LOW) {
configWiFi();
}

// put your main code here, to run repeatedly:
}`

Originally created by @Daemach on GitHub (Mar 29, 2019). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/860 AutoConnect serial port returns the following immediately after reset: *WM: [2] WiFi Scan ASYNC started *WM: [2] Config Portal Running, blocking, waiting for clients... *WM: [2] WiFi Scan ASYNC completed in 3216 ms *WM: [2] WiFi Scan ASYNC found: 11 Because the scan results are completed quickly, the portal is responsive and works smoothly OnDemand says it started the scan but does not return the completion time or number found. This is useful information. Also, it starts another scan upon opening the portal which wastes time. Clicking on the configure wifi link does not return results at this point, because it's waiting on the scan to complete, I assume, which leads to confusion. I think you should complete the first scan and have the code look for a scan completed within 1 minute (or something) to avoid running another scan immediately after, or provide some kind of UI info that explains why poking the configure wifi button repeatedly isn't doing anything. It just looks broken. Thanks for your hard work! I used this code for the onDemand testing btw: `/** OnDemandConfigPortal.ino example of running the configPortal AP manually, independantly from the captiveportal trigger pin will start a configPortal AP for 120 seconds then turn it off. */ #include <WiFiManager.h> // https://github.com/tzapu/WiFiManager // select which pin will trigger the configuration portal when set to LOW #define TRIGGER_PIN 4 //for LED status #include <Ticker.h> Ticker ticker; int LED = BUILTIN_LED; void tick() { //toggle state digitalWrite(LED, !digitalRead(LED)); // set pin to the opposite state } int timeout = 120; // seconds to run for //gets called when WiFiManager enters configuration mode void configModeCallback (WiFiManager *myWiFiManager) { Serial.println("Entered config mode"); Serial.println(WiFi.softAPIP()); //if you used auto generated SSID, print it Serial.println(myWiFiManager->getConfigPortalSSID()); //entered config mode, make led toggle faster ticker.attach(0.2, tick); } void configWiFi(){ WiFiManager wm; //reset settings - for testing wm.resetSettings(); // set configportal timeout wm.setConfigPortalTimeout(timeout); wm.setClass("invert"); wm.setMinimumSignalQuality(20); //set callback that gets called when connecting to previous WiFi fails, and enters Access Point mode wm.setAPCallback(configModeCallback); if (!wm.startConfigPortal("_THCGuard Pro")) { Serial.println("failed to connect and hit timeout"); delay(3000); //reset and try again, or maybe put it to deep sleep ESP.restart(); delay(5000); } ticker.detach(); //keep LED on digitalWrite(LED, LOW); //if you get here you have connected to the WiFi Serial.println("connected...yeey :)"); } void setup() { // put your setup code here, to run once: Serial.begin(115200); Serial.println("\n Starting"); //set led pin as output pinMode(LED, OUTPUT); pinMode(TRIGGER_PIN, INPUT_PULLUP); } void loop() { // is configuration portal requested? if ( digitalRead(TRIGGER_PIN) == LOW) { configWiFi(); } // put your main code here, to run repeatedly: }`

kerem added the

Incomplete

label

2026-02-28 01:26:46 +03:00

kerem commented

2026-02-28 01:26:46 +03:00

Author

Owner

@Daemach commented on GitHub (Mar 29, 2019):

I also reset the device once in autoconnect mode, then immediately connected to the AP and poked the configure wifi button. It loaded, pretty quickly but with no APs in the list. I hit back then poked the button again and there they were.

A more efficient method might be to load the wifi config page then use an ajax load in the background to pull the list of APs - that way you can show a message saying "Scanning network" or something while waiting for the async scan to finish, then load the list of APs dynamically when it becomes available. The drawback here is that to do this well might require a library like jquery... Maybe show a fast-loading interim page that does a javascript reload in 3-5 seconds if the scan isn't finished?

FWIW...

@Daemach commented on GitHub (Mar 29, 2019): I also reset the device once in autoconnect mode, then immediately connected to the AP and poked the configure wifi button. It loaded, pretty quickly but with no APs in the list. I hit back then poked the button again and there they were. A more efficient method might be to load the wifi config page then use an ajax load in the background to pull the list of APs - that way you can show a message saying "Scanning network" or something while waiting for the async scan to finish, then load the list of APs dynamically when it becomes available. The drawback here is that to do this well might require a library like jquery... Maybe show a fast-loading interim page that does a javascript reload in 3-5 seconds if the scan isn't finished? FWIW...

kerem commented

2026-02-28 01:26:46 +03:00

Author

Owner

@tablatronix commented on GitHub (Mar 29, 2019):

Yeah I need to see if I can optimize it, I thought caching would be nice so it appears snappier, but it also causes wifiscans in the background because peoples devices cause a barrage of requests.

So I might have to filter them somehow, there already is a cache timeout that can be adjusted to prevent that, or there is a bug.

You did not fill out the form, so no idea.

ajax will not be added at this time, but adding some kind of wait indication would be useful since captive portals are lacking in progress statuses.

@tablatronix commented on GitHub (Mar 29, 2019): Yeah I need to see if I can optimize it, I thought caching would be nice so it appears snappier, but it also causes wifiscans in the background because peoples devices cause a barrage of requests. So I might have to filter them somehow, there already is a cache timeout that can be adjusted to prevent that, or there is a bug. You did not fill out the form, so no idea. ajax will not be added at this time, but adding some kind of wait indication would be useful since captive portals are lacking in progress statuses.