Utility Meter total_increasing not working as expected

Configuration
1

Created a Utility Meter sensor to count all the received seconds from a sensor and show a daily summary.
Source sensor (ttn_gate_02_richard_airtime) delivers a float like 0.061696 every 15 min
the utility meter sensor (ttn_gate_2_richard_totalairtime) should count these up where I am expecting that 0.06xxx would roughly be like this
0.06xx
0.12xx
0.18xx
0.24xx
with the graph, it only increases with 0.01 on every update end ending at around 0.20 after 24h.

The airtime comes in through MQTT in Node-Red and is then delivered to a sensor in HA using the NodeRed HA integration. The JSON string used to get all the relevant data out where I convert the string “0.061696” to 0.061696. I also tried to leave it as a string, both options give the same result.

What am I doing wrong?

Source Sensor:

image
image896Ă—366 40.1 KB

Utility Meter Sensor:

image
image1002Ă—350 66.3 KB

NodeRed update for the Source Sensor
image

NodeRed created HA sensor:
image

2

The utility meter does not sum the readings from a sensor. It sums the difference from the last reading. i.e. if you have a sensor that counted up from 0 to 100 in 24 hours the utility meter will read 100 after 24 hours, not 0+1+2+3+4+5+6+7+…99+100.

3

Ah, ok. That explains it.
What would be the best way to create something that does this?
(could you point me in the right direction?)

another user recommended the Utility Meter as a suggestion for my question.

4

I tried to create a dummy template sensor without a value, so it can be updated by an automation.
Somehow it can’t seem to create such a sensor. It fails on "state: {{ }} " or “value_template: {{ }}”
( or {{ ’ ’ }} )

Through NodeRed a can register a new sensor and then use that with HA, seems a bit like a de-tour to get a sensor that counts its own value together with a just received value from another sensor.

5

You could create a template sensor like this in your configuration.yaml file:

template:
  - sensor:
      - name: "Running Total"
        unit_of_measurement: "seconds"
        state: "{{ states('sensor.running_total') | float(0) + states('sensor.ttn_gate_02_richard_airtime') | float(0)  }}"

Then if you want a daily total, feed sensor.running_total to a utility meter with a daily cycle.

6

Thanks for the help, learned something today!

I tried something like that and I keep getting red-lines in the VS Code addon, guess I did something wrong there. Your format works.

7

That seems strange.

I would think that with a name like “utility meter” you should be able to create an entity that works just like your utility meter at your house.

To clarify…

An electrical meter for your house (the prototypical “utility meter” that everyone thinks of when thinking of that concept) measures the continuous power draw of the electrical loads of your house and adds it up over time providing you with the total power used that day.

Like in the OP’s case every update of the airtime sensor should add more airtime to the meter just like every update of my electricity usage adds more power to my electrical meter.

But you are saying that the HA utility meter doesn’t work like that.

it seems you are saying that the HA utility meter just provides a way for you to monitor some other already existing utility meter that you can draw data from.

I actually thought about creating a test utility meter to see how it functions by using an existing energy sensor (sensor.stove_hood_light_power) and then realized based on the docs and what you wrote above it wouldn’t work as expected.

But then I realized I have another sensor that provides the total energy for that bulb (sensor.stove_hood_light_energy_total) that I could use to create the utility meter from.

But then I realized again that the way the utility meter was described those two sensors should be exactly the same if I never reset the utility meter sensor.

so it’s not really a “utility meter” in the usual usage of the term. it’s more like a periodically self-resetting history stats sensor? but history stats can also be self-reset based on the time frame selected.

:thinking:

Then why have a utility meter integration if the functionality is the same?

Sorry, I’m just trying to wrap my head around what the utility meter integration actually does.

8

If you have a device like an energy meter that keeps counting up forever the utility meter allows you to create other meters to count daily, hourly, monthly, etc… totals from this.

It does not integrate power to get energy use. That’s what the the Riemann Sum sensor is for.

The name confused me at first too.

9

But again, isn’t that what the history stats sensor can do as well?

is there a difference I’m missing?

10

The history stats sensor will only go back as far as your recorder purge keep days. It also only has these types of tracking:

  • time: The default value, which is the tracked time, in hours
  • ratio: The tracked time divided by the length of your period, as a percentage
  • count: How many times the tracked entity matched the configured state during the time period

None of those will track how much energy you used.

1 Like
11

Ah, yep, you’re right.

I thought I remembered that it could track states as well.

12

Hi,
For anyone coming across this thread I think the issue can now be resolved in configuration by setting delta_values: true for the utility meter. This should avoid have a separate summation sensor.

Taken from Utility Meter - Home Assistant

For example, you should enable this when the source sensor returns readings like “1”, “0.5”, “0.75” versus “1”, “1.5”, “2.25”.

I realised my rainfall hourly / daily / weekly utility meter sensors were just taking the difference from the previous reading, if positive, and not (as I had assumed) just accumulating each value.

1 Like
13

Actually this doesn’t fully work.
If two sequential readings are the same then the utility meter will not increase.
E.g. two readings in a row of 0.3, 0.3 gives utility count of 0.3 - not 0.6 as expected.

However this would work: 0.3, 0, 0.3 = 0.6 as expected.

I am sure there is a way around this by setting the input value back to 0 after each reading however that is very similar to already having the incrementing sensor.

Edit: Rather than over complicating things I have added an automation that sets the value back to 0 after 2 minutes (the update interval is 15mins)

1 Like
14

Can you share me configuration…

I am strugling with my water tank water consumption…

What is then correct configuration / automation…

Thank you for replying…

15

I quite crudly use this automation:

alias: "[Weather Station] Reset RainTips after 2 minutes"
description: >-
  Reset rain tips back to 0 after a value is sent to allow next value to be
  counted if it is the same as the previous value
trigger:
  - platform: numeric_state
    entity_id: sensor.raintips
    for:
      hours: 0
      minutes: 2
      seconds: 0
    above: 1
condition: []
action:
  - service: mqtt.publish
    data:
      topic: home/Weather/Data
      payload: "{  \"rainTips\": 0 }"
mode: single

It just reset the number of tips of my tipping bucket rain meter 2 mins after each update (it sends an update every 15mins)

I have a rainfall sensor that coverts the number of tips to mm and then this is the utility meter:

utility_meter:                         
  hourly_rainfall:                              
    source: sensor.rainfall                                   
    cycle: hourly                         
    delta_values: true               
  daily_rainfall:      
    source: sensor.rainfall     
    cycle: daily           
    delta_values: true
1 Like