Schedule configuration validation

[cswrd]

Hi, I just realized some schedules I configured in the summer, don't make sense in the winter, anymore. Example:

...
noon+180
golden_hour-180
...

Mathematically, the 2nd line should be scheduled before the 1st line. Hue scheduler still "works". Maybe it does this, already. If you think about more complex schedules and situations (tr, tr-before, turning on the lights during overlapping phases or having them powerd on all the time) I don't even know what users are supposed to expect here. Is there is any good interpretation people would understand and intent to configure like that?

I can't think of any good interpretation here. That's why the idea of validating the schedule configuration came into my mind. I'd be happy if hue scheduler would refuse to execute such a "weird" configuration (already in the summer in my case). "Weird" might be defined as:

1. The configured schedule order doesn't match the execution order.
2. There're overlapping phases.
3. ... both detected in advance for an entire year when hue scheduler is started for the given long, lat, elevation.

[stefanvictora]

Hi, thank you for opening the issue and sorry for not getting back to you sooner. Working with changing solar times between winter and summer is indeed a challenge and a source of frustration, even in my own setup.

You are right: Hue Scheduler will automatically switch the order of states depending on the time of year. It dynamically calculates the next start (and end) time of such expressions after each execution, continuously shifting the states as needed. However, I agree that this can cause quite a lot of confusion and unintended schedules throughout the year, especially if you manually adjust solar times or combine them with local times.

I do like the idea of performing such validation on startup. However, I'm a bit concerned that it might limit the flexibility of the configuration file. Currently, Hue Scheduler does not use the defined order for anything, as the states are dynamically sorted after each execution once they are read from the file. Nevertheless, I see how they could be useful for sanity checks to avoid potential misconfigurations.

---

Another idea I had for tackling the different seasons was to allow the definition of date ranges in which the defined states should be scheduled. Since a validation alone would not solve the issue of wanting different schedules in winter versus summer. It could look something like this, which is a more advanced version of restricting states to certain days of week:

# Common states:
Light  sunrise
Light  12:00

# Date range specific states:
date-range: 01.01.-01.04.
  Light    sunset
  Light    civil_dusk

...

date-range: 01.06.-31.10.
  Light    21:00
  Light    22:00

Another variant I had in mind involves time brackets, which define the minimum and/or maximum value for a dynamic solar time:

# Sunrise, but not earlier than 06:00
Light  [06:00,sunrise]

# Sunrise, but not earlier or later than 06:00 and 08:00
Light  [06:00,sunrise,08:00]

# Sunset, but not later as 21:00
Light  [sunset,21:00]

Such brackets could also be created implicitly, based on the defined order:

# Implicit
Light    06:00
Light    sunrise
Light    08:00

Even though this could mean that some states would be skipped, for example, if sunrise occurs before 06:00 or after 08:00.

I'm not sure yet, what the best approach would be or if any of the advanced configuration are usable 🤔 I appreciate any feedback and thoughts on this topic. The dynamic nature of solar times is also one of the primary reasons why I would like to create a GUI to easily adjust my schedules and see their current execution times.

[cswrd]

Hi @stefanvictora, also sry for my late feedback. This is exactly what I was thinking of, too and it could have been useful in my scenarios so often, already. Both the feature to limit schedules to specific ranges and the time brackets one are nice. The date range thing came to my mind first. Later on I realized that I could solve all my schedule intentions with such min/max expressions (bracket approach) in a smarter way. Personally, I'd rather use the data range in situations like having a diiffernt setting during New Year's Eve or so but not to do the scheduling for the seasons of a year.

The lack of a feature like that lead to some "workarounds" I applied like controlling the brightness in the evening with noon as the reference instead of something more obvious like sunset. Reason: noon has a smaller difference compared to other solar constants. That way I can achieve a slightly earlier brightness decrease in winter compared to summer (light 1 hour earlier or so). But not like 5 hours earlier.

Regarding the file validation: I didn't know the order is not used up until now. Considering your concerns about the flexibility of the config file, maybe one could produce an optional log entry when the schedule order doesn't match with the line order, anymore?

Even though this could mean that some states would be skipped, for example, if sunrise occurs before 06:00 or after 08:00.

Indeed, that'd also mean one could do sanity checking for individual lines them self (on top of the syntactic issues). The situation you describe is at least a logic error that might be spotted upfront, technically.

The implicit configuration looks interesting. It's the least verbose solution and feels a little bit more natural. I guess most users would implicitly think it works like that. Given that the order is not considered yet, I am confused though. I'd be happy with the brackets solution, also.

btw I also want to share a little crazy Idea with you as it might fit in the context here: The solar and wall clock times concept might be enhanced by using the natural luminosity of the sun as the reference point. Like saying at 10.000 Lux sun luminosity the lights should be at 50% brightness. I don't mean the actual light conditions measured by a or due to weather conditions (just the calculated one based on datetime, lat, long etc.). It'd achieve the same purpose of applying an "appropriate" light condition during the year. Interestingly, it'd be the most accurate solution I could think of when it comes to applying a brightness that feels exactly the same over the year. Of course there are situations where this is not intended and the traditional wall clock time based approach is preferable (like in my "evening" scenario above).