mega-20200721 oddity - %unixtime% different for power vrs reboot

[dampa]

release: ESP_Easy_mega_20200721_normal_ESP8266_4M1M
device: WeMoc D1 mini

I created a simple test:
A controller - Home Assistant (OpenHAB) MQTT - pointing to a broker running on a PiZerow on my locol network
Device 1 - a Generic - Dummy Device set with four values: boot1, boot2, boot3 and boot4(unused)
Ruleset 1 is the following:

Code: Select all

// ruleset 1 - system events timing

on System#boot do  //runs on cold boot, reset or wake from sleep
   TaskValueSet,1,1,%unixtime%
endon

on WiFi#Connected do
   TaskValueSet,1,2,%unixtime%
endon

on MQTT#Connected do
   TaskValueSet,1,3,%unixtime%
endon

When I reboot the device and go look at the device I see this:

reboot.png (19.96 KiB) Viewed 5233 times

but when I poweroff the device and power it back on, I see this:

power-on.png (18.67 KiB) Viewed 5233 times

Very odd....

[TD-er]

I don't think I really get what you're trying to show here.

Let me explain what I think is happening here.

Time may not have been set (yet) if you try to save the values to the dummy.
On system boot, there is no WiFi connection yet, so there cannot have been a NTP query.
On WiFi#Connected, it may be possible a call to NTP was made, of course only if NTP was enabled.
Same applies for MQTT#Connected.

Until the time has been set, the "unix time" is probably the number of seconds since boot.

Another thing to consider, is that the task variables are stored in RTC memory, so they are read at a warm boot and restored before any call to a function or rule has been made.
If the time was set, then this is also kept in RTC memory, so we may have some idea of time and date when we perform a reboot and are not in reach of WiFi to perform a NTP request.
However, this last update may be from a few seconds before a crash. For example a watchdog reset may be triggered after 2 (Software WD) or 6 (Hardware WD) seconds in which the time is probably not updated in the RTC memory.
Also it takes time to reboot, so the time may be off by 1 .. 7 seconds after a crash or other warm reboot.
Since the values are quite low, I don't think NTP is enabled.


Another thing that will happen when you try to store the Unix time in a dummy variable, is that you will loose resolution.
The task values are of type float. This means we only can use about 20 bits (+1 for the sign) for the value.
Meaning the difference of a few seconds or even longer will be stored as the same value.
As a matter of fact, since the most significant bit of the 32 bit Unix time is set, there will be roughly 12 bits lost when storing the value in a float.
This translates to roughly an hour for which the Unix time will result in the same float representation.

[dampa]

TD-er -Thanks for the explanation -(I messed up with the images but have correct them now) What you say makes sense.

I was doing this because someone said they thought the latest release was taking longer to boot so this was just a little test to see if anything showed up. I should have realized that there is no clock to figure out the time until WiFi was up (Duh)

Once again thanks for the great product and awsome support!