Multiple AP with same SSID

[laserir]

I have a setup with multiple access points, all having the same SSID and password. Signal strength varies due to weather and changing position of the ESP32-device, which should connect via your library. (Scan shows signal strength between 30-50%)

I understand that I can have the environment scanned for SSID instead of the specific AP‘s BSSID (https://hieromon.github.io/AutoConnect/adconnection.html#match-with-known-access-points-by-ssid), but…

It seems not to be working very well with multiple SSIDs of the same name being present at the same time.

My goal would be to have the device connected to the strongest AP at all times.

Any suggestions? Thanks a lot in advance! :)

[Hieromon]

It is not an issue. Because AutoConnect::begin doesn't use BSSID with WiFi.begin. It is not used even if the AutoConnectConfig::principle setting is AC_PRINCIPLE_RSSI. BSSID will be the priority in your desired situation, but in other use cases, WiFi.begin with BSSID will be a stumbling block. It is common for multiple remote locations to have the same SSID (of course, different BSSIDs). Such infrastructure eliminates the need to reconfigure the WiFi connection configuration as clients move.

Use AutoConnectConfig::autoReconnect, and intentionally execute WiFi.disconnect before AutoConnect::begin to clear the recent setting of SDK. Of course, AutoConnectConfig::principle must be set properly.

NOTE:
If you operate multiple access points on the same network segment with the same SSID, you need to separate channels in such an environment, not a WiFi client-side decision. This can be achieved by roaming the access point.

[laserir]

I don’t think I understand… so the wifi credentials on matching SSIDs will always connect but if a (by BSSID) already known AP is present, the connection will be made to this one even if the RSSI is not the best of all networks?

What would be the „proper“ setting for principle?

All APs are in the same network segment and are controlled by the „main router“, FritzBox Mesh (if that helps).

currently I deal with connection losses all 1 or 2 days even with autoReconnect there is no reconnection. I have to manually reset the esp to restore the connection.

is there a „minimum“ quality for the esp to connect? Quality is show in ranges from 20-40%

[Hieromon]

The following parameters with accurate values are required for WiFi.begin to succeed to match a beacon from an access point with the same SSID. We can see it in the ESP32's WiFi library.

https://github.com/espressif/arduino-esp32/blob/5de09a9a4964961385f919eec12249dda5726a31/libraries/WiFi/src/WiFiSTA.h#L42

AC_PRINCIPLE_RSSI can find the strongest RSSI beacon and either SSID or BSSID is used to detect it, depending on the definition of AUTOCONNECT_APKEY_SSID.
Having discovered the strongest RSSI; That said, it's just the signal strength at that point. The WiFi signal is constantly changing due to radio wave interference from the external environment. Even if it is the strongest at a certain moment, the WiFi signal strength will deteriorate when radio waves of the same channel start to interfere with the WiFi frequency band. For the same reason, each AP in your WiFi network must also be assigned a different channel; AutoConnect will attempt a WiFi.begin using only the SSID and password of the stored established credentials. In other words, where the AP actually connects depends on the internal wireless control of ESP_IDF. My imagination is probably to negotiate in ascending order of channel number. And your hope will not be met.

AC_PRINCIPLE_RSSI will find the strongest RSSI but does not use the BSSID and channels that are essential to connect to that AP. That is because of the following reasons.

1. BSSID varies depending on the device

Generally, BSSID is generated from the MAC address of the device. However, there was a security issue with that immobilization method, and iOS and Android decided to randomize the MAC address. Cisco is starting to follow it. Refs.: https://datatracker.ietf.org/doc/html/draft-lee-randomized-macaddr-ps-00 This means that BSSID will not be able for WiFi connection negotiations in the future. Some AutoConnect users are already experiencing the inability to reconnect to iPhone mobile hotspots by BSSID matching. Because the BSSID changes every time you launch a mobile hotspot on your iPhone.

2. Cannot fix channel

The channels that carry that BSSID are not always the same. It depends on the AP specifications. This means that you will be forced to try to connect to a different channel than the original channel, which can fail. Also, SoftAP and STA share the same channel. In other words, if you try to connect to the network from the captive portal, the password will be authenticated but the WiFi will be disconnected. After all, even in this scene, AutoConnect can not aim for the target AP using BSSID and channel.

3. Why is BSSID the detection key nevertheless?

Because to enable connections to hidden SSIDs. The SSID field of the AP beacon for the hidden SSID is blank. In other words, it can only be found by BSSID. (However, there is a risk that this strategy will be invalidated in the future. The reason is as mentioned above)

