[GH-ISSUE #1342] Fastconnect

kerem commented

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

Owner

Originally created by @tablatronix on GitHub (Jan 22, 2022).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1342

#1114

On save using esp support

store bssid from scan
store channel from scan
On autoconenct if fastconnect and wifi connect fails, recheck fastscan options in case bssid or channel changed

Add getter to determine if fastconenct is saved/set in flash

Originally created by @tablatronix on GitHub (Jan 22, 2022). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1342 #1114 On save using esp support - [x] store bssid from scan - [x] store channel from scan - [x] On autoconenct if fastconnect and wifi connect fails, recheck fastscan options in case bssid or channel changed Add getter to determine if fastconenct is saved/set in flash

kerem added the

enhancement

Branch

labels

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

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Jan 22, 2022):

https://github.com/tzapu/WiFiManager/commits/feature_fastconnect

up to date with master, please test I see no improvement in my env

@tablatronix commented on GitHub (Jan 22, 2022): https://github.com/tzapu/WiFiManager/commits/feature_fastconnect up to date with master, please test I see no improvement in my env

kerem commented

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

Author

Owner

@roberttidey commented on GitHub (Jan 23, 2022):

Did you already have a connection set up? If so then you first need to erase those connection details otherwise the connection will continue to be made with just ssid and password and will still take longer.

Fast connect relies on starting from a fresh connection so that the mac address and channel get persisted on the first Wifi.begin call with mac address and channel included. From then on if any details like mac address or channel change then the fast connect automatically re-persists the new values.

@roberttidey commented on GitHub (Jan 23, 2022): Did you already have a connection set up? If so then you first need to erase those connection details otherwise the connection will continue to be made with just ssid and password and will still take longer. Fast connect relies on starting from a fresh connection so that the mac address and channel get persisted on the first Wifi.begin call with mac address and channel included. From then on if any details like mac address or channel change then the fast connect automatically re-persists the new values.

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Jan 24, 2022):

you don't need a fresh connection, it just sets BSSID and CHANNEL in the config struct
also it does not auto re-persist afaik, you have to set them via begin() if they change

void WiFi_print_sta(){
    if(wifiIsConnected()){
      Serial.println("[WIFI] CONNECTED");
      Serial.print("[WIFI] IP: ");
      Serial.println(WiFi.localIP());
      Serial.print("[WIFI] HOST: ");
      Serial.println(getHostname());
      Serial.print("[WIFI] BSSID: ");
      Serial.println(WiFi.BSSIDstr());
      Serial.print("[WIFI] RSSI: ");
      Serial.println(WiFi.RSSI());
      Serial.print("[WIFI] CHANNEL: ");
      Serial.println(WiFi.channel());         
    } else {
      Serial.println("[WIFI] NOT CONNECTED");
    }
}

@tablatronix commented on GitHub (Jan 24, 2022): you don't need a fresh connection, it just sets BSSID and CHANNEL in the config struct also it does not auto re-persist afaik, you have to set them via begin() if they change ```CPP void WiFi_print_sta(){ if(wifiIsConnected()){ Serial.println("[WIFI] CONNECTED"); Serial.print("[WIFI] IP: "); Serial.println(WiFi.localIP()); Serial.print("[WIFI] HOST: "); Serial.println(getHostname()); Serial.print("[WIFI] BSSID: "); Serial.println(WiFi.BSSIDstr()); Serial.print("[WIFI] RSSI: "); Serial.println(WiFi.RSSI()); Serial.print("[WIFI] CHANNEL: "); Serial.println(WiFi.channel()); } else { Serial.println("[WIFI] NOT CONNECTED"); } } ```

kerem commented

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

Author

Owner

@roberttidey commented on GitHub (Jan 24, 2022):

Maybe I am missing something here, but I thought that if autoconnect is on and the ssid and password have already been persisted from previous software then it will connect using those and therefore never get as far as calling fastconnect scan to get the BSSID and channel.

