ESP32 wifi.connect() priority when multiple APs with identical SSID are present (WiFi extenders)

[liudr]

I have this really weird issue that if I have multiple APs sharing the same SSID and password to expand my WiFi coverage, then sta_if.connect() will always prefer a certain AP even if the reception is horrible. I wonder if there is any default settings when multiple devices broadcast the same SSID, which to connect, if bssid is not given in connect().

Here is my set up. I have 3 APs, office (best rssi by sta_if.scan() around -25), basement (worst rssi by sta_if.scan() around -65), and phone (good rssi by sta_if.scan() around -30).

So if all 3 are present and I issue sta_if.connect(SSID, PASS), the board always seems to connect to my phone even though before and after connection scans show consistently that office AP is better than phone in reception. But if the phone AP is turned off, the connection is made to the basement AP, worst rssi by a large margin, always. Office AP with best reception by scan() isn't touched. Only if I also disconnect my basement AP, and the only one still on is office AP, the board connects to office AP.

So I wonder if a desired behavior of connecting to the SSID with the best rssi value can be specified for connection, so if multiple APs are present, the best one is used.

I checked ESP-IDF reference on wifi initialization and connection, which I used to do a number of years ago but never dealt with multiple APs with same SSID:

https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/network/esp_wifi.html

There isn't any mention of the scenario I mentioned (pick best rssi if multiple AP have the same SSID). The only other thing I can think of is maybe channel number. I wish micropython doc is better and simply gives the definition of returned scans, like which element in the tuple is what. But [2] may be channel number if [0] is SSID and [1] is BSSID. Then what is [4]? Found the definition in the doc, wish it had one example.

(ssid, bssid, channel, RSSI, security, hidden)

So the order of preference of phone>basement>office is an ascending order of channel numbers 1,2,7. Maybe ESP32 scans one channel for desired SSID, if found, connect to it, if not, go to the next channel?

Here is my 3-AP scans:

[
(b'myap', b'\xd8\x07\xb6\xd8\xc0/', 7, -28, 3, False), # office
(b'myap', b'\xf6\xc1\x91\xc8\xd7_', 1, -32, 7, False), # phone
(b'myap', b'P\xd4\xf7l\x8f\xc4', 2, -66, 3, False) # basement
]

There is a vague mention of channel in ESP-IDF here:

https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/network/esp_wifi.html#_CPPv4N17wifi_sta_config_t7channelE

The struct struct wifi_sta_config_t, which contains a channel element, is one of the init parameters.

Thanks for your time!

[liudr]

I'm also looking for how to find the BSSID of the AP that ESP32 is connected to. I found sta.config() that takes keywords such as mac, ssid, channel, hidden, security, key, hostname, reconnects, txpower, pm, but no bssid! sta.ifconfig() will return gateway IP address but no bssid. Is there any way to get bssid? Thanks.

[bidrohini]

It is possible that the ESP32 scans channels in order and connects to the first AP it finds. By explicitly scanning all available APs, you can avoid this behavior and you should select the AP with the best signal.

[glenn20]

It is possible that the ESP32 scans channels in order and connects to the first AP it finds. By explicitly scanning all available APs, you can avoid this behavior and you should select the AP with the best signal.

Yes, this is just what the ESP-IDF does when connecting to an SSID. It starts at channel 1 and scans up till it finds an AP to which it can connect. There is a PR #11819 that would help with this.

[liudr]

Thanks for confirming. I got a similar response from esp32.com forum. I'll read through PR #11819

[zonyl]

I have this problem with multiple IOT devices and the fix I went with was to set the RSSI threshold on the AP's themselves. Now my ESP boards (about 11 of them active) get routed to the better signal APs.