How to compensate for missed events (e.g. sunrise) after a restart of HA?

I have a few automations that trigger at sunrise
Problem is when I restart Home Assistant at e.g. 10AM
Then those automations won’t run until sunrise of the next morning. This will leave devices in the wrong state for the remainder of the day.
I was wondering if there are any best practices (and examples) on how to compensate for this?
One possible solution, which I like, would be to run automations at startup time to provide the necessary triggers.
I found how to run an automation at HA-startup time, but how would I trigger a “sunrise” event from that automation?
Any ideas and/or examples are greatly appreciated (a totally newbie here, so lots to learn)

An automation can have more than one trigger. In cases like yours I have an additional trigger

 - platform: event

and fire appropriate events on HA startup (another automation)

Hi Ahmad,
thank you for your quick reply
However, I don’t understand what you mean
I have the following automation:

- alias: actions to do at startup 
    platform: homeassistant
    event: start
    #generate/simulate the "sunrise" event
    #how do I do that?

Or is this a dead-end and do I need to find another approach ?

Why not use a condition ‘sun state above horizon’ and call all the services the would have been called at sunrise?

No, you can read docs instead :wink:
Btw, an option with ‘sun state above horizon’ condition might be a reasonable one as well, think about it.

thank you @ahmadK
Following the link to the documentation in your reply, I did write the following automation… which does not seem to work:

- alias: compensate for missed sunset after a reboot
    platform: homeassistant
    event: start
    condition: state  # from sunset until sunrise
    entity_id: sun.sun
    state: 'below_horizon'
    - event: SimulateSunset
        name: myEvent
        entitiy_id: sun.sunset

As a test, in the action I can hardcode turning off individual lights after sunset. That works as expected, but I am looking for a more generic solution by triggering a sunset event myself. The idea is that by doing this, all automations that “missed” the real sunset event due to a reboot of hassio, would then trigger and set the right “states”.

So far I did not get it to work.
Any tips are welcome
thanks again,

I don’t have the code here (typing on mobile), so you should double check my syntax here, it’s probably wrong :wink:

I would take the automation and add a second trigger, like this, then add a condition to make sure it won’t run at 2PM

  - platform: sun.sun
    event: sunrise
  - platform: homeassistant
    event: start

  condition: and
      - condition: state
        entity_id: sun.sun.attribute.elevation
        below: 5
      - condition: ........

This way you have two events to trigger your automation - at sunrise and after your homeassistant reboots.
The condition is important to prevent a post-sunrise triggering. This is useful in case you have lights turning on, coffee machine making coffee, tv turning on to watch news, etc. which should only happen at sunrise, not 2PM.
Testing for sun elevation below 5 should give your PI enough time to boot, knowing it started reboot before sunrise.

Thanks for a good discussion. I think I’m going to re-write some of my automations.

Come to think of it, probably most automations would benefit from some sort of condition check on start-up. I can’t think of too many times when you want something to happen when a transition occurs, but not happen when you start HA, if that transition has already occurred.

It almost seems like this should be the norm. It seems odd to need to add extensive logic to each automation.

Sorry, what exactly does not work?

I’m afraid I don’t get you. Could you explain in as much details as possible what exactly you want to achieve in your more generic solution?

How do you see such a things implemented in HA?

Hi @ahmadk, @shadowdream and @CaptTom Thank you for your time and effort in answering this topic.
Let me try to explain in a bit more detail:
What are we trying to solve:
If hassio (re-)starts it will probably have missed certain events (like sunrise, sunset,…) This will set several outputs (relays, lights, sprinklers, thermostats,…) in the wrong position.
Automations in Hassio trigger on events, which are typically “changes in state”
A classic event is: sunrise (not to be confused with the “state”: “Sun above the horizon”)
If, due to a restart of Hassio, the event is missed, then several outputs could be in the wrong state. (the automations didn’t see the event, and their “actions” didn’t fire.)
Let’s follow the example of a missed sunrise for this discussion, but keep in mind that we are trying to solve the bigger issue. (missed events due to a reboot)
Expected Solution:
There are 3 possible solutions to this issue:
Modify (all of) the existing automations to add a second trigger that fires on restart of hassio. This works, but it would require to modify all existing automations
2. what I am trying to achieve:
Create an automation that triggers at startup of Hassio and the generates the missed events. In our example: this automation would generate a “sunrise” event. This would trigger all existing automations that listen for “sunrise” and the outputs would be set in the correct state.

I tried generating the sunrise event via YAML and via the Hassio WebUI, but my automations do not fire. I tried the following code, which would fire the sunset event at startup:

    platform: homeassistant
    event: start
    condition: state  
    entity_id: sun.sun
    state: 'below_horizon'
    - event: SimulateSunset
        name: myEvent
        entitiy_id: sun.sunset

I have set logging to “INFO” and when hassio restarts, I see that the automation is processed. I see no errors, but my other automations do not receive the sunset event.
Does this make more sense?

  1. As I learned from your posts, there may be third solution: Rewrite the automations to check for the current state (e.g. “sun below horizon”). This would be more solid. But we would still need a trigger. The example by @shadowdream relies on the event/trigger of “sunrise”. After a restart, we don’t see that event. I guess we could poll for “sun.sun.attribute.elevation” at set intervals, but that may generate too much overhead.

