- id: '1553346538460'
alias: Closet on with Motion
trigger:
- entity_id: binary_sensor.closet_motion_65
from: 'off'
platform: state
to: 'on'
condition: []
action:
- data:
entity_id: switch.closet_67
service: switch.turn_on
I walked into the closet this morning, I saw the motion sensor flash, but the light never turned on.
The logbook shows that the sensor was indeed triggered and hassio was aware of it:
However, there is no entry stating that the automation was triggered. Sometimes it works, sometimes it doesn’t. My other automations are working (just used a different sensor -> lights on automation successfully).
I just came back to report that was indeed the problem. But as I was combing the threads, it appears that initial_state is supposed to be set to true. But every automation I have defaults to false if I don’t have initial_state: true in it.
Should I file a bug report?
Oh wow. Sure enough. I really dislike that idea. There should be a checkbox in the automation editor that says “Initial state: [on] [off]”. Wonder how hard that would be to implement.
When you create a new automation, it will be disabled (and therefore won’t trigger) unless you explicitly add initial_state: true to it or turn it on manually via UI/another automation/developer tools.
That’s false.
In the process of helping people on this forum, I have created and tested many automations and all withoutinitial_state. After creating the automation, I run “RELOAD AUTOMATIONS”, and the automation is immediately functional.
Upon restart, Home Assistant will restore the previous state of each automation.
If the automation was off it will be restored to off.
If the automation was on it will be restored to on.
There is an exception. If Home Assistant fails to restart properly there is a chance it won’t be able to restore the previous states. When it does finally restart successfully, all automations will be off. I’ve restarted my test system many times and have never experienced the situation where all automations are off. However, that’s not to say it can’t happen.
If you have automations that absolutely, positively must be on after any restart, either a good or bad restart, then set initial_state: true for that automation.
Don’t forget that, by using initial_state: true, your ability to temporarily disable the automation is compromised. Yes, you can disable it but it will be automatically re-enabled after the next (good) restart. That behavior may be desirable, or undesirable, depending on your use-case.
I have experienced this. I always set my initial state to true now. I don’t use the automation config but can see how the true/false option would be useful for those that do.
FWIW, when the restore feature was added to Home Assistant (I no longer recall the version; possibly as far back as 0.84), after upgrading, everyone’s automations were turned off. That’s because the feature was brand new and had no way of determining an automation’s state prior to the upgrade. The solution was to manually turn on all automations (you can use the Services page to do that). Afterwards, the new feature would restore automations to their previous state after a restart.
However, many people latched on to the idea that the solution was to add initial_state: true to each and every automation. It definitely works but initial_state is designed to override the restore feature. As I explained above, that may be desirable/undesirable behavior.
I’ll give one example where initial_state: true would be undesirable. You have an automation that runs on demand. When you need it, you enable it manually, when you don’t you disable it. If you disable it, but it has initial_state: true, the next time you restart Home Assistant the automation will be re-enabled. What you had disabled days or weeks ago is now enabled again. You may not even notice the change until the automation executes.
In a perfect world, there should be no need to manually enable/disable an automation. Its trigger/conditions should be sophisticated enough to know when it should and should not run. In this ideal situation, one could use initial_state: true with confidence.
If one wanted to still have a manual override in this so-called ideal situation, the automation’s conditions could monitor the state of an input_boolean. Now you can use initial_state: true with the knowledge that you still have ability to manually suppress the automation (with the input_boolean) and it won’t be countermanded by the restore feature.
In a perfect world, there would be a master setting which says “automatically set all automations to initial_state: true” (or false, depending on your desire), unless I specify otherwise. For whatever reason, the restore feature just doesn’t seem to love me.
this is not completely correct. It used to work perfectly before, and relied on recorder.
the move from recorder to the .storage ‘broke’ it. Ever since that move, every once in a while all automations lose the state they were in, and one has to reset manually.
I reentered the initial_state for the ones I need to always be on at startup, and several to false (apparently ‘off’ isn’t allowed any longer) for the automations I need only in certain situations.
All in all, restore state has lost its use for automation because of that…
Throughout this thread, I’ve been referring to the current restore feature (using .storage), as implemented in 0.84 (or whatever version it was) and not whatever may have existed prior to it.
This form of state-restoration was indeed “new” since it no longer worked the same way as its predecessor (for better or worse). Because it worked differently, after performing the upgrade, it had no knowledge of an automation’s previous state, so it defaulted to off. That seemingly simple design decision caused the user-community a lot of confusion after upgrading (and still causes confusion).
Ideally, the new restore feature shouldn’t be influenced by a bad startup and default to setting all automations to off. The chance of this happening is low but low is not never so it causes users to add initial_state: true. The irony is that the option effectively overrides the new restore feature! What should have been an improvement (using .storage) only became more complicated and ultimately disabled by using initial_state: true.
Just a suggestion to help those who don’t want to use initial state true… ive had this happen to me a couple times, usually after multiple reboots or upgrades etc. I ended up making an automation that alerts me if the group.all_automations is off for 2 minutes … because then I know it has erroneously set all my automatons to off… again just a suggestion so people don’t troubleshoot why their automations aren’t working for 10 minutes before they realize they all got turned off again, because that’s what happened to me.
