When HA is started or restarted, it will set the state for any entity, for example device_tracker, hence (rightfully) triggering automation rules like this in case all_devices state is set to home:
- alias: Turn lights off when everybody out
trigger:
platform: state
entity_id: group.all_devices
state: not_home
action:
service: script.turn_on
entity_id: script.lights_off
Is there any easy way to express an automation condition like unless HA was just restarted?
Have you tried
trigger:
platform: state
entity_id: group.all_devices
state: 'not_home'
for:
hours: 0
minutes: 15
seconds: 0
to make sure actions will not be immediately after restart of HA?
If I understand the for condition correctly, this might work. But the problem is mostly with state: home triggers, that will be eventually triggered if I do a restart while I’m at home (and usually that’s the case)
A restart condition would really help. The for condition is only a workaround for that demand.
For now I’m accomplishing this using one command_line sensor that reports the home-assistant.service uptime in seconds, and a second sensor that returns true when uptime is > 30 seconds. This also assumes you’re using systemd to manage the Home Assistant service, which was what I got by default after using the Raspberry Pi all-in-one installer.
sensor:
- platform: command_line
name: Time Since Last Home Assistant Restart
command: 'echo "$(($(date +%s) - $(date --date="`systemctl show home-assistant.service -p ActiveEnterTimestamp --value`" "+%s")))"'
unit_of_measurement: 'seconds'
- platform: template
sensors:
home_assistant_not_restarted_recently:
value_template: '{% if states(''sensor.time_since_last_home_assistant_restart'') | float > 20 %}true{% else %}false{% endif %}'
For my system this was first getting evaluated around 10 seconds at the most after restarting the service, but I just put in 20 for good measure. You should adjust accordingly for your system.
Add a condition to automation that checks the state of sensor.home_assistant_not_restarted_recently:
automation:
- alias: Front Door Open Notification
trigger:
platform: state
entity_id: binary_sensor.ecolink_doorwindow_sensor_sensor_2
to: 'on'
condition:
- condition: template
value_template: '{{states(''sensor.home_assistant_not_restarted_recently'')}}'
action:
- service: notify.pushbullet
data:
message: 'Front door was opened at {{ now }}.'
The second sensor isn’t strictly necessary, but it prevents you from having to hardcode some value for seconds in multiple places.
Hope this helps.
Or simply try rewriting your trigger to look like this:
trigger:
platform: state
entity_id: group.all_devices
from: home
to: not_home
Can you explain what this is doing? I’m not sure I understand how this stops automations from being triggered right after a Home Assistant restart.
If you check the syslog of the host you are running HASS on, you will be able to see what state changes of entities look like during HASS startup. Those state changes will show that the old state (from) tends to be blank (’’, null, none, whatever you wanna call it) and the new state (to) is something you’d expect to see (like home or not_home for your group above). By specifying the from state, you would avoid triggering the automation during start when the old state is blank.
I know that this conversation is quite old - but I am new to HASS (and am loving it so far btw) 
How are others handling that scenario (automations being triggered after rebooting or restarting the service)?
Example: I’ve set up an automation that notifies me when the washing machine finished its work (power consumption drops below a certain value), or a PIR notifies me when motion is detected etc … so I am getting notified (or whatever actions are triggered by that state change) after each service restart or reboot of the raspi.
The workround above (from @fanaticDavid ) would prevent that from happening, but this adds an extra level of “complexity” when writing automation rules. Shouldn’t that logic be somehow handled by HASS itself?
What you could do is right after the restart, run the following:
- service: automation.turn_off
data:
entity_id:
- group.all_automations
- delay: 30
- service: automation.turn_on
data:
entity_id:
- group.all_automations
After 30 seconds, the states of some of entities that got messed up due to the start up should should have ‘stabilised’ and when you activate the automations again, they will no longer trigger unwanted automations to start (because an automation only starts at the moment of the state change). You can play with the 30 seconds of course if you need it to be longer or if it can be shorter. Also, you could specify the exact automations you want to exclude…
- service: automation.turn_off / turn_on
data:
entity_id:
- automation.name_of_the_automation_to_deactivate
- automation.name_of_another_activation
- automation.and_so_on_and_so_onI’ve been running into this issue lately. To conclude, put this into your automations:
- id: delayautomationsonrestart
alias: 'Delay automations on restart'
hide_entity: true
trigger:
platform: homeassistant
event: start
action:
- service: automation.turn_off
data:
entity_id:
- group.all_automations
- delay:
seconds: 30
- service: automation.turn_on
data:
entity_id:
- group.all_automations
I almost feel this should just be the default behavior of automations. Add a flag that allows automations to trigger on startup triggers.
That you for this, i couldn’t work out why my lights kept turning on when i rebooted my HASS
Hey - thanks for the suggestion @liquidox. This looks like it will solve my problem (same as others). But in practice, I am finding that home assistant loads this automation quite a bit later than the ones I want to inhibit at restart, so the problem remains unsolved.
I can’t find anything about how to determine which automations will load first. Looking at the logbook, it doesn’t appear to be alphabetical (either by automation name or by yaml file name).
Any thoughts? Any way to force the delayautomationrestart automation to load before all the others?
And I agree - this should be default. Don’t allow automations to fire until all the platforms have loaded / settled / whatever. Too much unpredictable behaviour as it is.
Thanks
Personally I have “fixed” it by moving all my automations over to AppDaemon, obviously not a solution for most people, but worked out for me. And now have all the power of AppDaemon, which is amazing.
I only have 1 automation that would go nuts when restarting Home Assistant: an automation which sends me a notification whenever certain devices in my network would go offline or come back online. Whenever I restart Home Assistant, that automation would send me a notification for every device stating it came back online (and sometimes even that it had gone offline first). So with 6 devices being monitored by that automation, I would get either 6 or 12 notifications on my phone.
I work around that by checking how long Home Assistant has been up and running: if it’s less than 5 minutes, then don’t trigger the automation. For this, I use a sensor:
- platform: uptime
name: "HA runtime in minutes"
unit_of_measurement: minutes
and then the following condition in said automation:
- condition: numeric_state
entity_id: sensor.ha_runtime_in_minutes
above: 5
Ah that’s perfect. Thanks David.
(PS it worked nicely, too)
My problem isn’t quite the same but maybe you guys have figured this out while figuring out the problem in this topic. So I’ll borrow the topic a bit - sorry about that 
I have an automation that sends me a notification (ios) if a device becomes unavailable. This is mainly to monitor whether any of my many wireless Zigbee-sensors run out of battery. Now every time I restart HA, I get zillion notifications, because apparently HA considers the sensors being unavailable right before it shuts itself down. I tested that it happens in shutdown, not on start.
I doubt that there is a way (or at least it won’t be quick enough) to for example turn the automation off if HA receives a restart command? And then set the initial_state to ‘on’ so that it will come back on after start?
Any other ideas?
My suggestion would be to create a script that first disables the automation to send a notification and shuts down homeassistant afterwards. Do bear in mind: it needs to be a script as that can do consecutive actions.
If the problem is that you get a lot of reminders, then you can put a timer in place and use that as a condition (do not fire the notification if previous notification has been sent less than 5 mins ago)
Main drawback is that you always need to shutdown via that script.
Thanks! Actually this was so stupid simple that I almost feel embarrassed I just added for: 00:04:00 to the original automation. This solves the problem completely. Below 4 minutes would probably also be more than fine but that works too for this purpose.