It sould fire every 3 seconds ??? so it should pick up a reading and it should add that reading to the running total ???
As I mentioned earlier, the “last trigger” is null. It never triggered 
Hmmmm Please try the ‘/3’
Long thread, so hope I’m not repeating stuff that was already said.
I think the statistics sensors don’t take time intervals into account, thus they can end up misleading in common scenarios. I have attempted to resolve this in the past by using a time sampling approach, which you can find here: Time based (vs event based) Statistics / Filter.
It doesn’t do integration, but with the right interval, the difference between an integral and a sum could be negligible.
Thanks for joining the thread too!
From what I understood with the help of this thread, it seems like exactly that was the problem, but changing the method to “left” solved the problem.
Thank you for sharing this. A question remains: Is there any advantage over the “method: left”?
Will do! I’m just thinking that this will probably consume a lot of ressources, as it will trigger every 3 seconds, and this accounting for just one sensor! But I’ll do it anyway 
Probably not in your case. The math under the hood just takes the current value divided by the last update duration. So if it updates more frequently, you just get more updates but the same result.
Your graph would look better though. No big jumps, just gradual increases and decreases.
It’s A LOT less than the statistics component has to do for the same sensor (1 simple calc every 3 secs)
The stats sensor has to take into account other readings and process a result, this one doesn’t care.
Check your CPU stats before and after, it should not be noticeable (may 1% if that)
Uh, not correct at all… math processes barely hog any resources. The integration component will be much less than what you created.
Okay, but I’d still like to see it’s output and what increase in resources it consumes.
Petro, do you think the ‘/3’ will be okay ? should it have been *3 rather than ‘*3’ ??? I thought that ‘should’ have worked :petulance:
/3 will fire every second that is divisible by 3. so 0, 3, 6, 9, etc.
I’m not sure about *3 because I’ve never used it. Looking at the docs, i’m not sure how they do it but I would expect it to fire every 3 seconds based on startup.
I’m not familiar with “method: left”, so I don’t know.
The integration component only calculates on state changes. It uses simple addition, subtraction, multiplication and division to approximate the area under the curve. So in regards to your template, the calculations are negligible. But yours fires every 3 seconds.
I couldn’t find *3 in the docs but I’ve seen a thread with Phil debating it’s use with Taras
My understanding was pretty much as yours and I thought to try to avoid the “full second bottleneck” (cos “if” it did it on a fraction … 
)
I believe I’m experiencing a similar issue and wanted to add this at the risk of duplicating information that is already in here 
.
When comparing 3 integrations; pv power, battery (dis)charge power; I’m faced with a smooth curve for pv and a more erratic one for battery.
These values are updated at a steady frequency of 1/60s, originate from the same physical device and are relayed to HA via MQTT.
The integrations are based on almost identical sensors and their method is not specified (so should be trapezoidal).
Battery charges every morning at 0500h to 0530h at about 4kW.
I’ve marked a part of the curve where the “charge” stops climbing at 1700h until 0500h where it receives a value of about 4kWh. Since HA has been ignoring 0 since 1700h (previous day) it seems to average 12h of 0-4kWh which could amount to a rise of about 25kWh. In this situation, where I know for a fact that the battery charge has not increased during this time, this seems like a slight miscalculation 
This issue almost certainly also occurs in the integration for the pv power sensor but is much less obvious by the smooth nature of pv power.
Is there any way to make sure HA does not ignore the 0 value delivered 60s earlier?
It seems to me like this would limit the averaging to 60s instead of 12h.
I’ve set my integration to “left” for the time being.
it’s not. This is how the trapezoidal calculation works. There’s no bug in the code, it’s just how the calculation works.
Use left or right.
You’re welcome to request a new integration method. But as it stands, Trapezoidal is performing exactly how Trapezoidal should work.
This post here attempts to remove the calculus from the explanation and show the differences in the calculations with graphs.
it’s not. This is how the trapezoidal calculation works. There’s no bug in the code, it’s just how the calculation works.
I’m not suggesting there’s a bug. I’m way to uninformed on the maths and codebase involved to do so.
Rather a miscalculation in the sense that I’m using the wrong tool for the job.
Thanks for providing even more information.