Espeasy on wifi connected

#1 Post by Rob Muller » 08 Apr 2019, 13:11

After a recent router failure i experienced that ESPEasy would not reconnect to WiFi on its own. A device reboot was required.
All my devices run a stable version of ESPEasy Mega-.
I could not find a script to monitor WiFi without use of plugins not available in the basic stable version, and i try to stay off the leeding edge.

So i cobbled this together, i tested this on many versions and it worked for all Mega.

on System#Boot do Let,1,0 // set user variable to initial state of 0 EndOn on Wifi#Disconnected do // if no wifi, wait 3 minutes if [VAR#1]=0 timerSet,1,180 Let,1,1 // set user variable 1 to 1 to prevent re-set of var1 on each event. endif endon on Wifi#Connected do // if wifi returns, cancel reboot timerSet,1,0 // cancel timer Let,1,0 // set user variable 1 to 0 endon On Rules#Timer=1 do // if still no Wifi, reboot reboot endon

I hope others will find a use for this.

If you have improvements or a beter idea, share please

Thanks for reading,
regards,

Re: ESPEasy WiFi reconnect Rules

#2 Post by riker1 » 08 Apr 2019, 14:25

Re: ESPEasy WiFi reconnect Rules

#3 Post by Rob Muller » 08 Apr 2019, 19:17

I tried that and could not get it to work reliably, but a reboot worked 100% of the time.
maybe a reboot clears something in memory that prevents re-connection.

I tested using the following method, as i have only one wifi network and cannot switch that off if i want to live (Wife!!)

Testing method:
connect to iPhone personal hotspot
open serial connection
switch off personal hotspot and observe reconnect in serial console

Thanks for reading,
regards,

Re: ESPEasy WiFi reconnect Rules

#4 Post by riker1 » 09 Apr 2019, 07:53

Re: ESPEasy WiFi reconnect Rules

#5 Post by 1CM69 » 09 Apr 2019, 13:29

Rob Muller wrote: ↑ 08 Apr 2019, 13:11 Friends,

So i cobbled this together, i tested this on many versions and it worked for all Mega.

on System#Boot do Let,1,0 // set user variable to initial state of 0 EndOn on Wifi#Disconnected do // if no wifi, wait 3 minutes if [VAR#1]=0 timerSet,1,180 Let,1,1 // set user variable 1 to 1 to prevent re-set of var1 on each event. endif endon on Wifi#Connected do // if wifi returns, cancel reboot timerSet,1,0 // cancel timer Let,1,0 // set user variable 1 to 0 endon On Rules#Timer=1 do // if still no Wifi, reboot reboot endon

I hope others will find a use for this.

If you have improvements or a beter idea, share please

Источник

WiFi¶

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 mode will be enabled when at least one applies:

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:

Change of wifi settings when both apply:

Reset of wifi_connect_attempt to 0 when both apply:

WiFi disconnect reasons¶

Beacon timeout (200)¶

For more information on the Beacon frame, see Wikipedia.

ECO mode is enabled (see below)
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.

ECO mode¶

If the “ECO” mode is enabled, the ESP does turn off the radio for longer amounts of time.

Normally an access point does send out a beacon at every so called “beacon interval”. A typical beacon interval is ~100 msec (102.4 msec). When you try to send data to a connected WiFi station, your access point first tries to send directly to the node and if it doesn’t immediately reply, the access point includes a notification for this node in such a beacon package. Meaning, if you send a ping (or just any package) to a WiFi connected node, the first reply typically takes half this interval. (later ping replies may receive a response more quickly as the radio may be on continuously)

On ESP32, setting the ECO mode will also reduce the CPU clock to 80 MHz. (added: 2022/12/15)

If the ESP (or any other WiFi device in “power save mode”) is not listening to each beacon interval, it may take longer to reach the node. Such a “listen interval” is called a DTIM interval and is often set between 1 and 3 for almost all WiFi devices. I’m not entirely sure what the ESP uses when consuming ~80 mA, but I think it has the radio on all the time, effectively receiving packets before the next beacon interval.

Here a quick test performed on 2 ESPEasy nodes. One with “Eco mode” enabled and one disabled:

gijs@DESKTOP-QLB7N8I:~/GitHub/letscontrolit/ESPEasy$ ping 192.168.10.92 PING 192.168.10.92 (192.168.10.92) 56(84) bytes of data. 64 bytes from 192.168.10.92: icmp_seq=1 ttl=254 time=6.51 ms 64 bytes from 192.168.10.92: icmp_seq=2 ttl=254 time=4.24 ms 64 bytes from 192.168.10.92: icmp_seq=3 ttl=254 time=104 ms 64 bytes from 192.168.10.92: icmp_seq=4 ttl=254 time=3.01 ms ^C --- 192.168.10.92 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3005ms rtt min/avg/max/mdev = 3.007/29.329/103.562/42.876 ms gijs@DESKTOP-QLB7N8I:~/GitHub/letscontrolit/ESPEasy$ ping 192.168.10.211 PING 192.168.10.211 (192.168.10.211) 56(84) bytes of data. 64 bytes from 192.168.10.211: icmp_seq=2 ttl=254 time=885 ms 64 bytes from 192.168.10.211: icmp_seq=4 ttl=254 time=40.9 ms 64 bytes from 192.168.10.211: icmp_seq=5 ttl=254 time=34.8 ms 64 bytes from 192.168.10.211: icmp_seq=7 ttl=254 time=85.6 ms ^C --- 192.168.10.211 ping statistics --- 13 packets transmitted, 4 received, 69.2308% packet loss, time 12323ms rtt min/avg/max/mdev = 34.788/261.588/885.111/360.524 ms

As you can see, one of them did not reply on all ping packets and the first ping took quite some time to get a reply. N.B. both are connected to the same access point.

What happens if you try to reach any host on your network?

Case 1, your PC does not know the MAC address of the ESP:

Your PC tries to find the MAC address belonging to an IP address using an ARP packet (question is like: “Who has 1.2.3.4?”)
ARP packets gets broadcasted to the entire network
If the ESP misses such an ARP request, you cannot route the IP packet to your ESP. -> fail

Case 2, your PR does know the MAC address of the ESP, but a switch or access point does not:

Your PC sends out a packet for MAC belonging to your ESP
Switch does not know how to rout and discards packet
timeout on your PC.

Work around: Send Gratuitous ARP packets (answer to a question nobody asked)

ESP sends “AA:BB:CC:DD:EE:FF has IP 1.2.3.4”
All switches, access points and hosts on your network receiving this packet update their ARP table
Roundtrip time of routing packet depends only on DTIM interval of the ESP.

TL;DR¶

If you only send data from your ESP to something like a broker, then using “ECO” mode does probably have little to no effect on WiFi performance. If you need a swift response (e.g. turning on a light), then you should not use “ECO” mode.

Support us by using one of these alternatives: Patreon Ko-Fi PayPal

Источник