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.
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.
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).
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.
I suggest you add the availability option to your Template Sensor.
availability: "{{ states('sensor.second_bathroom_shower_in_use_count') not in ['unavailable', 'unknown'] }}"
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}}"
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?
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] }}"
?
In that case, I suggest this:
availability: "{{ states('sensor.second_bathroom_shower_in_use_count') | int(0) != 0 }}"
Perfect, many thanks for your time!
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.
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).
Senior citizen - my bad.
No worries and thanks for taking the time to make the change.
Sorry to reawaken the thread but I landed here with a very similar question
I want to track how long my hot water is on each day
I’ve created the History Stats sensor
#Track Hot Water History
- platform: history_stats
name: Hot Water ON today
entity_id: sensor.hot_water
state: "On"
type: time
start: "{{ now().replace(hour=0, minute=0, second=0) }}"
end: "{{ now() }}"
Now, I may be misunderstanding this, but that reads to me that it will only give me the time today from midnight until now…
And having only just set it up it seems this is what it’s doing, since it has no data for past days:
This is fine, but what I really want to do is track the total for a 24hr period and have that stored day after day (in the standard history) so that I can see that today it was on for 3 hours, yesterday 2 hours etc
I’m guessing that if I used
start: "{{ 0 }}"
end: "{{ now() }}"
It would simply give me the sum total from all time, which isn’t what i want either
Can anyone advise how I can do this daily?
I actually found a way to do this after posting which I wasn’t sure would work but have just found that it does… Frustratingly can’t find the post to link it now, but basically;
I created an apex graph card which does the tracking with the existing sensor
(code below)
type: custom:apexcharts-card
apex_config:
chart:
height: 140%
dataLabels:
background:
enabled: false
style:
colors:
- var(--primary-text-color)
graph_span: 1w
span:
end: day
header:
show: true
title: Daily Hot Water (Time On)
experimental:
color_threshold: true
yaxis:
- id: left
min: ~0
apex_config:
forceNiceScale: true
series:
- entity: sensor.hot_water_daily_on
type: column
yaxis_id: left
float_precision: 2
show:
datalabels: true
group_by:
func: last
duration: 1d
color_threshold:
- color: '#e45e65'
value: 4.5
- color: '#e0b400'
value: 3
- color: '#0da035'
value: 1.5
- color: '#039BE5'
value: 0
card_mod:
class: top-level-chart
That’s fine as long as you don’t want more than about 10 days of history. Recorder’s default storage duration for the state history of all entities is 10 days (older data is discarded).
What I proposed stores data in a separate table within the database that is not purged and can accumulate indefinitely.
Oh that’s interesting - I had been looking (for other things) to get data older than 10 days (for this I actually don’t think I mind… tho may later!)
Is it because a Utility Meter sensor has a special status? Any harm in whacking other things into that?
Long term statistics are stored in a table within the database that isn’t periodically purged. The data in this table is collected from entities that meet the criteria explained in the following documentation:
Long term Statistics
Entities produced by the Utility Meter integration meet the criteria.