I am confused about what I am saying wrong and where misunderstanding is.
Both are nothing more than an AND Gate for the Triggers.
The Required Expression is a Global Gate.
The Conditional Trigger is a Gate for a specific Trigger.
Both are doing the exact same thing, i.e. preventing to run rule Actions.
They are implemented differently and as a result have very different timing
but this is irrelevant to the intended use. Which is āDo not run rule if condition is FALSEā.
Now please convince me they are doing different things.
No, you are missing the point.
I said exactly the same "... the Rule will Trigger and run Actions only if the RE is TRUE".
And we are not talking about implementation details.
Please be more specific: Which point(s) I am missing?
Regarding Logic I am saying the same things in a different word.
Regarding Timing, the Conditional Trigger implementation is incorrect. Nobody can convince me that Condition should be evaluated AFTER the Event and then be applied to the same Event. It smells like Time Machine is invented. But it is what it is and I have to leave with it.
There is something that you are missing here. Yes, the regular expression and the conditional expression are AND gates for the rule to run based on the trigger.
Once the regular expression is true, it takes a finite amount of time to instantiate the trigger, during which a trigger could be missed.. After that, it will fire whenever the event occurs.
When the RE becomes false, likewise there is a small window during which a trigger could (improperly) fire, before it is deactivated.
These āwindowsā donāt occur with only conditional triggers. But there is a possibility that the event that caused the firing of the trigger could also have a side effect that alters the condition and what was true āwhenā the trigger fired is no longer true.
Although these are subtle difference they are definitely differences.
These are āside effectsā of a Real World Event Driven machine.
If you overlook those points, and ignore the ācostā of executing all the triggers whose conditions fail, you could say they are not different.
Not really true. The required expression generates a subscription to the event that makes the state. If you have a required expression for a door to be open, the Rule subscribes to the Open/Close events and then enables/disables the rule accordingly. I mentioned this above.
Regular conditionals (and those on triggers) are not subscribed to the event. They are only evaluated after having been triggered by the main trigger event of the rule (not the required expression, but what is listed in the trigger section).
Conditional triggers are evaluate BEFORE any other actions but after the trigger.
Other condititionals are evaluated in the sequence laid out by the trigger
You keep trying to equate them to each other. But this is not the case. As has been said before, this is explained in the documentation. Even if others were to accept your thoughts on "how it should be," the reality is that it is working as stated in the documentation.
If you want to do things differently from how RM works perhaps a different approach would be more effective. There is a state machine community app. And paid AIs do Hubitat Groovy pretty well these days.
I have no problem designing logic (i.e. rules) with any complexity. The RM is my primary engine for all my Automations. Something does not make sense even if documentation is correct. But it is what it is.
And yes, I am the one who never reads a documentation well, occasionally I have to read docs for not obvious details). Everything must be self-explanatory and logical.
As a fellow EE, I get what you're saying, but it's not the right analogy.
Trigger conditionals are simply not trigger-specific equivalents to required expressions. I get that you believe it would be logical if they were, but they aren't.
As I and others have explained, REs disable all triggers - the triggers don't exist when the RE is false as the trigger events are not subscribed - only the events that can change the required expression evaluation are subscribed.
In contrast, trigger conditionals don't track device attribute or variable changes that could affect the conditional's evaluation, as trigger conditionals don't have event subscriptions. Therefore the only "time" the conditional can be evaluated is when the trigger fires. There is no other opportunity. To further emphasize this point, look up how conditional triggers work when they are made sticky (with a "and stays").
So sure, we can think of them as "gates from a specific trigger" but it's a very different kind of gate than REs at a "global" (rule) level, so the AND gate analogy falls apart.
Again, this is an IMPLEMENTATION details which are IRELEVANT to the intended logic.
As an EE think about how you will implement a Conditional Trigger āas isā?
You will need extra logic and extra clocks for aligning things backwards.
Gate is Open;
The Event goes through the Open Gate and should execute all the related Actions. But the same Event changes the State of Gate (not a problem);
Now gate is Closed which timewise and logicaly is absolutely OK.
However, now the extra logic looks backwards, sees a Closed Gate and prevents execution of whatever should be executed because the Gate was Opened BEFORE the Event happened.
I am not sure if I made my point clear enough but:
if āyesā does this make any sense?
if "no" forget about this discussion all together.
What I (and others, I think) object to is that what you call an implementation detail is actually the design intention, which isn't irrelevant.
It's like saying it's bad practice to have gates after the D latch to derive the state bit, rather than put all the logic upstream of the D and using the D state directly, after the clock edge. Well, yes. But RM isn't a synchronous SM and the behaviour you are observing is, apparently, what the designer intended to do here.
What is everyone see in a Select Trigger Events field?
My good guess, everyone will clearly see the Condition is True.
What will everyone expect in case of Event?
The Condition right before the Event is True.
All Actions must be Executed.
Right?
Tell me please what is not right with this picture?
Ops, Log says: Not Triggered because the condition is FALSE.
Why suddenly TRUE condition became FALSE?
Someone can argue that the Event changed a Condition State.
This is 100% correct. But timewise the Event was FIRST in time and a new Condition State FOLLOWED the Event.
I wish, I can talk directly to everybody who will say this is OK.
I am sorry to say this, but this implementation is 100% illogical.
This is clearly a BUG but unfortunately accepted by community.
Yes, and it is absolutely possible to write apps for Hubitat that are both event driven and designed as state machines in Groovy. The cheat code is to define the app with singleThreaded: true. Then the event stream, from the POV of the app, is completely serialized and delivered in chronological order. A sort of "clock".
I've written a few nice ones myself (if I may say so).
