Roaming/Association decisions in multi-AP setup

[unw1red]

IMPORTANT NOTICE If you do not complete the template below it is likely that your issue will not be addressed. When providing information about your issue please be as extensive as possible so that it can be solved by as little as possible responses.

FAILURE TO COMPLETE THE REQUESTED INFORMATION WILL RESULT IN YOUR ISSUE BEING CLOSED

Make sure these boxes are checked [x] before submitting your issue - Thank you!

• [X] Searched the problem in issues (https://github.com/arendst/Sonoff-Tasmota/issues)
• [X] Searched the problem in the wiki (https://github.com/arendst/Sonoff-Tasmota/wiki/Troubleshooting)
• [X] Searched the problem in the forum (https://groups.google.com/d/forum/sonoffusers)
• [X] Searched the problem in the chat (https://discord.gg/Ks2Kzd4)
• [X] Development/Compiler/Upload tools used : Platform.io and Arduino IDE
• [X] Hardware used : Sonoff S31 and KULED switches
• [X] If a pre-compiled release or development binary was used, which one? : 6.3 through 6.4.1
• [X] You have tried latest release or development binaries? : Yes
• [X] Provide the output of command status 0 :

  10:06:31 MQT: master_bedroom/stat/STATUS = {"Status":{"Module":1,"FriendlyName":["Master Bedroom"],"Topic":"master_bedroom","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}}
  10:06:31 MQT: master_bedroom/stat/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://thehackbox.org/tasmota/release/sonoff.bin","RestartReason":"Software/System restart","Uptime":"0T17:50:57","StartupUTC":"2019-01-03T22:15:34","Sleep":50,"BootCount":9,"SaveCount":37,"SaveAddress":"FA000"}}
  10:06:31 MQT: master_bedroom/stat/STATUS2 = {"StatusFWR":{"Version":"6.4.1(sonoff)","BuildDateTime":"2018-12-24T14:41:00","Boot":31,"Core":"2_4_2","SDK":"2.2.1(cfd48f3)"}}
  10:06:31 MQT: master_bedroom/stat/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["Gr1ff1n-1X",""],"TelePeriod":300,"SetOption":["000A8009","558180C0","00000200"]}}
  10:06:31 MQT: master_bedroom/stat/STATUS4 = {"StatusMEM":{"ProgramSize":521,"Free":480,"Heap":17,"ProgramFlashSize":1024,"FlashSize":1024,"FlashChipId":"1440C8","FlashMode":3,"Features":["00000809","0FDAE794","000383A0","23B617CE","00003BC0"]}}
  10:06:31 MQT: master_bedroom/stat/STATUS5 = {"StatusNET":{"Hostname":"master_bedroom-3448","IPAddress":"192.168.27.151","Gateway":"192.168.27.1","Subnetmask":"255.255.255.0","DNSServer":"192.168.27.20","Mac":"84:0D:8E:96:0D:78","Webserver":2,"WifiConfig":4}}
  10:06:31 MQT: master_bedroom/stat/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.27.20","MqttPort":1883,"MqttClientMask":"master_bedroom","MqttClient":"master_bedroom","MqttUser":"ha","MqttType":1,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}}
  10:06:31 MQT: master_bedroom/stat/STATUS7 = {"StatusTIM":{"UTC":"Fri Jan 04 16:06:31 2019","Local":"Fri Jan 04 10:06:31 2019","StartDST":"Sun Mar 10 02:00:00 2019","EndDST":"Sun Nov 03 02:00:00 2019","Timezone":99,"Sunrise":"01:43","Sunset":"10:06"}}
  10:06:31 MQT: master_bedroom/stat/STATUS10 = {"StatusSNS":{"Time":"2019-01-04T10:06:31"}}
  10:06:31 MQT: master_bedroom/stat/STATUS11 = {"StatusSTS":{"Time":"2019-01-04T10:06:31","Uptime":"0T17:50:57","Vcc":3.504,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER":"OFF","Wifi":{"AP":1,"SSId":"Gr1ff1n-1X","BSSId":"90:4C:81:69:9F:20","Channel":11,"RSSI":40}}}

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

When devices are in a multi-AP environment, poor roaming/association decisions are made. My situation involves four Aruba Networks AP-335 access points running in controller mode. The SSID being used runs on both 5 and 2.4GHz. The following is an example of current association of the above posted device.

(Aruba7210) #show ap association client-mac 84:0d:8e:96:0d:78

The phy column shows client's operational capabilities for current association

Flags: A: Active, B: Band Steerable, H: Hotspot(802.11u) client, K: 802.11K client, M: Mu beam formee, R: 802.11R client, W: WMM client, w: 802.11w client V: 802.11v BSS trans capable

PHY Details: HT : High throughput; 20: 20MHz; 40: 40MHz; t: turbo-rates (256-QAM) VHT : Very High throughput; 80: 80MHz; 160: 160MHz; 80p80: 80MHz + 80MHz

ss: spatial streams Association Table ----------------- Name bssid mac auth assoc aid l-int essid vlan-id tunnel-id phy assoc. time num assoc Flags Band steer moves (T/S) phy_cap ---- ----- --- ---- ----- --- ----- ----- ------- --------- --- ----------- --------- ----- ---------------------- ------- Pantry 90:4c:81:69:9f:20 84:0d:8e:96:0d:78 y y 12 100 Gr1ff1n-1X 27 0x10010 g-HT-20sgi-1ss 5m:48s 1 WA 0/0 g-HT-20sgi-1ss 84:0d:8e:96:0d:78-90:4c:81:69:9f:20 Stats ------------------------------------------ Parameter Value --------- ----- Channel 11 Channel Frame Retry Rate(%) 40 Channel Frame Low Speed Rate(%) 0 Channel Frame Non Unicast Rate(%) 2 Channel Frame Fragmentation Rate(%) 0 Channel Frame Error Rate(%) 1 Channel Bandwidth Rate(kbps) 255 Channel Noise 95 Client Frame Retry Rate(%) 66 Client Frame Low Speed Rate(%) 0 Client Frame Non Unicast Rate(%) 0 Client Frame Fragmentation Rate(%) 0 Client Frame Receive Error Rate(%) 40 Client Bandwidth Rate(kbps) 158 Client Tx Packets 3962 Client Rx Packets 5972 Client Tx Bytes 256380 Client Rx Bytes 824209 Client SNR 27 A2c_SM SeqNum, Old SeqNums 9513 0 This device is 3 meters from another access point. Although 27 SNR is good, you can see that the retry rate is quite high because of other 2.4GHz devices between this switch and the associated AP which is ~12 meters away. The perceived RSSI of this switch is currently 38%. If I force the device to connect to the nearest AP (MasterCloset), you can see that the association parameters are much better with much lower retry rate. (Aruba7210) #show ap association client-mac 84:0d:8e:96:0d:78 The phy column shows client's operational capabilities for current association Flags: A: Active, B: Band Steerable, H: Hotspot(802.11u) client, K: 802.11K client, M: Mu beam formee, R: 802.11R client, W: WMM client, w: 802.11w client V: 802.11v BSS trans capable PHY Details: HT : High throughput; 20: 20MHz; 40: 40MHz; t: turbo-rates (256-QAM) VHT : Very High throughput; 80: 80MHz; 160: 160MHz; 80p80: 80MHz + 80MHz ss: spatial streams Association Table ----------------- Name bssid mac auth assoc aid l-int essid vlan-id tunnel-id phy assoc. time num assoc Flags Band steer moves (T/S) phy_cap ---- ----- --- ---- ----- --- ----- ----- ------- --------- --- ----------- --------- ----- ---------------------- ------- MasterCloset 90:4c:81:69:fa:80 84:0d:8e:96:0d:78 y y 1 100 Gr1ff1n-1X 27 0x10009 g-HT-20sgi-1ss 51s 1 WA 0/0 g-HT-20sgi-1ss 84:0d:8e:96:0d:78-90:4c:81:69:fa:80 Stats ------------------------------------------ Parameter Value --------- ----- Channel 1 Channel Frame Retry Rate(%) 8 Channel Frame Low Speed Rate(%) 0 Channel Frame Non Unicast Rate(%) 22 Channel Frame Fragmentation Rate(%) 0 Channel Frame Error Rate(%) 0 Channel Bandwidth Rate(kbps) 41 Channel Noise 96 Client Frame Retry Rate(%) 0 Client Frame Low Speed Rate(%) 0 Client Frame Non Unicast Rate(%) 0 Client Frame Fragmentation Rate(%) 0 Client Frame Receive Error Rate(%) 0 Client Bandwidth Rate(kbps) 0 Client Tx Packets 77636 Client Rx Packets 22116 Client Tx Bytes 3348526 Client Rx Bytes 2484809 Client SNR 51 A2c_SM SeqNum, Old SeqNums 19211 0 Most enterprise wireless devices have roaming parameters within their drivers. They normally build a roaming candidates table of 5-20 choices and only decide to roam if the signal level (RSSI) is -72 or better and at least 3dB better than their current association. In my case, the device should have voluntarily roamed to the MasterCloset AP from the Pantry AP on its own. When running in a place with only one access point, this situation is moot. But with Google WiFi and other multi-AP setups, this can become an issue and make the devices far less responsive to MQTT. The QoS setting becomes much more important when poor association/roaming decisions are made. Although, I am running a commercial-grade wireless system and can force/nudge devices to make better decisions, the Google and Orbi systems do not have this granularity. Please let me know if further data can be supplied for this issue.

[arendst]

From your status information I see you do not use "auto detection of strongest wifi signal". In that case it just uses the first connecting configured SSID (either AP1 or AP2) without strongest signal detection. This was always the case until v6.4.0

Starting with 6.4.0 there are two options to select the strongest signal from the two configured AP SSID names. If you have many AP's with same name it will detect the stringest signal within a margin of 10%.

To use wifi signal detection you will have to enable SetOption56 and SetOption57. See wiki for background info.

[unw1red]

I have set both options on all devices. I will monitor for 24hrs and update or close ticket. Thank you.

[ascillato2]

Closing this issue as it is duplicated

Support Information

See Wiki for more information. See Chat for more user experience.