AC_PRINCIPLE_RSSI does not work well when the following conditions are met:
a. You have enabled background reconnection.
b. Candidates for reconnection are one hidden fixed AP and the other a mobile hotspot.
c. The RSSI strength in the initial stage is strong for fixed AP, but since You started the mobile hotspot, You will try to connect to it.
d. But the BSSID does not match the saved credentials. The BSSID changed because the MAC address changed due to the restart of the mobile hotspot. If you enable AUTOCONNECT_APKEY_SSID to avoid that, then you will not find the hidden fixed AP SSID this time.
e. The AutoConnect connection attempt fails and resumes exploration, but it does not attempt to connect to the original fixed AP unless the hotspot stops. This behavior is limited.

Something similar to this is happening in your network environment. AutoConnect scans by BSSID to enable reconnection to hidden SSIDs, while WiFi.begin connects only by SSID without BSSID to support mobile hotspots.
We can use BSSID only if it is clear that the BSSID in the WiFi environment is immutable. AutoConnect has no way of knowing that. (I don't think it can be achieved with an Arduino core based on ESP-IDF) So, I think the ESP32 WiFi SoC needs to support roaming. It's not the task for the Arduino library. You can understand the limitations of the ESP32 SoC by reading the ESP32 datasheet. At least I couldn't find a solution to it.
If there is a mistake in my understanding, please point it out. I want to make AutoConnect more useful.

is there a „minimum“ quality for the esp to connect? Quality is show in ranges from 20-40%

That's the first thing I researched prior to implementing AutoConnect. The ESP-IDF station configuration API has it, but it's not implemented in the Arduino core. Instead, AutoConnect itself is discarding less than min RSSI. Use AutoConnectConfig::minRSSI setting with AC_PRINCIPLE_RSSI. However, in the end, AutoConnect doesn't use BSSID with WiFi.begin, It has no effect on your environment. Refs.: Station Basic Configuration::threshold

[Hieromon]

@laserir This topic will continue in the Discussions as it allows for enhancements.

[laserir]

Okay, this is much more complex (for me) than I thought!

My sketch restarts the ESP every two hours, just to keep things fresh.
So, I've discovered that the WiFi will always connect "manually" via the Open SSID menu. The connection quality is poor, but for my application (MQTT door sensor) will do. RSSI is normally >-80.
Sometimes the connection will work after restart, sometimes it doesn't, even though autoReconnect is enabled. First I thought it may be when RSSI drops below minRSSI, which may happen for a few minutes once in a while, but shouldn't it never stop to try reconnecting?
The ESP can find two APs with same SSID/password which it may connect to. If it looses connection, it should try to reach the "better" AP.

Second topic... Strangely sometimes when the connection is successful, the mode stays in AP_STA, sometimes it switches to STA... I Think this started with the AC_OTA_BUILTIN config, which I added later for convenient updating, may I be correct?

Here are the relevant code fragments, maybe this will help...

Config.apid = Config.apid = (String)HOST_NAME + "-"+String((uint32_t)(ESP.getEfuseMac() >> 32), HEX);
  Config.psk = "password";
  Config.autoReconnect = true;
  Config.reconnectInterval = 1;
  Config.principle = AC_PRINCIPLE_RSSI;
  Config.minRSSI = -80;
  Config.ota = AC_OTA_BUILTIN;
  Config.hostName = HOST_NAME;
  Config.title = HOST_NAME;
  Portal.config(Config);

  if (Portal.begin()) {
    if (MDNS.begin((Config.hostName).c_str())) {
      MDNS.addService("http", "tcp", 80);
    }
  }

The loop of course has the .handleClient()

[Hieromon]

My sketch restarts the ESP every two hours, just to keep things fresh. So, I've discovered that the WiFi will always connect "manually" via the Open SSID menu.

If that is an actual phenomenon, restarting the ESP every two hours means that the module has lost the connection configuration to the WiFi station where the ESP-IDF SDK is stored. It's a hardware failure that happens or your sketch fault.

Sometimes the connection will work after restart, sometimes it doesn't, even though autoReconnect is enabled. First I thought it may be when RSSI drops below minRSSI,

If you need further investigation, Please post the log acquired by AC_DBUG and CORE_DEBUG_LEVEL=5.
Refs: https://www.esp32.com/viewtopic.php?t=3885
And, I hope the following documents will help you. There is a description about roaming and RSSI.
https://docs.espressif.com/_/downloads/espressif-esp-faq/en/latest/pdf/

Second topic... Strangely sometimes when the connection is successful, the mode stays in AP_STA, sometimes it switches to STA... I Think this started with the AC_OTA_BUILTIN config, which I added later for convenient updating, may I be correct?

No. I can't know that how did you know the ESP module state in WIFI_AP_STA mode? switching to WIFI_AP_STA mode has nothing to do with the OTA feature.

[laserir]

Thanks for all the info! I assume it is in AP_STA when the own Wifi remains „on“, meaning I can connect to the portal either via the ESPs created Wifi or the Wifi it is connected to.