I have a physical switch trigger a ‘bedtime’ script that turns off all lights, the TV, etc.
The problem is I also have an automation that turns some lights on when the TV is turned off. So what happens is the the bedtime script turns off the TV and lights, then the TV automation sees the TV go off and turns some lights back on.
Is there a way for the TV automation to only respond when ‘TV off’ is not triggered by the script?
In the bedtime actions, turn off the TV light automation with the homeassistant.turn_off service, do your bedtime routine then turn the automation back on.
1 Like
Add this as a condition to your TV automation:
condition: "{{ (now()|as_timestamp - state_attr('automation.bedtime_script', 'last_triggered')|as_timestamp) > 5 }}"
EDIT: @tom_l’s solution is more elegant.
Thanks guys, you’re like ninjas!
Both good solutions. I’ll look at implementing one of them.
Edit: Based on @Troon 's edit I will go with @tom_l 's solution 
1 Like
If this switch’s state is visible in Home Assistant, it can be used in a State Condition within the script (that turns on lights when the TV is turned off).
If it’s not visible, or merely a stateless pushbutton, then that idea won’t work.
1 Like
FWIW, the technique of one software component disabling another is not a ‘best practice’. By “disabling” I don’t mean simply influencing the other’s behavior but outright shutting it down.
It’s an expedient technique, that I have seen suggested more than a few times, but it isn’t optimal. Aside from the questionable design philosophy, one loses the ability to definitively and reliably disable an automation.
For example, if you had a good reason to turn off an automation (due to a malfunction that you intend to resolve at a later time) you can’t be certain it will stay off. You might have one or more other automations that will turn it back on. (As luck would have it, it will probably be turned on at the worst possible moment.)
Optimally, each automation has access to all inputs needed to properly guide its behavior. Short of that, a global “flag” can be used (like an input_boolean) to signal one automation’s intentions to others (and thereby influence their behavior, not disable them outright).
Analogy:
Imagine a team sport. Each player knows their role. Their individual actions are influenced by the actions of their team mates.
You pull a player out if they are injured, fatigued, or under-performing. You don’t pull a player out to temporarily stop them from performing their role. You train them to be better at it. That might even require changing the behavior of other team mates so everyone works together more effectively.
4 Likes
You could store the state of the automation prior to turning it off, and only turn it back on if it was already on prior to the automation running.
I done that in another system (Tasker) where is has been useful to compare the previous state of something with the new state. Although I don’t know how to do it in HA.
If one is willing to do that then they might as well use a ‘flag’, as a signaling technique, to allow one automation to influence the behavior of another.