Hub is C7, platform is 2.4.4.156
Here is a very simple rule with Conditional Trgger
And here is a log:
It looks like on the EVENT the Condition evaluates BEFORE Trigger.
This is incorrect. The Condition before a Trigger is TRUE and Trigger must start the rule. Then Condition must be re-evaluated. Yes, in this case the Trigger and Condition is the same Device, but it should not matter because Trigger must be first in line.
This is typical Race Condition case and should be fixed.
This is clearly addressed in the RM Documentation:
Well OK, but this is incorrect and illogical implementation.
Yes, the Condition must be True BEFORE the Trigger.
And it is True before the Trigger.
The sequence should be:
Event happens (trigger) -> Condition is True -> Run Actions -> Re-evaluate the Condition(s).
Current implementation is:
Event happens (trigger) -> Re-evaluate the Condition(s)(wrong place for re-evaluating a conditions) -> Condition is True -> Run Actions.
No, it's just not what you were looking for.
Says who? The documentation is correct, and both the implementation and documentation match the intent of the developer. That intent, more or less, is just to save a few clicks compared to using conditionals in your actions (which, of course, also happen after triggering) or to allow evaluation only in response to a specific trigger event (probably do-able somehow otherwise but a lot easier this way should anyone have a use for it).
If you are looking to capture specific state changes, as it looks like you are in your rule, then you are looking for a required expression -- or any older way (these were not introduced until Rule 5.0, and people found ways before this) of capturing the same change. But, of course, an explanation of the actual automation you're trying to create would get you better help if you are looking for ideas.
Nope, it's consistent (and correct and correctly and clearly documented) behavior -- in case that still needs to be said. 
There is no re-evaluation, there's just the one evaluation after the trigger event.
Your proposed flow makes no sense - why would you re-evaluate the trigger's condition after the whole rule already fired?
Oh well.
If I design HW following current logic nothing will work correctly.
And just to implement this in HW it will take extra useless logic and extra clocks.
Current implementation is simply incorrect. But it is what it is ...
It makes a lot of sense.
Event happens, Condition already evaluated and it is True -> Run Action.
And sure, Conditions may change at this time but AFTER Actions are running.
And BTW, Actions may and will change a Conditions.
Again, it is correct; it just doesn't work the way you assumed it did. Wanting a feature to work differently is a perfectly fine opinion to have, but it doesn't make something else "incorrect."
If you are looking for help creating an automation that does what you want, please share what you are having trouble with -- otherwise that's just the way things are. 
(And the feature cannot change, because that would be a bug for anyone who's been using this feature as intended for the last several years.)
My assumption is very logical and follows common sense.
I.e if the Condition is True before the Event happened -> Run Actions.
And Event may or may not change a Condition. This is secondary.
Again, this is what happens in real life:
Events -> Actions -> New Conditions.
What is wrong with this picture?
But the problem is:
Conditions are Simple Logic and must not be event driven in a first place.
This was already discussed many times and I donāt want to continue this discussion again.
What you seem to be describing there sure sounds a lot like a Required Expression (which is not the same thing as a Trigger Conditional).
But logic-wise these two should not be different.
One is a Global Gate. Second one is a Gate per Event.
The RM Documentation does a very nice job (IMO) explaining how each works. While both are indeed gates for the trigger, the timing of their respective evaluations WRT the trigger event is what makes each option uniquely useful.
What makes them uniquely useful is the trigger-specific gating (as opposed to global - affecting all rule triggers - for REs).
AFAIK the "timing difference" is a side effect of the implementation, as, contrary to required expressions, trigger conditionals don't have their own event subscriptions, so there is no opportunity to evaluate them outside of the context of the trigger's event.
Is balcony open/close a binary switch? I am trying to understand the logic of a conditional trigger for something turning off that requires it to be on? If it's binary, what other state could it be in?
Yes.
That was a simple test.
Near all my automations are StateMachine-based (eventually all rules will be SMs). The "Required Expression" works just fine for gating SM States but because it is event driven it may not be correct under certain circumstances circumstances (occasionally this happens). My goal is nearly 100% robustness by design.
Here is a very simplistic view of RE vs conditional triggering.
Letās assume triggers are āwatchersā for events.
Also assume that they can be actively watching (enabled) or not currently looking (disabled)
When a RE is false, the triggers will be ādisabledā, I.e., not even looking.
When RE turns true, the triggers will be āenabledā and start watching for event.
When it āfindsā event, rule runs.
Conditional triggers are āenabledā and ādisabledā by RE like any other trigger
If no RE or RE is true they are enabled and watching for their event.
When they āseeā the event, they donāt automatically run the rule, they first evaluate their conditional and if it is true, run the rule.
Otherwise they go back to watching.
Feel free to correct my simplification.
The Required Expression (RE) is a Global Gate for running Rule.
I.e the Rule will Trigger and run Actions only if the RE is TRUE.
The Conditional Trigger logically is the same but applicable to only a specific Trigger.
Timing for both these cases should/must be the same but it is not (unfortunately).
Simply put,
The Triggers create subscriptions to events (i.e. "watchers")
Required Expressions ALSO create subscriptions to events (sorta like a rule to enable/disable the rule)
Events are changes in state (requires an ACTION verb - Opens, Closes, Turns on/off, etc). Conditions are the states before/after the change (Requires a linking verb - is/are/etc).
Door is open = State
Door is closed = State
Door becomes open = Event
Door becomes closed = Event
You subscribe to events, not states
The "trigger" for a required expression is the Event that makes the expression true/false, even though it reads like a condition.
Conditions on conditional triggers DO NOT create subscriptions. The "condition" isn't an event, it's a state that gets evaluated once it has been triggered by the associated event.
I think the biggest difference between that and an if block is just that it gets evaluated before any other actions run. So, it is useful if you have multiple triggers and want to specify conditions to check without having to write an overly complicated if block (which could therotically do the same thing)
You missed the key issue here:
If RE is false, no trigger code will be executed. Itās the same as is the trigger(s) didnāt exist.
[In the absence of RE. or if RE is true] trigger code WILL run if event occurs and THEN the trigger condition is tested.
You keep saying this, and maybe it's a sort of mistranslation, but it's not true. The fact that you want it to work differently (and actively refuse to read the documentation to understand the difference before making a false bug report -- the original title of this topic) does not change that fact. Perhaps what you mean to say is something like "I assumed it would work differently" or "I wish it worked differently."
Required expressions and conditional triggers are different features with different uses (and different names), all working as intended, clearly documented, and in use for years by many users with Rules using these features.
Download the Hubitat app
