Skip to content
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

wifi: fix reconnect issue due to enablement of fast connect #6598

Merged
merged 1 commit into from
Apr 22, 2024

Conversation

jpeletier
Copy link
Contributor

What does this implement/fix?

Types of changes

  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Other

Related issue or feature (if applicable): fixes

Pull request in esphome-docs with documentation (if applicable): esphome/esphome-docs#

Test Environment

  • ESP32
  • ESP32 IDF
  • ESP8266
  • RP2040
  • BK72xx
  • RTL87xx

Example entry for config.yaml:

wifi:
  fast_connect: false # false by default, but to make it clear for this PR.
  networks:
    - ssid: MyWiFi
      password: password
      bssid: AA:BB:CC:DD:EE:FF
      priority: 3
    - ssid: MyWiFi
      password: password
      bssid: FF:00:11:DD:EE:FF
      priority: 16
    - ssid: MyWiFi
      password: password
      bssid: DD:33:00:11:22:AA
      priority: 3

Checklist:

  • The code change is tested and works locally.
  • Tests have been added to verify that the new code works (under 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:

      // Try hidden networks after 3 failed retries
      ESP_LOGD(TAG, "Retrying with hidden networks...");
      this->fast_connect_ = true;
      this->num_retried_++;

The effect of enabling fast_connect_ this way has the following side effects:

  1. It gets enabled until next reboot, so if there are more disconnections, there will not be a few retry attempts first without fast connect.
  2. A behavior is enabled that the user did not explicitly enable in the configuration.
  3. save_fast_connect_settings_() will be invoked to save prefs to flash about a feature that the user did not actually enable.
  4. Decreasing priorities will be ignored. As per the documentation, the 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 when fast_connect_==true, the other networks are not looked at any more.
  5. When reconnecting, scan will be skipped and the first network in the list will be tried directly.

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 one retry_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 if fast_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 enabling fast_connect_ without actually touching a configuration setting (with all those side effects) and without altering the existing priority-countdown based behavior.

@codecov-commenter
Copy link

codecov-commenter commented Apr 22, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 53.43%. Comparing base (4d8b5ed) to head (c238a78).
Report is 424 commits behind head on dev.

Additional details and impacted files
@@            Coverage Diff             @@
##              dev    #6598      +/-   ##
==========================================
- Coverage   53.70%   53.43%   -0.28%     
==========================================
  Files          50       50              
  Lines        9408     9537     +129     
  Branches     1654     1685      +31     
==========================================
+ Hits         5053     5096      +43     
- Misses       4056     4130      +74     
- Partials      299      311      +12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@nagyrobi nagyrobi added this to the 2024.5.0b1 milestone Apr 22, 2024
Copy link
Member

@jesserockz jesserockz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fix

@jesserockz jesserockz modified the milestones: 2024.5.0b1, 2024.4.1 Apr 22, 2024
@jesserockz jesserockz merged commit 927caf0 into esphome:dev Apr 22, 2024
61 checks passed
@jesserockz jesserockz mentioned this pull request Apr 22, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Apr 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants