I realize that I can subscribe to event = sunset but how can I set an event 1 hour prior. Do I have to loop periodically and compare current time to sunset time?
Thanks
I'm not sure which app you are trying to use, but in RM and a host of other apps you can use Sunset and then pick an offset + or - secs/mins/hours to that time.
Which app are you using?
Have a look at the app you are using and see if that option appears when you select sunset.
2 Likes
What your saying exists in RM I want to implement in my own custom App. I just prefer Apps rather the RM environment.
Thanks
Ah. OK. I'll leave that then for people who know what they are talking about. 
1 Like
LOL... Thks
2 Likes
Would I simply do a Runin() that corresponds to sunset minus one hour? Any other method?
1 Like
I would schedule a function to trigger at something like 2AM every day.
Use this method getSunriseAndSunset: Common Methods | Hubitat Documentation
To get the sunrise / sunset times for the day.
Then you could calculate the offset and use RunIn to schedule the correct function.
Or you could also use schedule to schedule it for an exact time using a cron string.
2 Likes
Appreciate the help.
FWIW, I think the built-in apps do this shortly after midnight, though this may have changed since they were originally written. I would personally avoid 2 AM since there are time zones where that time never happens one day a year. 
(Or really anything in that whole hour and probably anything in 1 AM too unless running twice the other day a year isn't a problem.)
Sometimes there are bugs where things run an hour or late after such changes, too, possibly because of when this calculation was made, so I'm not saying it's the best option, but 3 AM seems worse since that might not be soon enough to catch sunset minutes 1 hour in some locations.
Of course, if it's all for your own use, you'd both know what might work best and be able to fix what quirks arise, if any, from whatever method it is. (And if the "if any" thing turns out to be "none" and the answer isn't that you live in an area that doesn't use summer time/DST, people may want to know. )
4 Likes
Cache the values from the day before and only update them each morning. That way, worst case, you’re off by a minute or two if things fail to run at 1-2/3 AM or whenever you pick.
There are hub events that fire at sunrise/sunset that contain the next day's corresponding times, sunriseTime and sunsetTime.
So I guess that I forgot that it must have changed, even though that response was directed to me in the first place.
(But I'm still wondering if scheduling things a day in advance might mess it up by an hour twice a year in time zones with DST/summer time changes...there have historically been some problems with apps like Mode Manager being inaccurate for one day after the change, and I remember it happening as recently as a few months ago in the fall for me. The scheduler or some other aspect of the hub might not be accounting for this, so the above workarounds may still help. I'm not sure anyone has really cracked this case yet...)
I've also got a "Sun Position" driver that could be used: https://github.com/DanielWinks/Hubitat-Public/blob/main/Drivers/Virtual/sunPosition.groovy
It's pretty lightweight, so having it update every minute isn't any real load on the hub. Anytime "altitude" goes from below 0 to above 0, it's sunrise, and reverse for sunset.
It also spits out azimuth, which is handy for things like lowering some smart shades in my office when the combination of altitude and azimuth means the is shining onto my monitors.
But since it updates every minute (or whatever you set in the driver config), there's no need to run anything at 3AM or whatever. You can simply trigger "when altitude > 0" for sunrise. You'll want a state variable or two so you only trigger once per day for sunrise and sunset. But it should be entirely immune to any issues arising from daylight savings time changes.
After years of messing with this problem, using various approaches including the sunriseTime and sunsetTime events, I finally settled on a somewhat different approach. In the contexts where I had to solve this problem -- all of the apps that allow sunrise/sunset +/- an offset, the issue of the negative offset is the problem case.
For those problem cases there are two sub-problems. The first has to do with the time the app's installed() or updated() method runs and that time's relationship to before sunrise/sunset today. The second is what to do on every subsequent day. The first case may devolve simply into the second case if the current time is after the target time, because in that case the first scheduled event will be tomorrow. If the first case is to happen yet today, that is a runOnce() for the time when the event should happen.
For the future before sunrise/sunset events, the second case above, my scheduleTime() methods schedule() a recurring job to run during the first minute after midnight, on a random second of that minute (so that not all apps using this approach run at once). That scheduled job, in turn, computes the time remaining until the target event and schedules runOnce() for it.
This approach, using a midnightHandler() has proven to be solidly reliable, and relatively simple to setup. It takes advantage of the ability of the platform to pass parameters through a scheduled job, allowing the schedule handlers to know what to do.
As for DST changes and how that interacts with scheduling, I for one have given up on solving that problem. We've been trying to solve it for all cases for years now, and still things happen on DST change day that we can't figure out.
4 Likes
That sure sounds like an interesting way of eliminating any dependency on time... and therefore time offsets. Not bad! Thks
Hi daniel.winks, I have integrated your Sun Position driver into my app and believe that the new capability is going to work out better than something based on time. What I am seeing so far is that my event handler for sun altitude comes in usually in 1 minute intervals and then I get an occasional 2 or 3 minute interval... And then every 20 to 30 minutes it will wait about 15 minutes between updates. I have the device view up as I am tracking my log.debug and the extended durations correspond. I can't see that it is something I am doing to cause this... it is pretty straight forward. What could be causing this to occur?
Thanks
Edit: was broken, fix is on GitHub.
Thanks for checking daniel.winks. I had another looong duration between updates and went into my SunPosition driver and at the bottom of the screen shot it shows about a 20 minute difference:
I thought I would give you a screen shot of the events also:
Please look at the transition from 3:54:21 PM to 4:26:21 PM
I have to wait at least 30 minutes or so before seeing this behavior.
