Save daily counter helper value

Configuration
1

I would like to keep track of how many times each day the boiler gets a call for heat.

Specifically, when either of these two binary sensors turn to a state of ON:

binary_sensor.125_1st_fl_heat_graph_binary
binary_sensor.125_2nd_fl_heat_graph_binary

I have this automation enabled:

alias: 125 boiler call for heat
description: ""
trigger:
  - platform: state
    entity_id:
      - binary_sensor.125_1st_fl_heat_graph_binary
      - binary_sensor.125_2nd_fl_heat_graph_binary
    to: "on"
condition: []
action:
  - service: counter.increment
    metadata: {}
    data: {}
    target:
      entity_id: counter.how_many_ons_125_boiler
mode: single

I am using this counter helper to count the number of ON changes:

image
image480×812 26.5 KB

I have the counter reset at mightnight every day with this automation:


alias: Reset 125 boiler on counter at mignight
trigger:
  - platform: time
    at: '00:00:00'
condition:
  - condition: time
    after: '00:00:00'
    weekday:
      - mon
action:
  - service: counter.reset
    target:
      entity_id:
        - counter.how_many_ons_125_boiler

Can someone show me a way to retain the daily count so I can look back and graph the daily count?

Thank you.

2

I’d create a number helper (maybe call it daily boiler ons). then add an action to the reset script before the actual reset that sets that input helper to the counter value. The only someone tricky part is that you can’t set a number helper to another state in the GUI. You have to use the YAML editor. It would look something like this:

  - service: input_number.set_value
    data:
      value: "{{ states('counter.how_many_ons_125_boiler') | int(0) }}"
    target:
      entity_id: input_number.daily_boiler_ons
  - service: counter.reset
    target:
      entity_id:
        - counter.how_many_ons_125_boiler
3

Thank you very much but I am lost.

I’ve never used a number helper.

I don’t understand where “states(counter.how_many_ons_125_boiler)” comes from.

I think the code takes that value and assigns it to the variable “daily_boiler_ons” – is that right?

Seems the more I learn about HA, the more I discover how much more I don’t know. (And the amount I don’t know if growing much faster than the amount I know.)

4

This tells HA to get the value of the counter you created and convert it to an integer. I copied the name right from the YAML you provided of the counter. So yes, the YAML I posted would assign the value of counter.how_many_ons_125_boiler to input_number.daily_boiler_ons right before the script resets the counter.

Note that I made a small update to the YAML I posted, as I didn’t have the name of the entity enclosed in single quotes in my example, so it wouldn’t work if you copy and paste it. I fixed that.

5

I suggest using the History Stats integration to do that. Then use the History Stats sensor with the Utility Meter integration to keep track of daily/weekly/monthly/yearly data.

The data produced by the Utility Meter integration is stored in a database table that’s never purged (unlike other data that’s purged, by default, after 10 days).

6

@pkscout:

I am trying to move away from creating things in configuration.yaml in accordance with HA’s current guidelines.

It helps that I don’t really understand how using a number helper works.

@123:

I am so confused.

I tried to create a Utility Meter but I could not set the Input Sensor to a binary_sensor.

I have these binary_sensors (binary_sensor.125_1st_fl_heat_graph_binary and binary_sensor.125_2nd_fl_heat_graph_binary) that are created by templates such as:

      - name: 125 1st Fl Heat Graph Binary
        state: "{{ is_state_attr('climate.125_1st_floor', 'hvac_action','heating') }}"

So that is where the ON state comes from.

Is my idea of using a counter helper incremented by an automation trigged by either binary_sensor changing its state to ON an okay idea?

And then reset with another automation at 00:00:00 each day okay?

Or should I start from scratch to count and keep track of how many ON states the boiler gets in a day?

7

There’s no such “guideline”. If you only want to use integrations that are configured via the UI, you’ll lose access to a lot of useful integrations.

Instead of a History Stats sensor, you can create a Trigger-based Template Sensor that counts the number of times either of the two binary_sensors turns on (and resets the count at midnight). However, that also requires configuring it in YAML. :man_shrugging:t3:

If you refer to its documentation, it’s designed to work with a sensor.

8

Here’s a Trigger-based Template Sensor that counts the number of times either of the two boiler binary_sensors changes state from off to on. It resets the count at midnight.

