Reload template entities causes binary_template sensors to trigger automations

Configuration
1

using this simplest of automations:

  - alias: Daylight sets outside motion sensors
    id: Daylight sets outside motion sensors
    trigger:
      platform: state
      entity_id: binary_sensor.outside_daylight_sensor
    action:
      service: >
        homeassistant.turn_{{'off' if trigger.to_state.state == 'on' else 'on'}}
      entity_id: group.philips_buiten_motion_sensor_switches

never was an issue. until the reload template entities came along (which in itself is a great tool)

the binary_sensor is based on another entity, hue_daylight sensor, which is taken of the Hue hub even before the template entities are initialized in startup, so no issue whatsoever there.

binary_sensor:

  platform: template
  sensors:

    outside_daylight_sensor:
      friendly_name: Outside daylight sensor
      device_class: light
      value_template: >
        {{is_state('sensor.hue_daylight','on')}}

Upon reload, all my outside motion sensors keep getting switched on…

I can probably add a few guards in this automation, or template binary_sensor, but this borders the ridiculous imho. We are now forced to create a full set of guards on these binary sensors (my quake, and battery alerts go awol too…)

Seems a rather undesired side-effect of a nice addition to the toolbox. What to do here, issue a bug, or rebuild all binary template sensors?

btw, before you suggest: I’ve already tried the availability sensor but this seems futile, since the base sensor is always there. its simply the fact the template binary_sensors are re-created upon reload.

for this particular automation, I can rewrite to

  - alias: Daylight sets outside motion sensors
    id: Daylight sets outside motion sensors
    trigger:
      platform: state
      entity_id: sensor.hue_daylight
    action:
      service: >
        homeassistant.turn_{{'off' if trigger.to_state.state == 'on' else 'on'}}
      entity_id: group.philips_buiten_motion_sensor_switches

but that of course doesnt take away from the issue. Especially since the binary_sensors are extremely useful and ‘made’ for this purpose, checking ‘on’/‘off’

2

add an availability template to your binary_sensor. Then add a condition on the automation to verify that a from_state exists

3

well tbh, I wouldn’t know what to add for availability_template on the binary_sensor…other than I already tried.

as said, this sensor.hue_daylight is available almost immediately after startup.

and for the automation to check for {{trigger.from_state is not none}} doesn’t help, because it isnt none, its always on or off… Nor does the check for

not in ["unknown", "unavailable"]

which is tried in the below battery sensor too.

as are all binary_sensors, they never see another state.

same goes for the mentioned battery binary_sensor

    battery_alert:
      friendly_name: Battery alert
      device_class: problem
#        availability_template: >
#          {{ states('sensor.low_level_batteries') not in ['unknown','unavailable','None'] }}
      value_template: >
        {{states('sensor.low_level_batteries')|int > 0}}

which triggers an automation. Ive now rebuild to the only way I could get it to work properly: base it on the sensor itself, no longer use the binary_sensor. This would trigger on each HA restart, and reload templates.
even using

    trigger:
      platform: numeric_state
      entity_id: sensor.low_level_batteries
      above: 0

would do so btw.

  - alias:  Alert when batteries are below alert level
    trigger:
      platform: state
      entity_id: sensor.low_level_batteries
      from: '0'
#      entity_id: binary_sensor.battery_alert
#      from: 'off'
#      to: 'on'
    action:
      service: notify.system
      data:
        title: Battery alert
        message: >
          {{state_attr('binary_sensor.battery_alert','List')}}
4

Your post made me review all my automations and, wonder of wonders, none of them use a Template Entity for triggering. That would explain why I never witnessed the behavior you described (despite using Reload Template Entities).

The addition of Reload Template Entities is greatly appreciated but I will now keep your post in mind should I ever use a Template Entity in a trigger. It’s too bad this great feature comes at the cost of “protecting” certain automations from being falsely triggered. :man_shrugging:

5

Your template is

so your availablity_template would be

        {{ states('sensor.hue_daylight') not in ["unknown", "unavailable"] }}

Then when the other entity isn’t available, it will be ‘unknown’.

Then in your automation, check to see if the from_state is unknown or unavailable.

6

really sorry, but this doesn’t fix it.

binary_sensor:

  platform: template
  sensors:

    outside_daylight_sensor:
      friendly_name: Outside daylight sensor
      device_class: light
      value_template: >
        {{is_state('sensor.hue_daylight','on')}}
#          {{is_state('binary_sensor.driveway_reachable','off')}}
      availability_template: >
        {{states('sensor.hue_daylight') not in ['unknown', 'unavailable']}}

