New RM feature request

📢 Feedback Feature Requests
#1

The RM Rule is capable to set and/or reset Private Boolean for ANY RM rule.
It will be very helpful if RM Rule also can check a Status of ANY RM Rule Private Boolean.
The use case is - a better synchronization of multiple dependent RM rules.
As of now it is possible to create a Hub Variable but the problem is - Hub Variables
responsiveness is not fast enough. From the other side the responsiveness of
Private Boolean built-in variables is much faster.
Since any given RM rule can manipulate a PB of any other RM rule (so, PB already is not a
100% PB) I don't see why any given RM rule cannot check a status of any other RM rule.

Another possibility is to create a "RM Rule Status Indicator" (active/idle).

1 Like
#2

Private Boolean state fetched from another rule would be slower than Hub Variable state retrieval, as the second rule would have to be instantiated.

At one point in time, Private Boolean was the only variable available. I really don't see chasing further down this particular rabbit hole, and question the perceived need for it. This makes zero sense to me.

Being reliant on the difference in these timings is way beyond the intended use envelope for both the hub and Rule Machine.

#3

How are you measuring this?? I'm seeing nearly identical timing for fetching Private Boolean and Hub Variable, both less than 10 msecs. In my test, Hub Variable is faster. But at these timings, other activity on the hub could easily dominate the results. And there is no way to control that.

Setting variable speed is comparable also for the two, with Hub Variable slightly quicker than Private Boolean.

1 Like
#4

The response assessment was/is indirect (I don't have any tools for the direct measurements).
Some time ago I tried to use Hub Variable (boolean) instead of PB but the same way.
The reason was - Hub Variable could be checked and controlled by ANY RM rule plus it had/has
a nice friendly self explanatory name.
The intention was to set this variable FALSE at the begging of actions and reset to TRUE at
the end (the same as intended use for the PB). The expectoration was to see very first log entry
this variable was set to FALSE. Instead the log showed this setting was happening after 3-5
actions later. However PB behavior is exactly as expected, i.e. PB set to FALSE is a very first
logged action. This behavior is very consistent which means the PB response is near instant
but Hub Variable is much slower and unpredictive.

I have a relatively complex Front Door automation which does automatic unlocking/opening
the door and closing/locking (yes, I have motorized door actuator).
Few sensors are involved in this automation:

  • door sensor;
  • door lock sensor;
  • internal MS;
  • external MS;
  • active RF ID tags;
  • Guest Mode hub variable;

With all that sensors I can reliably detect ARRIVAL or DEPARTURE events.
The problem is - few events are happening near at the same time but depend on which
event is detected I need to block unrelated RM rule from executing (better even from triggering).
The problem could be solved by introducing a delays. However all these delays are too annoying
for my inpatient wife. That is why I am looking for the fastest but very reliable solution for this
problem. I guess, the best will be a custom app but I am not yet there.

There are few other automations for curtains and balcony doors which will benefit if I can
come up with fast reliable RM rules synchronization.

#5

The setting of a Hub Variable is instantaneous, not delayed.

The only time there was any delay had to do with using a Connector instead of a Hub Variable directly. In the case of using Connector, there can be a delay as the event queue is processed.

Further to this, you have no way to show the value of Private Boolean in a log, so you can't assert that it behaves differently. You would have to either use a conditional action based on PB value, or set a variable to Private Boolean and show that in a log.

#6

In all cases I was using only Hub Variables. I have never used a Connectors.
I can try to use Hub Variable in parallel with PB an see what will happen.

#7

What you are seeing in the logs is the processing of the event queue. A subscription to a Hub Variable used in a Required Expression requires that the event of setting the Hub Variable be processed through the event queue to hit the method that handles Required Expression events. This will be asynchronous to the execution of the rule's actions, and this is why it appears to take longer to access a Hub Variable. Changes to Private Boolean do not generate an event, so the Required Expression appears to change instantly (as perceived from within the rule). When used for some sort of synchronization across rules, the event queue would come into play.

So for locking a rule, it is better to use Private Boolean than to use a Hub Variable. However, to do this across different rules (as your feature request suggests) for use in a Required Expression, would entail some event to cause the evaluation of the Required Expression. You'd be right back where you are using a Hub Variable. Besides, there are no events generated by setting Private Boolean, so what you are requesting departs from the current design in multiple ways. A rule would have to generate an event every time Private Boolean is set (not good), or have some other means to determine that its Private Boolean is in use (not good). This is a non-starter proposed feature, and wouldn't help you at all.

Synchronization of multiple rules is beyond the design envelope for Rule Machine, and certainly will be non-deterministic in general. If your automations can't live with non-deterministic outcomes, they are beyond the scope of what is reasonably doable with Rule Machine. To implement something like this would require carefully crafted custom code.

2 Likes
#8

Thank you very much for the very detailed explanations. Everything what you said now makes sense.
I am not sure I will be able to create a good custom app. Let me think what else I can do except for
fixing problems by introducing a delays.

#9

It occurs to me that Required Expression is the wrong mechanism for synchronization across rules, since it relies on events to establish its truth. This makes it asynchronous to other rules.

However, because a Hub Variable is instantaneously set (for all practical purposes), It is possible to do synchronization of a sort just referencing a Hub Variable.

Suppose Rule 1 sets a Hub Variable called Rule-1-Busy when it begins its actions, and Rule 2, which runs asynchronously anyway, has a test on the value of that variable, like this:

IF(Rule-1-Busy = true) THEN
    do something
ELSE
    do something else
ENDIF

That does not entail any events, and the relative timing would not leave much to be desired. In the next release, 2.3.6, now in beta, there is a new feature in RM for Conditional Triggers. This allows for a different type of synchronization, similar to Required Expression, but different in one key regard: the condition is tested everytime the trigger event happens.

Also, Wait for Expression could work instead of IF-THEN-ELSE. Wait for Expression tests the condition first, and only if false does it begin the Wait. So you could have

Wait for Expression (Rule-1-Busy = false)
    some actions

This does entail an event for the ending of the Wait, but the relative timing would work, assuming that the actions that follow can happen whenever Rule 1 becomes not busy, shortly thereafter (for event queue time).

#10

Yes, this was my suggestion for this feature and many of my current rules are waiting for this one.
Thank you for implementing it in the next release.

Thank you again for the ideas. Since timing for the Required Expression is not deterministic
( I learned this in a hard way) I was thinking to use some sort of Coordinator Rule as you
suggested above. It will be some sort of State Machine. I like SMs a lot and using them left
and right in all my electrical designs.

Download the Hubitat app