feat: wifi companion handling robustiness improvement#2706
Open
NickDunklee wants to merge 1 commit into
Open
Conversation
I am redoing my change from a while back to be more human-readable.
It's true, looking at one's earlier code can make one feel
terrible!
Anyways, the existing implementation of wifi reconnect in MeshCore
leverages two reconnects with `WiFi.setAutoReconnect(true)`
as well as the manual reconnect loop.
From some research, the existing method creates two competing
reconnect mechanisms that can fight against each other.
My original desire to fix this stemmed from WiFi connections not
completing successfully, becoming stale, taking a very long time to
reestablish. An older variation of this fix has been running for
months now, and the network controller shows a steady stable
connection. On the other flavors, wifi would often disconnect,
go stale, and periodically disappear until the node was reset.
The second PR handles the cli rescue commands to provision wifi.
**Improvement Things:**
- Utilizes `WiFi.begin()` which does a full re-init and recovers
reliably. The existing buggy `reconnect()` calls
`esp_wifi_connect()` without reinitializing the stack,
which can silently fail on ESP32-S3 under flakey wifi conditions.
- Remove `WiFi.setAutoReconnect(true)` so there aren't competing
mechanisms.
- 30-second reconnect throttle to avoid rapid reconnect shittery
in situations like AP not currently being available or put node
in the fridge for some reason.
- Using `WiFi.persistent(false)` to prevent stale NVS-cached creds
from interfering with `WiFi.begin()` calls, both on initial
connect, and on each reconnect attempt.
- Add flash-stored credential storage: SSID/password are loaded
from /wifi_config on SPIFFS at boot, falling back to compiled-
in defaults if absent. This allows runtime-provisioning and
being able to avoid compiled-in defaults with the subsequent
CLI rescue PR to come.)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I am redoing my change from a while back to be more human-readable.
It's true, looking at one's earlier code can make one feel terrible!
Anyways, the existing implementation of wifi reconnect in MeshCore leverages two reconnects with
WiFi.setAutoReconnect(true)as well as the manual reconnect loop.From some research, the existing method creates two competing reconnect mechanisms that can fight against each other.
My original desire to fix this stemmed from WiFi connections not completing successfully, becoming stale, taking a very long time to reestablish. An older variation of this fix has been running for months now, and the network controller shows a steady stable connection. On the other flavors, wifi would often disconnect, go stale, and periodically disappear until the node was reset.
The second PR handles the cli rescue commands to provision wifi.
Improvement Things:
WiFi.begin()which does a full re-init and recovers reliably. The existing buggyreconnect()callsesp_wifi_connect()without reinitializing the stack, which can silently fail on ESP32-S3 under flakey wifi conditions.WiFi.setAutoReconnect(true)so there aren't competing mechanisms.WiFi.persistent(false)to prevent stale NVS-cached creds from interfering withWiFi.begin()calls, both on initial connect, and on each reconnect attempt.This, and the subsequent rescue CLI PR replace the old #1888 - I will close that PR once I have the CLI PR committed for review, so those that have been using it for months don't have a coverage gap where they can't apply the code again while waiting for review. Not an arrogance, just making sure people don't lose functionality. It is genuinely so awesome for wifi heltec nodes. They just become part of your life instead of wondering why they don't randomly work.