Runtime wrong

[reloxx13]

Hello, its me agian x.x

The new runtime as seconds would be great, but the time is so much wrong counted, its useless :(

From 24h real uptime only 7-10h are counted.

30mins real are ~7mins in Tasmota.

within 10sec only 3-4sec are counted.

[arendst]

That's probably because you use sleep. I don't use sleep and am very happy. I never understood why anyone wanted sleep. It's your choice.

[reloxx13]

heya,

since you are form netherland, ill post this in german. tell me if you dont understand this:

Welche auswirkungen hat der in einer Festen Installation, habe aktuell 9 x Tasmota Sonoffs mit Iobroker und 3 x Echo Dot am laufen, und es werden noch ein paar mehr werden, an der hälfte sind aktuell über koppelrelais noch Taster Schaltungen dran, um konventionell das Licht einzuschalten, Frage wäre, wie schnell reagieren die Geräte bzw. weckt Alexa die Geräte über den iobroker aus dem Sleep auf?

In meiner Zukunftsplaung sind ca. 30 Tasmota Geräte geplant und der Stromverbrauch bzw. die Leistung ist ja auch ein Kostenfaktor, somit hätte ich dann 30 x 1,1 Watt = 33 Watt x 24 Std x 365 Tage = ca. 289 KWh im Jahr Stromverbrauch was bei ca. 0,26 Cent die KWh kosten von ca. 75 Euro im Jahr wären , im Sleepmodus wären es ja bei 30 x 0,4 Watt = 12 Watt x 24 Std x 365 Tage = ca. 105 KWh im Jahr Stromverbrauch was bei ca. 0,26 Cent die KWh kosten von ca. 27 Euro im Jahr wären!

Denke das sollte man nicht vernachlässigen und wenn durch den Sleepmodus keine Nachteile in der Performance entstehen wäre dies nicht nur bei Akkugestützen Systemen Interessant!

[reloxx13]

in short with 30 devices as example:
without sleep: 1,1watt = ~ 289KWh/year = ~75€
with sleep: 0,4watt = 105KWh/year = ~27€

but yep, I thought it will be the sleep and/or other loop lag.

oh and also i should note, some users notices that the devices get hotter without sleep.

[reloxx13]

how about saving the start date and additional subtract it from current time.

also only the saved starttime would be enough for other platforms to get the calculate the real uptime themselfes.

[arendst]

The teleperiod counter and now also the uptime counter are more hevily being used by sensors that need to be visited every 3 seconds to keep their measurements valid.

As I cannot oversee the consequences of sleep I just cannot take it into acccount while providing features. Consedring tthe amount of time difference you noticed I fear many uptime counter related events will also be hamperred.

Btw I thought Germany was on free solarpower anyway ;-)

[tobox]

I am also having trouble with the new uptime format:

• all mqtt changes to interesting values are logged in a database. With the old uptime (in hours) this created 24 entries a day, which was fine. Now I have thousands of (mostly useless) entries.

• the format is difficult to parse. It is neither human friendly nor computer friendly. Uptime in seconds or hours can be plotted without any pre-processing and creates nice sawtooth patterns that make reboots easily visible.

I think it would be best to just have all three options, than I could decide which one I want to log and process. It doesn't use much memory or computing power to provice uptime in human readable format, hours and seconds.

Regards
Thomas

Btw: With solar power in germany, it works like this:

• old installations get much money for produced energy, even more than it costs to buy energy (current price for buying: 25c/kWh, old installations get up to 50c/kWh produced)
• newer installations get about 12c/kWh for produced power that is send to the grid. But for the power you create and use yourself, you save 25c/kWh, because you don't need to buy it

That is why many germans with solar power build all kinds of systems that use power when its available from solar, which works well with sonoffs. Example: lower the temperature in the freezer when you have much solar power, to save power during the night (letting the temperature rise to normal). There are many applications like this.

[curzon01]

