Sunrise time overtakes set time

[bartkummel]

Checklist

• I checked for similar existing issues (both open and closed) before posting.
• I am running the latest version.

Expected behavior

I've a schedule to put on an outdoor light early in the morning and put it off at sunrise. However, now the days are getting longer, the "early in the morning" time is actually past sunrise. I'd expect the light to stay off in this case.

                               6:00          sunrise               
                                 ┌───────────────┐                 
 WINTER   ───────────────────────┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼───────────────  
                                 └───────────────┘                 

                 sunrise                                         
                    │                                            
 SPRING   ──────────┼────────────────────────────────────────────
                    │                                            
                                                                 

Actual behavior

The light is triggered to go on "early in the morning". But that's now after sunrise, so it never goes off again.

                               6:00          sunrise               
                                 ┌───────────────┐                 
 WINTER   ───────────────────────┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼───────────────  
                                 └───────────────┘                 
                                                                   
                 sunrise                                           
                    │            ┌───────────────────────────────┐ 
 SPRING   ──────────┼────────────┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼│ 
                    │            └───────────────────────────────┘ 
                                                                   

Steps to Reproduce

• Create a schedule where you put on a light on a set time, of which you know that it's a couple of minutes before sunrise.
• The turn off time should be "sunrise".
• Then wait a couple of days until sunrise is changed to be before the set time.

Note that this only works if you're far enough from the equator, and if it is spring. You can think of similar scenarios in autumn of course.

[nielsfaber]

There is currently no intelligence built-in to compare start and end point of a schedule.
So there is no check whether the slot has a positive duration, and skip it otherwise as you consider to be logical (personally I see more logical the swapping of start and end points to obtain a slot with positive duration).
Instead it is considered to be user responsibility to prevent schedules from becoming 'corrupted' due to negative duration.
Corrupted schedules cause problems with the execution (as you mention here) but also in the visualization in the card.

In short, I expect you to be aware that sunrise can be as early as 6:00 in the Netherlands during the spring/summer.
You can choose to modify your schedule with fixed start and stop times, start and stop times being both dependent on sunrise or set the duration wide enough that corruption cannot occur.
If you have a proposal for improvement and are willing to contribute, that would be very welcome. Otherwise I'm afraid this will not be changed anytime soon (I am focusing on other improvements in the coming period).

[bartkummel]

My goal with automations always is "set and forget". However, I can't do that in this case. I need to manually monitor when the sunrise gets too early and then disable or adjust the schedule. While I understand it's not trivial to implement, it would still be a great addition to the scheduler component to detect these situations automatically.

[mikeage]

I'd opened nielsfaber/scheduler-card#815 earlier before I saw this issue, although upon reflection, mine should be an issue on this component and not on the card.

If we could use another object, it'd be easier to handle cases like this outside of the component, removing the need for a complicated GUI here.

There are still risks in the functionality, if the varying datetime goes before or after a fixed time, but I think that once the user has taken this level of control, it's fair to expect them to ensure that the order is always consistent.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days