RM[4] UI Confusion / Feedback

[grodik]

It's entirely possible that I'm still just not in the right frame of mind when I'm creating rules at this point, but I wanted to throw some feedback out there and see if I'm just being dumb, and if not, to hopefully provide some useful criticism as it relates to the UI!

I threw together a quick and simple rule here that simply checks for whether or not a door sensor is closed, and motion is inactive in one room. And if so, set a bunch of switches to Off.

These two sections here are at-odds, conditionally. If my understanding is correct, "Select Trigger Events" is intended as a place for you (the user) to list out all possible events for the rule¹. At which point, you then define how they're used in "Select Actions to Run" (makes sense to me). But as you can see, I'm using a logical AND, but they're displayed in the top box as being in a logical OR. Presumably this is just a display inconsistency?

Note 1: Assuming my understanding is correct, having the ability to add a new condition during the action definition (below), seems out of place to me. If this is here, why have the select triggers and events at all?

Additionally, if I add a new condition here (below), the newly created condition doesn't show up in the "Select Trigger Events" box on the main rule screen

• Note lack of date range condition in the trigger events

Stream of consciousness thought here, I suppose I understand the semantic distinction between a "Trigger Event" and a "Condition", but fundamentally, they're the same thing here, are they not? The condition is just one or many trigger events with logic, right?

Proposal
From a simplification perspective, the idea that I had addresses all of these.

1. The logical thought process might be to begin by thinking about what sensors/devices/etc are at play for the rule being created. All of these, with their desired state (eg: contact->closed) to be a list in "Trigger Events" (perhaps a rename of this box to "States, Triggers, and Events"). In my case my "States, Triggers, and Events" list would consist of [Bedroom Door: Closed, Multisensor: Inactive, Between Jan 1 and Feb 1]. A help question mark that describes what each are might be good as well.

2. The removal of OR in the current "Triggers and Events" box. I think functionally, this entire box should be nothing more than a list

3. The second box should be renamed to "Conditions and Actions" (since that's functionally what's happening there today). In there, the ability to add a "New Condition" during the actual conditional rule build out, needs to be fixed (see: removed). I say removed because the ability already exists to add sub conditions and negations - the part that actually needs to be removed is the ability to add additional "Trigger Events" (as they exist now) from that screen, which is what that option allows you to do.

[bertabcd1234]

@grodik

I'm using a logical AND, but they're displayed in the top box as being in a logical OR. Presumably this is just a display inconsistency?

No, anytime something in "Trigger" happens, the "Actions" will run. Your trigger is the sensor closing or the motion becoming inactive, as stated. You can make whatever you want happen in "Actions," whether its based on other conditions (more on that later), conditions based on your trigger(s) but combined with any logical (AND, OR, etc.) operators, or even no conditions at all if you just want the entire "Actions" to run anytime anything in "Triggers" happens.

Also, triggers are always "OR"--the "Actions" section will run any time any of these happens, which you seem to indicate understanding later in your post (I could see the other side of this argument where a new user would mistakenly think they all need to happen, though further thought should show that isn't possible since these are instantaneous events).

@grodik

having the ability to add a new condition during the action definition (below), seems out of place to me. If this is here, why have the select triggers and events at all?

Because sometimes you will want to test for conditions that are not related to your triggers. For example, suppose a you have a rule that triggers on a contact sensor's contact state changing, but you only want some (or all) actions to run between a certain time--that's a different condition. Or suppose you have a rule that triggers on a motion sensor becoming inactive but only want something to happen if a contact sensor is open (and don't care if the contact sensor opens after motion is already inactive)--then your motion sensor would be used in the trigger, and the contact sensor would be an additional condition. (If you want something to happen, or at least to be able to test for something and maybe make something happen, any time either changes, then you would indeed need both as triggers.)

@grodik

Additionally, if I add a new condition here (below), the newly created condition doesn't show up in the "Select Trigger Events" box on the main rule screen

Correct. Rule Machine is just being nice and automatically creating conditions based on your triggers under the assumption that you'll probably want to use them for conditionals in your actions (e.g., if you create a "contact sensor changed" trigger, it will automatically make a "contact sensor open" or something conditional since a very common pattern would be to do an IF ... ELSE ... END-IF testing for that). The reverse would not make sense for reasons that are hopefully now clear from the previous explanation.

@grodik

I suppose I understand the semantic distinction between a "Trigger Event" and a "Condition", but fundamentally, they're the same thing here, are they not?

I hope it is now clear that they aren't, but perhaps it's just terminology as to what "condition" means. It used to be a bigger deal in older versions of RM; now, it's, basically something you can use to complete an "IF..." when defining the actions for a rule, assuming you need conditional logic in your rule at all.

Hoepfully, this clears up some of the proposals you'd make, but if not, I'd highly recommend reading the docs if you haven't already. I know it sounds boring, but they're highly informative. Here they are: [Released] Rule 4.0 (also available on docs.hubitat.com)

And if you're trying to do something but are having problems figuring out how, feel free to ask for help! And also don't be afraid to look at Hubitat's built-in apps--there are a lot, and Rule Machine is there to help when one doesn't already do what you want (lots of people make their lives harder by creating rules for simple motion-based lighting when there are two stock apps that can handle many of these cases already).

[grodik]

This all makes insanely good sense. Thank you Excellent write up with really great descriptions and examples. Kudos!