Has anyone else noticed rules not triggering despite conditions being met?
Iāve got 2 rules on 2 different hubs that havenāt been changed recently and were working a couple of HE revisions ago.
I know the rules work, because I can see that the conditions have been met, and if I hit run, they do what they are intended to do.
Eg
Both hubs are on N-1
May or not be the same but I had a lighting rule I wrote in rule machine that stopped triggering as well. All the sensors showed to be activating as they should but the rule just would not trigger. I went into the rule and hit update rule as if I made a change but I did not. Then of course done to exit the rule. After it took me back out to my apps list I disabled the rule waited about 5 seconds and enabled it again. Then the rule went to working correctly and has worked since. I have no idea why this would have happened nor if it will help in your case but it is something simple you may want to try. Hope it does work for you.
The only common things between my 2 rules and 2 hubs, is both rules had āignore trigger events while runningā timed on and use temperature changes to trigger the rules.
Iām wondering if the private Boolean under the hood of this feature got stuck, so Iāve turned this off and will advise if the rules work by themselves today.
This is the second rule on my other hub and the conditions are met for it to turn on the fan.
@bravenel looks like my suspicion was correct, after turning off ā ignore trigger events while runningā, both of my rules are now working again.
Is there a way to reset the under the hood mechanism in RM when this happens?
This rule is really simple and has no scheduled delays, so I donāt see any reason why it would get āstuckā.
Hitting Update clears it out. But, this feature appears to be the source of more problems than it's worth, so it's coming out in the next release.
Is there a way to find rules that are using this feature without opening each one to see if it's turned on? Will there be some step during the upgrade to the next release that notifies the user which rules were affected by the removal of the feature?
No there isn't.
No, there won't be such a step.
So I guess anyone who has used this feature needs to open up every rule and check the switch before upgrading to the next version? I better start now...
Not really. You don't have to do that.
But if I'm relying on it to prevent multiple simultaneous rule execution, I'm going to need to modify the rules to use a Private Boolean (or maybe move the affected rules to Node Red where I can have more definite control over multiple instances of a flow). When I've checked that switch, it's been for a good reason where multiple instances of the rule running at once will mess things up.
Fair enough.
It would be nice if there was a better way to do it, as it makes a noticeable, cumulative difference to hub loads when you have 2 dozen rules and many of them are triggered by temp changes.
I guess this comes back to our discussion on Multi threading in RM. I honestly think itās overly complicated.
IMHO, a better concept would be to make all rules execute serially by default, and if folk want multi threading, they can call other rules as sub-routines. KISS principal basically.
/2.5c
How this case will be handled?
You just said, the feature will be removed without any warnings and that is it.
At least that wasn't too painful for my setup.
Control-click to open each rule in a new tab (I did a few letters of the alphabet at a time) --> Click on each tab and scroll down to check the status of the switch --> Control-W to close the tab if the switch wasn't enabled --> Check each tab that's still open to see what needs to be done to the rule.
When I was done I had about 10 rules across two hubs using this feature. I ended up re-implementing a Private Boolean on one rule and moved one rule to Node Red. I found one rule with no delayed actions where the switch was probably on by mistake. I had a handful of rules that will probably be OK as-is when the feature disappears even though they have delayed actions. I put a note on those rules to remind me that it was using this feature so if they act up in the future I'll know I need to add a PB to limit them.
Pretty much same boat here - back to PBs in several cases, and a few rules where it was added in an abundance of caution, but should be fine without.
It's not RM per se that is multi-threaded, it's the entire platform. That's necessary for it to be a hub. So singling out RM is off base. Any app can have multiple instances, and can be triggered while running. It's the nature of the beast.
Whoa, isn't this a warning?
One other option, that doesnāt rewrite a full RM rewrite, is to label functions that schedule tasks more clearly. This would help new users and those of us with autism who canāt recall the difference because the wording is too similar. Eg
A Delay that schedules a task and keeps running through the rule could be called āScheduled Delayā, or āScheduled Waitā.
And a delay causes a rule to stop in place while waiting could be called āpause rule forā, or āpause execution whileā or something like that.
Basically, RM should use language that makes it crystal clear when an action is scheduled and the rule will keep running after the action has been sent to the HE scheduler.
This would remove a lot of confusion and requests for help, without a major rewrite of RM.
Iām going to do the same, although I donāt like PBās due to their habit of getting stuck as a result of a reboot or other unknown circumstances - although at least you can see when they get that way.
It strikes me as arrogant to assume that you know what wording will fix things for all users, new and experienced alike.
And the reason the feature is being removed is because it evidently can get stuck in some edge case situations, and you can't see that it's stuck.
A better suggestion: don't write rules that would suffer from multiple instances.
How is suggesting clearer, more concise labelling being arrogant?
Iāve spent a good portion of my career in IT writing end-user documentation, and communicating Major Incidents to non-IT people, so i would like to think I have a pretty good understanding of how to communicate concepts clearly.
The rules execute without issues, but running them serially reduces the load on my hubs, increasing responsiveness.
Download the Hubitat app
