mirror of
https://github.com/letscontrolit/ESPEasy.git
synced 2026-09-14 10:35:30 +00:00
Gijs Noorlander
07e30ff616
See #2650 The counter wifi_connect_attempt is being used to determine whether the fallback SSID should be tried. It is also used to determine whether a "quick reconnect" is possible using the BSSID and channel of the last successful connection. If the connection is unstable, (last connection was active for over 5 minutes) then the connect attempt counter can be reset.
88 lines
2.8 KiB
ReStructuredText
88 lines
2.8 KiB
ReStructuredText
WiFi
|
|
****
|
|
|
|
WiFi State Machine
|
|
==================
|
|
|
|
WiFi STA states
|
|
---------------
|
|
|
|
#. STA off -> ESPEASY_WIFI_DISCONNECTED
|
|
#. STA connecting
|
|
#. STA connected -> ESPEASY_WIFI_CONNECTED
|
|
#. STA got IP -> ESPEASY_WIFI_GOT_IP
|
|
#. STA connected && got IP -> ESPEASY_WIFI_SERVICES_INITIALIZED
|
|
|
|
N.B. the states are flags, meaning both "connected" and "got IP" must be set
|
|
to be considered ESPEASY_WIFI_SERVICES_INITIALIZED
|
|
|
|
The flag wifiConnectAttemptNeeded indicates whether a new connect attempt is needed.
|
|
This is set to true when:
|
|
|
|
- Security settings have been saved with AP mode enabled. FIXME TD-er, this may not be the best check.
|
|
- WiFi connect timeout reached & No client is connected to the AP mode of the node.
|
|
- Wifi is reset
|
|
- WiFi setup page has been loaded with SSID/pass values.
|
|
|
|
|
|
WiFi AP mode states
|
|
-------------------
|
|
|
|
#. AP on -> reset AP disable timer
|
|
#. AP client connect/disconnect -> reset AP disable timer
|
|
#. AP off -> AP disable timer = 0;
|
|
|
|
AP mode will be disabled when both apply:
|
|
|
|
- AP disable timer (timerAPoff) expired
|
|
- No client is connected to the AP.
|
|
|
|
AP mode will be enabled when at least one applies:
|
|
|
|
- No valid WiFi settings
|
|
- Start AP timer (timerAPstart) expired
|
|
|
|
Start AP timer is set or cleared at:
|
|
|
|
- Set timerAPstart when "valid WiFi connection" state is observed.
|
|
- Disable timerAPstart when ESPEASY_WIFI_SERVICES_INITIALIZED wifi state is reached.
|
|
|
|
Quick reconnect (using BSSID/channel of last connection) when both apply:
|
|
|
|
- If wifi_connect_attempt < 3
|
|
- lastBSSID is known
|
|
|
|
Change of wifi settings when both apply:
|
|
|
|
- "other" settings valid
|
|
- (wifi_connect_attempt % 2) == 0
|
|
|
|
Reset of wifi_connect_attempt to 0 when both apply:
|
|
|
|
- connection successful
|
|
- Connection stable (connected for > 5 minutes)
|
|
|
|
|
|
WiFi disconnect reasons
|
|
=======================
|
|
|
|
Beacon timeout (200)
|
|
--------------------
|
|
|
|
For more information on the Beacon frame, see `Wikipedia <https://en.wikipedia.org/wiki/Beacon_frame>`_.
|
|
|
|
In short, the access point sends periodically a packet containing information about the network.
|
|
This interval is typically 100 TU (102.4 msec).
|
|
The ESP module is trying to listen to this beacon every time, but for a number of reasons it may
|
|
miss a beacon frame.
|
|
The timeout is longer than 100 TU, so it must miss a number of these beacon frames
|
|
to report a beacon timeout.
|
|
Reasons to miss such a beacon frame are:
|
|
|
|
- too busy processing other blocking tasks (very likely)
|
|
- access point not sending a beacon due to high traffic demands of others (depending on brand/model/settings)
|
|
- RF disturbances (not likely given how often this occurs)
|
|
- clock drift (not really likely)
|
|
|
|
So the "beacon timeout" is happening every now and then on the ESP nodes and ESPeasy will try to reconnect.
|