Why do the first two automations have the same id?
Make them different.
Just for fun, I’ll add my own version of a “motion-activated light that automatically turns off but only if it was activated by motion”.
- alias: 'Light Auto On'
trigger:
platform: state
entity_id: binary_sensor.backyard_motion
to: 'on'
condition:
- condition: template
value_template: "{{ state_attr('sun.sun', 'elevation') < 0 }}"
- condition: state
entity_id: switch.backyard_lights
state: 'off'
action:
- service: homeassistant.turn_on
entity_id:
- input_boolean.your_switch_auto_on
- switch.backyard_lights
- alias: 'Light Auto Off'
trigger:
platform: state
entity_id: input_boolean.your_switch_auto_on
to: 'on'
for:
minutes: 3
action:
- service: homeassistant.turn_off
entity_id:
- input_boolean.your_switch_auto_on
- switch.backyard_lights
1 Like
lol. I don’t use ids as they are useless unless (I presume) one uses Automation Editor - if you have id and alias, the latter is always used so what’s the point in using id?
experimented just yesterday with aliases - they are used to generate object_id and act as friendly_name in the same time (with spaces converted to underscores etc) and there is no way to set a friendly_name it via customise.yaml (didn’t work for me) so basically there is no way to give your automation a nice name and know the exact name of your automation (to use it in service call, for example) as to be able to do that one need to know the HA conversion rules (which may change in the future as it’s internal thing).
I might be wrong though but that’s how I see it now.
if you use templates, how about reducing conditions in the on automation to
- condition: template
value_template: >
{{
state_attr('sun.sun', 'elevation') < 0 and
is_state('switch.backyard_lights', 'off')
}}
?
UPDATE: however, it depends on what camp are you in according to this discussion 
Sure, why not.
As for the id, it is, as you mentioned, used by the Automation Editor. That’s the identifier it uses to uniquely identify each automation. I don’t use the Automation Editor but I imagine it may be unhappy when it encounters two or more automations using the same identifier. I don’t know if it has any bearing on JohnB’s reported problem but, in the interests of disambiguation, it would be best if the automations have unique identifiers.
I’ll try giving them a unique id to see if that soles the problem. The lights turn on on motion from the ring camera, but do not turn off after 1/3 minutes. I used 1 minute for testing.
try one of the proposed solutions. if it doesn’t work, create a new topic as I suggested earlier.
So that no matter how the switch/light/whatever is turned off the boolean is turned off. Otherwise if it’s turned off manually, or by another automation, it’ll remain on.
And why do we need this feature (remain on) considering it was created to indicate the fact an automation turned the light on? Shouldn’t it be tied to that automation as it might cause very weird side effects…
Do it your way and see how it works for you 
The way I’ve documented it is how I use it - works just fine for me with no weird side effects 
I will. The thing is people copy your example so if there is a problem, it becomes their as well
I didn’t say it doesn’t work, just pointed out the 3rd automation should be incorporated into the 2nd so it’s less code/less room for error/easier to understand and maintain - win-win-win situation.
There will be no weird side effects unless something like this happens
So potentially it might get stuck and disrupt your light automation.
My point is simple - if the flag is for lights only, it should be controlled by lights automations only or you’re asking for troubles.
If it’s controlled only by lights automation, it’s enough tu turn it off when the automation switches the light off as it’s over.
Yes, there are cases when a flag is used to indicate that one of automations is controlling the lights and that means other automations should wait/not trigger, but it’s not the case here so again, you’re asking for troubles or overcomplicating your config.
But I’m not insisting
I like your solution. I changed it a bit because yours always shuts off after 3 minutes, even if the motion sensor is on. My turn off routine is :
trigger:
- platform: state
entity_id: binary_sensor.motion_sensor_kitchen_occupancy
to: 'off'
condition:
condition: state
entity_id: input_boolean.wled
state: 'on'
action:
- service: homeassistant.turn_off
entity_id:
- light.wled
- input_boolean.wled
This then turns off after the motion sensor is off.
No it doesn’t. It only turns off if there is no motion for 3 minutes. If there was more motion after 2 minutes and 59 seconds that automation would not trigger.
Your automation just turns off the light straight away with no grace period, which is often undesirable as you will come to see when your automation regularly leaves you in the dark.
No because his turn-off routine does not work based on the motion sensor, but it’s based on the input.boolean. So if ‘input.boolean’ ‘on’ after 3 minutes the ‘light is off’.
The entity_id is irrelevant, it’s the ‘for:’ statement that causes the system to wait until the state has been the same for a certain amount of time.
I know what “for” is for. But his always shuts off 3 minutes after turning on the Motion Sensor, no matter if someone is still moving there, but if I (for your sake) put “for: 3 minutes” in it, mine will turn off 3 minutes after the Motion Sensor is off. I tried it with ‘for: 10 seconds’ and the Motion Sensor was still active but the light went off.
Then something else is wrong with your configuration.
Hello all, I want to start by telling you that I am new to HA and this is my first automation.
Let me tell you about the setup, I have a bathroom windows that is actioned by a motor, with 2 relays. Relay1 ON, Relay2 OFF the window will open, Relay1 OFF, Relay2 ON windows will close, Relay1 ON and Relay2 ON windows stops (also used for close/open position).
What do I want to achieve is a way to prevent the automation to run multiple times when the trigger value is above the value configured using input_bolean.
Here is the open automation:
alias: Bathroom window open
description: open bathroom windows
trigger:
- platform: numeric_state
entity_id: sensor.bathroom1_si7021_humidity
for: '00:01:00'
above: '50'
condition:
- condition: state
entity_id: input_boolean.bathroom_manual
state: 'off'
action:
- type: turn_on
device_id: 030eab3206bc4ddcf775ca7b0497500e
entity_id: switch.bathroom1_2
domain: switch
- delay:
hours: 0
minutes: 0
seconds: 4
milliseconds: 500
- type: turn_off
device_id: 030eab3206bc4ddcf775ca7b0497500e
entity_id: switch.bathroom1_2
domain: switch
- service: input_boolean.turn_on
target:
entity_id: input_boolean.bathroom_window
mode: single
Here is the close automation:
alias: Bathroom window close
description: close bathroom window
trigger:
- platform: numeric_state
entity_id: sensor.bathroom1_si7021_humidity
for: '00:10:00'
below: '40'
condition: []
action:
- type: turn_on
device_id: 030eab3206bc4ddcf775ca7b0497500e
entity_id: switch.bathroom1
domain: switch
- delay:
hours: 0
minutes: 0
seconds: 12
milliseconds: 0
- type: turn_off
device_id: 030eab3206bc4ddcf775ca7b0497500e
entity_id: switch.bathroom1
domain: switch
- service: input_boolean.turn_off
target:
entity_id:
- input_boolean.bathroom_window
- input_boolean.bathroom_manual
mode: single
The problem is that when the condition is set, the automation is not triggered any more, regardless the state of input_boolean.bathroom_manual state, on or off.
I figured I’d throw this out there if anyone stumbles upon this thread like me looking for a solution to this issue. I had a similar problem where I have a light switch in our bathroom that I wanted to be able to “override” motion control from when I wanted. Since this switch is z-wave based I was able to use the z-wave event to accomplish this control.
I always have modes and then actions for my automations so in my mode automation I flip the status of an input select to my desired value:
initial_state: "on"
alias: Master ensuite motion
trigger:
- platform: state
entity_id: binary_sensor.master_bedroom_ensuite_sensor_motion
to: "on"
condition:
- condition: template
value_template: "{{ states('input_select.master_ensuite') not in ('On') }}"
action:
- service: input_select.select_option
data:
entity_id: input_select.master_ensuite
option: Motion
mode: single
This would trigger my lighting motion automation. Which looks like this:
initial_state: "on"
alias: "Master ensuite lights motion"
trigger:
- platform: state
entity_id: input_select.master_ensuite
to: "Motion"
condition:
- condition: state
entity_id: input_boolean.lighting_automations
state: "on"
action:
- service: light.turn_on
data:
transition: 10
brightness_pct: 50
entity_id:
- light.master_ensuite_shower_light_dimmer
I then setup an “On” mode with the following:
id: master_ensuite_on
initial_state: "on"
alias: Master ensuite on
trigger:
- platform: event
event_type: zwave_js_value_notification
event_data:
value: KeyPressed
property_key_name: "001"
node_id: 19
action:
- service: input_select.select_option
data:
entity_id: input_select.master_ensuite
option: "On"
mode: single
Here I’m listening for the zwave_js event notification from my switch and using that to then set the input_select to “On” which overrides my “Motion” value allowing anyone to manually take over control of the light.
Any way hope this helps anyone who has this same problem in the future and stumbles upon this thread.
FWIW, that’s the usual way to handle the situation assuming the device reports its button events.
Given a device that does not report its button events, the fallback is to monitor its brightness attribute but only if it’s a dimmer. For a switch, the only recourse is to adopt some less-than-natural behavior like turning off the switch then turning it back on immediately to serve as a signal that the user wants to override the automatic-off feature.
Lastly, it’s possible to consolidate your three automations into one (but it’s purely optional).