-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Select strongest AP if duplicate SSID exist #10395
Conversation
When performing WiFi scan, do not terminate at first matching SSID as it may not be the strongest one if multiple access points are visible. NOTE: The scan results are not sorted in descending order of RSSI, rather they are grouped by channel number Early termination means a very weak match on channel 1 will be selected over a very strong match for the same SSID on channel 6.
This only occurs if you set both SSIDs to the same name (which makes no sense). I suggest you leave SSID2 set to empty ( Set |
Can confirm that configuring ONLY one SSID in Tasmota and using |
I specifically observed this on my esp32 d1 mini. I have only one ap configured in tasmota. I will instrument the loop to confirm the scan results list are not ordered by descending rssi, which i believe is the case. It could be a difference in the esp32 WiFi library? |
So... the problem was nothing to do with the wifi-scan code, I can confirm this, and I can see that my pull request makes no sense. However, I also did manage to 'reproduce' my problem:
The 'bug' arises in the sense that in commissioning new devices, one may not expect them to get 'stuck' on a very weak AP during the first scan performed by tasmota32-lite. I agree option 56 fixes this and for me this is an acceptable solution, but I can well imagine novice users assuming their esp32 module has inferior WiFi performance. Indeed I did assume this initially, as the channel number is not displayed in the information page. Without option56 enabled, the only way their device will ever rescan (I believe) is if it loses all WiFi coverage, which might be triggered if they took down all their WiFi for a period of time. Do we agree this is a 'bug' ? If so, I happy to file one, with the suggested work-around being to set option56. |
Change force initial default state ``SetOption57 1`` to scan wifi network every 44 minutes for strongest signal (#10395)
Discussed and decision was to enable SetOption57 1 by default. |
The FRITZ!Box support mesh technologies where all ap sending on the same wifi channel and same ssid. This is how it should be configured. I can confirm that at least the esp8266 to quite well to select the best ap with the strongest signal. |
All sending on same channel. Thats why i dont like cheap Mesh systems. Mesh APs needs to communicate to each other. Using the same channel is the easiest and cheapest way to do. |
I just checked because I found that hard to believe. |
Description:
When performing WiFi scan, do not terminate at first matching SSID as it may not be the strongest one if multiple access points are visible.
NOTE: The scan results are not sorted in descending order of RSSI, rather they are grouped by channel number
Early termination means a very weak match on channel 1 will be selected over a very strong match for the same SSID on channel 6.
To reproduce: Setup two access points, with identical SSID:
AP1: Set to channel 1, and place it perhaps 20m away (about -80dBm RSSI)
AP2: Set to channel 11, and place it about 2m away (about -60dBm RSSI)
NOTE: Channel number matters - the bug causes Tasmota to select the lowest numbered channel for a given SSID.
SetOption56 1 to initiate a new scan on each restart.
Result: The device will consistently select AP1, despite AP2 being much closer/stronger.
Using the WiFi scan feature will confirm AP2 is stronger.
Checklist:
_NOTE: I have not run any CI tests on this change, however I have confirmed the fix on a SONOFF mini and a ESP32 D1 mini dev board.