It would be useful.
Agreed. Though you can kind of do this already. I created an empty Rule in RM with conditional actions. Then the button uses the command "Rule Actions" or something like that.
Ah. They should just add conditional actions to the button controller IMO.
I definitely agree. Would be easier for sure.
More than just running a custom action, you can do the whole button control in RM using the button press in a Trigger as the trigger event.
I agree, this would be wonderful. The problem is that Button Controller only subscribes to Button events. The app would have to be expanded to include all device event subscription possibilities. And since that already exists in RM, it's not likely to get much traction. But I agree. Would make things a lot easier if we could. Fingers crossed.
Will go you one better: Next release is going to include Rule 4.0. Among other things, Button Controller functionality is folded into Rule Machine, with full access to conditional actions, global variables, etc. Coming soon....
I guess if RM 4.0 combines Button Controller functionality into it, this is a moot point. But from the general perspective of how one should write rule actions (or similar for buttons)--and Hubitat app development in general--it still seems like an important consideration.
I don't think RM, BC, or any app that just checks the state of the device as part of a conditional action should need to subscribe to that device. That should only be necessary when they are used as "real" conditions (subscription necessary so the rule can be evaluated) or triggers (for obvious reasons). For conditional actions (e.g., something under "Actions for True" or "Actions for False" in a rule), just checking the state when the actions are run should suffice--no subscription necessary since there is no chance of needing to respond to a change on such devices.
If this is not actually how RM works, I will rethink several rules I have with conditional actions that use a bunch of my motion sensors. (I like to minimize event subscriptions on these since most are used for lighting, and I can only assume: the fewer, the better.)
Check the apps details page and you'll see what subscriptions exist. Waits for example create a subscription when they occur.
But I probably shouldn't have used subscription. But in general, it doesn't check devices status, just performs them. So, none of that logic is built in the app.
This is correct. You will see this in spades in Rule 4.0.
In Rule 3.0 (and 4.0) a condition that is part of an IF-THEN or ELSE-IF does not have an associated subscription. A condition for Wait for Condition gets a temporary subscription, and obviously conditions of a Rule get subscriptions. The conditions of a Triggered Rule do not get subscriptions, only the Trigger Events.
In Rule 4.0, the Button Controller functionality allows IF-THEN and ELSE-IF conditional actions. Thes conditions can entail any devices that have state, and do not created subscriptions.
Sounds awesome. Excited to see what you come up with!