I tried both the Utility_Meter and the Integration Sensor components but neither are solutions.

The Utility_Meter adds up energy “pulses”. I uses energy sensors as input, not real time power as is stated in this posting.

The Integration Sensor does not have a reset service to reset the integration value after an hour.
I have requested this feature is this posting.

My power sensor changes when the power changes but not periodic so the Statistics Sensor won’t work either. The Integration Sensor would be ideal if it only had a reset.

I’m back to explain why the Integration Sensor to Utility_Meter flow has issues.
I created a test power waveform and fed that to the Integration Sensor to Utility_Meter flow
and my own python script.
My power waveform was simple so that I could do my own integration calculation
for the known good result.

minute/power
0 / 0
20 / 10
30 / 30
40 / 5
50 / 0

I hope you agree the known good result is 7.5 kWh

Here are the test results:
Integration Sensor to Utility_Meter flow: 8.463 kWh, error = 12.8%
Custom Python Script: 7.5113 kWh, error = 0.15%

Clearly, there are issues with the Integration Sensor to Utility_Meter flow.

The integration sensor output never resets. This does not seem to bother the Utility_Meter
but I wonder if there is a floating point overflow or loss of accuracy when subtracting large floating point numbers.

The hourly sensor output from the Utility_Meter changes throughout the hour. You would expect it to change on the hour. It resets to zero on the hour so you would need a automation to sample the hourly sensor output one second before each new hour.

Now here is the big reason why I don’t like the Integration Sensor to Utility_Meter flow.
The Integration Sensor uses Trapezoidal rule for integration! While this is OK for continuously variable power sources it adds energy that does not exist for pulsating or staircase power waveforms.
This is why the above testcase error is plus 12.8% It is adding triangles of energy between the staircase power levels.
My power source is my gas furnace which ramps up the burners in three discrete steps until the temperature set point is satisfied. Another example could be a baseboard heater which pulses ON and OFF.

For those who want a more accurate flow, I provide this link to my python script. The installation instructions are provided in the file header. Feedback Welcome.

I don’t agree it’s 7.5 kWh… by my calculation it’s 8.33 kWh (It’s only 7.5 if you apply the “Left Riemann Sum” method)

You are applying the “Left Riemann Sum” method while the integration sensor is applying the “Trapezoidal Riemann Sum”. As you pointed out in your point 3!

We can discuss on the virtues of both methods, but HA documentation clearly states what the integration sensor is about, which method it uses. You have a good explanation in wikipedia https://en.wikipedia.org/wiki/Riemann_sum of the various methods and since this is a GENERIC integration sensor, it makes much more sense to use the Trapezoidal method.

Going back to your points

Utility_meter will sum the variances of the source sensor, so it is not much bothered if a reset occurs (it will discard negative variances, that occur when a reset happens). In what respects to floating point overflow, it is using python Decimal class to avoid those issues, but there are always rouding errors.

You have an attribute in the utility_meter sensor last_period so you don’t need any automation. Furthermore it continuously updates providing up to date consumption values (based on the variances of the source sensor)

The integration sensor can always be improved with a configuration option to indicate which method to use (Left, Right, Middle, Trapezoidal)

The ‘real world’ correct answer is the “Left Riemann Sum” of 7.5 kWh for my type of power source so I will continue to use my custom python script. I will put in a feature request to add the “Left Riemann Sum” to the integration sensor.

On point 2.
Unfortunately, the last_period utility_meter sensor attribute is not documented. I don’t believe you can graph an attribute so you would have to add a template sensor to extract the attribute for graphing.

Here is an example template sensor used to graph energy use with an update only every hour.
“sensor.furnace_hourly” is from the utility_meter component.

There is a testcase for which the Integration Sensor to Utility_Meter flow that will produce an incorrect result even if the Integration Sensor uses the “Left Riemann Sum” method.

Consider this power waveform with a period of 2 hours:
minute/power
0 / 0
30 / 1
90 / 0
Basically, a square wave crossing the hour boundary.

The correct result should be 0.5 kWh every hour period.
I suspect that the improved Integration Sensor to Utility_Meter flow would produce an
alternating sequence of 0 kWh then 1.0 kWh which is not, strictly correct.

Maybe a better thing to do would to request a power input option to the Utility Meter component which considers time boundaries. My python script works for this testcase.

Again… this is not the way the integration sensor works, or is supposed to!

The integration sensor doesn’t care what happens at 60 min, because nothin happened at that time. All calculations will occur at the time the sensor changes (30 and 90). It will account correctly 1kWh.
There is no 0.5kWh at 60min because at that time there is nothing happening! Integration is done from state_change to state_change, there is no clock involved.

I’m currently measuring pulses each time a watt is used. Using a counter, each time a pulse is send, I add one to the counter.

Am I correct to assume that I can use the value of the counter (which I think is in fact the total amount of kWh since I started counting) to the utility meter? Or do I make false assumptions?

@rdehuyss I am also reading pulses (in my case light blinks from energy meter from provider).
1 blink is 1/6400kWh (as stated on meter case)
I am using photodiode and ESP8266. Calculation from pulses to kWh is done on ESP - number of pulses * (1/6400).
Via MQTT sesnor I am getting value in kWh which is passed to utility meter.
I think you can also do this calculation on HA side via templating

In different solution (Sonoff POW R2) I don’t know what is pulse to kWh ratio but I have power in W (watts).
So I am using Integration Sesnor to get total power usage in kWh - same unit as my proviser chares me

Hi Diogo, I am using the integration sensor but I am having some issues with it sometimes showing NaN, I have triple checked that when I am summing all the sensor data containing my watt readings and they are numbers, as in they are displaying numbers. Any idea on what I can check to sort this out.

For Utility Meter, this is a great tool works perfect for my monthly readings, I would like to do Yesterday, is there a way this can be added?
Thanks
Dave

Some sources don’t provide “proper numbers”, they just provide a string which happens to contain a number… One way to fix that is to use an intermediate sensor template that casts the “string value” into an actual number.

Each utility_meter sensor has an extra attribute called last_period, so if your meter_period is daily then last_period will be “yesterday”. You can use a sensor template to pull the attribute into the frontend directly.

Thanks for responding, much appreciated. I will try the last period now. Thanks for that!
For casting a string I thought I am already doing that. See my code below.

Hi, I still can’t get this working, I keep checking the longs NaN ver shows up in the logs on ESPHome and when I check the watts value it is always returning a float, so I am out of ideas why the integration sensor is returning NaN.

Any thing you can help me with? Thanks in advance.

Integrate each sensor separately, see if that works.

I don’t know if the integration sensor has to be running for at least one unit_time. But if it does you can try to add this to see if you get some values right away: