Have you look for this feature in other issues and in the wiki?
yes
Is your feature request related to a problem? Please describe.
If there is a power outtake there is no time or period stored from the point of time when measurement has begun. So the value Energy Total has no relationship to a time period.
Describe the solution you'd like
A new variable which stores Time & Date from Measurement start: "MeasureTimeTotal"
Automatically set with actual Date and Time if Energy Total is reseted
Describe alternatives you've considered
Rules. For not skilled users to complicated
This could be useful for users who do not use a HA solution and just want a standalone mobile extension with a POW inline to do power usage of a device to evaluate whether or not the device necessitates a permanent POW or not.
I have, for example, some items like a freezer which I am not sure if I want to install a POW on because maybe the power usage is not significant enough to warrant measuring it over an extended period of time. Having a standalone device in this way makes it possible to test what I will get prior to committing to the installation (which as we know in some cases is not exactly reversible)
I think it is a fine idea, but you already have access to the information with a little math. It keeps track of uptime, subtract that from current time and you have what you want.
@Frogmore42
No wont work if there is a litte power outtake uptime is wrong
You are right. But, I have also found that the total will sometimes go back to a previous value when there is an outage, since the total value is not written to NV every time it changes.
I have also found that the total will sometimes go back to a previous value when there is an outage
Yes, I've also observed this when I was calibrating the devices but I think at the expense of a small amount of code it could still be a nice feature. Perhaps we add a counter how many times the device rebooted since the last reset? Then I think we need to also a setoptionXX for this feature as we would not want it to confuse users who are using the webui for normal purposes (even though the normal purpose is actually just to configure anyway, but be that as it may)
@Frogmore42
Never lost energy total values... But yes could happen. So nothing is 100% perfect
Always in mind only costs about 10€ !
+1 for more metrics displayed for Pow unit.
Personally, I'd love to see:
Unlike a fridge, i've got a heater triggered by Sonoff directly.
For a 24x7 fridge a Runtime value might be calculated for power consumption bigger than some threshold.
So what do you think, as a possible solution, to add to the actual JSON for energy the start time of total energy measurement :
"StatusSNS": {
"Time": "2018.02.04 23:17:01",
"ENERGY": {
"Total": 3.185,
"StartTimeTotal": 2018.02.01 13:07:00,
"Yesterday": 3.058,
"Today": 0.127,
"Power": 0,
"Factor": 0.00,
"Voltage": 221,
"Current": 0.000
}
And when using the command EnergyReset3 0
, Tasmota will put in that variable the actual date and time.
@ascillato
Like your idea for solution!
OK
Perhaps just a change in naming, I think
StartTimeTotal
would be easier understood if it were
TotalStartTime
Like:
16:53:07 MQT: tele/pow3/SENSOR = {"Time":"2018-10-30T16:53:07+01:00","ENERGY":{"TotalStartTime":"2018-10-30T16:45:16+01:00","Total":6.418,"Yesterday":0.100,"Today":0.074,"Period":0.51,"Power":27.97,"ApparentPower":32.12,"ReactivePower":15.80,"Factor":0.87,"Voltage":225.0,"Current":0.143}}
Do we need the SetOption52 extra timezone info with TotalStartTime? I think no as it is already shown with realtime and the starttime might have been during daylightsavings so it would be wrong anyway if it had started last week before end of daylightsavings...
This is it!
16:57:55 MQT: tele/pow3/SENSOR = {"Time":"2018-10-30T16:57:55+01:00","ENERGY":{"TotalStartTime":"2018-10-30T16:45:16","Total":6.420,"Yesterday":0.100,"Today":0.076,"Period":0.09,"Power":27.77,"ApparentPower":32.10,"ReactivePower":16.10,"Factor":0.87,"Voltage":224.2,"Current":0.143}}
Thanks :+1:
Great Thank you👍
And just like that, the number of issues is again equally divisible by the number of open PR's 🥇
Most helpful comment
This is it!