Curious as to why these commands were added to the capabilities and basically forced upon the drivers? I have not found any use to include these in my drivers but I believe I need the capability in there for the RM and button controller apps to allow the associated events (pushed, held, released) to be attached to rules (correct me if wrong).
So now all my drivers show these command buttons but I don't have any functions for them, nor do I see a need to add the functions. When pressed it just generates errors in the logs. Is there a real world use-case scenario to use these commands besides testing things? Testing rules is the only time I can see they might be helpful.
I know there was some debate about this back when the capabilities themselves were introduced. It seems like they have decided the commands are now required and not just the events/attributes. I assume that one intent was to make all button devices usable on Dashboard or with the "push" action in Rule Machine, both of which call push() (with a button number) on the device and what will fail if it's not there. Presumably, this will facilitate knowing that similar commands should work going forward here and elsewhere.
Despite it not being technically required before, most (all?) stock drivers already implemented these commands, and many community ones did too. For physical devices, generally what you want thee commands to do is to generate a "virtual"/digital buttons event of the specified name (push, hold, etc.) and value (button number). That way, users can trigger automations based on these events either physically or via Hubitat--the latter now more reliably. This should be straightforward to implement in any driver.
Yeah I get what the command should do, I just cant think of any actual purpose for using it.
Lets say I have button 2 on my switch activate a scene, I press button 2, the button controller rule picks it up and activates the scene. Now what if I want something else to activate that same scene? Do I need to send a virtual pushed 2 command to activate button 2 on that switch??? No, I just activate the scene directly. Same would go with anything I can think of.
Maybe I am not thinking outside the box enough but I honestly cannot think of any situation where you would ever need to trigger those commands from any automations.
EDIT: I re-read your post, and I think I was looking at it from the wrong angle. You are suggesting that people might want to add a button push to the dashboard, which would require the command. That might be what I was not thinking of. Although I seem to have quite a few people using my drivers and no one has asked for this
They are only forced on a driver that presents the associated capability. If your driver has capability 'holdableButton', then it gets a command 'hold'. How else should it work?
But I think the issue the OP raised is different: doubleTap() is now a required command if you implement the DoubleTapable capability, whereas before it was basically convention but not technically required. This has no effect on physical use of the device (the main point of the capability is to get the attribute/event into Hubitat in a standard fashion, as it continues to do) but means that anyone will now be able to digitally "simulate" these button events. So, for example, if you have an automation triggred off a double tap, you can now do it with a command on Hubitat instead of just from the physical device, and you don't need to create a virtual button (adding it as an additional "trigger"/subscription for that app, for example) or use some other workaround.
But double taps aren't special in this regard. (Except that push() is the only not-formerly-standard command I know of that received anything that could have been considered widespread use before: Dashboard and RM both assume its presence for some uses.)
This seems like another form of the old FAQ that boiled down to whether a button device is a Sensor (only changes by received events) or an Actuator (can be changed with commands).
e.g.:
Why do buttons not have push() command?
Why do motion sensors not have active() and inactive() commands?
I presume from these capability updates that it has been decided that the button related capabilities should be used for devices that maybe either or both sensor and actuator.
All that being said, nothing prevents a custom driver from ignoring or not implementing these commands if you want to use the capabilities to implement a "sensor" device.
This sort of came along originally with Lutron stuff, where RA2 main repeater and Caseta SmartBridge both have "phantom buttons" that can be programmed in the Lutron system to activate scenes or other specific things. But, to be of any use, since they are phantom, something in software has to 'push' the button -- hence the push command on these drivers, and held and released.
I do find from time to time that it is very useful for an app to 'push' a button of a real button device, i.e,, to cause the same thing to happen that pushing the real button would do. Even if viewed as a sensor, the event generated is subscribed to, and causes something to happen.
If I am understanding correctly, I do not think that this is correct (it hasn't been in the past for other capabilities). Your driver can raise events for attributes (e.g. as a result of parsing incoming messages) independent of which command methods it implements.
That's true, of course, but I think he was referring to (and I know I was referring to) the built-in "Push a button" action in Rule Machine, which runs push() on the selected device. Similarly, a "Button" tile on a Dashboard runs push() on the device too, both with a specified button number. I'm not aware of anything that depends on this formerly-not-quite-standard command--push() seems to be the only one with any traction so far--but my guess is that this may (slowly...) change for the other new commands as more apps can depend on these for button devices.
EDIT: I realize I may have misunderstood; perhaps you meant that you can declare that you implement the capability but not implement the method, or implement a "dummy" method that maybe just logs that it's not supported. That's true (though I'm not sure the former is really encouraged), but implementing a "digital" button event should be do-able and is personally what I'd recommend (and what I assume the intent of these commands is).
I understand what you are saying, but I don't see how formalizing it with the capability definition in this release changes any of that... That is, if you don't implement push() command, the button tile wouldn't work with 2.2.5 and it still won't work with 2.2.6 unless/until you implement the method.
I had this same discussion with @bcopeland when he first released his drivers for the Zooz zen switches and dimmers.
I did have RMs that digitally pushed button on switches and his driver broke that behaviour. He asked me at that time why I would ever do that (lol)
Why? From my POV it’s nice to define behaviour in one spot. If I define a button controller action to do something and I want a RM to mimic that behaviour then just point to the button. Yes scenes is another option but a little overkill for defining most button behaviour.
Does this new functionality allow me to activate a button's push/double/held status directly via MakerAPI at last? If so, Hallelujah! I saw absolutely no reason why button capabilities were not available to a button driver on the device page and via MakerAPI. Made no sense whatsoever. Imagine a switch not allowing direct access to on/off.
most, but not all button controllers are sensors only (ie they only generate, and cannot accept commands), for those devices that aren't (specific devices within Lutron and other lighting systems) there needs to be a way of sending a button activation command to the actual device via its API, the device will respond via parse within the driver which will then generate the button event, the same as if the actual physical button was pressed in the host system.
for button controller sensors, the methods being requested to add really couldn't get any simpler than:
Is that a yes, a no, or an add this to your driver and it will work? Other than that I have no idea what you are saying, sorry. If its simple, maybe it should be fixed for dummies like me. In the meantime I will persist with the pain of having to use a virtual device activated by MakerAPI in order to then drive the button activation I want.
(Except that 