I see a significant decrease in connect time from 3+ seconds to less than 1 second when I use fastconnect. Obviously if BSSID or channel change then the first connect after that is 3+ seconds but then reverts to quick for future connections.

I'll run some further tests and also update my copy to be the same as your current fastconnect in case any changes are affecting my results.

@roberttidey commented on GitHub (Jan 24, 2022): Maybe I am missing something here, but I thought that if autoconnect is on and the ssid and password have already been persisted from previous software then it will connect using those and therefore never get as far as calling fastconnect scan to get the BSSID and channel. I see a significant decrease in connect time from 3+ seconds to less than 1 second when I use fastconnect. Obviously if BSSID or channel change then the first connect after that is 3+ seconds but then reverts to quick for future connections. I'll run some further tests and also update my copy to be the same as your current fastconnect in case any changes are affecting my results.

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Jan 24, 2022):

It only gets saved when saving via the web interface, I tried adding an autoupdate, but doing a scan always fails for me after trying to connect, there seems to be some kind of delayed event coming in from the sdk

@tablatronix commented on GitHub (Jan 24, 2022): It only gets saved when saving via the web interface, I tried adding an autoupdate, but doing a scan always fails for me after trying to connect, there seems to be some kind of delayed event coming in from the sdk

kerem commented

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

Author

Owner

@roberttidey commented on GitHub (Jan 25, 2022):

Tested with Arduino sketch checking time to first program execution after setup with wifi connected. This sketch could optionally do a config wipe with ESp.eraseConfig(); and WiFi.disconnect(true);

FastConnect false 3400mSec
FastConnect false Wipe, set up network connection from scratch using portal
FastConnect false 3400mSec

FastConnect true 3400mSec (still using basic from ssid and password from before)
FastConnect true Wipe, set up network connection from scratch using portal
FastConnect true 980mSec

Connections stay fast from then on.

The fastconnect works because a Wifi.begin is done with all parameters BSSID , channel and this is persisted in the native ESP wifi flash configuration. Subsequent calls even with just Wifi,begin and no parameters will still use the BSSID and channel values from the ESP Wifi config.

I think that enabling the erase during upload in the Arduino board set up would do the same as my programmatic wipe which would be easier to do.

Note I did all this using Arduino 2 but I have had same results using 1.8 in the past.

@roberttidey commented on GitHub (Jan 25, 2022): Tested with Arduino sketch checking time to first program execution after setup with wifi connected. This sketch could optionally do a config wipe with ESp.eraseConfig(); and WiFi.disconnect(true); FastConnect false 3400mSec FastConnect false Wipe, set up network connection from scratch using portal FastConnect false 3400mSec FastConnect true 3400mSec (still using basic from ssid and password from before) FastConnect true Wipe, set up network connection from scratch using portal FastConnect true 980mSec Connections stay fast from then on. The fastconnect works because a Wifi.begin is done with all parameters BSSID , channel and this is persisted in the native ESP wifi flash configuration. Subsequent calls even with just Wifi,begin and no parameters will still use the BSSID and channel values from the ESP Wifi config. I think that enabling the erase during upload in the Arduino board set up would do the same as my programmatic wipe which would be easier to do. Note I did all this using Arduino 2 but I have had same results using 1.8 in the past.

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Jan 25, 2022):

Yeah I know how it works, I did the testing for it.

Do you have logs? Are you using autoconnect?

I have no improvement, I wonder if there is something wrong with the channel here..

They are different

*wm:[1] Connecting to NEW AP: MyHotspot
*wm:[1] Using FASTCONNECT NEW 
*wm:[2] WiFi Scan SYNC started 
*wm:[2] WiFi Scan completed in 4712 ms
*wm:[2] Fast Config RSSI:  -36
*wm:[2] Fast Config CHAN:  6
*wm:[2] Fast Config BSSID:  40:16:7E:C3:1E:28
*wm:[1] connectTimeout not set, ESP waitForConnectResult... 
*wm:[2] Connection result: WL_CONNECTED
*wm:[1] Connect to new AP [SUCCESS]

