Two WAX214 APs -- Devices connecting to first one to boot and don't switch to closer AP

The RSSI does not count much at these low data rates required for this kind of applications.

 

i would be much more concerned to operate this very basic level of wireless clients which associate once, and remain "happy" forever. Devices not having any intelligence for roaming, no way to re-associate with a better suited radio on the same network. The primary reason to drop associations to clients is if the radio does become overloaded, and the AP does know there are better candidates on air.

 

The 802.11k and 802.11v amendments provide very good information about the environment overall. However, this is advisory information only. The final decision remains with the client, who may still choose to ignore this useful information.
Remember, even though our WLAN infrastructure may be able to provide this information to WLAN clients, not all clients will support the 802.11v and 802.11k amendments. Support of amendments such as 802.11k/v is optional. Far to many simple IoT clients are very basic, and don't care much. however, this explains where the priorities on the implementations are today. it must be a very weak signal and extremely unreliable basic data rate before a client is dropped-off, in the idea of forcing a re-orientation and  triggering a re-association is just a last resort.

 

The similar observations exist by the way from customers of the expensive and powerful mesh systems. Even there, we often face longer delays before potentially "better suited" AP radios become available. in the case of a complete cold restart, typically the primary mesh root does come up early, and all IoT clients jump on it. And this does never change over the runtime, because they jump and stick on the (only) AP available during the cold start.