[GH-ISSUE #455] setTimeout not working #386

Closed
opened 2026-02-28 01:25:03 +03:00 by kerem · 23 comments
Owner

Originally created by @thubaggins on GitHub (Nov 14, 2017).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/455

Hi,
I'm using ESP-12E with wifimanager 0.12
I try to config portal timeout to 60 seconds but it doesn't work.

  WiFiManager wifiManager;
  wifiManager.setAPCallback(configModeCallback);
  wifiManager.setTimeout(60);
  if (!wifiManager.autoConnect("Station name", "12345678")) {
    ESP.restart();
  }

When timeout reach wifimanager still in portal, please check this!

Originally created by @thubaggins on GitHub (Nov 14, 2017). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/455 Hi, I'm using ESP-12E with wifimanager 0.12 I try to config portal timeout to 60 seconds but it doesn't work. ``` WiFiManager wifiManager; wifiManager.setAPCallback(configModeCallback); wifiManager.setTimeout(60); if (!wifiManager.autoConnect("Station name", "12345678")) { ESP.restart(); } ``` When timeout reach wifimanager still in portal, please check this!
kerem 2026-02-28 01:25:03 +03:00
  • closed this issue
  • added the
    invalid
    label
Author
Owner

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

Are any clients connecting to the AP ?

<!-- gh-comment-id:344275842 --> @tablatronix commented on GitHub (Nov 14, 2017): Are any clients connecting to the AP ?
Author
Owner

@thubaggins commented on GitHub (Nov 14, 2017):

No matter clients connected to the AP or not portal still doesn't restart to enter station mode.
I just wonder why ESP-32 fork for ESP-32 work fine!

<!-- gh-comment-id:344299554 --> @thubaggins commented on GitHub (Nov 14, 2017): No matter clients connected to the AP or not portal still doesn't restart to enter station mode. I just wonder why ESP-32 fork for ESP-32 work fine!
Author
Owner

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

esp32 branch is just a clone of master , nothing has been committed to it.

<!-- gh-comment-id:344312846 --> @tablatronix commented on GitHub (Nov 14, 2017): esp32 branch is just a clone of master , nothing has been committed to it.
Author
Owner

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

I noticed sometimes if a client connects, the esp8266 does not update clientlist if they leave. I think this is fixed in the latest SDK and core. rc2, have not tested it though.

<!-- gh-comment-id:344314700 --> @tablatronix commented on GitHub (Nov 14, 2017): I noticed sometimes if a client connects, the esp8266 does not update clientlist if they leave. I think this is fixed in the latest SDK and core. rc2, have not tested it though.
Author
Owner

@thubaggins commented on GitHub (Nov 14, 2017):

No I used this fork: https://github.com/zhouhan0126/WIFIMANAGER-ESP32
Not sure what happened but maybe sdk or esp8266 hardware cause issues?

<!-- gh-comment-id:344314875 --> @thubaggins commented on GitHub (Nov 14, 2017): No I used this fork: https://github.com/zhouhan0126/WIFIMANAGER-ESP32 Not sure what happened but maybe sdk or esp8266 hardware cause issues?
Author
Owner

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

I doubt it, this probably introduced a bug #308
Your esp thinks a client is connected to the ap , and will not timeout.
Would be my guess

<!-- gh-comment-id:344347224 --> @tablatronix commented on GitHub (Nov 14, 2017): I doubt it, this probably introduced a bug #308 Your esp thinks a client is connected to the ap , and will not timeout. Would be my guess
Author
Owner

@thubaggins commented on GitHub (Nov 15, 2017):

But I have no client connected to the AP for sure!
I don't know why esp8266 just stuck in AP mode when esp32 work fine.
--edit: esp after timeout has run into my code, but still have AP mode but not accessible. I think esp stuck in AP+STA mode instead of STA mode only.

<!-- gh-comment-id:344473445 --> @thubaggins commented on GitHub (Nov 15, 2017): But I have no client connected to the AP for sure! I don't know why esp8266 just stuck in AP mode when esp32 work fine. --edit: esp after timeout has run into my code, but still have AP mode but not accessible. I think esp stuck in AP+STA mode instead of STA mode only.
Author
Owner

@tablatronix commented on GitHub (Nov 15, 2017):

Yeah thats a known bug, ap persists you will have to workaround it by setting mode in your code after wifimanager is used.

<!-- gh-comment-id:344594074 --> @tablatronix commented on GitHub (Nov 15, 2017): Yeah thats a known bug, ap persists you will have to workaround it by setting mode in your code after wifimanager is used.
Author
Owner

@thubaggins commented on GitHub (Nov 15, 2017):

I’ll try it, but wonder why esp32 work when esp8266 is not!

<!-- gh-comment-id:344639723 --> @thubaggins commented on GitHub (Nov 15, 2017): I’ll try it, but wonder why esp32 work when esp8266 is not!
Author
Owner

@tablatronix commented on GitHub (Nov 15, 2017):

because that code was removed

#if defined(ESP8266)
    if(_configPortalTimeout == 0 || wifi_softap_get_station_num() > 0){
#else
    if(_configPortalTimeout == 0){  // TODO
<!-- gh-comment-id:344640105 --> @tablatronix commented on GitHub (Nov 15, 2017): because that code was removed ``` #if defined(ESP8266) if(_configPortalTimeout == 0 || wifi_softap_get_station_num() > 0){ #else if(_configPortalTimeout == 0){ // TODO ```
Author
Owner

@tablatronix commented on GitHub (Nov 15, 2017):

If i had to guess, something is wrong with
wifi_softap_get_station_num() and it is not returning 0 when no clients.

<!-- gh-comment-id:344642332 --> @tablatronix commented on GitHub (Nov 15, 2017): If i had to guess, something is wrong with `wifi_softap_get_station_num()` and it is not returning 0 when no clients.
Author
Owner

@tablatronix commented on GitHub (Nov 15, 2017):

I have not seen that issue, but I did have problems with it not dropping to 0 after a client disconnected.
But you say a client is not connecting, it it possible a client is autoconnecting with saved credentials ? Try changing ap name or something. I am curious. I WIll have to fix this since its buggy

<!-- gh-comment-id:344643220 --> @tablatronix commented on GitHub (Nov 15, 2017): I have not seen that issue, but I did have problems with it not dropping to 0 after a client disconnected. But you say a client is not connecting, it it possible a client is autoconnecting with saved credentials ? Try changing ap name or something. I am curious. I WIll have to fix this since its buggy
Author
Owner

@thubaggins commented on GitHub (Nov 15, 2017):

I’m using only one laptop connect to the AP. I’m sure my laptop doesn’t connect to the AP cause I tured off automatically connect in windows 10!
Any chance to improve wifi_softap_get_station_num() Function?

<!-- gh-comment-id:344645165 --> @thubaggins commented on GitHub (Nov 15, 2017): I’m using only one laptop connect to the AP. I’m sure my laptop doesn’t connect to the AP cause I tured off automatically connect in windows 10! Any chance to improve wifi_softap_get_station_num() Function?
Author
Owner

@tablatronix commented on GitHub (Nov 15, 2017):

I added debugging to my dev PR, so it will output some debugging. I do not see any problem yet.
Feel free to test

*WM: AP IP address: 
*WM: 192.168.4.1
*WM: Starting Web Portal
*WM: HTTP server started
*WM: Config Portal Running, blocking, waiting for clients...
*WM: Portal Timeout In 50 seconds
*WM: Portal Timeout In 40 seconds
*WM: Portal Timeout In 30 seconds
*WM: Portal Timeout In 20 seconds
*WM: -> captive.apple.com
*WM: <- Request redirected to captive portal
*WM: <- HTTP Root
*WM: -> 192.168.4.1
*WM: -> captive.apple.com
*WM: <- Request redirected to captive portal
*WM: <- HTTP Root
*WM: -> 192.168.4.1
*WM: -> captive.apple.com
*WM: <- Request redirected to captive portal
*WM: <- HTTP Root
*WM: -> 192.168.4.1
*WM: NUM CLIENTS: 1
*WM: NUM CLIENTS: 1
*WM: NUM CLIENTS: 1
*WM: NUM CLIENTS: 1
*WM: Portal Timeout In 52 seconds
*WM: Portal Timeout In 42 seconds
<!-- gh-comment-id:344671418 --> @tablatronix commented on GitHub (Nov 15, 2017): I added debugging to my dev PR, so it will output some debugging. I do not see any problem yet. Feel free to test ``` *WM: AP IP address: *WM: 192.168.4.1 *WM: Starting Web Portal *WM: HTTP server started *WM: Config Portal Running, blocking, waiting for clients... *WM: Portal Timeout In 50 seconds *WM: Portal Timeout In 40 seconds *WM: Portal Timeout In 30 seconds *WM: Portal Timeout In 20 seconds *WM: -> captive.apple.com *WM: <- Request redirected to captive portal *WM: <- HTTP Root *WM: -> 192.168.4.1 *WM: -> captive.apple.com *WM: <- Request redirected to captive portal *WM: <- HTTP Root *WM: -> 192.168.4.1 *WM: -> captive.apple.com *WM: <- Request redirected to captive portal *WM: <- HTTP Root *WM: -> 192.168.4.1 *WM: NUM CLIENTS: 1 *WM: NUM CLIENTS: 1 *WM: NUM CLIENTS: 1 *WM: NUM CLIENTS: 1 *WM: Portal Timeout In 52 seconds *WM: Portal Timeout In 42 seconds ```
Author
Owner

@thubaggins commented on GitHub (Nov 16, 2017):

Where is your PR :)

<!-- gh-comment-id:344846275 --> @thubaggins commented on GitHub (Nov 16, 2017): Where is your PR :)
Author
Owner

@tablatronix commented on GitHub (Nov 16, 2017):

Oh i thought i pasted it lol
https://github.com/tzapu/WiFiManager/pull/313

<!-- gh-comment-id:344914125 --> @tablatronix commented on GitHub (Nov 16, 2017): Oh i thought i pasted it lol https://github.com/tzapu/WiFiManager/pull/313
Author
Owner

@thubaggins commented on GitHub (Nov 17, 2017):

As I said before, startConfigPortal() set WiFi mode to STA+AP cause root problem esp won't reset after timeout reach. I try to change WiFi mode in startConfigPortal() to AP only then everything working property.

  //WiFi.mode(WIFI_AP_STA); // Commented out this line
  WiFi.mode(WIFI_AP); // Add this line

Your PR it's work, because function startAP() set WiFi mode to AP!
Also I've add some debug message:

*WM: 
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result: 
*WM: 1
*WM: SET AP
Entered config mode
192.168.4.1
*WM: 
*WM: Configuring access point... 
*WM: ESP-AP
*WM: 12345678
*WM: AP IP address: 
*WM: 192.168.4.1
*WM: HTTP server started
*WM: Portal Timeout In 9 seconds
*WM: Portal Timeout In 8 seconds
*WM: Portal Timeout In 7 seconds
*WM: Portal Timeout In 6 seconds
*WM: Portal Timeout In 5 seconds
*WM: Portal Timeout In 4 seconds
*WM: Portal Timeout In 3 seconds
*WM: Portal Timeout In 2 seconds
*WM: Portal Timeout In 1 seconds
*WM: Portal Timeout In 0 seconds
*WM: config portal has timed out

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v09f0c112
~ld
*WM: 
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result: 
*WM: 3
*WM: IP Address:
*WM: 192.168.0.201
<!-- gh-comment-id:345149983 --> @thubaggins commented on GitHub (Nov 17, 2017): As I said before, startConfigPortal() set WiFi mode to STA+AP cause root problem esp won't reset after timeout reach. I try to change WiFi mode in startConfigPortal() to AP only then everything working property. ``` //WiFi.mode(WIFI_AP_STA); // Commented out this line WiFi.mode(WIFI_AP); // Add this line ``` Your PR it's work, because function startAP() set WiFi mode to AP! Also I've add some debug message: ``` *WM: *WM: AutoConnect *WM: Connecting as wifi client... *WM: Using last saved values, should be faster *WM: Connection result: *WM: 1 *WM: SET AP Entered config mode 192.168.4.1 *WM: *WM: Configuring access point... *WM: ESP-AP *WM: 12345678 *WM: AP IP address: *WM: 192.168.4.1 *WM: HTTP server started *WM: Portal Timeout In 9 seconds *WM: Portal Timeout In 8 seconds *WM: Portal Timeout In 7 seconds *WM: Portal Timeout In 6 seconds *WM: Portal Timeout In 5 seconds *WM: Portal Timeout In 4 seconds *WM: Portal Timeout In 3 seconds *WM: Portal Timeout In 2 seconds *WM: Portal Timeout In 1 seconds *WM: Portal Timeout In 0 seconds *WM: config portal has timed out ets Jan 8 2013,rst cause:2, boot mode:(3,6) load 0x4010f000, len 1384, room 16 tail 8 chksum 0x2d csum 0x2d v09f0c112 ~ld *WM: *WM: AutoConnect *WM: Connecting as wifi client... *WM: Using last saved values, should be faster *WM: Connection result: *WM: 3 *WM: IP Address: *WM: 192.168.0.201 ```
Author
Owner

@tablatronix commented on GitHub (Nov 17, 2017):

Cant reproduce,

When you say it stays on , is it actually on, or is this a dup or #457
Where AP is persistent after config, but configportal is not actually running ?

Does autoconnect ever return or exit ?

How are you testing this?

use the autoconnect example, it clearly outputs

  if (!wifiManager.autoConnect()) {
    Serial.println("failed to connect and hit timeout");
<!-- gh-comment-id:345302741 --> @tablatronix commented on GitHub (Nov 17, 2017): Cant reproduce, When you say it stays on , is it actually on, or is this a dup or #457 Where AP is persistent after config, but configportal is not actually running ? Does autoconnect ever return or exit ? How are you testing this? use the autoconnect example, it clearly outputs ``` if (!wifiManager.autoConnect()) { Serial.println("failed to connect and hit timeout"); ```
Author
Owner

@thubaggins commented on GitHub (Nov 18, 2017):

Yes, I think this is a duplicate of #457
AP won't shutdown and configportal actually not running. Change WiFi mode to AP and problem solved!
WiFi.mode(WIFI_AP);

<!-- gh-comment-id:345416597 --> @thubaggins commented on GitHub (Nov 18, 2017): Yes, I think this is a duplicate of [#457](https://github.com/tzapu/WiFiManager/issues/457) AP won't shutdown and configportal actually not running. Change WiFi mode to AP and problem solved! `WiFi.mode(WIFI_AP);`
Author
Owner

@tablatronix commented on GitHub (Nov 18, 2017):

Thats kind of strange I wonder what the actual issue is though. Seems like it is working around one of the many bugs. The main problem i had was persistent toggling so ap mode didnt get stored in memory, softapdisconnect bugs.

<!-- gh-comment-id:345417649 --> @tablatronix commented on GitHub (Nov 18, 2017): Thats kind of strange I wonder what the actual issue is though. Seems like it is working around one of the many bugs. The main problem i had was persistent toggling so ap mode didnt get stored in memory, softapdisconnect bugs.
Author
Owner

@tablatronix commented on GitHub (Nov 18, 2017):

Also my pr only disables sta if its not connected so not sure if this is still an issue

<!-- gh-comment-id:345417763 --> @tablatronix commented on GitHub (Nov 18, 2017): Also my pr only disables sta if its not connected so not sure if this is still an issue
Author
Owner

@SadafShafi commented on GitHub (Jan 14, 2019):

ehy...i tried using
if (!wifiManager.autoConnect()) {
Serial.println("failed to connect and hit timeout");
but it when kept watch on serial monitor, the loop never ends.......therefore never prints failed to connect.......what should i do now...???

<!-- gh-comment-id:453911413 --> @SadafShafi commented on GitHub (Jan 14, 2019): ehy...i tried using if (!wifiManager.autoConnect()) { Serial.println("failed to connect and hit timeout"); but it when kept watch on serial monitor, the loop never ends.......therefore never prints failed to connect.......what should i do now...???
Author
Owner

@tablatronix commented on GitHub (Jan 14, 2019):

This issue is closed and old

<!-- gh-comment-id:454020880 --> @tablatronix commented on GitHub (Jan 14, 2019): This issue is closed and old
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/WiFiManager#386
No description provided.