*wm:[1] Connected in 2207 ms
*wm:[1] STA IP Address: 192.168.1.39
Mode: STA
Channel: 6
SSID (9): MyHotspot
Passphrase (12): password!
BSSID set: 0

AFTER

*wm:[1] Connected in 2208 ms
*wm:[1] STA IP Address: 192.168.1.39
Mode: STA
Channel: 10
SSID (9): MyHotspot
Passphrase (12): password!
BSSID set: 1
connected...yeey :)

@tablatronix commented on GitHub (Jan 25, 2022): Yeah I know how it works, I did the testing for it. Do you have logs? Are you using autoconnect? I have no improvement, I wonder if there is something wrong with the channel here.. They are different ```php *wm:[1] Connecting to NEW AP: MyHotspot *wm:[1] Using FASTCONNECT NEW *wm:[2] WiFi Scan SYNC started *wm:[2] WiFi Scan completed in 4712 ms *wm:[2] Fast Config RSSI: -36 *wm:[2] Fast Config CHAN: 6 *wm:[2] Fast Config BSSID: 40:16:7E:C3:1E:28 *wm:[1] connectTimeout not set, ESP waitForConnectResult... *wm:[2] Connection result: WL_CONNECTED *wm:[1] Connect to new AP [SUCCESS] ``` *wm:[1] Connected in 2207 ms *wm:[1] STA IP Address: 192.168.1.39 Mode: STA Channel: 6 SSID (9): MyHotspot Passphrase (12): password! BSSID set: 0 AFTER *wm:[1] Connected in 2208 ms *wm:[1] STA IP Address: 192.168.1.39 Mode: STA Channel: 10 SSID (9): MyHotspot Passphrase (12): password! BSSID set: 1 connected...yeey :)

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Jan 25, 2022):

Let me try 2.0, pretty sure my esp version is hardcoded to fullscan, also this channel thing is strange..
ohhhh its int32_t!

@tablatronix commented on GitHub (Jan 25, 2022): Let me try 2.0, pretty sure my esp version is hardcoded to fullscan, also this channel thing is strange.. ohhhh its int32_t!

kerem commented

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

Author

Owner

@roberttidey commented on GitHub (Jan 26, 2022):

I include here logs.

There are two sets here. The first is using the Aug 22 2021 fastconnect code which is what I have been using. This has a set up from erased condition plus a normal restart This shows the connect time of 1 second.

The second is from the current github version. This does show a problem with the fastconnect set up. and the connection remains slow. I thought I had tested with this before but I think the IDE didn't recompile and used the older version from the object cache. This time I cleared all caches which does show a problem.
fastlog.txt

@roberttidey commented on GitHub (Jan 26, 2022): I include here logs. There are two sets here. The first is using the Aug 22 2021 fastconnect code which is what I have been using. This has a set up from erased condition plus a normal restart This shows the connect time of 1 second. The second is from the current github version. This does show a problem with the fastconnect set up. and the connection remains slow. I thought I had tested with this before but I think the IDE didn't recompile and used the older version from the object cache. This time I cleared all caches which does show a problem. [fastlog.txt](https://github.com/tzapu/WiFiManager/files/7941877/fastlog.txt)

kerem commented

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

Author

Owner

@roberttidey commented on GitHub (Jan 28, 2022):

I have got the current GitHub fastconnect branch to work.

In the getFastConConfig the scan and number of networks found is being done by WiFi_scanNetworks(true); and this leads on to a failure to find the network to extract channel and BSSID from.

If I replace this by the original direct call WiFi.scanNetworks(); as in Aug 2021 version then it works as intended.

I am not sure currently why the WiFi_scanNetworks(true); is not working as there are several different versions of this. Either this needs to be figured out or the direct call used anyway. The getFastConConfig is only used for an initial connection or if channel / BSSID changes so it is not a significant overhead.

