WiFi-problem

[KLelong]

Hi, I have 3 access-points in my home, each transmitting the same SSID's, on different channels. At the location where I am testing the project, it seems to always connect to a "bad" AP. By bad I mean there is a better AP, signal-wise. On channel 6, one AP has severe interference with wireless sensors (non-wifi) and the other has a low signal because of distance. As a result I can't get a stable wifi-connection, if at all. Channel 13 would be the preferred channel. Is there anything I can do to get a stable wifi-connection ? I'm dabbling myself with esp8266 and esp32, but this is the only device/software that behaves like this. The device is an ESP32 Devkit V1

This is the log I recorded via the serial port :

SECURITY   Type:0 Username:[] Password:[] Pin:[] Permissions:0
Connection Type: 1
NTP Settings 
be.pool.ntp.org TZ:CET-1CEST,M3.5.0,M10.5.0/3
WIFI Settings
 SSID: [SSIDxx1] PassPhrase: [Very secure password]

Launching web server...
Creating Web MicroServices...
WiFi Mode: 0
Scanned 10 Networks...
 0:  (-58dBm) CH:13 MAC:26:E8:29:E7:D4:E7
 1: SSIDxx2 (-61dBm) CH:13 MAC:18:E8:29:E7:D4:E7
*2: SSIDxx1 (-61dBm) CH:13 MAC:1E:E8:29:E7:D4:E7
 3:  (-62dBm) CH:13 MAC:22:E8:29:E7:D4:E7
 4: SSIDxx2 (-68dBm) CH:6 MAC:E0:63:DA:15:C9:E8
*5: SSIDxx1 (-68dBm) CH:6 MAC:E6:63:DA:15:C9:E8
 6:  (-69dBm) CH:6 MAC:EA:63:DA:15:C9:E8
 7: SSIDxx2 (-70dBm) CH:6 MAC:80:2A:A8:84:C8:13
 8:  (-70dBm) CH:6 MAC:8A:2A:A8:84:C8:13
*9: SSIDxx1 (-71dBm) CH:6 MAC:86:2A:A8:84:C8:13
Socket Server Started...
Max Heap: 110580
Free Heap: 183976
Min Heap: 181796
Connecting to AP
Set hostname to:ESPSomfyRTS2
*************************
Successfully Connected to WiFi!!!!192.168.89.248 (-69dbm)
MDNS Responder Started: serverId=A98C8C
Max Heap: 110580
Free Heap: 176140
Min Heap: 173904
App Version:2.4.0
shades.cfg exists so we are using that
Reading header at 0
version:22 len:76 roomSize:29 roomRecs:2 shadeSize:276 shadeRecs:2 groupSize:194 groupRecs: 0 pos:76
Applying radio settings Setting Data Pins RX:12 TX:13
Setting SPI Pins SCK:18 MISO:19 MOSI:23 CSN:5
Radio Pins Configured!
Successfully set up the radio
Enabled receive on Pin #12 Timing: 1
Initializing RX Queue
MQTT Connection failed for: -2
Timing Net: 7001ms
Check github for updates...
Max Heap: 110580
Free Heap: 174872
Min Heap: 168552
Internet is Unavailable: -1: 5006ms
Timing WebServer: 5011ms

[rstrouse]

Is this a mesh network with some method of beamforming or do you just have multiple APs with the same SSID? If it is the former this will be dynamic and the ESP32 will switch channels all on its own. Whichever radio that responds to the SSID request is the one that connects as this is typically up to the network not the client. I remember reading that there is something odd about any channel > 11 and the ESP32.

[KLelong]

I'm using Ubiquiti AP's, so meshing : yes. Beamforming, I don't know. That oddity about channel 13 : I flashed 3 extra EPS32's. I have now 3 pieces with WROOM32(D) which show the problem. One has a WROOM32U (= external antenna) which never has a problem. I'm going to make a test-application which only connects to wifi to see if anything changes.

[open1999]

I have the same problem. Multiple APs and even SSIDs with 802.11r Fast Transition enabled.

The only solution I found is to put the MAC address of the ESP32 in a blacklist on the APs

APs with openwrt

[rstrouse]

The weird part of all this is that the STA doesn't get to choose its AP even under 11r. It only gets to choose the SSID. As far as 11r goes I have yet to see anything definitive about whether ESP32 processes the negotiation properly or not. I don't know the entire life cycle of the renegotiation but I suspect the WiFi module would need to do some channel surfing.

[KLelong]

So I made a test-app. It scans and report the SSID's, just like SomfyRTS. Then it tries to connect to an SSID. Yesterday evening, my "remote" AP was not visible (roller-shutters closed ?) and I had no problems with the two devices I tried. All connecting to channel 13. But this morning, I had the problem again, with my software. Just to try something I changed the channel of the remote AP to 1 and suddenly the problem was gone. Strange though, one device connects to channel 13, the other to channel 1 (so the remote AP). I know there is some persistence of wifi-configurations, maybe that interferes ? About choosing an SSID : there is a way to choose (I think), but I don't know how to do it with the Arduino libraries. See this. There you can select "scan_method" and "sort_method".

[open1999]

In my case it connects it is the channel which has priority. If there is a stronger signal for example on channel 11 and a much weaker signal on channel 6 it will always take 6 by default.

Why not change the channels on the APs?

[rstrouse]

I know there is some persistence of wifi-configurations, maybe that interferes ?

That was one of the first things I disabled.

[KLelong]

I know there is some persistence of wifi-configurations, maybe that interferes ?

What I mean is that certainly the ESP8266-libraries I use store WiFi information in persistent memory. If that includes BSSID, it maybe prefers that although there is an AP with a stronger signal. If you disabled that in ESPsomfy-RTS, then that is not what causes my problem.

Changing channel 13 to something else is not an option (interference).

[rstrouse]

Ok so I looked at the code reference for the unreleased v5.x of the IDF and interestingly there are some things that I could do on the current release to facilitate a better channel selection on the SSID. Please install the pre-release of v2.4.1 and let me know how the channel selection is working.

[rstrouse]

Please install the most current v2.4.1 release as I have added roaming where ESPSomfy RTS will dynamically detect the best connection and change it on the fly.

[open1999]

Installed. Select the SSID with the high dBm.

[KLelong]

Installed it, and it connects to channel 13, which is OK. Very handy, that indication of the channel #.

[rstrouse]

Awesome I am going to close this one out. It is apparent that the ESP32 core was never designed to deal with this. The documentation is very vague and as it turned out it will hop around to get the best signal now. Weird that is not part of the ESP32 core.