Selecting the best Access Point?

[mrwee]

Hi,

Unsure what the status is, when it comes to Wi-Fi scanning and selecting the best AP, but having installed "ESP_Easy_mega_20210503_normal_ESP8266_4M1M" on an original Wemos D1 mini pro, shows me that ESPEasy doesn't connect to the strongest RSSI, but rather one with much lower RSSI value, resulting in -90dB signal strength, rather than the ~-40dB it could have been.

I've tried setting "Extra WiFi scan loops" to 3, but it's the same result

Is this still work-in-progress, or am I missing something?

[TD-er]

I have received a number of issue reports with the latest build (0503) regarding WiFi.
Working on a fix, so for now, better use the last build before this build.

[mrwee]

It does not seem to make much difference. It seems like the first BSSID is selected, despite weaker signal. Really hope that you can figure out a good way of making it more dynamic (e.g. periodic scan)

[mrwee]

@TD-er: Which ESPEasy version do you recommend for testing Wi-Fi / connecting to strongest AP?

I have a UniFi Wi-Fi setup with 6 AP's, and the versions I've tested usually selects a "wrong" AP

[TD-er]

Have you tested the builds of a week ago? https://td-er.nl/ESPEasy/ ( https://td-er.nl/ESPEasy/static/ for the bin files)

If those do not work, I can make you a test build where you can disable the re-use from RTC where you won't reconnect automatically to the last used AP on reboot.

I am now having a look at the WiFi scan code to see why it may not (re)connect to the strongest.
One thing I already noticed is that the WiFi scan does not scan for at least 100 msec per channel, which makes it clear why it does not always find the strongest AP as an AP may need upto 102.4 msec to reply to an active scan request. Most react within 50 msec, of course, but it seems the ESP may already jump to the next channel after 60-ish msec if it found some AP.

[mrwee]

Have you tested the builds of a week ago? https://td-er.nl/ESPEasy/ ( https://td-er.nl/ESPEasy/static/ for the bin files)

If those do not work, I can make you a test build where you can disable the re-use from RTC where you won't reconnect automatically to the last used AP on reboot.

I am now having a look at the WiFi scan code to see why it may not (re)connect to the strongest.
One thing I already noticed is that the WiFi scan does not scan for at least 100 msec per channel, which makes it clear why it does not always find the strongest AP as an AP may need upto 102.4 msec to reply to an active scan request. Most react within 50 msec, of course, but it seems the ESP may already jump to the next channel after 60-ish msec if it found some AP.

Tried https://td-er.nl/ESPEasy/static/, but get a 403

Are all 2.4GHz channels being scanned or just the recommended 1, 6, 11? I've found that ESPEasy doesn't even find some of my AP's (All are on channel 1, 6 or 11) when scanning, as the list of neighbour SSID's is long.

[TD-er]

Hmm that's strange, I just clicked your link and it does present a list of files
https://td-er.nl/ESPEasy/static/esp82xx/

When did you try this?
Last night there was an issue with the switch to this rack in the colo. (entire rack was unreachable around 20h)
I'll try to keep an eye on it as it may again be flaky.

What build do you need, as I am now testing with a different scan function call so I can set the min and max. scan duration per channel.
It should scan on all channels, but maybe I can force it to scan per channel to make sure.

[mrwee]

5 seconds ago
Doesn't work from home, but link works from my mobilephone.. GeoIP blocking?

Dunno which build I need. Which will you recommend, for testing Wi-Fi performance?

[TD-er]

It is just static HTML, so there should be no geo blocking.
I also switched back from IPv6 & IPv4 for that domain to IPv4-only as Wordpress which is also on that domain was a bit picky on blocking IPv6 ranges for spammers/hack attempts.
But since this is just in a sub dir of that domain no mod_rewrite should be present there as I don't include any Wordpress code.

You can DM me your IP, so I can check the Apache logs to see what may be happening here.