Edit:
I did try with WiFi_scanNetworks(true, false); as I thought that might be the issue. This returned 1 network found so the subsequent check for channel and BSSID won't find the right ssid unless it was first in the list and so it too failed.

Edit2:
So I think the basic problem is that WiFi_scanNetworks(true, false); returns true or false rather than the number of networks so the subsequent logic in the getFastConConfig fails. I suspect that if it returned the number or 0 false f none found then it would work but it is currently set up as a bool function

@roberttidey commented on GitHub (Jan 28, 2022): I have got the current GitHub fastconnect branch to work. In the getFastConConfig the scan and number of networks found is being done by WiFi_scanNetworks(true); and this leads on to a failure to find the network to extract channel and BSSID from. If I replace this by the original direct call WiFi.scanNetworks(); as in Aug 2021 version then it works as intended. I am not sure currently why the WiFi_scanNetworks(true); is not working as there are several different versions of this. Either this needs to be figured out or the direct call used anyway. The getFastConConfig is only used for an initial connection or if channel / BSSID changes so it is not a significant overhead. Edit: I did try with WiFi_scanNetworks(true, false); as I thought that might be the issue. This returned 1 network found so the subsequent check for channel and BSSID won't find the right ssid unless it was first in the list and so it too failed. Edit2: So I think the basic problem is that WiFi_scanNetworks(true, false); returns true or false rather than the number of networks so the subsequent logic in the getFastConConfig fails. I suspect that if it returned the number or 0 false f none found then it would work but it is currently set up as a bool function

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Jan 29, 2022):

@roberttidey thank you so much for this, I would have never figure this out without more eyes on it. Good catch
I think I will also rework this to avoid bugs in the future like this.

@tablatronix commented on GitHub (Jan 29, 2022): @roberttidey thank you so much for this, I would have never figure this out without more eyes on it. Good catch I think I will also rework this to avoid bugs in the future like this.

kerem commented

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

Author

Owner

@smashteevee commented on GitHub (Jun 1, 2022):

Hi,
Really call branch! I'm unable to get this to work as well (with latest commit). I don't see the same debug messages that indicate Fast Connect config is being used. Do I need to set a different debug level to see what's going on?

@smashteevee commented on GitHub (Jun 1, 2022): Hi, Really call branch! I'm unable to get this to work as well (with latest commit). I don't see the same debug messages that indicate Fast Connect config is being used. Do I need to set a different debug level to see what's going on?

kerem commented

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

Author

Owner

@roberttidey commented on GitHub (Jun 1, 2022):

I assume you are using the library branch feature_fastconnect.

If so then debug level should default to DEBUG_VERBOSE

During the attempt to set up fastconnect you should first see debug messages showing that is scanning networks.

One of these should be WiFi Scan ASYNC found: followed by the number of networks found.

@roberttidey commented on GitHub (Jun 1, 2022): I assume you are using the library branch feature_fastconnect. If so then debug level should default to DEBUG_VERBOSE During the attempt to set up fastconnect you should first see debug messages showing that is scanning networks. One of these should be WiFi Scan ASYNC found: followed by the number of networks found.

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Jun 1, 2022):

Ill take a look at merging it i

@tablatronix commented on GitHub (Jun 1, 2022): Ill take a look at merging it i

kerem commented

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

Author

Owner

@roberttidey commented on GitHub (Jun 2, 2022):

I just ran a test on a fresh copy of the feature_fastconnect branch and all seemed Ok to me.

I tested with a module that previously had been connected under fastconnect and also after I had wiped the config and had to set up via the portal. In both cases connect time after reset was just under 1 second.

@roberttidey commented on GitHub (Jun 2, 2022): I just ran a test on a fresh copy of the feature_fastconnect branch and all seemed Ok to me. I tested with a module that previously had been connected under fastconnect and also after I had wiped the config and had to set up via the portal. In both cases connect time after reset was just under 1 second.

kerem commented

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

Author

Owner

@smashteevee commented on GitHub (Jun 3, 2022):

I assume you are using the library branch feature_fastconnect.