and

  - alias: Daylight sets outside motion sensors
    id: Daylight sets outside motion sensors
    trigger:
      platform: state
      entity_id: binary_sensor.outside_daylight_sensor #sensor.hue_daylight #binary_sensor.outside_daylight_sensor
    condition:
      condition: template
      value_template: >
        {{trigger.from_state not in ['unknown','unavailable']}}
    action:
      service: >
        homeassistant.turn_{{'off' if trigger.to_state.state == 'on' else 'on'}}
      entity_id: group.philips_buiten_motion_sensor_switches

still cause the automation to be triggered.

correct ‘before’:

Schermafbeelding 2020-10-20 om 09.34.17
Schermafbeelding 2020-10-20 om 09.34.17774×370 20.2 KB

during reload:

Schermafbeelding 2020-10-20 om 09.34.23
Schermafbeelding 2020-10-20 om 09.34.23778×640 45.6 KB

after reload:

Schermafbeelding 2020-10-20 om 09.41.15
Schermafbeelding 2020-10-20 om 09.41.15788×658 47.6 KB

note this is odd for a second reason: the daylight binary being on hasn’t triggered the automation again, and turn-off the group. During the reload, the automation is triggered (in spite of all guards) to turn on the group (can only mean the binary template sensor is reset (and turned off by default?). And, during that same moment, even when the binary is correctly set after that, the automation doesn’t get triggered once again.

the availability_template btw is always ‘true’ as explained, so that won’t help/make a difference. Because of that, the condition in the automation is simply always ‘true’ too, and that would explain the observed behavior I am afraid.

I did try with

{{trigger.from_state is not none}}

which I use as guard in all other places, but that too doesnt help here. I really feel this is another issue altogether. Templates are all reset at reload, apparently binary_sensors are defaulted to ‘off’, hence the issues at reload. This can be different from restarting the HA instance, because that depends on the order of loading al other integrations, and would explain people not noticing it maybe?

7

I have not gone through all of the testing and trial and error that you have. However, I have noticed that automations that trigger on a template binary sensor do fire when reloading template entities.

In the best cases, lights in a room turn off and then right back on. In the worst of cases, the lights turn off and don’t come back on, presumably because the device itself can’t handle being toggled that quickly.

I’m going to try @petro 's recommendation of an availability template to see if that helps. However, in the meantime, I’m using “for” as a bandaid, which isn’t the best solution, and adds a delay, but, fixes it for now.

  - alias: Daylight sets outside motion sensors
    id: Daylight sets outside motion sensors
    trigger:
      platform: state
      entity_id: sensor.hue_daylight
      to: 'off'
      for:
        seconds: 3
    action:
      service: homeassistant.turn_on
      entity_id: group.philips_buiten_motion_sensor_switches
8

hi, thanks for your suggestion.

This would of course be viable, were it not for the fact that during operation, one needs the binary to trigger without delay…

do note though, that in your suggestion, you’ve used the sensor, not the binary_sensor as trigger. Not sure if this is merely a typo, but the regular sensor.hue_daylight works alright, and fixes the issue (it isn’t a template sensor…)

it’s the binary template sensor that causes the trouble. rephrase, it’s the binary template_sensor that is impacted with this undesired side effect of the reloading of template entities :wink:

9

Ah, yes, I did indeed. I copied the automation from your original post and just edited it. I picked the wrong one to copy/paste. :slight_smile:

Regardless of that, yes, the delay is not-desirable. With some extra code, there are better ways around it. An input_boolean that turns “off” when template sensors are reloaded and then turns back on 3 seconds later, and then setting all of your other automations with a condition of that input_boolean being on should keep them from triggering during that 3 second window when template entities are reloaded.

It’s certainly not ideal.

And, to add to the mess, many of my binary_sensor templates have a delay_off. These still seem to turn off and then back on when reloading template entities, though more testing is needed to be sure.

10

Since you have done extensive testing, you likely have all the information needed to submit a proper bug report/issue. I would recommend doing so as, it certainly seems that this is a real issue. Regardless of an available work-around, it should be fixed.

11

see https://github.com/home-assistant/core/issues/42118

12

I still don’t see this as a bug. Anyways you can guard against this by listening to reload events with an automation and a input datetime

- alias: Last Template Reload
  trigger:
  - platform: event
    event_type: event_template_reloaded
  action:
  - service: input_datetime.set_datetime
    data:
      entity_id: input_datetime.xxx
      timestamp: "{{ as_timestamp(trigger.event.data.time_fired) }}"

then just use a condition

  condition: template
  value_template: "{{ now().timestamp() - state_attr('input_datetime.xxx', 'timestamp') > 5 }}
13

ok, hold on, that sounds interesting, creating a generic input_datetime to be used in all templated triggers.

doesn’t work yet, so I must be doing something wrong here:

  - alias: Last Template Reload
    trigger:
      platform: event
      event_type: event_template_reloaded
    action:
      service: input_datetime.set_datetime
      data:
        entity_id: input_datetime.template_reloaded
        timestamp: >
          {{as_timestamp(trigger.event.data.time_fired)}}

and

input_datetime:

  template_reloaded:
    name: Template reloaded
    has_time: true
    has_date: true
    icon: mdi:refresh

doesn’t get it’s datetime set upon reload templates.:

Schermafbeelding 2020-10-20 om 14.13.07
Schermafbeelding 2020-10-20 om 14.13.071040×244 17.9 KB

though I see this happening in the events:

Schermafbeelding 2020-10-20 om 14.17.49
Schermafbeelding 2020-10-20 om 14.17.49994×506 30.7 KB

am I missing a typo?.. can’t see it

14

It looks like time_fired is outside event data

{{ trigger.event.time_fired }}

15

yes, that’s correct:

Schermafbeelding 2020-10-20 om 14.29.59
Schermafbeelding 2020-10-20 om 14.29.59934×206 19.5 KB

with that changed, and working, there’s no change in behavior:

before:

Schermafbeelding 2020-10-20 om 14.28.20
Schermafbeelding 2020-10-20 om 14.28.20804×582 38.9 KB

during:

Schermafbeelding 2020-10-20 om 14.29.00
Schermafbeelding 2020-10-20 om 14.29.00778×584 42.5 KB

and after … :

Schermafbeelding 2020-10-20 om 14.29.07
Schermafbeelding 2020-10-20 om 14.29.07774×570 38.7 KB

maybe I should fiddle about with the timing of the > 5

16

yeah I set it to 5 seconds, make sure the date_time is correct in relation to your timezone. now() is local and your state_attr(‘input_datetime.xxx’, ‘timestamp’) might not be local. Edit, yeah its not the right tz

use this instead:

  condition: template
  value_template: "{{ now().timestamp() - as_timestamp(states('input_datetime.xxx')) > 5 }}
17

there’s no difference between these to templates, they change state on the exact same moments.

Schermafbeelding 2020-10-20 om 14.48.15
Schermafbeelding 2020-10-20 om 14.48.152100×610 79.2 KB

also, there’s no change yet in end result, even with the slider set to

Schermafbeelding 2020-10-20 om 14.49.45
Schermafbeelding 2020-10-20 om 14.49.45780×104 5.72 KB

18

separate post for this, comparing an automation triggering on a regular template sensor:

  - platform: template
    sensors:

      utc_offset:
        friendly_name: Utc offset
        value_template: >
          {% set trigger = states('sensor.time') %}
          {{now().utcoffset().total_seconds()/3600}}

and

automation:

  - alias: Utc Offset change
    id: Utc Offset change
    trigger:
      platform: state
      entity_id: sensor.utc_offset
    condition:
      condition: state
      entity_id: input_boolean.notify_system
      state: 'on'
    action:
      service: notify.system
      data:
        title: 'Ha Rpi4: Utc time'
        message: >
         {{as_timestamp(now())|timestamp_custom('%X')}} Utc Offset changed to {{states('sensor.utc_offset')}}.
         Check if time is set correctly in Python scripts, and day-time sensors.

also triggers upon reloading template entities, but, adding the one condition to rule them all:

    condition:
      - >
          {{trigger.from_state is not none and
            trigger.to_state is not none and
            trigger.to_state.state != trigger.from_state.state}}

mitigates that.

The binary_sensor triggering can not be mitigated with this? I am now seeing successful reloads twice though, so this really is the One to rule them All… need some further inspecting why this helps suddelny.

Still, it is a lot of extra work, while this should optimally be taken care of in core generically.

2 Likes
19

The above template does not work for me. Instead, the following template does the job. It’s not pretty, but it works.

{{ (trigger.from_state is not none) and (trigger.to_state is not none) and (trigger.to_state.state != trigger.from_state.state) and not(trigger.to_state.state == 'unavailable' or trigger.from_state.state == 'unavailable' or trigger.to_state.state == 'unknown' or trigger.from_state.state == 'unknown') }}

20

Simplify by using has_value(trigger.entity_id)