@bravenel (or others), would it be possible to have Button Controller added to the RM Private Boolean options?
It's a bit more complicated than meets the eye, as each Button Controller has (grandchild) Button Rule apps. What you are really requesting is access to PB in those, which is a mouthful of UI.
You could just use a Hub Variable to accomplish the same thing.
Makes sense. I just didn't want to change about 5 button rules, but it only took about 10 minutes, so no biggie. The rules are cleaner now anyway.
Logically yes, but timing fot the Hub Variables is less deterministic and may
reqier to use delays. I did step into this problem.
I don't think this is true. Timing for setting a Hub Variable from a connector has this issue, but not setting a Hub Variable directly. That is simply a hub method that runs in real time.
I was trying to use Hub Variables (not a connectors) for dependent rules synchronization and for preventing rule retriggering. I.e. Hub Variable set to false
as a first action and used in a Required Expression (must be true). Acording to logs
the event: now Variable is false was delayed near a second. Sure, unwanted trigger
did go through. Using Private Boolean is near instantaneous.
This is my true story.
My use case has no time criticality whatsoever, so I'm good with the Hub Variable solution. It's just a lock-out to make sure that you can't fill the coffee maker twice in a set period of time.
We looked into this in some detail recently for another user who made a similar claim that you are making. It turned out that he was using connectors to set the variable. Doing that involves creating an event, which is processed in the event stream, and as such is asynchronous. During our investigation we re-confirmed that setting a Hub Variable entails no delay as to the process setting it, as it is simply a direct method call in the running process.
However, as between two separate processes (as in, two different rules) there is always relative timing indeterminacy, and this is what you encountered "for dependent rules synchronization". You can't be anymore certain of setting another rule's Private Boolean than setting a Hub Variable, when referenced from the second rule. Both of these happen directly in the original rule's process. But as to any other rule that might reference the object, there are no guarantees as to relative timing.
I think you were simply lucky that Private Boolean appeared to happen 'faster' and unlucky that setting a Hub Variable was 'slower'. Further to this, "dependent rules synchronization" is not something to count on with RM. Only custom code can really accomplish true synchronization.
First - I am not using a connectors at all, only a Local or Hub Variables.
And I am talking about retriggering prevention with Private Boolean.
Rules synchronization is a different story.
My preference for naming variables is to provide a reasonable info what
for this variable is. I thought, it must not be any timing difference between
built-in Private Boolean and whatever Hub Variable I created. Indeed it was
a noticeable difference. Not to long time ago I reported this discovery with
correspondent logs. Your suggestion was to switch to Private Boolean.
I replaced my nice named variables with built-in Private Boolean and problem
went away. It is what it is.
I can easily synchronize rules in RM with State Machines. The only problem
with SM in RM - multiple rules are required.
Yes, you said that above. I was simply giving all of the pertinent facts for clarity.
OK, retriggering prevention does work better with Private Boolean (because Private Boolean uses atomicState, which is close to being protected -- as to that particular rule only). This topic was about setting Private Boolean in another rule, so naturally I assumed you were commenting about that context, not about retriggering.
So, for retriggering protection, use Private Boolean. For messaging between two rules (e.g. enablement/disablement) using Private Boolean or Hub Variable should be equivalent.
