Really?
Long time ago Bruce mentioned that the evaluation of Required Expression and Triger are two completely independent processes. (Conditional Triggers is a different story and so far are working exactly as expected). Therefore it is IMPOSSIBLE to guarantee which one will be evaluated first (once again, BIG Thanks to the multitasking/multithreading implementation). Over time the complexity of HE Platform (as well as RM app) is growing. This obviously requires more processing power leading to longer uncontrolled delays. For non Real Time OS (RTOS, which is (unfortunately) a case for the HE platform) once in while this gets out of control. I am absolutely not surprise to see more/increased timing related failures for whatever was working before with each platform and/or app update. I myself learned this lesson (DONT DO THIS) in a hard way. But also now I am 100% convinced to design new and/or modify existing RM Rules using State Machine design technique (which is my main tool for years for designing all my HW projects).
If the events in your trigger events and those that would affect your required expression are not related, maybe. (I seem to recall this being a problem with some of your rules where the events happened in quick succession and the timing could not be guaranteed.)
If they are, no. My explanation of this above and in the docs is the correct, necessary, and intended outcome for this feature to work in the way it was designed.
I have heard this before but I am not 100% clear on it. From what I understand, this approach basically means never use branching or conditions in your code, is that correct? Like, each "condition" has to be it's own simple rule and associated actions, rather than large rules that try to handle all the possible conditions within a single process (or single rule, in this case)
Or am I thinking of something else?
I forgot the details why my rules randomly failed but the "Required Expression" works/worked very well only when there is/was nothing related to the Trigger and actual Trigger Event is naturally far away (in time) from whatever is in the Required Expression. From the other side the Conditional Trigger is always works as expected because according to the Bruce explanation (by design) the Condition is ALWAYS evaluated first before Trigger can fire/ And sure, as a result Conditional Triggers (unlike the Required Expression which logically is the same things) are 100% reliable. Another words, timing for the Conditional Triggers is ALWAYS (there is still very narrow window for failure if Condition and Trigger events are within few mS apart) guaranteed vs the Required Expression when the delays could be up to 1 sec or even longer.
Bottom Line:
The Required Expression should/must be used very carefully and NEVER must include Trigger related events.
No, the conditions in conditional triggers are evaluated after the trigger event to which they are attached...
This is also false (except, I suppose, the part where you should consider use of any feature carefully). Please, again, see the example in the doc and the specific use case that demonstrates the ability of this feature to use (different values for) the same event in both, thus making it useful to capture specific state transitions.
No, incorrect. You can use Branching and Conditions but nested IF better to be avoided. Furthermore, the Conditions almost always must/should be used in order to switch between States. At least one IF-THEN-(ELSE)-ENDIF is required.
Something like this.
For instance, let create a Single Rule and than SM for Motion Lighting Control.
Simple rule is:
TRIGGER:
Motion Sensor change
ACTIONS:
IF (MS is ACTIVE) THEN
Turn Light ON
ELSE
Wait for LightOff delay
Turn Light OFF
END IF
Two-states SM:
Rule-1 (State-1)
CONDITIONAL TRIGGER
MS is ACTIVE only if Light is OFF
ACTIONS:
Turn Light OFF
Rule-2 (State-2)
TRIGGER
MS is INACTIVE
ACTIONS:
Wait for Event (elapsed time for turning light off)
Turn Light OFF
With 2 separate rules you can easily use different Trigger events for each rule and create individual conditions for Triggering. This is very simple example which may not show all benefits for using SMs. But with SMs each currently active rule can easily control what to run next (which rules could be triggered and under what conditions).
Action should be to turn light on.
I am the person who reads the docs only under very specific circumstances. This is because in many cases the documentation is very confusing or unfortunately simply incorrect (based on many years of experience). Normally I trust my eyes and my experiments. As I already mentioned, the Required Expression unfortunately is not a reliable instrument for gating Triggers. This statement is based on the gazillions of experiments. From the other side I have never seen failed Conditional Trigger. This always works as expected.
Bottom line:
With HE/RM whatever seems to be very logical and straight forward unfortunately is not always a case.
Yes, you are correct. I am sorry for the very simple typo (common cut-and-paste problem).
In your case, this was due to specific, intricate timing issues that were well discussed in various topics you created to discuss these issues. This is not universally true, but it certainly was a concern here due to the the specific events, devices, and rules.
How unfortunate that you did not share specific examples so that they could be addressed.
Also, moving this discussion to its own topic, as the original post in the original topic was about a specific bug that is present in 2.4.0, unrelated to questions and misunderstandings about the intent of these features that have started to become the focus of subsequent conversations.
This statement is from my past experience with documentations. It is not related to the HE documentation simply because so far I did not read any documents.
This actually makes sense. I guess, theoretically at least, the trigger will ALWAYS trigger based off the trigger in the rule, and thus "activate" the rule.
However, I would then expect that the very first thing that happens next is evaluating the Required Expression (or Trigger conditions). If the expression is false (or Trigger condition is false), then the Actions should not proceed.
Is this all correct so far?
It depends on what the value was at the moment just before triggering (or at least this is the explanation that seems to make the most sense to most people). Again, this is what makes it useful for capturing specific state transitions like in the docs:
Required expression: Mode is Away
Trigger events: Mode becomes Home
This triggers only on the specific change from Away to Home, not any mode to Home like it would without the required expression. But it still does trigger in the case of this specific transition, and this feature would not useful if the resulting value (mode is Home) is considered the value used in evaluating the required expression at this point.
Random failures are NEVER universally true. Unlike simple logical failure which is very easy to reproduce and after all easy to fix, random failures are always required enormous effort to figure out what is going on. I am coming from the HW design were many random failure are usually/commonly related to the compromised TIMING (not logic). The same things happens with the SW left and right. As we speak, the SW team from the project I am involved in is asking to add a HW support for time critical functions. Initially they thought they can easily handle all timing in SW. After months struggling with attempt to fix things in a SW now they are asking for HW support.
To my eyes this makes absolutely no sense at all, either theoretical and/or practical.
Example:
"Let me try to go through this door. Boom... Ouch, this door was closed!".