template: 
  - trigger:
      - platform: time
        at: '00:00:00'
    - platform: state
      entity_id:
        - binary_sensor.125_1st_fl_heat_graph_binary
        - binary_sensor.125_2nd_fl_heat_graph_binary
      from: 'off'
      to: "on"
    sensor:
      - name: 'Boiler Count Today'
        state: "{{ this.state | default(0, true) | int(0) + 1 if trigger.platform == 'state' else 0 }}"
        attributes:
          count_updated: "{{ now() | as_local }}"

Here’s the configuration for the Utility Meter integration to create sensors that report daily/weekly/monthly/yearly counts.

utility_meter:
  boiler_count_daily:
    source: sensor.boiler_count_today
    name: Boiler Count Daily 
    cycle: daily
  boiler_count_weekly:
    source: sensor.boiler_count_today
    name: Boiler Count Weekly
    cycle: weekly
  boiler_count_monthly:
    source: sensor.boiler_count_today
    name: Boiler Count Monthly
    cycle: monthly
  boiler_count_yearly:
    source: sensor.boiler_count_today
    name: Boiler Count Yearly
    cycle: yearly

EDIT

Correction. Add int(0) to the calculation.

9

In another thread where I am the OP, and in so many other threads, there are discussions of how the HA developers are moving away from configuration.yaml towards doing everything in the UI. This is partially evidenced by the new features (Helpers, for example) that, when created in the UI do not create an entry in configuration.yaml. That’s where I got the “guidelines” thinking.

But, I am glad to hear my understand is not correct.

As much as I am overhwhelmed by configuration.yaml, when I do learn how to accomplish something with configuration.yaml, I do really like the power of it.

10

There is a very easy and user friendly way to achieve what is asked above …is to use the measureit component, does almost everthing what you need in the UI.

1 Like
11

That’s a guideline meant for integration developers. It’s not meant to discourage people from using existing integrations that are configured via YAML.

If you have the time, I suggest you try the examples I posted above.

12

This is clearly an elegant solution.

But, this…

        state: "{{ this.state | default(0, true) + 1 if trigger.platform == 'state' else 0 }}"
        attributes:
          count_updated: "{{ now() | as_local }}"

I am trying to decipher (reverse engineer?) how it works.

Really advanced stuff. No idea how these work:

this.state with a pipe to default(0, true)
trigger.platform == ‘state’
count_update: "{{ now() | as_local }}

13

MeasureIT looks very interesting.

Will try it out.

14

Been fighting through using MeasureIT and can’t get it work for me.

This so incredibly frustrating.

15

I set this up and I don’t know if it’s working. So far, 125_boiler_count_today has a value of “unknown” despite the binary sensors changing to ON.

When I put this code into the Developer Tools | Template tester, it results in the error: "’ ‘trigger’ is undefined "

template:
  - trigger:
      - platform: time
        at: '00:00:00'
      - platform: state
        entity_id:
          - binary_sensor.125_1st_fl_heat_graph_binary
          - binary_sensor.125_2nd_fl_heat_graph_binary
        from: 'off'
        to: "on"
    sensor:
      - name: '125 Boiler Count Today'
        state: "{{ this.state | default(0, true) + 1 if trigger.platform == 'state' else 0 }}"
        attributes:
          count_updated: "{{ now() | as_local }}"
16

That’s not a good sign. If it reports unknown it implies it hasn’t been triggered yet.

It’s using the same State Trigger you have in your automation with one small difference.

  • It triggers only when the binary_sensor’s state changes from off to on.
  • Your version of the State Trigger detects a state-change from anything (off, unavailable, unknown) to on.
    However that small difference shouldn’t prevent the State Trigger from working in this situation.

I’m assuming you executed Developer Tools > YAML > Reload Template Entities after you created the Trigger-based Template Sensor (you must have, otherwise sensor.125_boiler_count_today wouldn’t exist).

Check the Log for any related errors.

You can’t use the Template Editor to test a template that references the trigger variable. That variable doesn’t exist outside of the Trigger-based Template Sensor. The same applies to the this variable.

17

Found this in the log:

Logger: homeassistant.helpers.sensor
Source: helpers/trigger_template_entity.py:208
First occurred: 6:52:12 PM (5 occurrences)
Last logged: 9:28:13 PM

Error rendering state template for sensor.125_boiler_count_today: TypeError: can only concatenate str (not "int") to str
18

Thanks, that helped me find the mistake I made in the template.

I have corrected the original example posted above. The correction simply requires adding int(0) to the template as shown here:

        state: "{{ this.state | default(0, true) | int(0) + 1 if trigger.platform == 'state' else 0 }}"
19

That did it!

Thank you.

1 Like
20

You’re welcome!

Thank you for the coffee.