Integration sensor wrong / inaccurate

Thanks for the information
Regarding your conclusions from it though : -
If I measure the voltage (v) across an element, and the current (a) passing through it then I am measuring power. If I wait a second then I have measured power for one second which is the equivalent of a Watt Second (Ws). Your device (if it’s anything like mine) will do an arithmetic mean across that sample period (3 seconds) so we have power across 3 seconds rather than 1 second or simply 3 x the Ws value
I think I can do some quick and dirty calculations with the enitites you have that will get you something that is pretty accurate. Then hopefully Tom or Petro can come in and clean my solution up or even get your stats to replicate it’s output. Dunno I’ll do the work anyway, even if it’s throw away.

What is your sensor name or shall I just call it : - sensor.water_heater_watts ?

Yep, if you look at the left calculations above, an on state for 15 minutes @3000w gives 0.75kw/h which matches @Mutt’s calculations. I.E. multiplying it by 4 will get you 3kw/h as it should. Where as trap over the same test period gave a 0.375 for the 15 minutes but padded it with 4.5 for the duration where your wattage was zero.

My device does not calculate Ws, only the instantaneous W usage, from what I know. It’s this device/component for reference: Peacefair PZEM-004T Energy Monitor — ESPHome

Well, if I understood right, what do I need to provide?

Well, then we could say that the trapezoidal isn’t that great for energy measure, from what I’ve experienced. A lot of people probably use it unknowingly and wonder why it isn’t that accurate.

It’s called “pzem_004t_boiler_v3_power”.
I now use:

  - platform: integration
    source: sensor.pzem_004t_boiler_v3_power
    name: consumo_boiler_usado
    unit_prefix: k
    round: 2
    method: left

But feel free to give any name to it

Well it would be accurate if you don’t have perfectly square waves like you have. If you have gradual changes and low sloping curves, trapezoidal would be more accurate. So it really depends on the application.

Personally, I’m glad I revisited these calculations. It helped me get back into estimating area under curves and the benefits/drawbacks.

Well, considering this, “trapezoidal” is probably more apropriate/accurate on devices which never reach zero when they’re off (a single device which always consumes something in standby or entire phases). “left” is more apropriate/accurate on single devices which switch completely on or off, where the “off” state consumes zero, which would be my case.

Am I correct?

Thank you for your help!

1 Like

Yeah, that’s a good summary.

Then I understood it!

I think this should be in the docs.

If you still want to do the calculations, you absolutely can! I’ll integrate both into my HA setup and report back on the differences of “left” and yours. Might be interesting to see. :slight_smile:

Okay,
I know it’s a power (Watt) sensor, that’s the whole point of my argument about integrating it’s value, but we can derive energy from it, as we KNOW the time period over which it’s giving us information.

So I’m not 100% sure that this config is perfect, I hope @petro and @tom_l will jump in to correct any mistakes I make; but here goes.
Create at least 2 input number’s similar to the below (do NOT repeat the input_number: header if you already have one set UNLESS you use packages, if in doubt - ask ! )
So lets assume the heater is on 8 hours a day for 31 days (that should be WAY overkill) = 744 (round up to 750)

input_number:
  in_utility_water_heater_wh_month:
    name: Water Heater Wh Month
    #initial: 0
    min: 0
    max: 750000
    step: 0.1
    mode: box
    icon: mdi:flash
  in_utility_water_heater_kwh_year:
    name: Water Heater kWh Year
    #initial: 0
    min: 0
    max: 9000
    step: 0.001
    mode: box
    icon: mdi:flash

This input number will carry across reboots and it will just keep increasing over time, so I’ve set the max value to be 0.75MWh, which should be fine. So this is to be used as a temporary (monthly) watt hour store (step value is set low to improve accuracy - and we’ll convert that to kWh in a mo)

