Status on Wi-Fi connectivity?

[mrwee]

Hi,

Just wondering what the status is on this topic? Running ESP_Easy_mega_20220809 on a Original Wemos D1, but the module keeps it connecting to an AP (Ubiquity) further away than the one sitting 2m from it, resulting in -84dB and unstable function.

Wi-Fi settings:

[Ath]

It should improve if you un-check that last checkbox in the screenshot, I'd expect.

[TD-er]

Also check "Force WiFi B/G" as this will give you some extra headroom regarding how well it may remain connected with low RSSI values.
Force WiFi No Sleep may fix some minor issues when the node is not replying immediately on each call made to it. (e.g. loading web page)

"Use Last Connected AP from RTC" will retry to reconnect to the last active connection on reboot.
So it will not perform a WiFi scan first, but just try to reconnect.

[mrwee]

Unticking "Use Last Connected AP from RTC" makes no change
Interestingly enough, it connects to the nearest AP at boot, but then changes to one of lower dB.

Since the best AP is so close, I can't see why enabling B/G should make that much difference, when it moves to a worse AP? Enabling B/G will impact my 2.4GHz SSID's, so I'd rather not go that way when I have plenty of coverage.

[TD-er]

Some modern access points do have some methods to redistribute clients among access points.
Especially when these work in a WiFi mesh setup.
Some access points from Asus are notorious for this.
What these do is they force a disconnect when a node is seen by more than one meshed access point.
The criteria for whether or not a node should be disconnected are often not configurable and vendor specific.
But I've seen that some may force a disconnect/reconnect when the connection quality is lower than some threshold.
Quality can also be determined by the nr of retransmissions, signal/noise ratio and a number of other parameters.

With a node too close to an access point, the SNR could even get worse.

By forcing b/g mode, you also indicate the device will for sure not support fancy things like a WiFi mesh etc.
(or at least the access point will not try to force newer tricks onto the client)
Especially for those notorious Asus access points, the only way to get an ESP device (and some others) to reliably connect is by forcing b/g mode.

[mrwee]

Well it’s the client who decides to roam, not the infrastructure. I know what Cisco, Aruba and others have some optional mechanisms to try and bump the client to another AP. But none of these are used on UniFi AFAIK. Normally a roaming treshold is used (e.g. 65dB for VoWiFi), if the signal strength goes below that, the client starts to look for a roaming candidate.

SNR is good, so that’s not the issue either. I’ll try to play with the treshold a bit, to see if that make a difference.

[mrwee]

Think I found the issue.
Had 12 publish commands executed when MQTT Broker was connected. All 12 commands were also used in MQTT imports on the same module.

In the logs I could see low memory warnings and the module has 100% load. NTP was not set, Wi-Fi associated to a "wrong" AP, and I could hardly browse to the module. Guess the combination of publish / MQTT import affects a lot of startup processes as removing the publish commands, fixed it . It now associates to the nearest AP.