Regarding energy consumtion & sleep usage:

For use of Sleep <value> and because I did not found detailed information of real power consumtion in a live environment I did some measurement of energy consumtion:

• Live 230 V~ line consumtion of a Sonoff Dual R2 switch
• 3.3 V = ESP8266 device consumtion for (ESP-12) using Tasmota 5.12.0 precompiled binary from Releases

All measurements were done

• having WiFi enabled and connected
• having MQTT enabled and connected
• using Syslog and connected
• using a Teleperiod of 60 for debuging

Hint: It seems an open webpage continuously prevents the WiFi Manager going to sleep. I observed for Sleep 1 no more Modem sleep periods when the browser is on main page.

Sonoff Dual R2 switch 230V~ line

The 230 V~ measurement was done over a period of ~24-46 h with different sleep values using two different MID calibrated meters (an Eastron 3 phase & Saia-Burgess 3 phase). The first impression was that a higher sleep value reduce the consumtion marginal only:

Sleep:	0	1	50	200
Energy	29.0 Wh	39.1 Wh	18.9 Wh	26.0 Wh
Runtime	23.4661 h	46.7219 h	25,0258 h	38.2058 h
Power	1.24 W	0.84 W	0.76 W	0.68 W

3.3 V = power on ESP-12

This measurement was selected because it's easy to have some current measure on DC instead of having additonal integration on AC. This should show the relative quantity of power consumtion, not the absolute.
This confirms my suspicion that a sleep value ≠ 0 starts reducing the power consumtion about 1/3.
(for easy reading the oscilloscope diagram I used a shunt of 1 Ω having a 1:1 interpretation between voltage and current).

Sleep 0

Using sleep 0 there are no delay() calls in Tasmota main loop and therefore the power consumtion is continuous at current ~80 mA:

Sleep 1

Due to the fact that the Tasmota main loop now calls delay() (even with 1 ms) it seems it results in peroidically (100 ms) enabling the WiFi Modem Sleep mode within the WiFi Manager library. It results in periodically lowering the current to 15-20 mA for periodically ~90 ms:

Sleep 100

Further increasing the sleep value there are more and more ~90 ms periods with additonal lowering the current to 8-10 mA - I realy don't know where this comes from:

Sleep 250

As alreafy noticed with Sleep 100 the number periods having 8-10 mA instead of 15-20 mA are again increasing:

Conclusion

Using Sleep <value> (value ≠ 0, e. g. 1) is enough reducing the power consumtion at minimum 1/3 up to 45 %.

As reloxx13 already calculated also for myself it is not unimportant using energy saving methodes. I'm currently installed 13 Sonoff devices + 22 own assembled (21 with Tasmota, 1 with ESPEasy) ESP8266 devices. Saving ~ 0,4 W each it saves ~120 kWh / a only for - doing nothing :-)
@tobox: I already have exchanged all high power consuming devices - lights, circulation pump, freezer, dryer, washer... but looking only on network there are a lot number of small (also IoT) devices consuming energy running 24/7.

Edit: Added results for Sleep 1 measurement

[reloxx13]

nice post curzon 👍

[reloxx13]

also, thx @curzon01 for adding this to the wiki 👍

just checked if its in already and add it, but you added it already :D

[earth08]

Dear what does this means,
I have physical switch before sonoff power
I have installed 5.12f
When I switchoff physical switch, the counter gets reset,
Please guide me,

Also in morning from 12:30 am to around 4:30 am or 5:00 am, no readings are recorded even when my air-conditioner is on,

[reloxx13]

dear @curzon01,
would be very nice if you can make a comparison with 2.4.1 framework and 2.3.0 or 2.4.0 👍

the wifi light sleep is off in 2.4.1 ( #2559 ), thats why its very important and interesting to know.
im sorry but i dont have the hardware to comparse it myself :X

[curzon01]

@reloxx13 - I will keep it in mind but it can take some time due to actual other tasks...

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem.