Skip to content

[wifi] Add optional multi_ap mode to select strongest AP by RSSI - #1581

Open
deltecent wants to merge 1 commit into
FujiNetWIFI:masterfrom
deltecent:wifi-strongest-ap
Open

[wifi] Add optional multi_ap mode to select strongest AP by RSSI#1581
deltecent wants to merge 1 commit into
FujiNetWIFI:masterfrom
deltecent:wifi-strongest-ap

Conversation

@deltecent

@deltecent deltecent commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

Summary

Fixes #1575.

ESP-IDF's default WIFI_FAST_SCAN associates to the first AP that answers for the configured SSID, ignoring signal strength. In a meshed / multi-AP SSID (extenders/repeaters, mixed 2.4/5 GHz), a stationary FujiNet can latch onto a weak/distant AP and stay there — flaky throughput and periodic disconnects even when a much stronger same-SSID AP is available.

Approach: opt-in via config, fast scan stays the default

This adds a multi_ap option to the existing [WiFi] section of fnconfig.ini (default 0). Behavior is unchanged unless it's turned on.

[WiFi]
...
multi_ap=1

When enabled, WiFiManager::connect() and test_connect() set an all-channel, signal-sorted scan before esp_wifi_set_config:

if (Config.get_wifi_multi_ap())
{
    wifi_config.sta.scan_method = WIFI_ALL_CHANNEL_SCAN;
    wifi_config.sta.sort_method = WIFI_CONNECT_AP_BY_SIGNAL;
}

so the strongest same-SSID AP is chosen at connect time. No minimum-RSSI threshold is set, so a lone weak AP stays usable.

It also logs bssid / channel / rssi on WIFI_EVENT_STA_CONNECTED (unconditional — useful in both scan modes) so the selected AP is visible in the debug output.

Why opt-in

WIFI_ALL_CHANNEL_SCAN scans every channel before associating, so connection setup is somewhat slower than fast scan. Rather than change the default connect path for everyone, this leaves fast scan as the default and lets users in meshed/multi-AP environments opt in.

Changes

  • lib/hardware/fnWiFi.cpp — gate the all-channel/signal-sorted scan on Config.get_wifi_multi_ap() in connect() and test_connect(); log AP bssid/channel/rssi on connect. (ESP-only; the PC build uses fnDummyWiFi.)
  • lib/config/fnConfig.h, fnc_wifi.cpp, fnc_save.cppwifi_info.multi_ap field, get/store_wifi_multi_ap(), and parse/save in the existing [WiFi] section.

Testing

  • FujiNet-PC RS232 build + ctest suite green (config plumbing compiles; fnc_wifi/fnc_save exercised by the build).
  • ESP behavioral verification of the scan modes is still worth a real-hardware check in a multi-AP setup.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GXyRJPxQQxGYBUHJRJG6JY

ESP-IDF's default WIFI_FAST_SCAN associates to the first AP that answers
for the configured SSID, ignoring signal strength. In a meshed/multi-AP
SSID (extenders/repeaters, mixed 2.4/5 GHz) a stationary FujiNet can latch
onto a weak/distant AP and stay there, causing flaky throughput and
periodic disconnects even when a much stronger same-SSID AP is available.

Add a [WiFi] multi_ap config option (default 0). When enabled, connect()
and test_connect() set an all-channel, signal-sorted scan
(WIFI_ALL_CHANNEL_SCAN + WIFI_CONNECT_AP_BY_SIGNAL) so the strongest
same-SSID AP is chosen. Default preserves ESP-IDF's fast scan, so behavior
is unchanged unless the option is turned on. An all-channel scan makes
association somewhat slower, which is why it is opt-in; no minimum-RSSI
threshold is set, so a lone weak AP remains usable.

Also log bssid/channel/rssi on WIFI_EVENT_STA_CONNECTED so the selected
AP is visible in the debug output regardless of scan mode.

Config plumbing: wifi_info.multi_ap, get/store_wifi_multi_ap(),
parse+save in the existing [WiFi] section.

Fixes FujiNetWIFI#1575

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GXyRJPxQQxGYBUHJRJG6JY
@deltecent deltecent changed the title [wifi] Select strongest AP by RSSI on connect [wifi] Add optional multi_ap mode to select strongest AP by RSSI Aug 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

WiFi STA connect ignores RSSI: in a multi-AP / mesh SSID it associates to the first-found AP, not the strongest

1 participant