Add BSSID binding command for mesh networks

[agenturamg]

PROBLEM DESCRIPTION

In mesh networks with multiple access points using the same SSID, Tasmota devices automatically connect to the AP with the strongest RSSI signal. This causes devices to connect to suboptimal or undesired access points.

Current Behavior:

• Tasmota automatically selects AP based only on signal strength (RSSI)
• The AP1 command only displays/sets SSID name, not BSSID
• No command exists to specify target BSSID for connection
• SetOption56 controls AP scanning but doesn't allow BSSID selection

Use Case:
I have a multi-story building with 4 access points in a mesh network (all broadcasting SSID "IoT"):

• Floor 1: BSSID 24:5A:4C:6F:07:DD (target)
• Floor 2: BSSID e0:63:da:06:b5:07
• Floor 3: BSSID 80:2a:a8:c6:b5:62
• Sauna: BSSID 74:ac:b9:90:d2:9c

A device physically located on Floor 1 should connect to Floor 1 AP, but instead connects to Sauna AP due to stronger signal caused by building layout.

Why Alternative Solutions Don't Work:

1. Different SSIDs per AP: Defeats the purpose of mesh network, requires manual device reconfiguration when moving
2. UniFi device binding: Device can spend hours attempting connection to wrong AP before being rejected, causing long downtimes
3. Reducing AP power: Affects all clients, not just Tasmota devices
4. Different channels: Doesn't guarantee connection to desired AP

Feature Request:
Add a command to bind device to specific BSSID: BSSID1 <mac_address>

Example usage:
Backlog SSID1 IoT; Password1 mypassword; BSSID1 24:5A:4C:6F:07:DD; Restart 1

This would ensure predictable and stable mesh network deployment in enterprise/multi-AP environments.

REQUESTED INFORMATION

• Read the Contributing Guide and Policy and the Code of Conduct
• Searched the problem in issues
• Searched the problem in discussions
• Searched the problem in the docs
• Searched the problem in the chat
• Problem is not scripter related, in this case open a discussion and tag gemu2015
• Device used (e.g., Sonoff Basic): ESP32-C3 (multiple devices affected)
• Tasmota binary firmware version number used: 15.2.0(release-tasmota32)
  • Pre-compiled
  • Self-compiled
• Flashing tools used: N/A (feature request, not bug)
• Provide the output of command: Backlog Template; Module; GPIO 255:

Configuration output here:
{"NAME":"ESP32C3","GPIO":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"FLAG":0,"BASE":1}
Module: 0 (ESP32C3)
GPIO255: N/A

• If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:

N/A - This is a feature request, not a bug with rules

• Provide the output of this command: Status 0:

