I was migrating my automation from RM4 over to RM5.0. I use a few of the Zooz Zen32 scene controller switches. With RM4, I was able to have a single rule to handle all possible (tap, 2xtap, 3xtap, etc) options for this scene controller. Since rm5 does not support "Button Device" trigger event type, i am having to create 10-15 different rules to do the same thing i did with one rule. is there another way to do this that i am missing, or can this be added back to RM?
Yes, the Button Controller app has been updated to version 5.0 and includes nearly the same featureset as "Button Device" did in Rule 4.x. This is the intended replacement.
If needed, you can still make rules that trigger on individual button events, though as you know, it's not an "all in one" solution for a single device (and all events from it).
2 Likes
The button controller app is not a suitable replacement for button device in RM4.x. Each button pressed/released state is it's own sub app. You cannot cancel timers between one rule and another. The only option you get is This Rule, but it fails to trigger for timers set in a different button state as it does in RM4.x.
I was trying to migrate my rules to RM5, but cannot because BC5, doesn't work. Aesthetically, it also sucks having 11 apps for a 5 button remote when in RM4 we only had one app.
These rules are not possible in BC5
Edit: Also, button controller apps cannot have variables.
Each button event being its own "grandchild app" is intentional. This also makes it clearer what things like "Cancel Timed Actions: This Rule" do (is it every button action or just the current one? apparently this was also hard to code for Hubitat, and it's now clear that it affects only that particular button event).
0p=\But I do think you've discovered a problem--I don't get anything from Button Controller showing up to cancel the timers on when I choose "Button Controller" as the type of rule to cancel timers on. This is in Button Controller 5.0a:
Tagging @bravenel if he wasn't aware of that problem (don't think I've seen it mentioned before) or knows any possible fixes. I've made sure I hit "Done" in the parent and grandparent BC apps (and at leat one other grandchild) with no change.
They can use hub variables. It is true that local variables (à la Rule 4.x/5.0) are not implemented, but you shoud be able to do the same with either.
The problem with Cancel Rule Timers has been fixed for the next release. In that release, Cancel Rule Timers will work in a Button Rule for any RM rule, RM Legacy rule, and for other Button Rules of the Button Controller parent (other button actions for same button device). This is a 'multiple' selector, so it is possible to Cancel Rule Timers in all of the other button actions, or selectively.
1 Like
As pointed out above, you can use Hub Variables for Button Rules.
There is a bit of a dilemma with respect to Local Variables per se in Button Rules. The main reason we moved to hub based Hub Variables was to get parent apps like Rule Machine out of the 'Global Variable' business. These Global Variables were inefficient, and introduced complexity where it shouldn't exist (parent app). With Button Controller 5.x, in theory there could be 'local' variables at the Button Controller level, but these would have the same inefficiency of Global Variables, as to access one would require loading the parent app for every variable access. Alternatively, a Button Rule might have local variables, but the scope of these would be limited to that specific Button Rule, and those would not be available to the other Button Rules of that particular Button Controller. So, neither of these are particularly attractive options.
Before 2.2.8, Local Variables had two benefits: they were efficient compared to Global Variables and they had local scope. In 2.2.8, Hub Variables are as efficient or more so than Local Variables, so the first benefit is addressed. That leaves local scope benefit as the missing element by not having 'Local' Variables in Button Controller.
1 Like
Thanks for the explanation about the local variables. I do prefer local scope variables, even if they are defined in the parent app, as it keeps the global scope clean, but I understand if there are inefficiencies.
I'm glad to see that the button controller fix for cancel rule timers has already been addressed in the next release. I want to use predicate conditions in my bedroom motion lighting rule, but I am stuck in rule machine 4 now because button controller 5 cancel timers isn't working as expected, and I can't pause RM5 rules from RM4 button device rules.
Thanks for all the hard work, HE has definitely elevated my home automations.
1 Like
Thank you for clarifying the question of efficiency. The local scope benefit still seems like an important one; otherwise a great deal of what would otherwise be local variables would wind up polluting the global Hub Variable namespace.
I have some RM4.x "button controller" rules that I cannot really migrate to Button Controller 5.x because of this: there are local variables shared between the buttons (sometimes quite a few because they are essentially configuration constants rather than true variables) that I don't particularly want to drop into the Hub Variable namespace.
Overall though, Button Controller 5.x is really nice: it's good to have access to all the RM features (except local variables), like IF/THEN in a button context. Also the Comments action and the ability to separately name the grandchild rules are really helpful for documenting which physical button the button number maps to, and what the rule is supposed to do.
(There are some other RM4.x "button controller" rules that I've not migrate until I figure out how capture/restore works in this context. One of them captures state in one button and restores it in another... but that's a topic for another day.)
One significant benefit of the approach taken for Button Controller 5.1 is that the individual Button Rules, Button Rule 5.1, share the same code base as Rule 5.1. Features added to Rule 5.1 are available for Button Rule 5.1, and bug fixes benefit both apps. It would not be possible to have this benefit AND have variables in Button Controller 5.1 available to the individual Button Rules.
Another significant benefit was to get away from parent app based variables. These were significantly inefficient, and introduced a good deal of complexity just where you don't want it: in the parent app. I can't see wanting to go back down that path.
Naming conventions that you could create could overcome this issue. One way or another there is going to be complexity somewhere to handle what you want to do. I would argue that you don't want that complexity in the parent apps, including Button Controller 5.1, or in the Hub Variables app. 
1 Like
I totally agree with this. Now, how do I rename my existing variables that I created without thought of this? 
Working on this... It will be available in one of the next two releases, most likely 2.3.2.
3 Likes
Kool! Thanks.
Actually, I think I found a case for which a variable that is local to just one Button Rule is useful (and cleaner than the local-to-the-button-controller of Rule 4.1)...
If I want to read an attribute of one device, then set another device with that value (possibly with calculation). The simplest example would be setting a dimmer level based on the level of another dimmer. Unless something has changed, this requires using a variable as an intermediary to hold the value. (And it certainly does, if a calculation is to be done.) But this variable can have very limited scope indeed, as it is essentially a temporary value.
That's a pretty narrow use case to justify a heavy weight feature such as Local Variables. We don't plan to introduce them to Button Rule.
Agreed, although a cheap version of scoping could be implemented in the UI for the Button Rule app (and potentially the Hub Variables app) without adding complexity to their runtime, by hiding the variables that are "out of scope". But I guess with an appropriate naming convention for these Hub Variables, I could do that myself with some (ugly) client-side CSS... 
Wow, that was a quick response.
And yes, I agree it's a pretty narrow case, especially since RM might someday just allow seeing the level of one device attribute based on (an offset from) the value of another device similar to the way comparisons can be done in triggers/conditions. (Which would eliminate the need for a temporary variable altogether.)
But on the other hand, I thought you mentioned that Rule 5.1 and Button Rule 5.1 share much of the same codebase, so wouldn't that mean the feature is, in some sense, already there but disabled?
And of course, since Rule 4.1 isn't going away anytime soon, for the odd cases that were easier to do with RM 4.1 Button Controllers, I can just keep using those old rules, while (eventually) migrating everything else to the latest RM and Button Controller.
With variable scopes currently constrained to either (A) HUB VARIABLES (which appear globally), or (B) RULE (esp. RM 5.1) VARIABLES (essentially local to the owner rule itself) . . .
. . . will it ever become possible to . . .
- In Rule B, read/write or trigger from a variable belonging to Rule A?
- In Hubitat Dashboards, include a tile linked to a Rule variable?
. . . without having to create intermediate Hub Variables. (I'm still clinging to the notion that we can/should somehow segregate Hub variables – with legitimate global intent – vs rule-specific variables that users don't want cluttering the Hub Var section.)
I'm envisioning something like:
- Trigger ► "Rule Variable" ► (which rule?) ► (select var) ► "Changes"/etc.
or - Condition ► IF ► (variable) ► (select rule) ► (select var) ► ">= 40" ► THEN
or - Dashboard ► Text tile ► (variable) ► (select var from list that includes rules' vars)
Nope. A local variable is, well, local.
1 Like
