After thinking about this failures I am also thinking about very rare race conditions.
And how do you want me to reproduce this and create an environment which will not
require long waiting time for failure to happen? I am thinking about two periodically
running rules when one will create a TRUE condition for the WAIT statement and
a second one will simply periodically run just a wait statement. The problem is - I don't
have a spare hub dedicated for the testing. And of course, i cannot use two working hubs
for the intensive testing.
Just turn on Action logging for any and all rules that use Wait for Expression with Timeout.
Couple posts above I did presented a failure with logs.
Is this still not enough?
Looking at the code, the risk of a race condition is running the following action twice, not failing to run the following action.
OK, there is no way to know what happened. Off hand I'd say that there is not a race condition even possible with those logs, and no way to know what became of the timeout. There have been isolated cases of scheduled jobs not running, none for an understood reason. These are complex systems and not all issues are resolvable, there is imperfection. If we can find a failure and find its cause, we're all over it. But, not all failures fit these criteria. It becomes a bit of chasing a ghost.
First of all - thank you very much for spending your valuable time and checking what could be
wrong. Yes, the system is very complex and of course it is impossible to check for all corners and
conditions. I will think about how to automatically check for this condition and fix it when it
happens. Quick Idea is to create a Hub Variable such as "Rule ABC is Busy" and check for that
variable is not in BUSY state for very long time. The problem with this idea is - it will be too
many extra variables and extra rules. Just in case, do you have a better idea how to deal with
this issue (but please do not spend a lot of your valuable time)?
Personally, I would make things much simpler. You have a great deal of complexity, while I believe and practice KISS with my automations. RM admits to unlimited complexity, but that doesn't mean that's the right way to approach home automation. Complexity is always going to present more difficulties than simplicity. Seeking perfection through complexity is not a good plan, as surely you know from electronics design. Software is much worse than electronics in this regard. When your complexity starts having undiagnosable failures, it's time to reconsider that approach.
I am 1000%+ agree with this statement, no doubts.
And believe it or not I am trying hard to create as simple rule as possible. But from the other hand,
I need all logic to do the right things. These things are very contradictive. And sure, as a result
some rules are very complex. Balancing between these two contradictive requirements is not
an easy task. My personal requirement to make rules easy manageable and self explanatory
adds even more complexity. Maybe the solution is a custom applications but I am not a SW guru.
But let me think about custom aps. There are few relatively complex RM Rules which are very
good candidates for the custom apps.
I had similar problems with PB sometimes not getting set in my rules so I stopped using it. I managed to find this screenshot I posted a while back with a rule. Now, this was rule 4.0 so it didn't have required expressions.
There was another rule that would set the PB of this rule to true. That rule was called "Joel's Room - Potty Time." Part of that rule would set to PB of this rule to true and then wait for motion in the bathroom with a 2 minute timeout. After that timeout, the PB of this rule should have been set back to false. I was never able to track down why the PB stayed true sometimes and didn't revert back to false, but it sounds like it may have been the wait.
I completely rewrote this in Rule 5.0 and also taking advantage of hub variables. So now when there is motion in the kids room at night, it sets a variable, PottyTime to true (and does a few other things not relevant to this discussion).
Then the rule above I split into 2 different rules. One has a required expression of PottyTime true and one has a required expression of PottyTime false. They both have the same triggers, but will perform different actions based on the variable. I know technically using the PB should allow you to do the same thing, but I have had bad luck using anything as a required expression that is modified by the rule it is restricting.
The problem is not with PB or whatever Variable.
The problem is - rule hangs in a middle and not finishing to the end.
In my case it looks like a problem is with "Wait for Expression" statements protected by Timeout.
I cannot be 100% sure but all rules failing this way have this statemen.
The problem is extremally hard to catch because it happens once out of 1000+ successful runs.
