Closed meingraham closed 5 years ago
Period reports the watts since the last teleperiod occurred. Since you have "Yesterday":0.001,"Today":0.001 it means that only 1 instance of Period = 1 would have been recorded for a 24 hour period.
In the test case below I have set teleperiod to 10 seconds and this is what I get
01:29:07 MQT: tele/ups/SENSOR = {"Time":"2019-01-17T01:29:07","ENERGY":{"TotalStartTime":"2018-11-19T12:02:10","Total":91.135,"Yesterday":4.845,"Today":0.240,"Period":0.550,"Power":194.069,"ApparentPower":194.069,"ReactivePower":0.000,"Factor":1.00,"Voltage":218,"Current":0.889}}
01:29:17 MQT: tele/ups/SENSOR = {"Time":"2019-01-17T01:29:17","ENERGY":{"TotalStartTime":"2018-11-19T12:02:10","Total":91.136,"Yesterday":4.845,"Today":0.241,"Period":0.530,"Power":166.800,"ApparentPower":203.674,"ReactivePower":116.900,"Factor":0.82,"Voltage":218,"Current":0.933}}
01:29:27 MQT: tele/ups/SENSOR = {"Time":"2019-01-17T01:29:27","ENERGY":{"TotalStartTime":"2018-11-19T12:02:10","Total":91.136,"Yesterday":4.845,"Today":0.242,"Period":0.540,"Power":166.000,"ApparentPower":198.435,"ReactivePower":108.700,"Factor":0.84,"Voltage":218,"Current":0.909}}
0.540W for the last teleperiod makes sense if the power = 198.435W / 60 minutes / 6 to get to my 10 second teleperiod.
"ApparentPower":198.435
"Period":0.540
198.435 / 60 / 6 = 0.551208
Seems close enough.
So the use case for Period in the telemetry data is to count the number of watts the device has observed since the last teleperiod occured.
To add, in theory if the apparent power was exactly 100 W consistently then Period would report
100 / 60 / 6 = 0.277778
Each subsequent Period value will be the same so I need to add these up in my home automation system which is exactly what I am doing. I do not use the Yesterday, Today etc at all.
If my teleperiod was 300 (5 minutes) I would see
100 / 60 * 5 = 8.333333
each time I receive telemetry data.
I forgot to mention, to see the fractions like I do you need to perform
WattRes 3
I have logs for two devices in my original post - an S31 and an HW-655 with a PZEM.
But the S31 has small power consumption each TelePeriod
all day long yet Period = 0
. This is actually the device that alerted me to a potential issue.
The PZEM had 0 watts since last restart (BTW, it's restarting periodically due to a Hardware Watchdog - a problem for later). So, OK, Period = 0
is correct. I just jumped to a conclusion because I saw Period = 0
for both and thought I had a related issue. Let's put this one aside.
Mike
P.S. It would be beneficial to add a field to the SENSOR
message to print out the value of the TelePeriod
at the time of those readings. Yes, querying TelePeriod
gives you that but not in one nice consolidated payload. Or you could just know what you've set it to. But if you have different devices and you've changed the value on some, then having that information along with the SENSOR
readings would be valuable in calculating information such as Watt-Hours, etc.
P.P.S. WattRes - Thanks!
It was maybe reporting 0.01 which would have rounded to 0 with WattRes 0 (default)
I can confirm that it was a rounding issue. Setting WattRes to 2 shows Period values >0. Thanks.
Thanks for your help.
Mike
I'll post a feature request for adding TelePeriod value to the SENSOR message.
Teleperiod is a configuration and it is a constant. I don't think it is needed a constant in a sensor json message
@ascillato
I tried to be more explicit in the feature request (#4962) I just posted. It's really not TelePeriod
but the actual interval.
I also just thought about this scenario...
TelePeriod
is set to 1500SENSOR
message is broadcast as a result of the "regular" mechanism when TelePeriod
transpires.TelePeriod 1500
command (could be done manually or as a result of some condition in a Rule or via a home automation system)STATE
and a SENSOR
messageSENSOR
message?@meingraham It would return the data as at the time the "trick" is executed. , so Period data, for example, will be reset and start measuring until either the next teleperiod occurs, or the "trick" is executed.
edit: Just tested it... it does not reset the value of Period but it does reset the timer used for teleperiod.
Thus the need to return the actual interval in the SENSOR
message for which the measured data is for since it's not equal to TelePeriod.
Didn't see @andrethomas edit... but still some uncertainty as to the interval for which the measurement applies.
More "argument" in my feature request #4962
@meingraham The "Period" value is the number of watts accrued during the teleperiod. I explained the math part of it in comment https://github.com/arendst/Sonoff-Tasmota/issues/4956#issuecomment-454985573
Yes, I got a bit confused about what the Period
field was because Period
/TelePeriod
/Interval got jumbled in what I was thinking and trying to convey.
What I'm trying to explain is a field that tells you the interval (in seconds) that transpired for which the totals collected and transmitted in the Period
represents.
The only value dependant of the Teleperiod elapsed time is the "period" value in Energy. All other values have no relation to TelePeriod elapsed time.
"Oh my, I wished I never invented the period value..."
@arendst - but you did ;-)
To be honest... I'd almost tend to agree that removing the Period field is better. After all, what's the period w/o an interval reference?
Period is useful if you don't have anything else messing with the SENSOR output which would likely be the most use case scenario.
My POW's are set to teleperiod 60 and I collect the Period data to perform further calculations and graph in node-red on load, consumption etc as I do not fully trust the totals for Yesterday and Today and I prefer live changing graphs.
I've posted a comment on your other issue on how you can add what you are asking for yourself as a user-defined driver here https://github.com/arendst/Sonoff-Tasmota/issues/4962#issuecomment-455263606
Period
always0
onTelePeriod
generated messages.S31
HW-655 (Generic) with PZEM-004T attached