If the expression is false (or Trigger condition is false), then the Actions should not proceed.
This wood be a task for the very first IF statement in ACTIONS.
The purpose of Conditional Trigger is not to run ANY ACTIONS at all if Condition is false. This proven behavior by logs.

The purpose of Conditional Trigger is not to run ANY ACTIONS at all if Condition is false. This proven behavior by logs.
You are both right (@bertabcd1234 too).
Trigger event happens first, then Condition of Conditional Trigger is evaluated, then if true, actions are run.

Required expression: Mode is Away
Trigger events: Mode becomes HomeThis triggers only on the specific change from Away to Home, not any mode to Home like it would without the required expression. But it still does trigger in the case of this specific transition, and this feature would not useful if the resulting value (mode is Home) is considered the value used in evaluating the required expression at this point.
Ok, so far all of this makes perfect sense to me.
In this case, the requirement is that the mode is Away for this particular rule to proceed to actions. I absolutely get this usage.
Now lets consider again the previous situation:
Required expression: Variable A <2
Trigger events: Variable =2
Why would the actions of this potential rule be allowed to execute?

Required expression: Variable A <2
Trigger events: Variable =2Why would the actions of this potential rule be allowed to execute?
This would capture the specific transition from 1 (or 0 or whatever) to 2, rather than any value to 2 as it would without the expression. This is not that different from the modes example above and is another illustration of how this feature can be used to capture specific state transitions.

Trigger event happens first, then Condition of Conditional Trigger is evaluated, then if true, actions are run.
Thank you Bruce for the clarification on the implementation details. The key points are:
- The Condition is evaluate right after the Trigger event.
- No actions is running if condition is false.
This way timing window for failure is next to zero.
I wonder how difficult it will be to do the same trick for the Required Expression?