Heads up if you have presence sensors as a trigger and use the "changed" mode, RM actions may not run in rules created pre 2.2.7 if the sensor goes from not present to present (actions run fine the other way around). At least this is what happened to me after doing the update from 2.2.6 yesterday.
Fortunately recreating the rule solves the issue. Although I am curious as to the cause of this.
Yep. I had the same problem - noticed several days after my update, but figured it was the update...
Do you still have the rule, or did you delete it? In some cases, removing and re-adding the trigger will resolve the issue - I wonder if it would have applied here.
There are some cases where stopping and re-starting the rule will work, but again, not sure it would have applied in this caseā¦
I initially thought the battery on my sensor had died (only 6 months old, usually they last 12 months) so spent half an hour chasing this down 
I changed the rule to have 2 triggers -- one for present, one for not present -- and it worked. Since then, I've restructured and consolidated several rules, so this specific rule no longer exists
Tried that 
I still have the same rule for another sensor - I'll try that later just to be sure. It is strange that this only affects the trigger in a highly specific way.
Nope - needed to recreate the rule. @bravenel any thoughts? So far I haven't experienced any other RM issues - these are the only rules I have that triggers on change.
There appears to be a bug in Rule with respect to changed. Not sure exactly what's happening in your case, but there will be a fix in the next release.
Best practices for RM with respect to changed are this: If you are triggering with changed, and then using a Conditional Action in the actions to test which value the device has, and then act accordingly, don't do that. Instead, split the rule into two rules each triggered by the appropriate device value.
Understood your best practice recommendation to split into two rules. But, for those changed triggers with only two states (switch on/off, Custom attribute number 1/0, power source mains/battery, etc.), would it also work to add both states as a trigger? Sometimes, for critical regions (e.g., Exit Rule if Private Boolean False idiom), itās necessary to keep everything in a single Rule.
Both states might as well be changed, exact same outcome. For critical regions with two rules, just use a global variable, or soon, hub variable. I can't see why it would be necessary to keep everything in a single rule.
It's just an odd practice to throw away event information just to test the result immediately after throwing it away. The only gain is that there are fewer rules in the list of apps, which is hardly an important consideration -- trading cosmetics for function. Hence, I say 'best practice' is for individual events to cause individual actions.
Understood, but I believe that a Deadly Embrace might be possible unless there is a guarantee that a systemStart triggered Rule could run to completion to initialize critical region Global Variable semaphores.
Perhaps, if you are adding a new feature of Hub Variables, they could have a preference/switch to initialize them on systemStart.
Is there a way in RM to test the event that triggered? It is available (%device% and %value%) in notifications, so it must not be "thrown away", but it seems not available for conditionals.
Here is a rule (Rule-4.0) that uses PB like @672southmain mentioned (I think):
Simplicity, performance and ease of use. Just gave you 3. I have several rules that magically stopped working because I use the "changed" trigger and couldn't figure out why. Re-creating them resolves it, but honestly I'm spending more time re-creating rules than enjoying the product. Very annoying!
For example I have a rule the opens or closes the shades behind my TV when I turn it on. One rule with the "changed" trigger is perfect enough for the rule to use a condition where "if TV = on, close, else if TV = off, open". Why do I all the sudden need to duplicate all my rules when I've spent so much time simplifying them to have as few rules of possible? Especially when there are countless posts here about RM and hub performance.
You can do it however you want! All Iām saying is that using changed makes those rules less efficient. But, thatās pretty much irrelevant as any approach that works is ok. Iām not saying that you need to do anything.
There is so much poor quality information that floats around here. Would you prefer that I not explain these things?
The rule posted above with two triggers from Tony has redundant triggers. That means it will trigger twice for each Front Door Sensor active event. No wonder it needs PB to stop it from running twice ā because itās being told to run twice. The hub is multi-threaded, so it will launch that rule twice within milliseconds.
Itās tempting to retire changed ā¦
I actually appreciate the explanation, I am just not sure if I understand it.
Are you saying that triggering two different rules is more efficient than triggering one rule twice?
I'm not clear how I can get the behavior I want without triggering on both the acceleration and the contact (it just happens that this is one device that provides both capabilities).
I'm sorry, your rule is fine. I didn't look closely enough last night to see that you are using two attributes for triggers.
The type of rule I intended to address is like this one:
These are better done like this:
Does the issue appear both in Rule 4.0 and Rule 4.1 rules?
When the fix appears, will we need to go into every rule using a * changed * trigger and click Done? Or, instead, will all of those rules just start working correctly?
No, fix will just work.
Blockquote
Maybe there should be a change so that for multiple triggers they are "grouped" and treated as a single trigger when one of the "group" fires? I would have assumed that is how that worked already until I read your reply there.
Devices generate events, and those events have attributes. For example, a multi-sensor may generate a contact.open event or an acceleration.active event (and many others). These are distinct events, and in the case of Tony's rule, either will trigger the rule. Notice that the rule display says this event OR this other event. The issue that arises is that opening the door will cause both of those events to happen, and consequently the rule will be triggered twice. In the case of Tony's rule, this is ok and works as expected, and is the reason he put the delays in the rule. It is non-deterministic which of those two events will trigger first, and the rule has to work for either order.
I'm not sure what grouping of triggers would mean. The device is still going to throw those events; the app is still going to have subscriptions to them. In Tony's case it needs both events and both subscriptions so that it can distinguish between the door opening, closing, or being knocked on.
Download the Hubitat app
