It’s not about me and you disagreeing.
I think you’re not following the distinction others (not me) were trying to make between an event and a state (or condition).
If you have questions about what that means, please ask.
Completely agree…apologies if it went somewhere else. I’m a bit firm about what I call complex. I know what works for me. So many thanks for the guidance.
Yes - what your showing to do branching/conditionals on the "Button Controlled Pushed" or "Button Controlled doubleTapped" conditionals in your actions will NOT work. - For all the reasons the @kkossev has stated several times about states - His key statement was
"The buttons are stateless. You can use only the event generated in the RM5 rules as a trigger. Inside the rule you can not check the ‘pushed’ or ‘double tapped’ states, as there are not states for buttons. Only events."
it's not a question of likes/dislikes/preferences or "bad form/complex/simple" - What your trying to do with conditions in your actions on stateless buttons attributes WILL NOT WORK. - So while you may not like breaking things up by each "trigger" (which is what the button controller app, is basically walking you thru) - Where you have blocks of logic per each individual button trigger.
Folks seem to be talking past one another, but this isn't a question of style, it's "this is the way that buttons work", and they are stateless, and you can't do conditional logic off these attributes, no matter how much you keep trying (well, you can write the actions, they just will not work as you have discovered).
Perhaps try the alternative (breaking things up per button which then removes the need for conditional branches in the actions) and confirm that works (or not), then we can get back to stylist pro/cons. And we can talk about RM functions and other alternatives to "shorten/consolidate/reuse" code.
It should be noted that it is not entirely impossible to use button state as the basis for conditional statements. I do not know if this works for all buttons, but it does work for Inovelli Blue switch/dimmer “button” presses: immediately capture the “lastButton“ state into a local variable, and then test the local variable. I’m on vacation until June 30, but I can then post a rather lengthy Rule Machine rule that has been successfully used for more than a year on over 30 Inovelli Blue switch/dimmer units.
I’m confused. It’s working perfectly. Why?
Sorry, I used the word state because my original remotes several years ago I didn’t have to deal with that problem using HS4 Homeseer.
My Zen32 I handled slightly differently...and I may just convert my new remote to that approach since I can do it all in one rule. Matching text is always little risky as when I tried to covert to JS early on and the verbiage was no longer returned on my Schlage locks.
I don’t have one of these switches, so I can’t test this. However, does this switch have the attribute “lastButton“? If so, set a variable to that device attribute value and test string values that could be sent by button presses.
Also, in your original post rule, why are you testing button presses against decimal values? Is that expected output from that device? Also, I didn’t understand why you were testing the same button for two different values, 1.0 and 2.0. I also suggest that you try instrumenting your original rule by outputting to the log the actual values being presented by the device to verify if your equalities make sense.
Hubitat defaulted to the decimal stuff…and even I was wondering if it was going to work. But it does. It’s not the same button. It’s button 1 and 2 out of 4…I’m catching any single press from ANY one of the 4 buttons and running events based on each.
I thank you for the help and sorry for all the spin from when I used the word “state.”
I have this working and understand most would use the button app. It’s just my personal preference to like to see every action for a device in a single rule. I’d need 12 button rules with the app to get this done. 4 Single tap - 4 Double tap - 4 long press. Right now I’m using one rule for single tap…one for double tap…and one for the long press.
Because of my preferences, I’m probably going to change over to match text in responses so I can do it all in single rule. I think I have this now…and really appreciate your time. THANKS!
I’m still not quite sure I understand. At the parent level, your “12“ buttons look like one large rule that has 12 actions. You also get rid of all the duplicated actions from your original role, such as setting the private Boolean, the conditional IF structure, and exiting the rule — all of that is taken care of by the app.
Edit: The main reason that I test for button press states in the one large rule that I mentioned above is that I set local variables based upon button presses, and the rule responds to different trigger events based on the current state of those variables.
The more I play with it I agree…
Ultimately only you can decide what’s most important for you.
Rule machine can be used to control a multi-button device, but at the cost of a great deal of additional complexity.
While button controller’s interface might force you to click through more screens to create each button press/double tap and its associated actions, it handles for you all that additional logic you have to create yourself in rule machine.
I’m not a programmer and thus not so great with the logic implementation side of things. For me it’s a no-brainer to use the app that can do that for me.
The more I played with it the more I agree. Mainly because at the main device level YOU CAN see all the things the buttons do in a single place. My fault. The first time I used it…it just created new individual entries for each button push…and I hadn’t noted they all populate back up to the main entry.
Thanks again.
I don’t know when this was added…but I have about 40 Homeseer dimmers that have a 10 deep button levels and this never came up before in other posts on that…so really thankful.
Button controller? In 2018.
Funny…nobody ever mentioned it and I didn’t stumble across it…but anyway…thx for everything.