-
Notifications
You must be signed in to change notification settings - Fork 1
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
Meshed Wifi compatibility #69
Comments
the preference on the strongest signal is already built in. you can preselect the channel to be used. |
Hi, Just as an FYI: From my experience roaming support still offers some additional benefits. An ESP might initially connect to the strongest AP (as mentioned, sometimes it still doesn't) but also might be forced to change to a different AP during operation. This might be caused due to an AP power cycling or something similar (Sidenote: Some APs will auto-disconnect a client if they have been connected for too long for security reasons). Also preselecting a Wifi channel doesn't help in all cases. I.e. if you use single radio wifi repeaters. But please don't feel forced to rush anything. I'm planning to switch to an Ethernet connection anyway, so this very problem won't affect me much longer. Only wanted to give some food for thought. Maybe it would help someone else. |
Hi there,
i'm running an AVM meshed Wifi and am experiencing some issues where my ebus Adapter Shield V5 likes to not pick the AP with the strongest signal after booting.
As far as I understand the firmware should already be able to pick the strongest AP and not the first one it finds for a given SSID. Since i operate a small army of ESPs this phenomenon isn't something new to me and i suspect an issue in the esp-idf code or an incompatibility with AVM meshes.
However i found that ESPs that have 802.11k and 802.11v enabled usually behave better and will eventually migrate to the proper AP.
I don't know though if the ESP SKU on the ebus Adapter Shield supports this.
If you would like to have a look, here's a contribution I made to a different ESP32 based project
meatpiHQ/wican-fw@f2e0374
Sidenote: Thank you for this piece of hardware. It's the only alternative to the overpriced Wolf ISM (currently unobtanium) and was really easy to integrate.
The text was updated successfully, but these errors were encountered: