Get the total time a input boolean was turned on and the average by dividing with a counter number

Configuration
1

Hi all,
I am using 2 input booleans which i turn on when a shower or bath is taken. I also increase a counter every time a shower is taken.

I can see them on the history graph, i would like to get the total runtime these booleans were on and i was also hoping to get the average by dividing with the counter.

Any way of doing this other then starting timers (i think that would get complicated quickly) ?

2

I suggest you consider using History Stats for runtime.

You may need to use a Template Sensor to compute the average or just a Statistics sensor.

3

Thanks Taras. I will look into those. Do you know if i could use input_boolean entity with the statistics sensor?

4

Yes. If you want a History Stats sensor to track when an input_boolean is on just set the state option’s value to on.

1 Like
5

Ah yes of course. I sort of assume that by being able to see a history graph of the input boolean already i wouldn’t need to setup another history_stats sensor. But maybe that’s not a history graph ?

6

An entity’s History graph simply shows you the entity’s recorded values (i.e. the values stored in the database). A History Stats sensor can perform calculations with the entity’s recorded values and report the result.

1 Like
8

So i added this in my template.yaml:

 # First Bathroom Shower Use On Time Average
  - sensor:
      - name: "First Bathroom Shower In Use On Time Average"
        state_class: measurement
        unique_id: First Bathroom Shower In Use On Time Average
        state: >-
          {{ sensor.first_bathroom_shower_in_use_on_time / sensor.first_bathroom_shower_in_use_on_time_count }}

Question: Can i not do simple division/multiplication/adding/subtracting in a lovelace card and do it on the spot ? Creating a sensor seems like a lot of work for simple operations like this. Probably don’t understand fully.

9

This template is invalid.

{{ sensor.first_bathroom_shower_in_use_on_time / sensor.first_bathroom_shower_in_use_on_time_count }}

It’s not the correct way of referencing an entity’s state value. I suggest you review the Templating section of the documentation, specifically this part: States.

Here’s the corrected version:

{{ states('sensor.first_bathroom_shower_in_use_on_time') | int(0) / states('sensor.first_bathroom_shower_in_use_on_time_count') | int(0) }}

Home Assistant’s standard cards don’t support templates, which are needed for performing calculations (the sole exception is the Markdown card). Custom cards may support templating but I can’t comment on which ones do/don’t.

10

Home Assistant’s standard cards don’t support templates, which are needed for performing calculations (the sole exception is the Markdown card). Custom cards may support templating but I can’t comment on which ones do/don’t.

Understood, makes sense. Still seems a lot of work/overhead to create sensors for the more simple maths like division/subtraction etc.

11

That means the divisor value is zero.

Copy-paste the following into the Template Editor and let me know what it reports:

{{ states('sensor.first_bathroom_shower_in_use_on_time') }}
{{ states('sensor.first_bathroom_shower_in_use_on_time_count') }}

You’re free to find a custom card that will do what you want.

12

I just edited my post, as one of the values did actually hold unknown. I tested this now and it works:

# Second Bathroom Shower In Use On Time Average
  - sensor:
      - name: "Second Bathroom Shower In Use On Time Average"
        unique_id: Second Bathroom Shower In Use On Time Average
        state: >-
          {{ states('sensor.second_bathroom_shower_in_use_on_time') | float(0) / states('sensor.second_bathroom_shower_in_use_count') | float(0) }}

I am however running into a problem with the sensor if it hasn’t recorded anything yet and the value is unknown, and divides by zero. Maybe some sort of availability sensor is the most elegant way here. Or even just setting a default value for a sensor (a history_stats platform in this case).

13

In that case, the int(0) filter substitutes the value 0 and that’s probably why it produced a divide-by-zero error. Your template should be designed to guard against receiving unknown and unavailable values. Typically filters like int and float guard against it because they can be configured to supply a default value (in this example the default is zero). However when used in a calculation, a default value of zero for a divisor will, of course, cause an arithmetic error.

1 Like
14

I suggest you add the availability option to your Template Sensor.

availability: "{{ states('sensor.second_bathroom_shower_in_use_count') not in ['unavailable', 'unknown'] }}"
15

I did this to test for both sensors, does 0 cover unavailable and unknown statuses as well ?

availability_template: "{{ states('sensor.second_bathroom_shower_in_use_on_time')|float(0) or states('sensor.second_bathroom_shower_in_use_count')|float(0) != 0}}"

16

No, it won’t.

The template you posted is invalid (logic error) and the option’s name is incorrect for a Template Sensor defined in modern format.

I suggest you try what I suggested in my previous post. The only reason it may need to be enhanced is if the value of sensor.second_bathroom_shower_in_use_count can be zero under normal circumstances. In other words, a count of zero is a nominal value. Is that a possibility?

17

Yes i realised i used the old availability_template instead of the availability: one as suggested.

Hmm well the sensors i created for count and average seem to be 0 or 0.0 (float) if nothing has been recorded yet.

Could i do :

availability: "{{ states('sensor.second_bathroom_shower_in_use_count') not in ['unavailable', 'unknown',0,0.0] }}"

?

18

In that case, I suggest this:

availability: "{{ states('sensor.second_bathroom_shower_in_use_count') | int(0) != 0 }}"
19

Perfect, many thanks for your time!

1 Like
20

You’re welcome!

Please consider marking my post above with the Solution tag. It will automatically place a check-mark next to the topic’s title which signals to other users that this topic has been resolved. This helps users find answers to similar questions.

For more information, refer to guideline 21 in the FAQ.

21

FYI, you initially marked my post with the Solution tag, then marked your own post with the Solution tag. Only one post in the entire thread can bear the Solution tag so now it’s on your post (with the unnecessary list comparison).

It’s customary to assign it to the post that was first to suggest the solution (as explained in the FAQ).