00:00:13.361 MQT: stat/tasmota_693550/STATUS = {"Status":{"Module":0,"DeviceName":"Tasmota","FriendlyName":["Toggle 1"],"Topic":"tasmota_693550","ButtonTopic":"0","Power":"0","PowerLock":"0","PowerOnState":0,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0,"InfoRetain":0,"StateRetain":0,"StatusRetain":0}}
00:00:13.365 MQT: stat/tasmota_693550/STATUS2 = {"StatusFWR":{"Version":"15.2.0(release-tasmota32)","BuildDateTime":"2025-12-12T10:58:45","Core":"3.3.4","SDK":"5.3.4.251205","CpuFrequency":160,"Hardware":"ESP32-C3 v0.4","CR":"432/699"}}
00:00:13.369 MQT: stat/tasmota_693550/STATUS5 = {"StatusNET":{"Hostname":"tasmota-693550-5456","IPAddress":"192.168.10.15","Gateway":"192.168.10.1","Subnetmask":"255.255.255.0","DNSServer1":"192.168.10.1","DNSServer2":"0.0.0.0","Mac":"80:F1:B2:69:35:50"}}
00:00:13.373 MQT: stat/tasmota_693550/STATUS11 = {"StatusSTS":{"Time":"1970-01-01T00:00:13","Uptime":"0T00:00:12","UptimeSec":12,"Heap":187,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":554,"MqttCount":1,"Berry":{"HeapUsed":4,"Objects":49},"POWER":"OFF","Wifi":{"AP":1,"SSId":"IoT","BSSId":"7E:AC:B9:91:D2:9C","Channel":11,"Mode":"HT40","RSSI":86,"Signal":-57,"LinkCount":1,"Downtime":"0T00:00:06"}}}

• Set weblog to 4 and then, when you experience your issue, provide the output of the Console log:

00:00:01.001 WIF: Connecting to AP1 IoT Channel 11 BSSId 7E:AC:B9:91:D2:9C in mode HT40 as tasmota-693550-5456...
00:00:03.369 WIF: Connected

# Device connects to BSSID 7E:AC:B9:91:D2:9C (Sauna) instead of desired 24:5A:4C:6F:07:DD (Floor 1)
# Even after commands:
# AP1 245A4C6F07DD
# SetOption56 0
# Device continues connecting to strongest signal AP, not desired AP

TO REPRODUCE

1. Set up mesh network with 3+ access points using same SSID
2. Place Tasmota device near one AP (e.g., Floor 1 BSSID 24:5A:4C:6F:07:DD)
3. Configure device with: Backlog SSID1 IoT; Password1 <password>; Restart 1
4. Device connects to different AP with stronger signal (e.g., BSSID 7E:AC:B9:91:D2:9C)
5. Attempt to bind to specific BSSID using various commands:
   • AP1 245A4C6F07DD - only shows SSID name, doesn't bind to BSSID
   • SetOption56 0/1 - doesn't allow BSSID selection
   • WiFiConfig 2 - doesn't bind to BSSID
6. Device continues connecting to wrong AP on every restart

EXPECTED BEHAVIOUR

Proposed Command:
BSSID1 <mac_address>

Expected Usage:
Backlog SSID1 IoT; Password1 mypassword; BSSID1 24:5A:4C:6F:07:DD; Restart 1

Expected Behavior:

• When BSSID is set, device attempts connection ONLY to specified BSSID
• When BSSID is empty/cleared (BSSID1), device uses current automatic AP selection
• Setting applies to both AP1 and AP2 (BSSID1, BSSID2)
• Command accepts MAC address formats: XX:XX:XX:XX:XX:XX or XXXXXXXXXXXX

Expected Output in Status 11:

{"Wifi":{"AP":1,"SSId":"IoT","BSSId":"24:5A:4C:6F:07:DD","Channel":6}}

Device should reliably connect to specified BSSID regardless of signal strength from other APs.

SCREENSHOTS

N/A - This is a feature request for new functionality

ADDITIONAL CONTEXT

Related Issues:

• choose bssid #2711 - User requested same feature in 2018
• Connecting to alternate Wifi Access Point on the wrong channel on AP command #8977 - Connection issues with multiple APs on different channels
• Tasmota uses wrong BSSid when switching between AP1 and AP2 on start #15273 - BSSID confusion when switching between AP1 and AP2

Impact:
This feature would greatly improve Tasmota usability in:

• Enterprise environments with multiple APs
• Multi-story buildings with mesh networks
• Smart home deployments requiring precise AP assignment
• Industrial IoT installations

Question: Is there any existing workaround or hidden command I'm missing? Or is this feature planned for future releases?

(Please, remember to close the issue when the problem has been addressed)

[ShortPutt]

I would also like the ability to lock in a bssid so I can force my tasmota devices on an IoT network but still have the main wifi network available as a fallback. The only way I am aware of to force tasmota devices to use a specific ssid is to not have a fallback. I would be fine having the locked bssid not consider the fallback ssid - I'd just create a rule that if it goes offline for more than 3 minutes it would remove the lock and connect to ssid2 Is this feature being considered?

[sfromis]

Why is it "suboptimal" to connect to the strongest mesh AP? It may not be on the same floor, but so what.

Still, you may see more AP affiliation by making your desired connection at short distance, and then turning off SetOption56 and SetOption57 to avoid rescans, before moving back to the normal location. Or turn off the other AP while making the connection.

[ShortPutt]

I have a multiple APs w same SSID on different channels.
I have about 5 devices where tasmota sees a minimal difference in rssi from the APs, but the APs see a significant difference in rssi from the tasmotas. For example wifiscan 1 on one tasmota shows APs rssi -78 +-5ghz, but one router reports rssi for that device as -45 and another reports -81. Ability to specify a preferred bssid on tasmota would help steer it to the AP w the best signal.

[sfromis]

Did you try the idea I posted?

[ShortPutt]

Let me make sure I understand. U r suggesting I move the ap close to the device, make the connection and then turn off setoptions 56 & 57? No I didn’t do that. It might work, but I’m not going to do that for the 5 or six devices that have the issue bc it doesn’t really seem like a sustainable solution.

[sfromis]

The suggestion was not to first move the devices, but making sure that you have the desired connection before turning off the options. Moving devices was only one possible technique. Anyway, you have a way already, even if it is not the most convenient.

[ShortPutt]

Seems like this is a feature that's not widely needed.
Best solution seems to be to ESPHome where capability to specify a bssid already exists.

[sfromis]

Just try what I posted. Seemed to work for me.

[ShortPutt]

Its too hard to try. The device is deployed in an ele box and there isn't any ethernet close to it so getting an AP close to it is also difficult.

[arendst]

You entered the magic word: ESPHome.

Command BSSid[1|2] [0|1|11:22:33:44:55:66] to select fixed WiFi Access Point disabling SetOption56 and SetOption57 has just been added to the dev branch ;-)

Command	Parameters
BSSId<x>	<x> = 1..2 <value> = set AP Wi-Fi BSSID in format 11:22:33:44:55:66 and restart 1 = reset AP<x> Wi-Fi BSSID to firmware default (AP_BSSID1 or AP_BSSID2) and restart 0 = Clear AP<x> Wi-Fi BSSID to empty and restart