Recently I decided to add a second button and moved this rule from Button Controllers to the RM so, each button (old and new) can call this rule as a single routine. Now in the recreated RM rule "Wait for Expression" statement always fails. The good news is - the failure is 100% consistent.
Here is a related logs:
Log for the "Kitchen CoffeeMaker Ready" virtual switch shows the switch was turned ON at 4/20/2024 8:32:24.589 am by command Action: Run Actions: Kitchen CoffeeMaker Ready;
but "Wait for Expression" statement failed to see this Event (i. e. status change).
This looks like again race condition is involved because "Action: Run Actions: Kitchen CoffeeMaker Ready" statement turn on the switch very fast before "Wait for Expression" is waiting for the status change. However this rule never failed when it was created under "Button Controllers" but started to fail consistently (100%) after exactly the same rule was re-reated under "Rule Machine". This is very alarming behavior.
Itās known behaviour by now. Iām afraid youāll have to design around it (or wrap the wait, with a timeout, in a repeat loop).
What happens in the Ā« Kitchen Coffeemaker Ready Ā» rule actions? If you add a short delay as the last action of that rule, will the race condition be avoided?
Doesnāt look like it would matter much if the coffee maker is turned on a with a short additional delay
Upon quick review of the rule, I don't see anything wrong with it.
I am not sure what the issue could be. I make extensive use of both "Wait for Expression " and "Wait for Event" and I have never had a failure like this.
Since this rule triggers actions for another rule, "Kitchen CoffeeMaker Ready", maybe post that rule too. Perhaps there is a clue there as to why this rule fails..
Maybe you need to add a simple Wait for Elapsed Time set for a second or 2 to give that rule a chance to run to completion before the wait for expression.
Sorry, but 10000% incorrect. END-IF must be executed after Wait becomes TRUE.
This rule was working flawlessly when it was created long time ago under "Button Controllers".
I know this phenomena very well. And yes, the workaround is to add a delay before Wait (done and it works). My point for the post was/is to warn a bit mainly new users. Without knowing a little details about race conditions new users could be very surprised to see this type of failures.
Exactly correct. And now I know very well what is going on.
The reason for this some sort of re-post is:
The same rule created with Button Controller and RM has very different behavior. This makes near no sense. At some point Bruce mentioned the RM and BC have a sheared code (not sure what exactly is shared). This way the behavior of the same rule must be the same but it is not.
If a race condition is involved, you could certainly expect to see different behavior between Button Controller and RM for a number of reasons, all related to timing and the underlying race condition cause. Even as between different rules there could be big differences. Button Controller and RM do share almost all code in common, but within different overall app structures -- and it is those overall app structure differences that would affect relative timing.
