Fastconnect

[tablatronix]

#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

[tablatronix]

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

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

[roberttidey]

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.

[tablatronix]

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");
    }
}

[roberttidey]

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.

[tablatronix]

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

[roberttidey]

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.

[tablatronix]

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]

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

[roberttidey]

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]

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

[tablatronix]

@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.

[smashteevee]

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?

[roberttidey]

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.

[tablatronix]

Ill take a look at merging it i

[roberttidey]

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.

[smashteevee]

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]

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

[roberttidey]

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.

[tablatronix]

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]

Just synched from master

[nullstalgia]

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!

[tablatronix]

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

[hunmik]

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.)

[tablatronix]

• test esp8266

[hunmik]

• 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.

[tablatronix]

Thats a task for me

[tablatronix]

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..

[hunmik]

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

[tablatronix]

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

Ill add some debug info

[hunmik]

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

[tablatronix]

Revisit this

[rguca]

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.

[F1p]

Revisit this

Yes please :)