Hi all, I could use some help understanding unexpected behavior in an automation.
I have a system to check for dead batteries in my zwave devices using a template and an auto-entries card on the Dashboard to display them as the template renders true. That card is as follows:
type: custom:auto-entities
card:
type: entities
title: Check Batteries
show_header_toggle: true
state_color: false
filter:
template: |
{{ expand('group.battery_sensor_overdue_normal_grp')
| selectattr('last_changed', 'lt',now()-timedelta(hours=states("input_number.time_till_sensor_overdue_in") | int))
| map(attribute='entity_id') | list | join('\n')
~ expand('group.battery_sensor_overdue_extended_grp')
| selectattr('last_changed', 'lt',now()-timedelta(hours=24 | int))
| map(attribute='entity_id') | list | join('\n')
}}
show_empty: true
sort:
method: none
There are two parts to this template, one that checks against an input_number (currently set to 3 hrs) and the other set to 24 hrs. The second set of sensors are expected not to change very often, so they were separated out so I could have better resolution for those that do. The referenced groups are as follows:
battery_sensor_overdue_normal_grp:
entities:
- sensor.zooz_zse19_siren_temperature
- sensor.zooz_zse40_multi_garage_entry_temperature
- sensor.zooz_zse40_multi_garage_left_temperature
- sensor.zooz_zse40_multi_garage_right_temperature
- sensor.zooz_zse40_multi_stairs_temperature
- sensor.zooz_zse40_multi_downstairs_temperature
- sensor.zooz_zse40_multi_den_temperature
- sensor.zooz_zse40_multi_litter_box_temperature
- sensor.fibaro_eye_office_temperature
- sensor.fibaro_eye_mbr_temperature
- sensor.fibaro_eye_lr_temperature
- sensor.fibaro_eye_foyer_temperature
battery_sensor_overdue_extended_grp:
entities:
- sensor.zooz_zse29_outdoor_motion_front_luminance
- sensor.zooz_zse29_outdoor_motion_side_luminance
- sensor.sensative_strips_comfort_temperature
- sensor.zooz_zse40_multi_shed_temperature
- sensor.zooz_zse40_multi_vault_temperature
This all seems to work as expected. On a separate status page, I have an input_boolean on a button that turns red if any batteries are dead, turned on/off by an automation that uses the same template as above (except for the != "" part at the end). That automation is shown below:
# Sensor Update Overdue (Check Battery)
- id: sensor_update_overdue_atm
alias: Sensor Update Overdue (ATM)
mode: parallel
trigger:
- platform: state
entity_id: input_number.time_till_sensor_overdue_in
- platform: template
value_template: >
{{ expand('group.battery_sensor_overdue_normal_grp')
| selectattr('last_changed', 'lt',now()-timedelta(hours=states("input_number.time_till_sensor_overdue_in") | int))
| map(attribute='entity_id') | list | join('\n')
~ expand('group.battery_sensor_overdue_extended_grp')
| selectattr('last_changed', 'lt',now()-timedelta(hours=24 | int))
| map(attribute='entity_id') | list | join('\n')
!= ""
}}
action:
choose:
conditions: >
{{ expand('group.battery_sensor_overdue_normal_grp')
| selectattr('last_changed', 'lt',now()-timedelta(hours=states("input_number.time_till_sensor_overdue_in") | int))
| map(attribute='entity_id') | list | join('\n')
~ expand('group.battery_sensor_overdue_extended_grp')
| selectattr('last_changed', 'lt',now()-timedelta(hours=24 | int))
| map(attribute='entity_id') | list | join('\n')
!= ""
}}
sequence:
service: homeassistant.turn_on
data:
entity_id: input_boolean.sensor_update_overdue_ib
default:
service: homeassistant.turn_off
data:
entity_id: input_boolean.sensor_update_overdue_ib
When I test this by varying the input_number up and down, both the auto-entities card AND the input_boolean work as expected, both in sync.
However, I’ve noticed that sometimes the input_boolean is on (turned on by the automation) but the auto-entities card is blank. It is currently in that state, and I’m not really understanding what the Changed Variables section is telling me in the Automation Debugger for the Trigger, shown below:
this:
entity_id: automation.sensor_update_overdue_atm
state: 'on'
attributes:
last_triggered: '2022-04-24T13:28:00.019197+00:00'
mode: parallel
current: 0
max: 10
id: sensor_update_overdue_atm
friendly_name: Sensor Update Overdue (ATM)
last_changed: '2022-04-22T18:53:37.159943+00:00'
last_updated: '2022-04-24T13:28:00.044581+00:00'
context:
id: 6e7efe5425d00141d695667f3db33eb1
parent_id: null
user_id: null
trigger:
platform: template
entity_id: sensor.zooz_zse40_multi_stairs_temperature
from_state:
entity_id: sensor.zooz_zse40_multi_stairs_temperature
state: '64.71'
attributes:
state_class: measurement
unit_of_measurement: °F
device_class: temperature
friendly_name: Zooz ZSE40 Multi Temperature (Stairs)
last_changed: '2022-04-24T17:11:41.271659+00:00'
last_updated: '2022-04-24T17:11:41.271659+00:00'
context:
id: 1cdccd7e07a69a778e37bc72bab559a8
parent_id: null
user_id: null
to_state:
entity_id: sensor.zooz_zse40_multi_stairs_temperature
state: '64.73'
attributes:
state_class: measurement
unit_of_measurement: °F
device_class: temperature
friendly_name: Zooz ZSE40 Multi Temperature (Stairs)
last_changed: '2022-04-24T17:39:56.790414+00:00'
last_updated: '2022-04-24T17:39:56.790414+00:00'
context:
id: f60b151a7021c04600326dedc00a6f29
parent_id: null
user_id: null
id: '1'
idx: '1'
for: null
description: sensor.zooz_zse40_multi_stairs_temperature via template
Below is the relevant history for that sensor around the times shown in the above Trigger details. As can be seen, there is not 3 hr span that would have caused the trigger. Note: Alaska lags GMT by 8 hrs presently, so this Automation was Executed: April 24, 2022, 9:39:56 AM per the automation editor, which is a state-change delay of only 28 minutes.
I understand from prior knowledge and looking at the template in the template editor in Dev Tools that the template is checked every minute (due to now()). I’m not sure why the input_boolean is being left on, or rather, why the automation is triggering at all.
I’m clearly missing something in my logic, but don’t see it. I’m hoping that some HA template guru will see something I don’t. Any advice would be appreciated.
Thanks
Shane
1 post - 1 participant
Read full topic
