All what is needed - is a single current state. Furthermore, even current state is need only for the still running instance. When rule finished state is not needed anymore.
What you just said is exactly my point. Multiple running instances are not useful but instead they are creating many problems. The solution seems to be very obvious - simply do not create multiple running instances. As you mentioned before Room Lighting app is a single threaded. So, there is no platform-related limitation.
Why not to create single threaded RM 6.X?
Well, yes. Hence my use of "For this specific use case (...)" in the post where I made the suggestion.
I'm sorry Bruce, but I think you misunderstood. I suggested using ZMC instead of a rule, therefore avoiding, not solving, the issue.
Right - I totally get it and my suggestion is clearly not relevant to that. And by the way, thank you for the time you spent explaining the details in this thread, I and I am sure many others have learned a lot.
That being said, a personal opinion : while I had already pretty much made up my mind on avoiding re-triggering / multiple instances for my rules, what I've learned in this thread tends to solidify that choice. Breaking things up logically into different rules, using the pb pattern, using virtual devices to represent state outside of a rule instead of having it buried inside of it, those are tricks I use and find useful to KISS.
All these trick are not a solution for the "running multiple instances" problem but just a band aids. Using multiple smaller rules and many virtual devices or variables drastically reduces maintainability. The problem must be solved globally by preventing of creation these multiple running instances instances instead of creating them and than applying all these band aids.
PS. When I joined my company back in 2007 they had many issues related to EMI (Electromagnetic Interference). The EMI test never passed on a first try. The solution was to put left and right many different shielding. I had a hard time to convince engineers and managers to apply just a best design practice in order not to create EMI in a first place. Very first design which followed this approach passed EMI test on a first try with very significant positive margins. And near all followed designs basically did not have EMI related problems.
Point is: Do not create a problem in a first place.
I'll say this as gently as possible. There is no issue in rule machine except in rule design and the usage of the Private Boolean within it. Your original rule before adding a PB worked fine without because every time a motion sensor triggers, it wipes out both waits and starts over again. In this scenario, your rule is only running once because it resets itself after each trigger.
If you want to use the Private Boolean, then you need to follow the best practice design with that variable. Almost everyone who uses a PB has it set false as the first action and then true as the last action. This is not what your original rule was doing and causes the issues that was seen. The new rule should work better as it is now following best practice.
Gently speaking this is a bit incorrect.
Without a PB rule unfortunately does not reset itself. Instead of resetting itself (I really wish this is a case) another running instance is created. Now 2 (or even more, depend on how many trigger events happened before rule finished) is running. And because this is a potential for the race conditions:
many occasional random problems are happening. I have seen (and actually reported) many times cases when rule simply fails to complete.
The reason for using PB encapsulation is to prevent rule re-triggering while rule is running.
Another words, this is a work around how to prevent from running multiple instances.
And excuse me for repeating this again, my point is - multiple running instances should/must not be created in a first place.
You are right and I misspoke. It still doesn't change that it is a rule design issue when using Rule Machine rather than a hub design problem.
Then design your rules this way. It's why we have Required Expressions and Conditional Triggers. If you didn't want to use a PB, then use a Conditional Trigger of the Virtual Presence Sensor of being departed. It would work similarly to the PB and still solve these issues.
No, this is not correct. "rule finished" has many meanings, including notably that it exits due to delay, repeat or wait.
No, this isn't actually possible, nor desirable in many cases (there are perfectly valid cases for multiple instances of an app). Room Lights can have multiple instances too -- that is not the meaning of "Single Threaded". Single Threaded means that only one instance can execute at any moment, not that there cannot be multiple instances. Again, as soon as an app exits due to delay, repeat or wait, that instance is not executing but will resume execution later. This happens for any app that has timings for things like how long after motion becomes inactive to do something.
This is not a "problem", but a core aspect of how the hub functions. We aren't going to throw out the hub because you have not figured out how to use it. These problems have solutions, that you dismiss with sweeping hands like "drastically reduces maintainability". There are many thousands of users with large automation systems that do not have the problems you bring up. I'm trying to be patient with you, but it is challenging.
You continue to go off the rails in a somewhat ridiculous fashion. Of course PB doesn't reset itself, that is for you to do as you see fit.
None of which except for this case just above have you provided logs and complete documentation, only rants. The case above has been adequately explained and IS a race condition, one that you allowed to happen by your rule design.
This topic is more than beat to death... Time to move on. If you come up with new fully documented cases I will of course take a look at them.
