I am trying to figure out the basic format of an automation to turn on a light when motion occurs.
The first trigger will be when sensor sees motion and the time is after 23:00 and before 04:00, turn on light.
The second trigger will be when the sensor see motion and the time is after 04:00 and before sunrise, turn on light.
The third condition will be to turn off the light at sunrise
I am not sure what goes in the trigger section and what goes in the condition.
Your first and second ones seem to overlap a bit. Could those just be simplified to after 23:00 and before sunrise?
The third would be best in it’s own automation.
Taking your 3 examples (and combining the first two) here’s the pseudo code for it.
alias: turn_on_light
trigger:
- platform: state
entity_id: binary_sensor.motion_sensor
to: 'on'
condition:
condition: and
conditions:
- condition: time
after: '23:00:00'
- condition: sun
before: sunrise
action:
- service: switch.turn_on
entity_id: switch.light_switch
----------------------------------------------
alias: turn_off_light
trigger:
- platform: sun
event: sunrise
condition: []
action:
- service: switch.turn_off
entity_id: switch.light_switch
Now, this is just something I typed up in the browser, so don’t expect it to work, but it should give you an idea of what should be a trigger, condition, action, etc.
Also, from the way you wrote out what you wanted, the lights will stan on until sunrise. You might want to think about turning them off again after 10-15 minutes of no motion detected.
Sorry I left out some details. For the condition between 2300 and 0400 if motion is detected then I want the light to come on then off after 10 min. For the second condition after 0400 I want the light to come on and stay on till sunrise.
For the condition between 2300 and 0400 if motion is detected then I want the light to come on then off after 10 min. For the second condition after 0400 I want the light to come on and stay on till sunrise.
In that case, a separate automation for each might be best.
alias: turn_on_light_from_2300_to_0400
trigger:
- platform: state
entity_id: binary_sensor.motion_sensor
to: 'on'
condition:
condition: and
conditions:
- condition: time
after: '23:00:00'
before: '04:00:00'
action:
- service: switch.turn_on
entity_id: switch.light_switch
- delay: '00:10:00'
- service: switch.turn_off
entity_id: switch.light_switch
----------------------------------------------
alias: turn_on_light_from_0400_to_sunrise
trigger:
- platform: state
entity_id: binary_sensor.motion_sensor
to: 'on'
condition:
condition: and
conditions:
- condition: time
after: '04:00:00'
- condition: sun
before: sunrise
action:
- service: switch.turn_on
entity_id: switch.light_switch
----------------------------------------------
alias: turn_off_light
trigger:
- platform: sun
event: sunrise
condition: []
action:
- service: switch.turn_off
entity_id: switch.light_switch
The suggestion for the turn off automation seems fine.
For the turn on, how about something like this:
- alias: Turn on light with motion
trigger:
platform: state
entity_id: binary_sensor.motion_sensor
to: 'on'
condition:
- condition: time
after: '23:00:00'
- condition: sun
before: sunrise
action:
- service: script.turn_off
entity_id: script.light_motion
- service: script.light_motion
with this script:
light_motion:
alias: Turn on light with motion
sequence:
- service: switch.turn_on
entity_id: switch.light_switch
- condition: time
after: '23:00:00'
before: '04:00:00'
- delay:
minutes: 10
- service: switch.turn_off
entity_id: switch.light_switch
The reason for putting the actions into a script is, if the automation was triggered again during the 10 minute delay period, that doesn’t actually restart the actions. Rather it would abort the delay and go on to the remaining steps, which is not what you’d want.
For those old enough to remember …
Would another way to avoid this situation be to add a condition that the light must be off? So if the automation re-triggers but the light is already on, then the action isn’t executed.
I’m definitely old enough! 
Yes, in this case I would think that would work as well. But it’s worth getting into the habit of moving any action sequences that contain delays or wait_templates into scripts and using the script turn_off/turn_on sequence in the automation action.
1 Like
I appreciate the tip about moving blocking functions (delay, wait_template) out of an automation’s action and into a script.
I’m going to digress here for a moment.
As you may (or may not) know, I’ve been using Premise to automate my home for over a decade. It runs user-created automation logic in a single thread. That means its scripting language has no sleep, wait, or delay statements because, quite obviously, they would bring all automations to a screeching halt.
The answer to the question ‘Jayzus! How can you can live with just a single thread?’ is ‘Pretty well, thank you very much!’ 
The trick is that timers and I/O run in their own threads. So to create a delay you start a timer and delegate it the task to be performed upon expiry. Effectively it’s like “Hey you there! Wait here for 10 minutes then take this package up to the third floor … and boo-yah my work is done!”
I should mention that the scripting language lets you create timers on the fly (they need not be predefined). If you create a timer with the same name as an existing one, it will trounce the old instance (even if it’s already counting down) and replace it with the new one. That’s a handy feature that comes into play in the next paragraph …
So Premise’s scripts are inherently non-blocking and can even be self-referential (recursive). A second execution of the same script would effectively overwrite the first timer and instantiate a fresh copy. In other words, a second execution of the same script will effectively restart the timer.
All this to say I’m a stranger in a strange land when dealing with Home Assistant’s delay and wait_template and “don’t call a script that’s already running”. I could use Home Assistant’s timers to emulate Premise’s design pattern but it’s a bit more awkward and definitely not ‘in fashion’. I appreciate whatever tips I can find to minimize blocking behavior.
Interesting. Well, every system has its own paradigms, and moving from one to another is often a difficult adjustment.
In my case I moved from SmartThings to HA. In ST, to do anything even slightly complex, you needed to either learn their weird, unique language (Groovy) and it’s development environment, which was almost nothing like anything I had ever used, or you probably used a custom app called CoRE (Community’s own Rules Engine), or its successor, webCoRE (which, obviously, was more web based), which was ok, but had a zillion bugs. I spent more time working around bugs than getting anything done. So, although HA might not be perfect, it’s 1000x better than ST.
And now back to our regularly scheduled programming…
Instead of having multiple automatons I was hoping to do this with one. I have seen some examples where an if statement was used but have not found the documentation on how to use it within HA. Can a script be written that would combine this into one?
Without getting too deep into the weeds, an if statement exists within the bounds of a template. It helps determine the template’s output. You can do a lot with this arrangement but it has its limitations. When you exceed them, so many templates may be needed within the action that it makes that one ‘do everything’ automation less efficient than splitting the task into separate automations.
FWIW, the contents of an action are effectively a script (it’s the same syntax). One of the benefits of a script is ‘code re-use’. More than one automation can call the same the same script (but not at the same time). So instead of having the same code replicated in several automations, it sits in one place.
@captjohn I agree with everything @123 said. I’ll also add that a condition step in a script acts like an “if” statement. The main problem is that there’s no “else” statement for a script. So unfortunately it’s very difficult to do common things that most other scripting languages allow. So, yes, sometimes you can force things into a fewer number of automations & scripts, but often it is not worth the effort.
I am trying to understand the effects of animations and scripts when they get triggered multiple times via a motion sensor. The input from people in this and other forum are very good but I would like to know where this info is documented. I have looked on the Docs of the website but the details are not there that I have found. Additionally when writing scripts I would like to know why a double set of brackets {{ }} are needed? If someone could point me to where I can read up on more of the specifics it would be appreciated.
It’s not documented. And, BTW, technically speaking, you can’t “trigger” a script; only automations have triggers. And you can’t restart a script if it is already running; that will cause an error.
It would probably make sense to add some additional details to the docs describing these behaviors. In this open source project, anyone can submit changes to the docs. I could probably do it, but right now I’ve got way too many other things on my HA “to do” list. 