If so then debug level should default to DEBUG_VERBOSE

During the attempt to set up fastconnect you should first see debug messages showing that is scanning networks.

One of these should be WiFi Scan ASYNC found: followed by the number of networks found.

Thanks, yes am using this dev branch. I don't think it's set at Verbose (is the level 3?) so will confirm I have it set. Thanks

@smashteevee commented on GitHub (Jun 3, 2022): > I assume you are using the library branch feature_fastconnect. > > If so then debug level should default to DEBUG_VERBOSE > > During the attempt to set up fastconnect you should first see debug messages showing that is scanning networks. > > One of these should be WiFi Scan ASYNC found: followed by the number of networks found. Thanks, yes am using this dev branch. I don't think it's set at Verbose (is the level 3?) so will confirm I have it set. Thanks

kerem commented

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

Author

Owner

@smashteevee commented on GitHub (Jun 3, 2022):

I can confirm my debug level is set at Verbose. Apologies as I hadn't previously clarified my specific issue: I'm getting pretty fast connect times on powerup (1.8s), but unclear if Fast Connect is working as intended because:

I was able to get sub-1 second connect times before adding setFastConnectMode(true) to my code
I don't see debug confirmation it is using previously stored SSID, channel info

My code snippet:

  WiFi.mode(WIFI_STA);
  WiFiManager wm;

// Set static IP for faster connect time
  wm.setSTAStaticIPConfig(local_IP, gateway, subnet); // optional DNS 4th argument

// Setup fast connect mode 
  wm.setFastConnectMode(true);
 
  if (!wm.autoConnect("AutoConnectAP", "password")) {
    Serial.println("Failed to connect");
  }  else { // Connected to the WiFi
    Serial.println("connected!");
  }

Here's what I'm seeing in log:

*wm:[1] AutoConnect 
*wm:[2] Connecting as wifi client... 
*wm:[2] Custom static IP/GW/Subnet/DNS 
*wm:[2] Custom STA IP/GW/Subnet 
*wm:[1] STA IP set: 192.168.86.29
*wm:[1] Connecting to SAVED AP: [redacted]
*wm:[1] connectTimeout not set, ESP waitForConnectResult... 
*wm:[2] Connection result: WL_CONNECTED
*wm:[1] AutoConnect: SUCCESS 
*wm:[2] Connected in 1731 ms
*wm:[1] STA IP Address: 192.168.86.29
connected!

Do I need to set another level (DEBUG_DEV or DEBUG_MAX) to see Fast Connect in action? Should I expect to see FastConnect messages here?

Thanks

@smashteevee commented on GitHub (Jun 3, 2022): I can confirm my debug level is set at Verbose. Apologies as I hadn't previously clarified my specific issue: I'm getting *pretty* fast connect times on powerup (1.8s), but unclear if Fast Connect is working as intended because: 1) I was able to get sub-1 second connect times before adding setFastConnectMode(true) to my code 2) I don't see debug confirmation it is using previously stored SSID, channel info My code snippet: ``` WiFi.mode(WIFI_STA); WiFiManager wm; // Set static IP for faster connect time wm.setSTAStaticIPConfig(local_IP, gateway, subnet); // optional DNS 4th argument // Setup fast connect mode wm.setFastConnectMode(true); if (!wm.autoConnect("AutoConnectAP", "password")) { Serial.println("Failed to connect"); } else { // Connected to the WiFi Serial.println("connected!"); } ``` Here's what I'm seeing in log: ``` *wm:[1] AutoConnect *wm:[2] Connecting as wifi client... *wm:[2] Custom static IP/GW/Subnet/DNS *wm:[2] Custom STA IP/GW/Subnet *wm:[1] STA IP set: 192.168.86.29 *wm:[1] Connecting to SAVED AP: [redacted] *wm:[1] connectTimeout not set, ESP waitForConnectResult... *wm:[2] Connection result: WL_CONNECTED *wm:[1] AutoConnect: SUCCESS *wm:[2] Connected in 1731 ms *wm:[1] STA IP Address: 192.168.86.29 connected! ``` Do I need to set another level (DEBUG_DEV or DEBUG_MAX) to see Fast Connect in action? Should I expect to see FastConnect messages here? Thanks

