I have a rule with a conditional trigger that will occasionally trigger even if the condition is not met… (FALSE)
I thought that maybe it happens if one of the devices in the list was on before the rule triggered, so I just tested this and confirmed it to be the case.
I’m wondering if there is something I’m just missing here…
Here is a situation where the devices were not on and where it worked as expected:
So the mystery is why the logs show all of the devices off and the condition false, while the rule was triggered only if one or more are on. How frequently is this? What is the failure ratio?
I hope I'm not muddying the water even more here, but in that last picture of the logs, I'm also curious why there's no "Waiting to stay 10:00..." log entry... Shouldn't there be one?
Exactly. And I did confirm manually that they were all “off”.
I have only seen it occur when one of the devices had been turned on prior to the rule running. If not every time, most of the time it seems.
This sounds like a timing/driver thing, but I have no way to tell.
I’ll see if I can reproduce it with built-in virtual devices on the weekend.
Since the condition is false the Wait doesn't start so the last picture of the logs is what you'd expect.
Interesting... It then seems I have misunderstood how this sequence would ideally work.
I thought that the trigger's condition would be assessed only after the sensor had been confirmed clear for 10 minutes, but that doesn't seem to be the case?
Are you saying the condition is assessed as soon as the sensor is clear, and if true, then the rule proceeds iff the sensor stays clear for 10 minutes?
Apologies if I'm overcomplicating this or otherwise totally missing the boat on something obvious -- it's been a long week and I'm not firing on all cylinders.
That was my guess. I'm not sure I understand what's wrong with the behaviour the OP is reporting.
For triggers with waits, if a condition must remain true throughout the wait, I'd go with a required expression for the condition instead of a conditional trigger as the required expression remains subscribed and iirc will cancel the trigger when becomes false.
Maybe this test rule will help show how the logs should look for different conditions.
Sensor departs but condition is false
Sensor departs and condition is true but doesn't stay for 1 minute... and I was able to reproduce the problem.
Except there is no problem, is there? I suppose it boils down to design intent: are conditional triggers' conditions evaluated at the start of the wait only, at the end, during?
Look at the rule's event subscriptions during the wait, there are no event subscriptions on the attributes of the conditional, it's clearly evaluated only once before the wait starts. The only "problem" here is the way logging works; the device attributes are logged in the state they are at the time the wait completes, not how they were when the condition was evaluated.
Here is a sample rule that would accomplish what the OP wants (I think):
and the logs when switches all go back to off during the wait
Right on -- thank you for laying that out (and further confirming what OP is seeing).
I guess I'm just surprised to learn that's actually the design intent here... As I mentioned earlier, the sequencing of that validation flow is not at all intuitive to me.
This seems to just be one of those things that makes perfect sense to some folks and little sense to others -- it is what it is. So awareness of how it really works (intentional or otherwise) is helpful - thank you again!
Yep, I'm with you on this.
It is very much possible that I did not properly understand the design intent - I didn’t even think of the possibility that the evaluation would be done before wait period rather than after it.
My expectation (right or wrong) was that the rule would evaluate the conditions after the delay.
That said, regardless of when it gets evaluated, what I think I was seeing is that the rule triggers when the condition is not met (whether this is on trigger or after the wait). However, I have yet to confirm this.
That was my expectation, too, and is why, early on when required expressions were added, I asked, and was told by Bruce, that triggers were discarded if the required expression was not true.
I guess it's the difference in the order in which the trigger and the conditions are evaluated:
(1) Discard triggers if conditions are not met, or,
(2) wait until conditions are met, then wait until triggered.
I would have expected #1.
If you turn on description text logging for all the switches perhaps you’ll see in the logs if it’s a timing issue as Bruce suggested
The condition of a Conditional Trigger is evaluated when the trigger event occurs. If there is a Stays element of the Trigger, the Stays delay happens after the Conditional test, and the test is not repeated after the Stays delay.
With respect to Required Expression becoming false, and the removal of trigger subscriptions, this happens when the transition to false occurs. However, in the case of overlap between the Required Expression and a Trigger event, for example a specific device state in both, those triggers remain in place, as the evaluation of the Required Expression and the Trigger event must both take place for such events. In this case, the Required Expression state prior to the event determines whether or not to trigger the rule (it has to be true for the trigger to run).
Robert (@bertabcd1234), it might be a good idea to add Bruce's explanation to the documentation. Just a suggestion for those of us who read the docs, which have improved so much in the past year.
Both of you? 
It's already there. 
(Not the exact wording, but the idea.)
Download the Hubitat app
