I have many RM rules using hub variables similar to Private Boolean plus for handshaking.
Here is one example.
At the very beginning this rule sets hub variable to TRUE "Set BdAutoSlide_Busy to true"
and reset it back to FALSE at the very end "Set BdAutoSlide_Busy to false".
This hub variable is used to prevent this rule from re-triggering and also is gating few
other rules (handshaking mechanism).
Variable is set at 09:46:55.223 app:22052023-04-03 09:46:55.223 PMinfoAction: Set BdAutoSlide_Busy to true
but correspondent event happens almost 2sec after at 09:46:57.204:
2023-04-03 09:46:57.204 PMinfoEvent: C8, Sunny Isles, FL(new) variable:BdAutoSlide_Busy true
My expectation is/was:
The correspondent even must happen near instantly but it takes near 2 sec,
Is this normal RM behavior and the delay is expected?
If "yes" I will have to re-think and re-design all handshaking logic for many rules.
The relative timing of these two instances of the same rule is indeterminate, generally speaking. There is a lot going on in the rule, thus occupying a processor for the actions as you can see in the logs. Why it is 2 seconds is impossible to say. It could have been 200 milliseconds as well. Depends on what else is going on in your hub at the same time, also possibly tying up processors.
Creating complex interactions between multiple processes is never going to be deterministic in this architecture, at least not without explicit synchronization software -- something that RM doesn't have. It may be possible to do this in custom apps, but not an easy thing to engineer. This technique of using a variable to protect a rule against double triggers is by no means fool proof.
Remember my advocacy for KISS principle when it comes to automations. You are pushing well beyond that, and beyond the 'safe' design envelope for multiple automations. The hub was not designed or intended to be used this way.
Incidentally, Private Boolean should have better timing than what you showed in the log, at least with respect to the aspect of getting the Required Expression to be false. In that rule you showed, try replacing the Hub Variable with Private Boolean, and see if the timing is more to your liking.
First of all - Thank you very much for the details and explanations.
Now I am really missing "State Machine" approach for the automations. In fact, every automation
is a some sort of State Machine. Even simple IF-THEN-ELSE is a very simple State Machine.
With RM 'as is" State Machine can be created but this will require multiple (one for each State)
set of RM rules performing single automation task. This should not be a big deal if rules could be
organized in a some sort of Folders (this is all about design maintainability). Unfortunately this
is not a case and all rule's grouping could be achieved by prefixing in a rule names. This is doable
but rule names becoming too long. I clearly understand the difference between implementation
and execution of State Machine in HW and SW. But actually designing Automation with
State Machines is more KISS-friendly vs very complex IF-THEN-ELSEIF-THEN_ ... sequences.
I agree completely with this. While adding folders for apps is on our list to do, we've been busy with more pressing things.
Back to your problem shown above: Please try Private Boolean instead of Hub Variable. There will be no delay from multiple processes with this approach. Private Boolean is handled internally within the rule, and uses atomicState (written immediately). While this is not foolproof semaphore as would be required for true synchronization, it comes very close. This will at least prevent the multiple instance problem for most if not all cases.
I 100+% agree. This is not (and should not) a highest priority. But really will help a lot for
maintainability.
This is what I will try before drastically changing my approach how to synchronize the
dependent rules.
I have one more question.
If a rule sets variables sequentially something like this:
set Variable_State to Number
Is a DELAY needed here?
set Variable_Trigger to True
delay 1 sec
set Variable_Trigger to False
How deterministic will be the above sequence?
Different rules will use a Variable_State as a Required Expression and Variable_Trigger
will trigger all the related set of rules. With a reasonable DELAY on a line 2 only one rule will
be triggered (this is a must).
But my question is:
Is this DELAY is absolutely required in order to guarantee each rule will see a valid
Variable_State value or by any chance the DELAY could be skipped?
I can use Variable_State *change as a Trigger and use IF_THEN to determine if
rule must be executed. This definitely will be very deterministic but all related rules
will be triggered and only one will be running.
May be this is not that bad?
Same issue as to multiple processes. However, please note that you can set the Private Boolean of another rule, and that won't have this problem.
I don't see any reason you would need a delay. By using Hub Variables you are effectively causing multiple processes to run by using the hub event stream processing -- avoided in the case of Private Boolean.
I am confused. So every Hub Variable modification starts hub event stream processing?
Or event generation will start only if Hub Variable is used as a Trigger and/or is a part of
Required Expression?
Well, if every Hub Variable modification starts event generation I can understand why
my rules creating a High Load warnings. I am using a lot of Hub Variables in many
cases just for readability and maintainability reasons.
Should I avoid heavy use of Hub Variables and use them only when absolutely required?
Setting a Hub Variable does cause an event. Some app could be subscribed to that event, in which case a new process would be started to instantiate that app for it to handle the event. Most events in the hub do not cause a new process, as there are no subscriptions to them. Events in and of themselves simply go into a stream of events.
As a matter of good hub hygiene, yeah, only use them when needed. I'm not sure why else you'd use them. If you just need a variable for some reason, but it does not need to be used outside of a particular rule, just use a local variable. Setting those does not generate any event, so they can't be used for triggers or Required Expression, and other rules can't see them.
Yes, wherever is possible I am using only Local Variables. Hub Variables are used only for
passing some data between rules and/or if EVENT is needed.
It is always good to know as many details as possible for things being used.
