Are you already using Private Boolean for anything? Because if not, that is an easy option, and it is available for predicate conditions (other rules can modify its value, so it's not 100% private/local). Otherwise, the general suggestion for the situation you describe is to use a variable connector, which is a device and thus generates events on value changes--which variables, even global variables, do not (at least in their current implementation, and possibly never).
For your very specific question, however, I'm not Bruce and would be curious what his recommendation is, but my recommendation would be to carefully consider your triggers so this is unlikely to happen (fewer triggers/devices are generally better; targeted triggers like "motion active" are generally better than "motion changed"); carefully weigh the actions you use (e.g., waits vs. delays; waits are automatically cancelled on retrigger and can often be used to your advantage in this regard, and the fact that waits can dynamically create subscriptions ties nicely in with the suggestion to use targeted triggers--you can still do something on "motion inactive" this way in my example before); or to try to address things at the device/driver level if the problem you're really trying to work around a problem there (e.g., a contact sensor that sends duplicate events in quick succession).
I have a lot of virtual switches that are basically just state variables. Or they exist to allow those states to be modified by voice. E.g. "Hey Google, turn on/off Movie Mode." Google sees it as a switch, but it actually turns certain lights off, others on, and adjusts dimmers.
So now I have another thing about which to repeat quietly, "If it's not broken, don't fix it."
No. All Rule Machine (Legacy) rules will continue to work and be editable. You just will not be able to create any new legacy rules starting with 2.2.9.
If desired, a way around this is to create a clone of a blank legacy rule now and use that clone as a starting point in the future.
A minor point, and maybe I missed something. I just started looking at RM 5.0 and converting some of my rules using Hub Variables.
When I go to advanced settings to add/change hub variables, the APP tab is highlighted to the left which would imply I can get to the hub variables directly from the Apps tab. It occurs to me that it would in fact be more convenient to get to the hub variables settings directly from within the apps page without having to go out to the settings page then back in, then vice versa to get back to the app. It just seems that one is usually updating hub variables while writing/updating an app.
Another minor issue: when adding predicate conditions you are unable to add from existing conditions if they have already been created elsewhere in the rule, you can only create new predicate conditions, unless you are editing the predicate expression.
Adding conditions overall is a bit cumbersome and easy to get out of synch with the flow of the editor, especially if you have to go back and change or delete / re-add any conditions.
This is intentional. The conditions are kept entirely separate. Shared conditions introduced two issues: First, it is possible to define conditions in the actions of a rule that cannot be used as a Predicate condition. By allowing the selection of such conditions, the Predicate Conditions would not work. Secondly, If there are conditions defined by an action, and that action is deleted, the the conditions are deleted also. This too would break the Predicate Conditions. Hence, there is a need to keep them separate.
That's what I also thought initially, however it seems that both predicate conditions and if/then conditions are showing up in the CONDITIONS block and can be deleted/edited. Also, if you go into EDIT PREDICATE and EDIT PREDICATE EXPRESSION, the full list of existing conditionals may be added into the predicate expression.
Also agree with @damianm. I haven't seen conditions deleted when the actions are deleted, but they have to be deleted manually from the conditions manager. Rather I have found that when adding predicate conditions (without going into the expression editor), this adds duplicate conditions to the conditions manager. With duplicated conditions, if you are going in later to edit the condition, you are unable to tell which part of the rule that condition is actually linked to.
Deleting the condition will leave a blank in the rule, when you later have to go back and correct.
This has led to unstable behavior, including a case where I was unable to edit/delete a broken action. When I tried to edit the broken action and tried to add a new action, when I selected the type of action, the second pull-up window never showed up. I was unable to get out of this state. Rather I suspect I should have deleted the broken action, then added a new action.
I'm sorry for the confusion -- on me. I'm between versions. In the upcoming version Predicate Conditions are kept entirely separate from all other conditions. When one goes into Manage Conditions in the Predicate Conditions section, conditions from actions will not appear, and vice versa.
When you create the connector you pick what type of device it is (it's virtual, but may be any number of different device types). Then the connector will show up as something you can select by using that device type in Predicate Conditions.
Variables coming to Predicate Conditions (and Triggers) in 2.2.9.
I've never found this to be the case for me, or am I reading this wrong?
