[Request] Add wifi setting to select fixed BSSID

[ranma]

Is your feature request related to a problem? Please describe.

In my home network I have 3 APs, one in the basement and two in the ground floor. When the closest AP becomes temporarily unavailable (e.g. Fritzbox restart, interference, ...), OpenDTU reconnects to the much further away AP (Fritzbox mesh repeater), but doesn't automatically reconnect back to the higher RSSI AP.

This leads to the reported RSSI dropping from ~-60 (good RSSI) to ~-90 (bad RSSI) and missing messages in the MQTT feed due to the slow and unreliable connection.

Describe the solution you'd like

OpenDTU should periodically scan for APs with a better signal strength and switch APs to the strongest one.

Describe alternatives you've considered

Periodically rebooting the mesh repeater to force OpenDTU to reconnected to the closer main AP.

Additional context

Sample of AP switch and better RSSI after rebooting the mesh repeater forced OpenDTU to reconnect to the closer AP:

This probably also affects the DPL loop accuracy as fetching the power usage data will be slow when connected to the bad AP.

[stefan123t]

@ranma please consider this issue and related issues upstream. Currently we only reconnect in case of a WiFi Disconnect, regardless of whatever reason the WiFi was disconnected.

You may try with some of the ESP-IDF Roaming 802.11k and Mesh Steering 802.11r+v examples, i.e. without the OpenDTU app code first, to verify whether this allows you to reconnect to a better AP in the vicinity of your device ?

tbnobody#2202 (comment)

Please note that there was some reluctance to implement Roaming or Mesh steering as it requires considerable amount of time to scan the WiFi using the SSID. Though this could eventually be reduced using the BSSIDs for the known network ?
During the Network scans the OpenDTU would be offline, if we can not use a second WiFi network stack, but that would require more memory and always CPU cycles from the WiFi core of the ESP32 too.

[schlimmchen]

I can understand that ranma is asking for something like this, but it's not going to happen.

• We are using the ESP32 and Arduino on ESP-IDF so we don't have to deal with Wi-Fi Details.
• If such a feature finds its ways into OpenDTU-OnBattery, it will be merged from upstream project.
• The upstream project already has several issues regarding this.
• If users have a non-trivial Wi-Fi situation, i.e., the need for more than one Access Point, potential logic of steering clients around should be in the backbone for legacy 2.4GHz clients, like our ESP32.

Ranma,

• is it acceptable to you to setup a unique SSID on the one AP located best for your OpenDTU-OnBattery? That would force your OpenDTU-OnBattery onto that one AP.
• Alternatively, your one Fritzbox near to your OpenDTU-OnBattery could provide a second SSID? Can Fritzboxes do that in the meantime?
• Multiple SSIDS is a trivial feature for "proper" APs such as UniFi (I love my three UniFi 6 LR), possibly with OpenWRT. Or you replace that one Fritzbox with an OpenWRT One?

[schlimmchen]

Maybe we could implement associating with a fixed BSSID, i.e., Wi-Fi AP MAC? @stefan123t has that been discussed?

Does it even help in this Mesh-Wi-Fi situation?

[spcqike]

To check the AP MAC address should help.

Maybe one could create a view / field to show the mac of the AP and a button to say „store this specific Mac and check every x minutes, if AP Mac is different, try to reconnect to the network“

(and a button to force a reconnect?)

[ranma]

• Alternatively, your one Fritzbox near to your OpenDTU-OnBattery could provide a second SSID? Can Fritzboxes do that in the meantime?

I don't think this is possible. In mesh mode, all wifi settings are controlled from the main Fritzbox and automatically copied to the mesh repeaters, so any secondary SSID would also exist on both.

[ranma]

Maybe one could create a view / field to show the mac of the AP and a button to say „store this specific Mac and check every x minutes, if AP Mac is different, try to reconnect to the network“

Yeah, that should be sufficient for me. I should check in the upstream bugs and look into implementing this, requesting connection to a specific wifi BSSID is also a standard feature of the espressif and Arduino apis (e.g. WiFi.begin() takes an optional bssid).

[stefan123t]

@schlimmchen there are separate method signatures to connect to a certain BSSID if I recall it correctly. That is why I suggested to look into the roaming and mesh steering example code first to find a proper solution for such a setup.

tbnobody#2202 (comment)

Maybe it is sufficient to search the Network for the proper SSIDs only and compare the signal strength of the BSSIDs every N minutes or when the signal strength has degraded considerably after the last forced disconnect ?
Also storing the BSSIDs for the configured SSID and resorting to the one with the best RSSI if available would be useful. We could even force a specific BSSID imho as ranma suggested.

addendum: usually you would like to use the same SSID for all access points to support roaming with devices capable. So providing a separate unique SSID for the OpenDTU/ODOB is a feasible workaround but obviously not THE solution yet ;)

[schlimmchen]

and check every x minutes, if AP Mac is different, try to reconnect to the network

Connecting to a fixed BSSID is a feature I can see be useful and maintainable. You are asking for logic to switch APs automatically, which I don't think OpenDTU should have.

@ranma Shall we rewrite this issue to be "Add support to connect to a specific BSSID"?

[stefan123t]

@schlimmchen I believe what @spcqike suggested is to either

1. reconnect to the AP with the fixed and stored BSSID (only) your suggestion.
2. verify the BSSID of the AP currently connect to and in case it differs from the BSSID,
   which we have connected to because the primary BSSID became unreachable,
   try to reconnect more frequently than before,
   ie. currently this happens only after the new BSSID has become unreachable too for some reason.

[schlimmchen]

By chance I noticed that this is now essentially a duplicate of #442, and should be tracked upstream in tbnobody#1354. I keep this open to remind us that we may contribute this out of this project.