Required Expression vs Conditional Action?

I don’t believe I’m fully understanding the purpose of Required Expressions.

It appears Conditions can be specified in a Required Expression or as the first (Conditional) Action.

I’m interested to hear your perspective on these two approaches.

1 Like

There's probably a few reasons for using req'd expressions, and I am being lazy and not looking up the documentation of even the original post when they were added.... Something I would recommend....
EDIT: And I finally took my advice... And by a nice surprise the scenario I mention below for mode changes does make a mention... :slight_smile: Though it does leave it open for interpretation as to whether my first reason for chatty devices is indeed valid....

But two scenarios that can make them useful are:

  • If you have a "chatty" device / event used in the trigger, a required expression can help reduce the number of times the rule is fired up to assess the condition

  • Bruce recently suggested I use it to detect the transition from one mode to another, using a required expression to detect the before and the trigger to detect the "to". Maybe you can do this somehow using a condition, but not from what I have seen.


I use them a lot and it just keeps the rest of the rule from having to be evaluated if the most basic of requirements are not met. For example for me a few are:

I have a virtual switch for when my cleaning team is here. At that time I want my motion rules all off and I turn all the lights on. So I require that switch to be off for my rules that have motion triggers.

To expand on that further I have a lux sensor in the bedroom and if it's bright enough from outdoor light I don't want the lights coming on so in addition to the virtual cleaning switch the brightness in the room must also be low for the rule to even evaluate the trigger.

I have another that will trip a virtual switch that will get Alexa to start playing music if there is motion in the kitchen for more than 3 minutes. But I don't want that rule to trigger if the TV is on or the cleaning people are here so I require the TV to be off and the virtual cleaning switch to be off as well as the mode to be day. Don't want music if I happen to be up early and in the kitchen as I don't want to wake anyone.

Basically you could work just fine without the required expression ability but it really helps clean up the rest of the rule. At least it did for me I went back and added it to quite a few rules and it really shortened them up a lot.


Many things in Rule Machine used to be most easily done using multiple rules. Some of the most common patterns have now been implemented directly within Rule Machine, and this is one.

Required Expressions are equivalent to a helper rule that says, "IF (XXX) Resume Rule Foo, ELSE Pause Rule Foo".

Sure, you could bail out at the start of the rule, but if it's a trigger that happens often, there's no reason to fire every time it happens only to bail out on the first line.

(That said, "IF NOT XXX, Exit Rule" remains a very useful pattern.)


I think the others have good examples of why Required Expression. Mine would be similar to Tivomaniacs example.

If Mode is "X" don't run certain rules would be another example. That way you have a very broad filter where if you are in say Away mode, things don't activate or run. They can only run when you are home.

Days of the week also is a good use case for Required Expression. You only want to run the rule on Sunday. No need to go through triggers, evaluation of conditions, and all that when the rule could sit dormant for 6 days at a time.

It may be worthwhile for someone to post a little blurb about what to look for in Past Logs which suggest the need for a Required Expression. For instance (and I'm not offering this as a concrete example) if you repeatedly see lots of "skipped" IF clauses in RM throughout a 24-hour period.

I strongly suspect "Required Expression" and "Private Boolean" are among the most under-utilized features of RM, but to date haven't encountered any exhaustive tutorial on implementing them. You guys are fleshing it out nicely for future readers!

Triggers and Required Expressions
Required Expression (formally Predicate Rule) Documentation
RM 5.1 Local Variable in Required Expression

There are some subtle differences worth being aware of.

When a Required Expression element overlaps with a Trigger, then it is the state of the Required Expression before the trigger event itself that is applicable. This allows for state transitions to be dealt with. This is not directly possible with conditional action, because those evaluations happen after the state of whatever has already changed.

For example, Required Expression that mode is Away, and trigger of mode changed: This could be used for a rule that should only run for the specific case of transitioning from Away. At the instant of the mode event that would trigger the rule, if the mode was not Away the Required Expression would be false, and the trigger would not fire.

This same approach is possible with device attribute values as well.

Another significant advantage of Required Expression (when there is not a trigger overlap as just described), is that when the Required Expression becomes false, the triggers of the rule are unsubscribed / unscheduled. The rule will have subscriptions to events or schedules that might change the Required Expression state, but not subscriptions to the triggers. I have some shades that open and close daily between April and August only. So after a specific date in August, that rule is completely quiescent until April, when it will awake from a scheduled job to begin its daily routine.


Is Required Expression evaluated when Run Actions is called from another rule?

In other words, if the RE is false and another rule says to run the actions - will the actions run, or not? I suspect they will run and RE only prevents "triggered" events from running the rule itself.

The answer depends on the setting of this option:

If that option is selected, as shown, then the Required Expression would be evaluated prior to running the actions. Otherwise, they would run.

This would be very easy for you to test.

1 Like

Hello Bruce, it seems like the "mode before and after" example you mentioned and that is documented in the link shared earlier does not work if the "cancel pending actions toggle" is enabled for the required expression. Consider this simple (admittedly contrived) rule:

When we change the Mode to Day, we can see that the Here message is NOT logged:

However, if we just disable the "cancel pending actions toggle", it works as expected:

Is this expected?

From what you've shown I can't tell what is going on. Please turn on all logging for both rules, then use screenshots of the logs.

Apologies, I enabled all three logs for the rule (I recreated it).

With "cancel pending actions toggle" enabled:

With "cancel pending actions toggle" DISABLED:

Re-enabling the toggle regresses behavior (i.e. no Here logged on mode change):

Please let me know if anymore information is desired.

I don't understand your question, must be dense. It's impossible for me to actually read logs from a mobile device.

Sorry, I do not mean to make the question difficult.

I am saying, in the example of "use required expression to check what the previous mode was when changing to a new mode" does not actually run the rule actions if the "cancel pending actions toggle" is enabled.

Here is a screenshot of the rule from my laptop:

Here is a screenshot of the last logs in my previous reply from my laptop:

In this screenshot, you can see there is only one Here logged, which is the action of the rule. However, from the logs, you can see that the hub changes mode such that the rule should trigger, with a valid required expression, three times. The only time the actions actually execute, and log the message, is when I turn off the "cancel pending actions toggle " for the required expression.

All I did to reproduce this was create the rule as shown above, and just use the mode manager app to toggle between two modes such that it should trigger this rule.

I apologize if I'm not being clear.

The case where the Required Expression and the Trigger use the same event is a special case and apparently has a subtle bug, where it's flipping the truth of Required Expression too early when Cancel pending actions is selected. Fix will be in the next release. See these logs post fix (rule just like yours with mode Day as the trigger and Required Expression test:


Excellent. Thank you.