OpenBK7231T_App icon indicating copy to clipboard operation
OpenBK7231T_App copied to clipboard

OpenBeken connects to a weak AP randomly when multiple SSIDs match the configured one

Open C0rn3j opened this issue 5 months ago • 4 comments
trafficstars

I have multiple APs with the same SSID.

One of them is downstairs, meters away from my two bulbs, one of them is upstairs, far too away from them.

Meanwhile one bulb connected to the good AP, one to the bad one, and as such is effectively inaccessible:

Image

Image

I would expect both to check which signal is better and connect to the one with better signal when detecting multiple APs, or at least connect to the stronger one eventually.

#1683 is mildly related to this issue

C0rn3j avatar Jun 22 '25 13:06 C0rn3j

It's a SDK problem, not OpenBeken. If a device is BK7231 or Realtek, this can be offset by enabling flag 51 (will use bssid to connect). If LN882H, then that function would need to be implemented first.

NonPIayerCharacter avatar Jun 24 '25 09:06 NonPIayerCharacter

I have devices on both BK and LN, I also have separate APs for 5 and 2.4GHz networks that are per-device named so I can work around this by simply setting a given device to the network AP that makes the most sense, but I'd really prefer if I could just not do that and use the unified AP.

So far I only spotted LN to be problematic for sure, but it could be both.

If here is the wrong place to report it to, where should I do so to get it fixed in the SDK?

On Tue, Jun 24, 2025, 11:17 NonPIayerCharacter @.***> wrote:

NonPIayerCharacter left a comment (openshwprojects/OpenBK7231T_App#1684) https://github.com/openshwprojects/OpenBK7231T_App/issues/1684#issuecomment-2999505113

It's a SDK problem, not OpenBeken. If a device is BK7231 or Realtek, this can be offset by enabling flag 51 (will use bssid to connect). If LN882H, then that function would need to be implemented first.

— Reply to this email directly, view it on GitHub https://github.com/openshwprojects/OpenBK7231T_App/issues/1684#issuecomment-2999505113, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMQXERSVPHNM3UG3I5GJLD3FEJTVAVCNFSM6AAAAAB73LIL32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOJZGUYDKMJRGM . You are receiving this because you authored the thread.Message ID: @.***>

C0rn3j avatar Jun 24 '25 09:06 C0rn3j

Wifi libs are always closed source. Even on ESP (though there is a reverse-eng attempt going on). You can try to adjust scan_time in OBK, maybe that would fix it. https://github.com/openshwprojects/OpenBK7231T_App/blob/e4791701c09e287b4d9b1e0638ea046bd5139d97/src/hal/ln882h/hal_wifi_ln882h.c#L205

NonPIayerCharacter avatar Jun 24 '25 10:06 NonPIayerCharacter

I also found this issue, but somehow fogott about...

IIRC the "better" AP was shown in the list, so if that is the case, I'm not sure, if changing "scan_time" can help. But that's some month ago...

If the APs are in fact all seen/scanned, I think, we can implement a workaround to enforce using the "best" AP. I'm not at home, so sadly I can't test, but a basic idea it there:

inside wifi_scan_complete_cb all found SSIDs, BSSIDs and RSSI is reported. So if we search for the lowest (I think it was lower is better?) RSSID of all APs sending the SSID we can set the BSSID of the AP.

I can try a PR for this, but can't test at the moment.

MaxineMuster avatar Jun 24 '25 11:06 MaxineMuster