kerem commented

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

Author

Owner

@roberttidey commented on GitHub (Jun 3, 2022):

When fastconnect has been used once then the wifi channel and BSSID are retained by the esp8266 native wifi config and will be used to provide a fast connection irrespective of setting any fastconnect mode.

To see the difference you can wipe the config data and then set the wifi parameters via the portal using no fastconnect. The connect times will then be about 3.5 seconds.

@roberttidey commented on GitHub (Jun 3, 2022): When fastconnect has been used once then the wifi channel and BSSID are retained by the esp8266 native wifi config and will be used to provide a fast connection irrespective of setting any fastconnect mode. To see the difference you can wipe the config data and then set the wifi parameters via the portal using no fastconnect. The connect times will then be about 3.5 seconds.

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Jun 3, 2022):

There should be debugging, also I posted debugging code info above, it either outputs bssid stored or not.

But i have no idea what esp chip/lib you are using so it could be not working.. not sure.

What happens when you save new wifi?

@tablatronix commented on GitHub (Jun 3, 2022): There should be debugging, also I posted debugging code info above, it either outputs bssid stored or not. But i have no idea what esp chip/lib you are using so it could be not working.. not sure. What happens when you save new wifi?

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Jun 3, 2022):

Just synched from master

@tablatronix commented on GitHub (Jun 3, 2022): Just synched from master

kerem commented

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

Author

Owner

@nullstalgia commented on GitHub (Sep 5, 2022):

Are there any changes remaining to be done to this branch? I was hoping to use FastConnect for my Deep Sleeping ESP32-S2 project, but as there are ESP32-S2 specific changes in master, I'm worrying about compatibility.

Edit:

https://github.com/nullstalgia/WiFiManager

I did a quick merge, and it seems to work for the moment! Very noticeably faster (most of the time).

Hopefully it can get to master soon!

@nullstalgia commented on GitHub (Sep 5, 2022): Are there any changes remaining to be done to this branch? I was hoping to use FastConnect for my Deep Sleeping ESP32-S2 project, but as there are ESP32-S2 specific changes in master, I'm worrying about compatibility. Edit: https://github.com/nullstalgia/WiFiManager I did a quick merge, and it seems to work for the moment! Very noticeably faster (most of the time). Hopefully it can get to master soon!

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Oct 5, 2022):

I will try to look at this in a bit, I am looking over the esp channel scan method and how this will affect that

@tablatronix commented on GitHub (Oct 5, 2022): I will try to look at this in a bit, I am looking over the esp channel scan method and how this will affect that

kerem commented

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

Author

Owner

@hunmik commented on GitHub (Dec 19, 2022):

Great job, thank you. However does not work on my ESP3266. Connection time after wakeup from deep sleep is 2400-3700ms regardless if fastconnect is true or false. However, with STA IP connection time is 375ms. (Again regardless of fastconnect state.)

@hunmik commented on GitHub (Dec 19, 2022): Great job, thank you. However does not work on my ESP3266. Connection time after wakeup from deep sleep is 2400-3700ms regardless if fastconnect is true or false. However, with STA IP connection time is 375ms. (Again regardless of fastconnect state.)

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Dec 19, 2022):

test esp8266

@tablatronix commented on GitHub (Dec 19, 2022): - [ ] test esp8266

kerem commented

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

Author

Owner

@hunmik commented on GitHub (Dec 20, 2022):

test esp8266

I have 3 wemos D1 on my desk, they do all wifi stuff as expected, but fastconnect does not improve connection time. How to test? Pls advise.

@hunmik commented on GitHub (Dec 20, 2022): > * test esp8266 I have 3 wemos D1 on my desk, they do all wifi stuff as expected, but fastconnect does not improve connection time. How to test? Pls advise.

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Dec 20, 2022):

