add an availability template to your binary_sensor. Then add a condition on the automation to verify that a from_state exists
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')}}
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. 
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.
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’:
during reload:
after reload:
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?
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
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 
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. 
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.
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.
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 }}
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.:
though I see this happening in the events:
am I missing a typo?.. can’t see it
It looks like time_fired is outside event data
{{ trigger.event.time_fired }}
yes, that’s correct:
with that changed, and working, there’s no change in behavior:
before:
during:
and after … :
maybe I should fiddle about with the timing of the > 5
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 }}
there’s no difference between these to templates, they change state on the exact same moments.
also, there’s no change yet in end result, even with the slider set to
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
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') }}
Simplify by using has_value(trigger.entity_id)
that wont test for:
trigger.to_state.state != trigger.from_state.state