Many of us use sunrise, sunset in automations. Most of the time offsets from sunrise and sunset are used.
It is possible in these automations to sometimes run twice in short intervals. IN GENERAL THESE WERE BUGS IN OLDER VERSIONS OF webCoRE - these should be fixed in latest versions.
Why this happens?
sunrise and sunset are calculated values in the hub. These are updated daily at the start of a new day. Sunrise and sunset change daily typically as daylight hours grow longer or shorter based on your location. What can happen in automations, especially when calculations are done as offsets of sunrise and sunset is that a calculated value the day before is offset in time from the next day's values. If the calculated value is slightly less than the actual (for sunrise or sunset), you can end up with an automation firing (that was calculated prior to today), then a minute or so later firing again based on today's calculation (from the first firing) because of daily sunrise/sunset time skew. AGAIN THIS SHOULD BE FIXED IN LATEST WEBCORE.
There can also be issues depending on how the automation works if the hub is down for a period of time then comes back up (if long enough that earlier calculated values are inaccurate).
So what to do?
-
make sure you are on latest webCoRE, as these should be resolved (except for the hub down for a period of time)
-
sometimes you can do nothing if the operation of the automation really does not care.
There are a couple of tricks to consider:
-
for the hub down for a period of time, then coming back up, the systemStart event can be helpful to have the automation run
-
for the daily skew of sunrise, sunset and DST changes, having the automation run a 'fix timers' run at say 3:15 AM (assuming you automations are not trying to calculate a sunrise or sunset offset that is around 3:15) can allow the automation to ensure the calculations for today are accurate for today. (SHOULD NOT NEED TO DO THIS ANYMORE)
- in the latest webCoRE releases, above works, but webCoRE uses new methods to calculate the future sunrises and sunsets, so you should see the next schedule correctly calculated for the future (with or without offsets).
For this to work well the automation needs to be able to correctly process if it started for another reason beyond the sunrise/sunset with offset reason. (ie it is not the sunrise or sunset calculated time, and perhaps do nothing but reset the timers accurately).
Below is an example of a piston, and its operation is discussed in writing pistons with condition comparisons and trigger aggregation
Few more notes
-
there are hub events you can use as triggers sunriseTime, sunsetTime that fire at those times (as calculated by the hub for your location).
- The value of those events is a string of the next sunriseTime or sunsetTime respectively
-
There are system variables $sunrise, $sunset that are today's sunrise and sunset
-
There are system variable $nextSunrise, $nextSunset which are tomorrow's sunrise, sunset
