Local variables?

Are there variables that I can use and set but only exists during the running of the rule? For example, I want to send a message and include a device attribute in the message, but it seems the only way is to create a global variable and during the run of the rule, assign the device attribute value to the global variable and finally reference that global variable in the message.

But the problem with global variables is that if multiple rules reference the same variable, then there is potential conflict as multiple rules update the same variable at the same time. I was hoping there was a way to create a local variable so that despite all rules referencing the same variable name, they can't actually read or update the variable that would affect another rule.

Do I really need to create a unique variable name for each clone of the same rule? eg: rule Send-message-to-rob would need variable battery-level-rob and Send-message-to-john would need variable battery-level-john. I rather just have one variable for battery-level.

There are https://docs.hubitat.com/index.php?title=Hub_Variables
And RM has Local variables:

Special Features

  • Local variables: each rule supports the creation of local variables. As their name suggests, they are available for use only in the same rule (not other rules or apps).
    • Note: Hub variables are also available for use in Rule Machine (and many other apps); they are similar in possible uses except that they can be shared among multiple rules/apps rather than just within the rule in which they are created.

https://docs.hubitat.com/index.php?title=Rule-5.1#Special_Features

1 Like

No, you do not need to use "global" variables or hub variables (these are actually two separate features, the former being a Rule 4.x/Rule Machine Legacy feature and the latter a new hub-wide feature available to any app that offers use of them, including Rule 5.x). Each rule has the ability to create local variables that work as you describe.

Use the Create Local Variables link (or the Create, Set, or Delete Local Variables link if you've already made some) in the rule to create them:

2 Likes

I have just remembered a couple of questions I wanted to ask about the scope of local variables in the context of a HE rule. Are they confined to one running instance of a rule or can any running instance of that same rule access their value (if changed by another instance)? Does the end value persist so that it's the initial value next time the rule runs, or do they "die" when the rule ends?

That is a good question. I do know that a local variable value is retained at the last value it was set to for each run of the rule. I would assume the variable space would be the same for each iteration of the rule that is running. That may not be the case, however. So multiple iterations of a rule running may cause unexpected results if they are stepping on each other.

2 Likes

Apps in general, including rules, have a single "state" to store things in, and I believe this is where local variables are ultimately stored in Rule instances. There are actually a couple different options here, the biggest difference between them being that one will commit changes as they are made while the other waits for the app to go to sleep (for a rule: end of actions, wait, delay, etc.) before guaranteeing a save, and I'm not privy to the internal implementation details here. So, as @terminal3 notes, with simultaneous execution, you may get unexpected results. But in general, the values are saved and persisted across different executions of a rule.

In general, however, it's best to avoid multiple simultaneous executions of a rule. There are some times when this can definitely cause problems (pending delays inside conditionals, for example, when the rule re-triggers--again, there's only a single state to store rule data in, and I believe current point in execution is one), but it can often cause unexpected results in any case. There are ways to prevent this, whether something explicit (e.g., a required expression and private boolean or another means to track) or just careful trigger design.

2 Likes

A post was split to a new topic: Feature request Rule 5.1