Select strongest AP if duplicate SSID exist

[peterb-dev]

Description:

When performing WiFi scan, do not terminate at first matching SSID as it may not be the strongest one if multiple access points are visible.
NOTE: The scan results are not sorted in descending order of RSSI, rather they are grouped by channel number
Early termination means a very weak match on channel 1 will be selected over a very strong match for the same SSID on channel 6.

To reproduce: Setup two access points, with identical SSID:

AP1: Set to channel 1, and place it perhaps 20m away (about -80dBm RSSI)
AP2: Set to channel 11, and place it about 2m away (about -60dBm RSSI)
NOTE: Channel number matters - the bug causes Tasmota to select the lowest numbered channel for a given SSID.
SetOption56 1 to initiate a new scan on each restart.
Result: The device will consistently select AP1, despite AP2 being much closer/stronger.
Using the WiFi scan feature will confirm AP2 is stronger.

Checklist:

• The pull request is done against the latest development branch
• Only relevant files were touched
• Only one feature/fix was added per PR and the code change compiles without warnings
• The code change is tested and works on Tasmota core ESP8266 V.2.7.4.9
• The code change is tested and works on Tasmota core ESP32 V.1.0.5-rc4
• I accept the CLA.

_NOTE: I have not run any CI tests on this change, however I have confirmed the fix on a SONOFF mini and a ESP32 D1 mini dev board.

[arendst]

This only occurs if you set both SSIDs to the same name (which makes no sense).

I suggest you leave SSID2 set to empty (ssid2 ") and retry. In that case it should select the strongest signal (as it does in my case with two AP's set to channel 1 and 11 too).

Set wificonfig 5 too.

[Jason2866]

Can confirm that configuring ONLY one SSID in Tasmota and using SetOption56 1 selects the strongest AP.
I have 6 APs (same SSID and different Channels) and Tasmota devices all around
There is no need for this PR, the wanted behaviour is already there.

[peterb-dev]

I specifically observed this on my esp32 d1 mini. I have only one ap configured in tasmota. I will instrument the loop to confirm the scan results list are not ordered by descending rssi, which i believe is the case. It could be a difference in the esp32 WiFi library?

[peterb-dev]

So... the problem was nothing to do with the wifi-scan code, I can confirm this, and I can see that my pull request makes no sense. However, I also did manage to 'reproduce' my problem:

1. Take a brand new esp32 (never flashed with anything)
2. Flash it with tasmota32-lite.bin from official releases URL.
3. Go to tasmota_xxxx SSID, enter my network info for AP1 only
4. Log into device on my network, and check 'information' - it's selected my very weak AP on channel 1 rather than the 30dB stronger AP on channel 11. Any amount of rebooting, etc will not 'fix' this. This is what triggered my bug hunting in the first place.
5. Still with the original tasmotta32-lite, I then setOption56 1, and reboot device. It's now selected channel 11 as expected.

The 'bug' arises in the sense that in commissioning new devices, one may not expect them to get 'stuck' on a very weak AP during the first scan performed by tasmota32-lite. I agree option 56 fixes this and for me this is an acceptable solution, but I can well imagine novice users assuming their esp32 module has inferior WiFi performance. Indeed I did assume this initially, as the channel number is not displayed in the information page. Without option56 enabled, the only way their device will ever rescan (I believe) is if it loses all WiFi coverage, which might be triggered if they took down all their WiFi for a period of time.

Do we agree this is a 'bug' ? If so, I happy to file one, with the suggested work-around being to set option56.

[Jason2866]

Discussed and decision was to enable SetOption57 1 by default.
Doing this the strongest AP will be searched every 44 minutes and used.
SetOption56 will be still off because enabling would disable the fast connecting from the Tasmota device to the AP after a restart

[stefanbode]

The FRITZ!Box support mesh technologies where all ap sending on the same wifi channel and same ssid. This is how it should be configured. I can confirm that at least the esp8266 to quite well to select the best ap with the strongest signal.

[Jason2866]

All sending on same channel. Thats why i dont like cheap Mesh systems. Mesh APs needs to communicate to each other. Using the same channel is the easiest and cheapest way to do.

[joba-1]

I just checked because I found that hard to believe.
My meshed fritz.boxes currently use 2.4GHz channels 1 and 11 automatically, avoid other used channels around my home as good as possible and play nice with an OpenWRT d-link with same SSID. My tasmota devices have no problem to find the best option (no problem with DHCP/NTP as well). But they don't move so I never tested take over scenarios with them.