I'm not the brightest bulb in the box but this isn't my first home automation rodeo either.
I'm not sure if the "switch" was failing to work at all...but my experience with using a private Boolean is that they are CONSTANLY getting stuck and no longer run.
My system is now less stable. It's frustrating. NOT working is better than getting stuck all the time.
I have no ideas if rules just crap out that often and don't reach the reset lines or what...I just know that the private Boolean approach just hoses up rules.
Then your Private Boolean is improperly configured. Without seeing screenshots of your rules, it is impossible for the community to help you fix them.
I have over 30 rules with Private Booleans. They've never been stuck in an inappropriate state - even when I've rebooted the hub while a Rule is still executing.
The same way it would if you hadn't rebooted. A hub reboot, in general, affects way less than people tend to think. Specifically, it does not erase and scheduled jobs, event subscriptions, etc. that an app put into place, which is likely tied to your PB reset (in your above example, some definitely are -- a delay is one way to create a scheduled job). Of course, if the hub is off when this job is supposed to happen, it will be missed, as would any real-world event that happens when the hub isn't up to listen for it (e.g., a Z-Wave switch turning on).
In general, logs are going to be the best clues for figuring this kind of thing out. Smaller, shorter rules are also generally easier to troubleshoot than larger, more complex rules, so like @aaiyar, I would suggest that as a next step if logs alone aren't a clue -- then the shorter, simpler logs from the shorter, simpler rules should give you clues that are easier to work with.
Yes, platform 2.3.9 had an "Ignore trigger events while running" option in Rule 5.1 that was quickly removed in 2.4.0 (and somewhat hesitantly added in the first place). It's nothing you shouldn't be able to accomplish with some other technique, like PB in question here, and you should be able to actually see and manually manipulate things when needed as an added bonus.
Turn on rule logging to see if your rule is bombing out somewhere.
I have seen hubs before that were under stress where rules waiting on a delay would just die and never complete. Once I fixed the issues the rules started working again.
The main problem with this feature was that there was no way to reset it if it got in the wrong state. During the period that it was available, sure enough, someone did something that caused a rule to not ever run again because of that feature being in the wrong state. Unlike Private Boolean, there was no way to manually manipulate the feature, so if it got hosed, that rule was hosed. With Private Boolean, there is always manual recourse available.
As the author of Rule Machine, it never ceases to surprise me what people do with it -- things I never imagined. I thought that feature was bullet proof, and was quickly proven wrong. I still don't know what happened to hose that rule, but that event proved that users can do things that I never imagined, and break things that I thought were solid.
Looking at your rule, it's not at all clear why you even need to protect it. What we can't see is what causes 'nighttime' to turn on. That's the only possible source of multiple executions of the rule.
For those who need to protect a rule from multiple simultaneous instances, the best approach is to use Private Boolean in a Conditional Trigger (rather than in a Required Expression).
I had a rule that wasn't doing what I expected. Moving the PB to the conditional trigger "fixed" it. Perhaps the documentation should be updated as the PB section mentions required expression usage but not usage as part of a conditional trigger.
I've always used PB as 'required expression' in my rules but will be sure to use the PB in conditional trigger in future. I'm not sure why it would be better that way but am interested to learn...
Rule Machine is awesome. Since in a couple years on Hubitat I'd never seen a problem from the feature toggle...I liked it. It was easy. I was clearly one of the lucky ones I guess.
IMHO that should simply be default for a rule. I know everybody has a use case...but I can't think of a single rule I would want to re-trigger while running that I have.
My preference has always been to be able to see everything in one place vs. having to jump from rule to rule trying to hunt down issues. Nightime and Morning are the longest ones of course since the most changes.
First, I wonder why you are using Private Boolean at all? I'm guessing it's because of the last section â run to shut off TV when falling asleep? I can see that the long delay before that section might cause it to run at or after 1:30. Could that section be moved to its own rule?
Second, I'm genuinely curious about why you have a delay between every step. I've only used a handful of delays in my rules, and always in a case like your last section, where I want to wait until I know that a previous step has completed before kicking off the next step. And I'm more likely to use Wait For Event --> Elapsed Time.
A hub reboot, in general, affects way less than people tend to think. Specifically, it does not erase and scheduled jobs, event subscriptions, etc. that an app put into place, which is likely tied to your PB reset (in your above example, some definitely are -- a delay is one way to create a scheduled job). Of course, if the hub is off when this job is supposed to happen, it will be missed, as would any real-world event that happens when the hub isn't up to listen for it (e.g., a Z-Wave switch turning on).
