Updated at 9:17AM PDT with the 3rd bullet below that reads, "Rule 1 never resumes execution from it 30-second random delay."
I have a rule with the option "Ignore trigger events while running" turned on. For purposes of this example, let's call it "Rule 1". Here is the scenario:
Rule 1 begins a random, 30-second delay at 01:30:00.175.
Another run initiates a reboot of the hub at 01:30:00. The logs show that the reboot() was executed at 01:30:00.236
Rule 1 never resumes execution from it 30-second random delay.
The hub successfully reboots, but my logs show that every subsequent attempt to trigger Rule 1 generates this log entry: "NOT Triggered - Already Running: Triggered at Certain Time".
Perhaps the reboot results in the rule being stuck permanently in an "already running" state?
Yes, because it was not 100% reliable, and users could get stuck with a dead rule. In the case of reboot, the time for the delay would have expired during the boot. It's set for a specific time and if that time passes while the hub isn't running, oh well, that's that.
Use a private boolean, required expression, or a conditional trigger. Depending on your needs, just one of those may suffice, or you can can stack them as necessary.
Use 'Private Boolean true' as a Condition for your trigger. First action of the rule sets PB to false, and last action sets it to true. It starts out true in every rule.
Corner-case question on this approach: If the hub is rebooted while the rule is running, will the Boolean automatically be reset to "True" when the reboot completes?
Maybe I'm staying the obvious, but if you have rules with private Booleans that should always be true after a reboot, you can create a rule that runs at system start and sets those Booleans to true.
OK, that means that if the hub reboots any time before the private boolean is set back to "true", the rule will remain permanently disabled until someone manually resets the private boolean.
The boolean is private to the rule, so the reset needs to happen within that rule. If I add an "on reboot" trigger to the rule, how do I determine in an action rule if the rule was trigger due to a reboot?
Here's the solution I used:
Whenever the rule executes successfully, I record the completion time in a local date/time variable.
When the rule starts I compare the time of last execution with the current time. If the delta is less than 30-seconds, I assume that this is a duplicate run.
The "on reboot" trigger would be for a separate rule, so there shouldn't be any need to determine whether a rule was triggered due to a reboot.
So to try to explain a bit more clearly:
Assume you have a rule that sets its PB to false to prevent multiple instances running at the same time, does some actions, and then sets its PB back to true. This rule has a required expression of "PB must be true" and some triggers or triggers.
If the hub is rebooted while that rule is running, the PB will be left in the 'false' state and the rule will not run the next time the trigger events happen.
You create a separate rule that triggers on hub reboot. That rule sets the PB on the first rule to true when it runs on reboot. The helper rule is what runs on reboot. The original rule doesn't run on every reboot, it just has its PB set to true so it can run the next time its trigger events happen.
Maybe, maybe not. It depends on exactly what "rule is running" means. Most actions happen in very short amount of time, so hub being rebooted during non-delayed actions is very low probability. If a rule is 'running' because it is waiting for some future event, it may very well still be waiting after a reboot. For instance, I have a rule that waits for sunrise. I can reboot all I want, and that wait is still going to run at sunrise -- rebooting does not affect that. So willy nilly resetting PB for a rule like that would not be right, and could just open it for double triggers -- which was after all the problem to be solved.
I should add, that to the extent the setting of PB is a problem in this matter, so would be the original feature. What happens to "Ignore trigger events" if the hub reboots while the rule is running?
Reboot is not the problem you are making it out to be. It could be a problem, but normally not.
I've learned something new -- a rule can change the value of another rule's local variable. That's good to know.
I am going to stick with my current solution strategy, as it ensures that the rule can never get "stuck" in a state where one has to manually reset it. ie, After the designated amount of time, it automatically assumes that the prior instance is no longer running. That threshold is currently set to 120 seconds.
A rule's actions can change a Hub Variable, or it can change the Private Boolean of another rule. However, a local variable can only be changed by actions within the rule which created it.
I see now where I misunderstood what was being suggested. I have never used "Private Boolean" before, and in my head I was equating it to a local Boolean variable. I've read up on it and now understand what it is.
I now see how using the private Boolean can be used to achieve the same outcome I did by having a separate rule that resets it on a reboot or some period of time after it was set false.
Custom Apps and Drivers / Custom Drivers - Hubitat
