Clock#Time events when Wifi not connected

[peces]

Hi all !

Simply, I just made the evidence, that the Clock#Time events are not triggered if the wifi is for some reasons lost, at the time of the event.
ex : the function below :

On Clock#Time=All,20:30 do
event,Light_On
endOn

Is not fired if at 20:30 the wifi is lost by that time.
This is kind of a shame since the esp clock is more than capable to remain accurate during several hours of wifi outages, but this will kill the rules automations.
Would there be a workaround ?

HW : Sonoff mini R2; Nodemcu with built-in oled
Builds : ESP_Easy_mega_20220809_normal_ESP8266_1M_VCC ; ESP_Easy_mega_20240414_normal_ESP8266_1M_VCC
NTP checked with adress box left empty.

I might be missing smth...
Thanks for the quality answer that will sure appears soon

Pierre, more than happy espeasy

[TD-er]

Is just the wifi lost or did the device power cycle and not reconnect for whatever reason?

If the clock was once set, ESPEasy should be able to keep track of time, even after a crash or reboot, as long as the device did not power cycle.
ESPEasy stores the last known system time in RTC memory which is loaded at boot and this restores the last known system time.

This will of course lead to some offset, but it should not be more than a few seconds per reboot.
Unless the device really hung in some loop and did not update the system time to RTC for a while, then the offset can be significant longer, but still it should have some idea of time.

Oh and is it possible for you to update one of those units (or test on some other ESP8266 which is easier to update) to see if it has been fixed in the most recent test build?
https://td-er.nl/ESPEasy/latest/
Here you can also find the 'all.zip' which will probably download a lot faster than via GHactions.

[peces]

This lack of event launch appeared all without any reboot nor power cycle.
I noticed this in work environnement, and then reproduiced this by kicking the ESP out off the wifi (using wifi access control policies). -> "ping -t" stops responding has expected.
-> I wait for the programmed "on Clock#Time = bla:bla do " etc events; I then notice that the rules no longer fire -> I re-allow the node connexion to wifi -> "ping -t" comes back quickly -> the node hasn't rebooted (through %uptime% value), times is still correct.

But during the time the wifi was down, Clock#Time events weren't launched.

Okay for updating, but as mentionned I think I am up to date with build 20240414; having the same issue.

[Ath]

Do you have "Sleep on connection failure" (Config tab) enabled?

[TD-er]

There have been a few changes regarding time sync since the april build

[peces]

Thanks for your repplies.

"Sleep on connection failure" is not enabled in any of the concerned setups.

"There have been a few changes regarding time sync since the april build" -> In the https://github.com/letscontrolit/ESPEasy/releases pages, I see Release mega-20240414 is the latest so I 'm kinda lost. Same goes for the all.zip file, 20240414 number.

I just made the experiment with a classic Wemos D1 (build 20240414 ) and I notice that the event ARE fired correctly even if I kick the node out of the wifi .. !

So Could it be a hardware related bug ? ... Concerning the sonoff mini R2...and with the oled built-in nodemcu ..

[Ath]

TD-er was redirecting you to https://td-er.nl/ESPEasy/latest/ where the latest development build is available, that's the current candidate for the next release. And, as said, a lot has happened (code-wise) since that 20240414 release...

[Ath]

Was the Sonoff mini R2 already updated to 20240414 release? As that 2022 build can have several issues, especially regarding WiFi, where a lot has been improved (mostly by the tenacious work of TD-er)

[peces]

The 20240414 and 2022 builds I am experiencing the pb on, concern two different sonoff mini R2.
The sonoff running 20240414 has been flashed right from factory to 20240414.
I'll try asap to update this latter sonoff to 20240812 and repport back.

I just paypaled 20€ for the great things that this community + software + helps are.
I so much encourage others to do so.

Thanks
Pierre

[TD-er]

Maybe also check with a regular ESP8266 with 4M flash and not the one used in some of the older Sonoff ones.
Those 1M builds have LIMIT_BUILD_SIZE defined and it might be of help to find a possible cause if this really makes a difference between the 1M builds and 4M build.

[peces]

Hi,

So far, I'm confused with my experiments, so will report and I might give up ..
I flashed a brand new Sonoff mini R2 to 20240812 1M build (using chrome on url https://td-er.nl/ESPEasy/latest/) and made my Clock#time event.

In order to monitor if the Clock#time events are properly triggered, I rule this function :

On Clock#Time=All, **:** do
longpulse,12,0,1 // this GPIO12 is the relay + red Led so it is easy to watch.
endOn

This time with 20240812 (more infos in attached file if needed), kicking the ESP out of the wifi does not change the behaviour of the LED right away.
-> the GPIO12 turns itself of every minute for a solid accurate second.
BUT
Hours later ( over night .. ) the things get random.
The longpulse is sometimes not triggered / sometimes triggered for way more than one second... ( like 10 or more seconds ).
It seams like the "CPU" gets really "stressed" or loaded by the attempts to join the wifi.

I attached the logs captured by putty in serial if that can be usefull. ( me I barelly can point few evidences )
The names of files are self-explanatory.

The LooptimerSet,10,1 is for me a way to have a solid timed event in my log.
My ssid is "New", and it is interesting to notice that the ESP node tries all viewable wifi APs after not being able to join one.

nb: even after re-allowing the esp to the wifi (at line 00:38:48.379Info) , I had to power cycle the esp (at 00:45:59.434Info : EVENT: Rules#Timer=10,1748) since the ping was really rare, and had troubles to access the gui. ( could not see its cpu load unfortunately ).

Thanks, have a nice day.

[Ath]

Thanks for the logs, but unfortunately, these are made using the 20240414 release build, just like you screenshot, and not the most recent nightly 20240812...

The longer delays after some time are, IMHO, caused by the WiFi being able to first connect, but then almost immediately being killed by the router, and not by not being able to connect. That may be a flow that's less intensively tested, as it won't happen that often

[peces]

Ohh... shoot...
I forgot that I downgraded this ESP to 20240414 during the experience... to see if i got the problem again.... Really my bad.
I am then re-doing it.

Sorry for stupid omission

[TD-er]

Do you also use some MQTT controller?
I know that on older builds reconnecting to the MQTT broker does stall the ESP for nearly 100%.
This has been improved in more recent builds, though not 100% sure if some of those improvements were already present in the April build.
You could try to disable any controller for testing to see if this makes any difference.
And please try the latest build (of a few days ago) as this does contain quite a few updates regarding handling timeouts, connecting to NTP server (which might be blocking the ESP as well when the connection is re-established)