With the retirement of Button Controller I'm trying to setup a simple on/off control using Rule Machine but it's misssing the Button type as a Action Condition so I can say
Trigger : button 2 pushed OR button 2 held
Action :
if button 2 pushed then
Turn on lamp
Else
Turn off lamp
End if
Select 'Button Device' as your trigger capability and then you'll be able to assign actions to your button bevice. This is how the old Button Controller was rolled into Rule 4.0
The way around using the “Last Event” of the button device works if the “held” condition is not used. But when used, the condition for Last Event may be both true for Held button 1 and Pushed button 1, avoiding the second condition from happening.
If your goal is to do different things based on different button events, then I'd really encourage you to look at Button Controller instead. I'm not sure why you wouldn't want to; it's nearly the same as RM but the "triggers" are button events, one reason the old "Button Controller" pseudo-trigger was removed in 5.x. That's actually a different issue from what you're talking about above, however, which is using the attribute as a conditional. I suppose what you have would work unless another event happens to have come in in the intervening milliseconds, but you could also use "Custom Attribute." But I don't think any of these options in RM are good ideas. (For example, your Rule will think button 1 was pushed even if triggered by button 1 held. The attribute value remains until it changes. There's another workaround I can think of here, but I don't like it, either...)
If you really do want to use only RM, then I'd suggest one Rule per button event with that specific event as a trigger. Then, there is no need for a conditional -- you know why the actions are running.
I was avoiding using the Button App, and individual actions per trigger to keep the Apps list as clean and simple as I can.
I have accomplished what was intended using the capability the button has of reporting “open” or “closed” as a contact sensor when doing a “button held”.
I still believe that adding Buttons as Actions Conditions would preserve the coherence for building rules in RM.
You can already do this; you just need to use Custom Attribute instead of a "stock" selection. But the problem either way is that it doesn't tell you what event just happened--it's only a way to test what the current value of the attribute is. (Attribute values are normally set by events; "button 1 pushed" sets the "pushed" attribute to "1." But it will remain at 1 until another button number is pushed. It will never disappear, neither with time nor as the result of other button events like held, released, or doubleTapped.) Thus, a conditional action testing for pushed == 1 doesn't really help you know what just happened, and it's why my suggestion would be to use a trigger instead, which works off of the event--i.e., the actual pushed event, so you know what just happened.
Button Controller handles this all for you and you can group all button events for a device into one "child" app, so it's likely cleaner than separate rules for everything, though that's certainly an option. But the best way to do it in either case is to rely on the event (trigger in RM, or just...built in to Button Controller), rather than a conditional (which can only check the state).