Could somebody help me make a single automation/bluerprint that will not be affected with home assistant restart and that turns on a light socket at sunrise turns it off after one hour and then wait for 30 minutes and turns it back on for one hour again then turning it off for 30 minutes and repeat the cycle for 4 times altogether and by the end the light should be turned off for the rest of the day.
I tested this automation and it works. Long winded and there may be a better way but it works 
- alias: 100 - Test Lights
id: Test Lights
initial_state: true
trigger:
platform: time
at: "07:51:00"
condition:
condition: and
conditions:
- condition: time
weekday:
- sun
- mon
- tue
- wed
- thu
- fri
- sat
- condition: state
entity_id: device_tracker.sm_f926u1
state: "home"
action:
- service: switch.turn_on
entity_id: switch.bedroom_switch
- delay: "00:00:05"
- service: switch.turn_off
entity_id: switch.bedroom_switch
- delay: "00:00:10"
- service: switch.turn_on
entity_id: switch.bedroom_switch
- delay: "00:00:05"
- service: switch.turn_off
entity_id: switch.bedroom_switch
- delay: "00:00:10"
- service: switch.turn_on
entity_id: switch.bedroom_switch
- delay: "00:00:05"
- service: switch.turn_off
entity_id: switch.bedroom_switch
- delay: "00:00:10"
- service: switch.turn_on
entity_id: switch.bedroom_switch
- delay: "00:00:05"
- service: switch.turn_off
entity_id: switch.bedroom_switch
- delay: "00:00:10"
You can of course edit this with your own entities and/or conditions.
1 Like
The technique shown will work but it won’t meet the first requirement: unaffected by a restart. If Home Assistant is restarted at any point while the automation’s action is underway, the automation is interrupted and cancelled. On startup, the automation won’t resume from the point where it was previously interrupted.
1 Like
You can use the sunrise offset
use one automation to turn the lights on:
automation:
trigger:
- platform: sun
event: sunrise
- platform: sun
event: sunrise
offset: "01:30:00"
- platform: sun
event: sunrise
offset: "02:00:00"
- platform: sun
event: sunrise
offset: "03:30:00"
and another to turn the lights off in a similar way.
automation:
trigger:
- platform: sun
event: sunrise
offset: "00:30:00"
- platform: sun
event: sunrise
offset: "02:00:00"
- platform: sun
event: sunrise
offset: "02:30:00"
- platform: sun
event: sunrise
offset: "04:00:00"
2 Likes
Good idea but it will need a bit more in order to ensure the light is set to the correct state after a restart (restart trigger, conditions to check in which time range the current time falls, etc).
The requirement to survive a restart always makes the automation a bit more complex.
1 Like
You’ll need to be able to check something…ie time for example so the automation can pick up where it left off. That would fix it. At some point writing a script may be a better idea and calling from an automation…
1 Like
Not really, the light will just remain on (or off) during the restart. Unless the restart happens exactly at the same moment as the trigger would have. But then I ask, why are you restarting?
1 Like
This. It was moments from being turned on/off but a restart occurs causing it to miss the trigger event.
It doesn’t even have to be a restart. The moment you execute Reload Automations, all automations that are in progress are cancelled. This happens transparently whenever you use the Automation Editor and save a new/modified automation.
1 Like
Yeah, but creating all these extra workarounds for just the slight chance that you missed a trigger. Well… go ahead, I just think it’s silly.
1 Like
You could also instead of using delay set the time in case the automation gets restarted…
Just like @niro1987 said… that way if restarted either HA or just automation it would pick
back up where it left off because they are specific times…
Other then that you are creating a very specific timed event[s] and you’d be better of writing a complicated script for that… lots of work just to have something turn on and off a light…
You’re entitled to think whatever you want but that’s a requirement and your suggestion fails to meet it.
FWIW, all of my scheduled automations are able to survive a restart. The server is protected by a UPS yet there have been power outages exceeding its capacity (90 minutes). When power is restored, all scheduled automations restore devices to their correct states.
2 Likes
NO we get that… you could have started off with the last info you just gave… that makes sense now. But again a specific time [using time] makes sense as @niro1987 suggested. Not hard. I’m still kinda new to all this and I overthink just about everything… so to put it in the simplest terms… do what makes sense…
Specific time events will work. ie 1 PM then at 2 PM so if the automation is restarted it will look at the time and fire accordingly.
Yes, this is where the real work lies; the rest is trivial.
There in lies the beauty… you can use just about anything for your trigger… the easiest thing would be to use a tracker… ie your phone… if not home then fire… or time… I tend to lean on my phone tracker until someone pointed out that what happens if you’re not home and someone else is… then the lights won’t work LOL Opps rookie mistakes… ugh.
Between the two suggestions there’s enough meat there to come up with something that will work. 
Can you use a template sensor to set the values? I use sun2 so you may have to modify to use sun and you may need to remove as_local()
template:
- trigger:
- platform: time
at: '00:00:00'
sensor:
- name: "TriggerOn1"
unique_id: "TriggerOn1"
state: >-
{{ states('sensor.sunrise') }}
sensor:
- name: "TriggerOff1"
unique_id: "TriggerOff1"
state: >-
{{ as_local((states('sensor.sunrise') | as_timestamp + 3600|int ) | as_datetime)}}
sensor:
- name: "TriggerOn2"
unique_id: "TriggerOn2"
state: >-
{{ as_local((states('sensor.sunrise') | as_timestamp + 5400|int ) | as_datetime)}}
sensor:
- name: "TriggerOff2"
unique_id: "TriggerOff2"
state: >-
{{ as_local((states('sensor.sunrise') | as_timestamp + 9000|int ) | as_datetime)}}
sensor:
- name: "TriggerOn3"
unique_id: "TriggerOn3"
state: >-
{{ as_local((states('sensor.sunrise') | as_timestamp + 10800|int ) | as_datetime)}}
sensor:
- name: "TriggerOff3"
unique_id: "TriggerOff3"
state: >-
{{ as_local((states('sensor.sunrise') | as_timestamp + 14400|int ) | as_datetime)}}
sensor:
- name: "TriggerOn4"
unique_id: "TriggerOn4"
state: >-
{{ as_local((states('sensor.sunrise') | as_timestamp + 16200|int ) | as_datetime)}}
sensor:
- name: "TriggerOff4"
unique_id: "TriggerOff4"
state: >-
{{ as_local((states('sensor.sunrise') | as_timestamp + 19800|int ) | as_datetime)}}
Then you can use the trigger time and trigger id to turn on and off
trigger:
- id: on
platform: time
at:
- sensor.triggeron1
- sensor.triggeron2
- sensor.triggeron3
- sensor.triggeron4
- id: off
platform: time
at:
- sensor.triggeroff1
- sensor.triggeroff2
- sensor.triggeroff3
- sensor.triggeroff4
I don’t think there is a way to fix if you reboot or reload automations at the exact time the automation was supposed to run. You could create another automation that looked at the time ranges then turned on or off as needed.
2 Likes
NOW that’ll work! VERY specific with time and no if your automations get restared it won’t matter… it’ll still fire.
Unless the ‘survive a restart’ requirement includes the ability to set device states for a restart in between trigger times (which is important when the restart was due to a power outage). In that case, merely having time-based triggers won’t address that requirement (regardless of whether it’s a Time Trigger based on a template sensor or a Sun Trigger).
1 Like
The automation is for a house plant light and I would ideally like the start of it at-least, to mimic the sunrise time (as it changes with seasons). I would like the plant to have at-least 4 hours light on time and the intermittent light off time is to prevent the light from over heating.
Thank you. @niro1987, I would try to work on this. But ideally I would have liked the turning on and turning off to be in a single automation (I have 3 plant lights, I want to control independently).
You can nowadays - you need to declare a variable in the trigger. In the actions you can use the choose based on that variable.
1 Like