Thats a task for me

@tablatronix commented on GitHub (Dec 20, 2022): Thats a task for me

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Dec 22, 2022):

I merged in master to the branch,

It seems to work fine for me, I do not really notice any difference with esp8266 though, i always connect under 300ms, and afaik esp8266 does not have a fast scan or channel storage so it can only store bssid_set which in my case didnt do much, maybe cause there is not that many aps around.. not sure..

@tablatronix commented on GitHub (Dec 22, 2022): I merged in master to the branch, It seems to work fine for me, I do not really notice any difference with esp8266 though, i always connect under 300ms, and afaik esp8266 does not have a fast scan or channel storage so it can only store bssid_set which in my case didnt do much, maybe cause there is not that many aps around.. not sure..

kerem commented

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

Author

Owner

@hunmik commented on GitHub (Dec 22, 2022):

I downloaded the merge. (now default is DEBUG_NOTIFY so I changed to DEBUG_VERBOSE)
What I get:
*wm:[1] AutoConnect
*wm:[2] Connecting as wifi client...
*wm:[2] setSTAConfig static ip not set, skipping
*wm:[1] Connecting to SAVED AP: itthon5
*wm:[1] connectTimeout not set, ESP waitForConnectResult...
*wm:[2] Connection result: WL_CONNECTED
*wm:[1] AutoConnect: SUCCESS
*wm:[2] Connected in 2702 ms
*wm:[1] STA IP Address: 192.168.1.132

@hunmik commented on GitHub (Dec 22, 2022): I downloaded the merge. (now default is DEBUG_NOTIFY so I changed to DEBUG_VERBOSE) What I get: *wm:[1] AutoConnect *wm:[2] Connecting as wifi client... *wm:[2] setSTAConfig static ip not set, skipping *wm:[1] Connecting to SAVED AP: itthon5 *wm:[1] connectTimeout not set, ESP waitForConnectResult... *wm:[2] Connection result: WL_CONNECTED *wm:[1] AutoConnect: SUCCESS *wm:[2] Connected in 2702 ms *wm:[1] STA IP Address: 192.168.1.132

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Dec 22, 2022):

Is bootup faster than wake?
Do you know what channel and auth mode your ap is?

Ill add some debug info

@tablatronix commented on GitHub (Dec 22, 2022): Is bootup faster than wake? Do you know what channel and auth mode your ap is? Ill add some debug info

kerem commented

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

Author

Owner

@hunmik commented on GitHub (Dec 23, 2022):

I see no difference. Channel is 4 auth mode WPA2-Personal.

@hunmik commented on GitHub (Dec 23, 2022): I see no difference. Channel is 4 auth mode WPA2-Personal.

kerem commented

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

Author

Owner

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

Revisit this

@tablatronix commented on GitHub (Nov 18, 2023): Revisit this

kerem commented

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

Author

Owner

@rguca commented on GitHub (Dec 18, 2023):

I did some testing on v2.0.16-rc.2.
Connection time is around 700ms.

in WifiManager.cpp:1133, when I replace

ret = WiFi_enableSTA(true,storeSTAmode);
delay(500); // THIS DELAY ?

with

ret = WiFi.mode(WIFI_STA);

I get around 200ms.
I don't know if the old function WiFi_enableSTA needs this delay, but I am sure WiFi.mode from the library doesn't.

@rguca commented on GitHub (Dec 18, 2023): I did some testing on v2.0.16-rc.2. Connection time is around 700ms. in `WifiManager.cpp:1133`, when I replace ``` ret = WiFi_enableSTA(true,storeSTAmode); delay(500); // THIS DELAY ? ``` with ``` ret = WiFi.mode(WIFI_STA); ``` I get around 200ms. I don't know if the old function `WiFi_enableSTA` needs this delay, but I am sure `WiFi.mode` from the library doesn't.

kerem commented

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

Author

Owner

@F1p commented on GitHub (Apr 19, 2024):