Integration sensor wrong / inaccurate

[Valentino_Stillhardt]

@Mutt

Can you post the full automation as you have implemented it ?

Yes, of course:

#automations.yaml

## get last Watt reading and add integration value (cumulative)
- alias: au_utility_water_heater_kwh_update
  trigger:
    - platform: time_pattern
      seconds: '*3'
  action:
    - service: input_number.set_value
      data_template:
        entity_id: input_number.in_utility_boiler_wh_day
        value: "{{ (states('input_number.in_utility_boiler_wh_day') | float) + (states('sensor.pzem_004t_boiler_v3_power') | float) / 1200 }}"

#configuration.yaml
input_number:
  in_utility_boiler_wh_day:
    name: Boiler Wh day
    #initial: 0
    min: 0
    max: 750000
    step: 0.1
    mode: box
    icon: mdi:flash

@Mutt

Confirm that you did create the input_numbers ?

I’m absolutely sure!

@Mutt

Did you try changing the seconds to ‘/3’ ?

Not yet, should I?

---

EDIT: One more thing: The boiler is now set to a lower temperature, which the water-solar-panels can maintain during a sunny day, making it rarely turn on electrically, so even if you fix your code, I’ll probably need some weeks to test it!

[Mutt (Muttley)]

but if it comes on just 1 reading in any time period monitored you should be fine

[Valentino_Stillhardt]

After I implemented your code, it turned on several times, but never got past 0.

[Mutt (Muttley)]

It sould fire every 3 seconds ??? so it should pick up a reading and it should add that reading to the running total ???

[Valentino_Stillhardt]

As I mentioned earlier, the “last trigger” is null. It never triggered

[Mutt (Muttley)]

Hmmmm Please try the ‘/3’

[DudeShemesh]

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.

[Valentino_Stillhardt]

Thanks for joining the thread too!

@DudeShemesh

I think the statistics sensors don’t take time intervals into account

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.

@DudeShemesh

I have attempted to resolve this in the past by using a time sampling approach, which you can find here

Thank you for sharing this. A question remains: Is there any advantage over the “method: left”?

@Mutt

Hmmmm Please try the ‘/3’

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

[petro]

@Valentino_Stillhardt

Thank you for sharing this. A question remains: Is there any advantage over the “method: left”?

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.

[Mutt (Muttley)]

@Valentino_Stillhardt

Will do! I’m just thinking that this will probably consume a lot of ressources

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)

[petro]

Uh, not correct at all… math processes barely hog any resources. The integration component will be much less than what you created.

[Mutt (Muttley)]

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:

[petro]

@Mutt

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.

[DudeShemesh]

@Valentino_Stillhardt

A question remains: Is there any advantage over the “method: left”?

I’m not familiar with “method: left”, so I don’t know.

[petro]

@Mutt

Okay, but I’d still like to see it’s output and what increase in resources it consumes.

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.

[Mutt (Muttley)]

@petro

Looking at the docs

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 … )

[tommyvdv]

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.

[petro]

@tommyvdv

is seems like a slight miscalculation

it’s not. This is how the trapezoidal calculation works. There’s no bug in the code, it’s just how the calculation works.

Trapezoidal rule

@tommyvdv

Is there any way to make sure HA does not ignore the 0 value delivered 60s earlier?

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.

[petro]

This post here attempts to remove the calculus from the explanation and show the differences in the calculations with graphs.

Calculating Watts / Kw and KWh

Make a template sensor for the W. You already have the equation and it’s written here enough. - platform: template sensors: power_watts: friendly_name: "Power Watts" unit_of_measurement: 'W' value_template: > {% set PF = state_attr(input_number.power_factor.state | int ) %} {% set V = state_attr('sensor.pow_voltage', 'V') %} {% set A = state_attr('sensor.measured_current', 'A') %} {{ PP * A * V }} Now, to properly cal…

[tommyvdv]

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.