Triggering at SleepTime is straightforward, as you've probably figured out. Triggering before is tricky: as you've probably also figured out, Rule Machine does not let you use offsets with variable (or any) time as a trigger. But it's nothing you can't do yourself, maybe with a set of rules and variables like this:
Variables:
Rules to modify other variable(s) when "main" variable changes:
Rules that effectively trigger 1 hour before:
"Triggering" things one hour after is easy: don't trigger an hour after; just trigger at the normal time, wait one hour (or whatever your desired offset is), and then continue with your actions:
Depending on the rest of your rule actions, you could even combine lots of this kind of thing at various intervals into your "main" rule that triggers first, i.e., at the actual SleepTime.
(That being said, I could see this being cumbersome with a ton of offsets like this, so it might be a decent feature request, though I'm not sure I've seen anyone ask for this before. A custom app might also be easier if you're comfortable with Groovy.)
Alternatively, you could combine both of these ideas and take an even more streamlined approach: have a SleepTime variable and just one other variable for the most amount of time before SleepTime that you would want to start doing anything. If that's 90 minutes, then set that variable to SleepTime - 90 as in my first example (just with 90 instead of 60). Then have a rule that triggers off whatever this "SleepTime minus 90" variable is, and you can do actions like:
Trigger events: Time is SleepTimeMinus90Variable
Actions to run:
Log "It's 90 minutes before SleepTime!"
Wait for events: elapsed time --> 0:30:00
Log "It's 1 hour before sleep time!"
Wait for events: elapsed time --> 1:00:00
Log "It's sleep time!"
Wait for events: elapsed time --> 1:00:00
Log "It's an hour after sleep time!"
Do keep in mind that the rule retriggering will cancel any in-progress waits (and everything afterwards). This shouldn't really be an issue here unless you change SleepTime while an action is "running," including a pending wait, and the new trigger for this rule (offset from that) happens to be a time that will strike while the entire set of actions has not yet been completed. Probably unlikely, but I suppose it depends on when you plan on changing these variables. There's nothing wrong with keeping these split out into multiple rules either, though the same note applies to each of those rules, too. Multiple smaller rules may be easier to edit, too, though in this case at the expense of needing to make more variables.
Just a few ideas to consider!
Obviously, Bruce can make that call, but adding complexity to an already complex app usually needs a pretty strong case.
