I’ve got a couple of my automations firing when I restart the server (typically to apply a new configuration) and I’m somewhat confused about it as I don’t think they should be. Could anyone suggest a possible reason and/or possible solution?
Automation #1
- id: 'boost_hot_water'
alias: 'Boost hot water if it gets too cold when people are in'
trigger:
- platform: template
value_template: >
{{ is_state('binary_sensor.house_occupied_day', 'on') and
is_state('binary_sensor.house_occupied_night', 'off') and
is_state('sensor.hot_water_power', 'OFF') and
states('sensor.heating_hot_water_temperature') | float < 45 }}
action:
- service: ifttt.trigger
data: { 'event' : 'hot_water_boost' }
- service: notify.pushover
data_template:
title: 'Boosting hot water'
message: >
This has been triggered because the water temperature ({{ states('sensor.heating_hot_water_temperature') }}C) has dropped below 45C.
This happened at: {{ now() }}
This pushes the following message through pushover:
This has been triggered because the water temperature (unknownC) has dropped below 45C
I’m confused by this because I’ve wrapped the triggers in is_state and states and yet it’s still firing. In this case, sensor.heating_hot_water_temperature is well over the threshold so should not be triggering anyway.
Automation #2
- id: 'heating_on_near_home'
alias: 'Turn heating back to automatic if near home'
trigger:
- platform: state
entity_id: binary_sensor.someone_near_home
from: 'off'
to: 'on'
action:
- service: ifttt.trigger
data: { 'event' : 'heating_on' }
- service: ifttt.trigger
data: { 'event' : 'heating_boost' }
- service: ifttt.trigger
data: { 'event' : 'hot_water_on' }
- service: notify.pushover
data_template:
title: 'Turning heating on'
message: >
This has been triggered because {{ states('trigger.to_state.name') }} has changed.
This happened at: {{ now() }}
This pushes the following message through pushover:
This has been triggered because unknown has changed
In this case, I appreciate that binary_sensor.someone_near_home will be undefined on startup, and I would appreciate any suggestions on how to suppress this from firing on restart.
that will be equal to zero when the returned value of states(‘sensor.heating_hot_water_temperature’) is ‘unknown’ because float defaults to zero when it can’t convert a string to a float. Zero is less than 45 so that portion results in True. Your other sensors must be initialized so everything else is working.
The second automation has incorrect syntax for getting the name. So it appears as if binary_sensor.someone_near_home is not initialized but it is. It must momentarily change from off to on. I’m guessing this is a template sensor based on a device tracker or something? Change your message to this:
This has been triggered because {{ trigger.to_state.name }} has changed.
This happened at: {{ now() }}
but in order to get to the bottom of the second automation, we need to know more about binary_sensor.someone_near_home
OK, that’s fair. Is there any way that I can filter this while it’s initialising to prevent this from firing? i.e. don’t attempt to fire if the value isn’t actually numeric.
I was under the impression that calls made to sensors within templates should always be wrapped up in is_state or states to avoid the sort of problems that I’m having. Have I misunderstood this?
You’re quite right. I should have included this originally. Apologies:
This returns an aggregate binary sensor which is “true” if any user is < 10 miles from home. At the point that I am restarting the server, one or more users will typically be at home, so in this case, I just want to suppress it from triggering on first startup, even if it’s satisfied. (I was hoping that the from and to in the trigger might achieve this, but it doesn’t!)
No you are correct, but that’s not a string. You’re passing 'trigger.to_state.name' to the states function. Do you have an entity_id with the name trigger.to_state.name? The answer is no. The states function only accepts entity_id’s. If you want to use a entity_id from the trigger, you need to get it from the state object. Also, it’s an object, so you don’t want the quotes around it.
states(trigger.to_state.entity_id)
as for the second automation, what is creating proximity.home?
{{ is_state('binary_sensor.house_occupied_day', 'on') and
is_state('binary_sensor.house_occupied_night', 'off') and
is_state('sensor.hot_water_power', 'OFF') and
states('sensor.heating_hot_water_temperature') != 'unknown' and
states('sensor.heating_hot_water_temperature') | float < 45 }}
As for your second one, we need to figure out why it changes from off to on at startup.
Perfect, this has fixed that trigger. Slightly kicking myself as I didn’t realise that “unknown” was a literal text value!
When I restarted the server, only the one remaining dubious automation fired on startup. This is the logbook entry for this:
I think that what’s happening is that binary_sensor.someone_near_home is initialising as false, then immediately re-evaluating based on proximity and transitioning to true, triggering a false arrival. In most cases, setting an initial value for this binary sensor to “true” would probably be OK as 99% of the time, I will be at home when the server restarts, and even if I wasn’t, triggering “leave home” transitions wouldn’t be an issue. It seems, however, that it’s not possible to set an initial value for a binary_sensor and I suspect they always start as false before being evaluated.
