F5F Stay Refreshed Power Users Networks Device on UniFi repeatedly chooses the least optimal network connection

Device on UniFi repeatedly chooses the least optimal network connection

Device on UniFi repeatedly chooses the least optimal network connection

S
Symphora
Member
177
08-24-2016, 03:25 PM
#1
I possess three end units that function as controllers for managing shed roller doors. These are custom-built hardware with specific firmware, though those details aren't included here. They're linked to a network through WiFi. Nearby, there are several UniFi access points. One large UAP-AC-M Pro is mounted about 3 meters away on the wall, and at the far end of the driveway, a smaller non-Pro UAP-AC-M is attached to a gate. One unit is roughly 50 cm closer to the non-Pro AP yet still much nearer to the Pro unit, but it keeps moving to the latter. This behavior causes significant issues: its connection quality drops sharply, leading to a large latency increase and massive packet loss. Below is a half-hour PingPlotter log showing the event at 12:36pm when the device switched from Pro to non-Pro AP. At 12:52pm, I manually redirect it back to the Pro AP via the UniFi dashboard. These units will likely be deployed in large numbers (hundreds), making it extremely difficult to manage them individually across a wide area. Thoughts?
S
Symphora
08-24-2016, 03:25 PM #1

I possess three end units that function as controllers for managing shed roller doors. These are custom-built hardware with specific firmware, though those details aren't included here. They're linked to a network through WiFi. Nearby, there are several UniFi access points. One large UAP-AC-M Pro is mounted about 3 meters away on the wall, and at the far end of the driveway, a smaller non-Pro UAP-AC-M is attached to a gate. One unit is roughly 50 cm closer to the non-Pro AP yet still much nearer to the Pro unit, but it keeps moving to the latter. This behavior causes significant issues: its connection quality drops sharply, leading to a large latency increase and massive packet loss. Below is a half-hour PingPlotter log showing the event at 12:36pm when the device switched from Pro to non-Pro AP. At 12:52pm, I manually redirect it back to the Pro AP via the UniFi dashboard. These units will likely be deployed in large numbers (hundreds), making it extremely difficult to manage them individually across a wide area. Thoughts?

Z
ZakenMannetje
Junior Member
46
08-31-2016, 10:21 AM
#2
The endpoint device is pretty dumb. But like, the Wireless Experience (which I know doesn't really mean anything) in the UniFi dashboard goes from 'Excellent' of 'Good' with -70 to -65 dBm, to 'Poor' with like -86 dBm, and the device goes "Ah yes, this is the AP I want to be connected to". Correct 2.4GHz. They're inside a big metal shed, so they don't have the best WiFi situation possible. There also isn't a lot of foot traffic. I had an epiphany that maybe another roller door being fully open was causing the swap, so I tested that with someone onsite. After unlocking the AP and getting him to open the door...nope, the device stayed happily on the Pro without any increase in latency or packet loss. I have no idea. I didn't do any of that lmao. There's no blacklisting or anything. The closer AP has objectively better connectivity, but it still drops that, for no reason, to connect to an objectively worse AP.
Z
ZakenMannetje
08-31-2016, 10:21 AM #2

The endpoint device is pretty dumb. But like, the Wireless Experience (which I know doesn't really mean anything) in the UniFi dashboard goes from 'Excellent' of 'Good' with -70 to -65 dBm, to 'Poor' with like -86 dBm, and the device goes "Ah yes, this is the AP I want to be connected to". Correct 2.4GHz. They're inside a big metal shed, so they don't have the best WiFi situation possible. There also isn't a lot of foot traffic. I had an epiphany that maybe another roller door being fully open was causing the swap, so I tested that with someone onsite. After unlocking the AP and getting him to open the door...nope, the device stayed happily on the Pro without any increase in latency or packet loss. I have no idea. I didn't do any of that lmao. There's no blacklisting or anything. The closer AP has objectively better connectivity, but it still drops that, for no reason, to connect to an objectively worse AP.

A
ahanlon26
Junior Member
18
08-31-2016, 12:16 PM
#3
These gadgets rely on an ESP microcontroller such as ESP8266 or ESP32. A notable behavior is that the wireless firmware always selects the device with the smallest MAC address for the network it joins.
A
ahanlon26
08-31-2016, 12:16 PM #3

These gadgets rely on an ESP microcontroller such as ESP8266 or ESP32. A notable behavior is that the wireless firmware always selects the device with the smallest MAC address for the network it joins.

M
MCCrafter100
Member
159
08-31-2016, 06:53 PM
#4
They are ESP32, correct? I just reviewed what you mentioned. The unusual pattern is that the Pro (the strong AP) has a lower MAC address than the non-Pro (weak AP), unless it ignores manufacturer-specific bytes... then the weak one shows a lower MAC (c3 for weak, 6a for strong). Still, the non-Pro connects through the Pro, which seems irrelevant. Possibly. But the issue disappears when the door the device is attached to moves, and I tested that too. When the opposing door was checked... it's a manual door, not linked to any motor at all! Plugged directly into 240v, and that's fine. This doesn't occur with any other similar devices we've encountered so far. The motor is connected straight to the device, but again, it doesn't switch networks when the door moves. Oh right—my idea was either 'Lock the AP back to the Pro' or 'Set a minimum RSSI on the weak one so it never connects to it.'
M
MCCrafter100
08-31-2016, 06:53 PM #4

They are ESP32, correct? I just reviewed what you mentioned. The unusual pattern is that the Pro (the strong AP) has a lower MAC address than the non-Pro (weak AP), unless it ignores manufacturer-specific bytes... then the weak one shows a lower MAC (c3 for weak, 6a for strong). Still, the non-Pro connects through the Pro, which seems irrelevant. Possibly. But the issue disappears when the door the device is attached to moves, and I tested that too. When the opposing door was checked... it's a manual door, not linked to any motor at all! Plugged directly into 240v, and that's fine. This doesn't occur with any other similar devices we've encountered so far. The motor is connected straight to the device, but again, it doesn't switch networks when the door moves. Oh right—my idea was either 'Lock the AP back to the Pro' or 'Set a minimum RSSI on the weak one so it never connects to it.'

J
JUANI_10PVP
Member
165
09-02-2016, 05:34 PM
#5
Verify the actual WLANs on the access points. For instance, on one AP the primary MAC address begins with 74, while the WLAN BSSIDs start with 74, 7a, and 7e, sharing the final 10 digits.
J
JUANI_10PVP
09-02-2016, 05:34 PM #5

Verify the actual WLANs on the access points. For instance, on one AP the primary MAC address begins with 74, while the WLAN BSSIDs start with 74, 7a, and 7e, sharing the final 10 digits.