RM Conditional Triggers

[vitaliy_kh]

I was the one who asked for the Conditional Triggers option.
This option appeared implemented in the latest 2.3.6.xyz platform release.
As a first try I was able to convert two separate related rules into single one but only because
I new exactly what I wanted. Unfortunately the new/updated GUI is not intuitive.

Here are two original rules (first one):

and a second one:

The idea is to trigger each rule only once depend on current Stove On/Off status.

And here is a combined single rule with the Conditional Triggers and exactly the same ;ogic
(it is not yet tested but I hope it will work):

Now the same set of Conditions is used for the Conditional Triggers and Conditional Actions.
This is OK but why the same "Manage Conditions" is presented twice (on the main rule page
and on the Actions page)? This is a bit confusing. More logical will be to show it just on the main
rule page. There is no need to show it on the Actions page, But if anything, it will be better make
it not editable on the Action page.

For the Conditional Triggers AND, OR, NOT, etc. logic is unavailable (most likely due some
implementation limitations). This requires to create a separate conditions say for "true" and "false"
states for the same variable in the example above. Actually this restriction may not be bad
because it makes rule more readable.

Bottom line:
This new option is very useful "as is" because it allows to easily restrict unwanted Triggers
(or rule re-triggering) and gives a possibility to create a single better readable rule instead
of creating set of related rules.
BIG Thank you for this improvement.

[bravenel]

@vitaliy_kh

This is OK but why the same "Manage Conditions" is presented twice (on the main rule page
and on the Actions page)?

Because you might need it in either of those UI contexts. It used to be only on the Actions page.

@vitaliy_kh

More logical will be to show it just on the main
rule page. There is no need to show it on the Actions page,

Well, for one thing, why would we change what people already know and expect? And second, why make the user go to a different page if he needs to create a Condition for a Conditional Action? Conditional Actions would still be the most common use of Conditions.

@vitaliy_kh

But if anything, it will be better make it not editable on the Action page.

Same as above, what's the point of making the UI harder to use? It's the same page that you get to from either starting point.

@vitaliy_kh

For the Conditional Triggers AND, OR, NOT, etc. logic is unavailable (most likely due some
implementation limitations).

Whoa, those aren't Conditions! That would be an Expression. This feature is not intended to place an entire Expression in front of a Trigger. Sorry, but not going there.

@vitaliy_kh

This new option is very useful "as is"

Striking a balance between understandability, complexity, UI usability, code sanity, and feature requests is only an art form. I'm the artist who has to find that balance. I'm certainly not Michelangelo, but this seems a reasonable design extension.

[vitaliy_kh]

@bravenel

Well, for one thing, why would we change what people already know and expect? And second, why make the user go to a different page if he needs to create a Condition for a Conditional Action? Conditional Actions would still be the most common use of Conditions.

Your points are valid but the ability to modify something in more than one place is confusing.
Could be just for myself.

@bravenel

Whoa, those aren't Conditions! That would be an Expression.

Well, this is philosophical question rather than technical.
I am seeing EXPRESSION as a CONDITION but please forget about it.

@bravenel

Sorry, but not going there.

Current implementation is perfectly fine.

@bravenel

Striking a balance between understandability, complexity, UI usability, code sanity, and feature requests is only an art form. I'm the artist who has to find that balance. I'm certainly not Michelangelo, but this seems a reasonable design extension.

Yes, this is very desired and reasonable design extension.
And once again, Thank You very much for this option. It really helps.

BTW, I just tested one modified rule and everything works as expected.

[bravenel]

RM is built upon certain basic building blocks. Defining a Condition is one, and evaluating a Condition is another. So it didn't take a lot of contortion to add this feature.