Then we need an auotmation to run every 3 seconds (equal to your sensor update and it doesn’t matter where in it’s cycle)
It then reads the value, divides by 1200 (cos it is averaging over 3 secs not 1 sec (so 1/3 of 3600) and that gives us Wh added over the last 3 secs) So 3000 / 1200 = 2.5 Wh added (as an example)
It would be better to do ALL the calculations in Watts for accuracy but asking an input number to store 9,000,000 is iffy (petro, please correct me, what are the limits on input numbers ? I’ve never seen that in the docs ???)
So (continuing the example) 2.5 Wh times 20 samples a minute times 60 minutes an hour = 3000 Wh (the number we started with, IF the heater were ON that whole period, but now in different units and moderated by the actual sensor reading)

The automation uses time pattern (again syntax may be off as the docs don’t mention * but I’ve seen it used) (thinking about it ‘/3’ would work just as well) : -

automation:
  ## 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_water_heater_wh_month
          value: "{{ (states('input_number.in_utility_water_heater_wh_month') | float) + (states('sensor.pzem_004t_boiler_v3_power') | float) / 1200 }}"

Again be careful not to duplicate the automation: header.

This should give you an incrementing Wh meter from which you can create a sensor to display kWh
This should also be periodically added to the kWh (but divide it by 1000) (AND resetting this one as you don’t want to count values twice !)

It’s bound NOT to work first time; but I’ll keep my fingers crossed :roll_eyes:

Edit: sorry forgot to add that this passed config check but I can’t test (in anger) as I don’t have a similar entity

1 Like

as opposed to a good wintery ??? :rofl:

1 Like

phone auto correct and laziness :wink:

Sorry, just being nit picking but the value has dimensions of ‘watts * time’ not ‘watts / time’

Is your goal to annoy people? Just wondering.

Genuinely not.
Dimensions were central to my argument as I had to go back through my hazy recollections to argue this from first principles.
If for example I said that the correct way to read a value and add 1, was : -
“{{ // read // sensor.madeupsensor + 1}}”
I would ‘hope’ someone would step in and correct me :blush:
I just don’t like things in print that are wrong. (edit : and from what I’ve seen, you don’t either)
I know exactly what you mean about auto correct but it’s a price you pay for predictive text. I have often fallen victim.
I also know about laziness, I value my laziness as its a contributing factor for me to get the job done right (it may take me 10 attempts but that’s better than 20 - I’m also OCD)
But my point here was that this was central to my proof

Sorry if I have offended you, that was not my intent and I still (as many of my posts attest) think you one of the top 3 4 (I’ve just thought of the other guy I rate) templaters on this forum (you know who the others are)
I aspire (but won’t get there) to be on your level

As you have also seen, I don’t blow smoke either, when you’re wrong you’re wrong (same for me, so feel free to argue. A man who can’t argue is generally bullshi77ing. AND (if the above works) it’s only because the ‘discussions’ with both you and Tom clarified my arguments and rationalised a potential solution) :man_shrugging:

BTW, I’m not gonna get credit for any solution here. The win is just to get ‘a’ solution

2 Likes

Thank you for the like :blush:

Just to add that I like to go ‘vanilla’ as much as possible and within that templates are my current favourite sandbox to play in. The top 7 or so templaters also happen to be really nice guys whose sense of humor comes through, though sometimes far too infrequently. And they’ll help ‘Anyone’ without condescension (well at least the first 10 times of making the same point :rofl: )

This kinda makes up for the fact that the number 8 guy is a complete “t vv a t”

I bet you know who that is too. :stuck_out_tongue_winking_eye:

1 Like

So Valentino,
You should have enough information now to give us some feedback.
What are you getting ?

On tenter hooks here ! (means I can’t wait ! ) :smiley:

Yes, I’ve implemented your code on that same day, but it got 0.00 so far.

# Automation "on"
last_triggered: null
friendly_name: au_utility_water_heater_kwh_update

Something isn’t working.

You guessed it ahaha

But thanks for trying!

The daily sensor, however, is working fine now since I’ve changed it to “left”!

That was not what I expected, the numbers ‘may’ not be what I expected but you should get something - not 0.0
Can you post the full automation as you have implemented it ?
Confirm that you did create the input_numbers ?
Did you try changing the seconds to ‘/3’ ?

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 }}"

image

#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


I’m absolutely sure!

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!

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

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