WiFi fast_connect: save/load BSSID and channel for faster connect from sleep

[rguca]

What does this implement/fix?

The fast_connect option allows to skip the scan for networks. Still, a scan for BSSID and channel is performed, which results in a connect time around 4 seconds.
This PR allows to save BSSID and channel, so no scan has to be performed on wake. The connect time is reduced to 1 second -> significant battery life improvement for sleeping devices that only wake to push their data.

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Other

Related issue or feature (if applicable): fixes

Pull request in esphome-docs with documentation (if applicable): esphome/esphome-docs#

Test Environment

• ESP32
• ESP32 IDF
• ESP8266
• RP2040
• BK72xx
• RTL87xx

Checklist:

• The code change is tested and works locally.
• Tests have been added to verify that the new code works (under tests/ folder).

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated in esphome-docs.

[jesserockz]

Why wouldn't you just add the bssid and channel into the yaml?

[rguca]

If your network has multiple BSSIDs and the esp device is portable, it will do a scan every time the BSSID from the yaml is not in range.

[jesserockz]

But setting the bssid in yaml vs it being loaded from the preferences in this PR is exactly the same...

[rguca]

The difference is the preference will be updated, when the BSSID changes. This ensures a faster connection time for future connects. If you put the BSSID in the yaml, the connection time will be slow if the BSSID changes.

[Unfocused]

Why wouldn't you just add the bssid and channel into the yaml?

My WiFi network is 3 access points providing one network, and they automatically check congestion to switch to the least used channel every 2 weeks. So that's 1 SSID, 3 BSSIDs, and a channel that can randomly change.

It's not an unusual setup these days - consumer-level mesh WiFi systems are becoming more common, and a lot of them self-optimise. Then there are commercial/industrial environments, which will almost always have multiple access points.

As @rguca said, manually setting the BSSID and channel in YAML would only help when you've got only 1 access point. But it also only helps when the channel never changes - even for people with only 1 access point, that's not necessarily the case.

Saving them in preferences makes it a cache for the last known good connection, which is the most common case for reconnections for everyone. The times you wouldn't benefit would be (from most common to least common):

• Connecting to a different access point than last time (different BSSID, but same SSID)
• When the channel changes
• The first connection the device makes after being first flashed or factory reset (and maybe safe mode?)

Compared to saving in preferences, setting it in YAML would be only help with the last of those conditions - which should be the thing that happens the least often.

But setting the bssid in yaml vs it being loaded from the preferences in this PR is exactly the same…

In addition to all the above, setting it in YAML requires that you know & manually specify the BSSID and channel - neither of which I would expect the average person to know how to find (doubly so because you'd almost never need to know them). Caching it in preferences makes it configuration-free, so everyone automatically benefits.

But I would suggest adding an optional fast_connect_cache config to allow disabling saving to preferences, for two reasons:

• If there's some worry about flash wear or running out of RTC memory
• The last known BSSID isn't necessarily the best BSSID. For some scenarios, connecting to the best BSSID could be more important than reconnecting as fast as possible.

[jesserockz]

Sorry for the delay. I just came back to this now and reading above, I think its fine to merge. This code is still "hidden" behind fast_connect: true so it should not affect most people that are not using that.