I have this action in a 5.1 Rule:
Set vTimeStop to sunrise time(7:09 AM) plus vTimeStopOffset(30) minutes
I want to set the variable vTimeStop to the sunrise time for the next day (+ offset) -- is that possible?
I'm not aware of anything to determine sunrise by specifying a date, and since the offset changes throughout the year you might try changing the strategy; like making whatever you're doing stoppable and creating another daily task that fires at sunrise to stop the previous day's task.
What I do here: I have hub variables set up for sunrise/set-dependent times, with a cron job that fires off at 12:20 am to set those values. Then, using the hub variables as triggers ("When time is Variable time: .SUNRISE") works just fine.
What @jwjr says above is how RM and the other apps do it. You might notice a scheduled job for midnightHandler, and that's exactly what it's doing -- getting (then) today's sunrise for calculating offsets from it. That handler runs on a random second during the first minute after midnight.
1 Like
Isn't sunrise today (+ offset) close enough? Is the precision essential for your end purpose? Especially since you are adding an offset to it anyway?
1 Like
Or you can just calculate it yourself based on latitude.
A python example is shown here: Sunrise equation - Wikipedia
It was mildly interesting to learn how this is actually done.
It's left as a exercise for the reader to translate that from Python to Rule Machine....
Sounds like what just RM functions are designed for...
(But to be honest, I like @jwjr's solution much better,,). This is also ignoring the differences between mean solar time and apparent solar time, which I didn't know was a thing either, until reading Wikipedia - So @CuriousB also has a point...
Yes, it is. I just wanted to know whether I'd missed something built in to RM that would make my rule "perfect". There isn't.
The original question has been answered, and everyone can stop reading here.
Here's my application: I have 34 Inovelli Blue Dimmers. I created a single rule that works for all of them (i.e., 34 instances of the same base rule). Each rule is customized to the corresponding dimmer by setting values for a set of 13 local variables within the rule (e.g., dimming thresholds for comparisons, dimming values for different numbers of paddle taps, Booleans for setting different modes, and start and stop times).
I have a string variable of initial setting values like this:
100,25,50,false,false,true,false,67,33,sunset,-30,sunrise,30
``
Part of my rule -- which is only run once per day -- parses that string and sets the values of each rule instance's local variables. Another part of my rule -- which need only be run if I change an instance's settings -- uses the corresponding dimmer's name in %device% to retrieve a similarly-named file from File Manager to set the initial settings string variable. This way, each instance self-selects and sets its own local variable values (I have a utility rule that writes all of the 34 settings strings to File Manager, making changes easy to do, and yet another utility rule that forces a trigger of each rule to update itself). All of this was done to ease the time needed to customize each rule after cloning 34 instances after a change to the base rule.
Four of the variables include a vTimeStart and vTimeStop pair of variables plus respective offsets that I use to construct valid datetime values for use in this IF statement:
IF (Time between Variable time: vTimeStart(6:51 PM) and Variable time: vTimeStop(7:48 AM)(T) [TRUE]) THEN ...
I naturally want vTimeStop to always represent a time AFTER the start time. If my settings string specifies "sunrise" and "30" for construction of my vTimeStop variable, my rule executes this action:
Set vTimeStop to sunrise time(7:09 AM) plus vTimeStopOffset(30) minutes
What I now get is today's sunrise time, which is technically going to be BEFORE the vTimeStart value. So I was just seeking a more technically correct calculation, if one already existed in RM.
According to Google's AI, in my area (Vancouver, WA), the greatest difference in minutes between the sunrises of consecutive days during a year is around 3 minutes, so the error is quite tolerable (I'm almost never awake anywhere near sunrise).
Perfection can be the enemy of progress… 
With help from the community , I wrote a personal 'Twilight Parser' driver I use to accurately track outdoor lights between actual SR/SS and twilight.
the call to Sunrise-sunset.org works very nicely and allows you to feed a date. I have to do this since HE pulls SR/SS from 30 miles away (Salem, OR) which is 3-7 mins off always. Us Farm Country people take SR/SS seriously.
1 Like
Beating a bit of a dead horse, but RM clearly knows how to determine sunrise (and set) times for arbitrary dates when defining triggers -- compare this rule's trigger sunrise time to the current day's sunrise time:
I'm hoping that someday RM will enable setting of a DateTime variable with similar flexibility.
