This is a common one from threads I’ve found, and seems like there are a half dozen ways to skin it.
I have a push button helper, and a button on my dashboard. It’s setup to show time since last change (pressed). This is a momentary button. I want to have a sensor that is the amount of time since that button was pressed - to use as a reminder for replacing a furnace filter.
seems I either don’t know the notation or can’t use this type of an entities perimeter here?
- sensor:
- name: "furnace_filter_age"
unit_of_measurement: days
state: >
{{ (as_timestamp(now()) - as_timestamp(states.sensor.input_button.button_furnace_filter.last_changed))|timestamp_custom('%d') }}
The template has a couple issues.
- Input button entities are not sensors, so
sensor.input_button.button_furnace_filter
doesn’t make sense. Also their state is a datetime string of when they were last pressed. The last_changed
property is actually less reliable, since it doesn’t survive restart.
- Timestamps can be problematic for durations, use the datetime-based methods instead:
The following returns whole days only (a 32 hour difference returns 1 day):
- sensor:
- name: "furnace_filter_age"
unit_of_measurement: days
state: >
{{ (now() - states('input_button.button_furnace_filter')|as_datetime).days }}
If you want decimal days instead (a 32 hour difference returns 1.33 days), you can replace the state
template with:
{{ (now() - states('input_button.button_furnace_filter')|as_datetime).total_seconds()/86400 }}
for what it’s worth, on my smart thermostat I have it time how long the fan is running in heating or cooling since a manually entered date helper with:
sensor:
- platform: template
sensors:
hvac_run_time_total:
friendly_name: "HVAC Fan Hours"
value_template: "{{ states('sensor.furnace_fan_heating_time') | float + states('sensor.furnace_fan_cooling_time') | float }}"
unit_of_measurement: "hours"
climate_thermostat_action:
friendly_name: Thermostat Action
value_template: "{{ states.climate.thermostat.attributes.hvac_action }}"
- platform: history_stats
name: Furnace Fan Heating Time
entity_id: sensor.climate_thermostat_action
state: heating
type: time
start: "{{ as_timestamp (states('input_datetime.furnace_filter_replaced'), default=0) }}"
end: "{{ now().timestamp() }}"
- platform: history_stats
name: Furnace Fan Cooling Time
entity_id: sensor.climate_thermostat_action
state: cooling
type: time
start: "{{ as_timestamp (states('input_datetime.furnace_filter_replaced'), default=0) }}"
end: "{{ now().timestamp() }}"
Then I have in the automation and get a notification to change it at x hours running. In case this helps…
Automation:
alias: HVAC Filter Change Notification
description: ""
trigger:
- platform: numeric_state
entity_id: sensor.hvac_run_time_total
above: "400"
condition: []
action:
- service: notify.mobile_app_pixel_4a_5g
data:
title: Change Furnace Filter
message: Filter has 360 hours or more.
- service: notify.living_room_tv
data:
message: Time To Change The Furnace Filter
mode: single
you killed it thanks! Lots of nuance to the home assistant scripting
thanks, I may play with this. I have the furnace fan on nearly constantly (any time there is a temp delta across the house) but its not a bad idea to scale in based on usage rather than just arbitrary time. Interesting thoughts and excellent to have a starting point if I do it. Thanks!
Are you sure your fan time sensors are giving you accurate values? History Stats only goes as far back as the Recorder’s purge_keep_days
, which by default is 10 days. You would need to extend that to whatever the maximum number of days it takes your hvac to run 400 hours is…
These are the results I get using History Stats with a start outside the range of Recorder vs. a daily History Stats accumulated using the Utility Meter integration…
I have my recorder set at 90 days. So maybe I only get the change notification when the fan demand is high enough to hit my setpoint within that period. I guess I hadn’t thought of it. I’ve heard of utility meter but hadn’t looked into it yet. Thanks for the info.
When I get some time, I’ll have to figure out how to implement it with the manual reset. It looks like it only works on a calendar driven reset.