Bottom line:
I’d like to get Solution2 to work (generate a “sunrise/sunset” event myself after a restart of hassio)
thanks again for your interest and time

@chrisV thanks for the clarification.

BTW, it would be great to see at least one of your original automations as there are few ways to trigger on sunrise as far as I can see in docs.

You’re firing SimulateSunset event, is it the standard one? And what’s sun.sunset?
Pretty sure it shouldn’t work, at least because of the above (as you need to broadcast Sunrise event).
Also, why your condition is ‘below_horizon’? It won’t be true between sunrise and sunset, will it?

Not quite. He suggested to ADD an additional trigger to any automation that reacts on sunrise so it triggers on HA restart as well (it’s logical OR, please read the 1st paragraph of the docs), and to avoid action executions if HA restarts at 10pm, for example, you need to add that elevation check condition.

I cannot see the sun integration firing any events, it just calls self.async_write_ha_state.
I just don’t have time to dig deeper now and find out what event is generated on sunrise, but it is somewhere in HA code and one can possibly fire it as well (but the result of an automation that is triggered by such a fake sunrise might be a bit surprising if you use some of sun attributes as they won’t be similar to real ones (like elevation).

There is a missunderstanding. In the example I have posted, the automation does pretty much what you want:

  1. When the sun rises, the trigger is fired. The condition checks if sunrise happened recently by checking if it’s still low in the sky (below 5). – Note: in this case the condition is not needed since sunrise means the sun is always below 5. But you need the condition for the second situation!!!

  2. When Homeassistant restarts, the trigger is fired too! Now the condition is important! The automation should only run on sunrise, so we need to check if sunrise was recently (below 5). This prevents the automation to run at any other time.

  - event 1
  - event 2

Writing your trigger this way means both triggers work at the same time. Both can and will trigger your automation. Only one has to happen to trigger the automation! This is how my example works.

Of course the same works for sunset

Hi @Shadowdream
thank you for your answer.
Yes, I guess what you describe is what I listed under “solution1”. It means to modify all existing automations.
The solution I am looking for is to trigger a sunrise event myself when hassio (re-)starts. This would then start all automations that have a trigger to “sunrise” (or sunset).

As I said, in that case you need to find out how to fire a ‘sunrise’ event properly as from my point of view your current implementation isn’t right.

On the other hand, I slightly doubt you have THAT much automations so it justifies spending a lot of time arguing against changing all of them in favour of “triggering” a sunrise event yourself but it’s completely up to you :wink:

Personally, I’d create sensors that are on/off. These sensors would resolve every minute and they would only be on for a duration. There initial state should be off as well. And change your automations to turn on based on these sensors. Here’s a sunrise to sunset example:

  - platform: time_date
      - 'time'

  - platform: template
        entity_id: sensor.time
          {{ is_state('sun.sun', 'above_horizon') }}

This will update every minute as well as when sun.sun changes state.

your automations will trigger off this:

  - platform: state
    entity_id: binary_sensor.sunrise_to_sunset
    to: 'on'

So when sunrise occurs, this will fire. Also, when you restart it will fire if it’s above the horizon.

You can get inventive with this but your templates may get complicated.

I think people will find hundreds of uses for this logic, but let’s take the simplest example: When I’m away from home, I say I want a light to come on at sunset, and go off at 11:30 PM.

But what I really want is the condition “between sunset and 11:30 PM.”

It’s easy to say it that way, but hard to code. The solutions we’re talking about here are fairly complex workarounds.

At some point before version 1.0, it would be great to have a way for non-programmers to automate turning on a lamp between sunset and 11:30 PM. The long-term success of HA will depend on it’s appeal to those non-programmers.

It’s funny that you bring this up because major companies don’t have this ability. I’m pretty sure HA will survive without it. All major companies have the same logic that HA has. Turn on at sunset off at 11:30 pm. Any restart in the middle has the potential to make it out of sync.

I had higher hopes for HA than that.

My own experience might be instructive here. Personally, I love HA. But even now, there are a couple of automations which aren’t working on my setup. I learned all kinds of new things when I was working on creating them. Some of it I remember, some I don’t. It’ll be a whole new project to start back at the beginning and re-learn to diagnose and code them.

While I’m very capable of doing so, (that was my job for several decades) I’m not really sure when that will come up the the top of my priority list.

The successful home automation products, long term, will be the ones you can “set and forget.”

If HA wants to be an exclusive club, with only hard-core, full-time coders allowed, then go for it. Not my problem.

Would something like this work, it doesn’t need to trigger every minute, it’s only triggered by HA startup and the setting sun:

- alias: 'Lights on at Sunset'
  initial_state: True
    - platform: state
      entity_id: sun.sun
      from: 'above_horizon'
      to: 'below_horizon'
    - platform: homeassistant
      event: start
    - condition: state
      entity_id: sun.sun
      state: 'below_horizon'
    service: scene.turn_on
    entity_id: scene.evening

Yeah, but op didn’t want to do that for some reason. :man_shrugging: