wifi: fix reconnect issue due to enablement of fast connect #6598
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.
What does this implement/fix?
Types of changes
Related issue or feature (if applicable): fixes
Pull request in esphome-docs with documentation (if applicable): esphome/esphome-docs#
Test Environment
Example entry for
config.yaml
:Checklist:
tests/
folder).If user exposed functionality or configuration variables are added/changed:
--
After #6322 was merged, upgraded devices in the network stopped connecting to WiFi. This is because there are setups that involve a number of possible WiFi networks and APs the devices may connect to in case an AP fails, etc.
#6322 introduces an improvement whereupon "fast connect" mode is enabled after failing to connect to an AP more than three times, in order to try some luck hidden networks:
wifi_component.cpp
, line 672:The effect of enabling
fast_connect_
this way has the following side effects:save_fast_connect_settings_()
will be invoked to save prefs to flash about a feature that the user did not actually enable.priority:
setting in a network allows the ESP to choose the network with the highest priority, decreasing the priority by one after each failed attempt. Since we are locked on to one network whenfast_connect_==true
, the other networks are not looked at any more.It seems to me that the only sought after effect is (5) in order to find hidden networks. Therefore, this PR uncouples the
fast_connect_
flag and introduces a new oneretry_hidden_
to achieve (5), without affecting (1), (2), (3) and (4). When there are more than 3 reconnect attempts, the WiFi component will then work as iffast_connect_
was enabled only until a connection is made or we exceed 5 connection attempts, when the WiFi component will be restarted, a new scan will take place and the ESP will then have the chance to choose a different network.Summary:
retry_hidden_
flag is introduced to simulate enablingfast_connect_
without actually touching a configuration setting (with all those side effects) and without altering the existing priority-countdown based behavior.