WaitFor "Contact" Timeout never times out

Hubitat Elevation® Platform Version
2.3.0.118

Hardware Version
Rev C-5

I've verified that WaitFor "switch/event" with a timeout works fine. However, using a WaitFor "contact/state" does not -- that is, the timeout is not honored and the rule waits forever.

The device I'm using is the Fortrezz MIMO2 contact sensors.

Is the rule above the same one you are testing? If so, you don't have a timeout specified on that "Wait" at all, which would be the problem with the timeout not working. :slight_smile:

Also since the rule is triggered every minute your wait is canceled and starts over.

Oops -- looks like I forgot the timeout in my repro. With the timeout, alas it does not repro with my simple rule. So let me introduce you to my complex rule where it's actually happening.

It is a pond refill controller. There are two sensors, one at a high water mark, one at a low water mark. When the low water mark is reached, it refills back up to the high water mark. However, the sensors bob around in the water a bit because the water is flowing. As a result, I have to do some noise reduction on the sensors, which often flip open/closed even when they are submerged in the water. I have a feature ask here which is it would be awesome if there was some kind of sensor noise reduction ability, but that's a whole different thread with ideas I have. In this rule, I'm reducing the noise by (1) making sure the two sensors agree that water level is low (that cleans up about 80% of the noise), and (2) introducing a delay to see that the low water sensor stays in the open position for at least 10 seconds. I've tried multiple rules in the past, but I find that a single controller rule provides simpler state machine coding. (I'd REALLY love a state machine engine app!!! I'd be willing to help code that but haven't had time to ramp up on habitat app coding).

Here's the full rule details:

And here's a few logs showing a couple things. In the first case, the event actually happened within ten seconds and it exited correctly.

In the second case, not only did it not time out, but when the event actually happened after the 10 second timeout period, it did not actually exit as far as I can tell. I found that the state variable was left in the "Evaluating" state, and so the rule never fired again due to not meeting required conditions. (which brings up a feature ask, which is I'd like to be able to mark a rule as "don't run if it is already running")

My suspicion is that perhaps the required conditions are causing the rule to suddenly stop running, and saw others posting threads that hint the same -- not sure if there's any proven known bugs around that though.