It’s a fair point. Although I should point out that’s basically how an input button works. Which might very well be users only experience with button entities in HA. They made a helper of type button and pushing it does nothing other then update the state.
And for the devices we’re talking about, pressing the button entities in HA would actually be the same as pressing the button on the device in a lot of cases. Nothing actually happens when you physically press the button except HA is told the button was pressed and any automations you have around that event are triggered. Same would happen if button.press was called on it.
EDIT: realized I was being confusing. The example you raised does pose a challenge obviously. In those specific cases (device button does something that cannot be triggered remotely) then I would agree, exposing a button is a bad idea. User would be confused why only the automations triggered and not the other stuff they expected to happen.
I guess the question is how common is that? I feel like the more common example (and what I’m seeing in here) is devices which do nothing in isolation. They exist to tell something else when a button was pressed. In those cases, exposing that event as a button seems acceptable
It is not a replacement for events created by physical switches (for which we misused binary sensors back in the day). As this entity is actionable virtually (pressable), which would not happen in the physical world. So, while events are used for Device → Home Assistant; buttons are used for Home Assistant → Device.
It would be nice to address the current desire though. Even if it is just some way of registering button-like events for the device, and then having a new device button trigger type (that is not integration specific). Going based on the current Device trigger system is not great, as every integration will expose these differently. Like even with some way allow a blueprint user to specify a device trigger to use (even if filtered to button-like triggers), it seems there is still too much variation.
Some integrations will expose a Device trigger type per button that needs no configuration.
Some expose a button click trigger where you then select a button.
I have some z-wave switches designed for “Central Scene” control, where you can trigger commands like double press, triple press, or press and hold. It makes reasonable sense that those should be available as button options for a blueprint. But each physical button is a separate central scene device trigger with a cryptic name, and then a parameter for each type of event.
I believe a standardized API for a single button will not suffice. If this is supposed to make a meaningful difference for the usability of HA it must be supported that a physical device exposes multiple buttons. In that case there must be a way to identify the buttons (could be button 1,2,3, or ON, OFF etc. ). A blueprint that only knows about the device must be able to listen to events of its button entities.
Obviously there will be cases of more exotic devices where such an abstraction doesn’t really work but they can always fall back to zha/mqtt events. But with a focus on abstracting the most common setups really nicely, we will be able to have blueprints that are independent of the integration and the button device. And this is where the magic begins.
Create a blueprint that needs any device with an on and off button and a cover entity to control any cover.
Create a blueprint for a light switch and a room that implements everything like cycling through scenes, dimming, on/off etc.
Blueprints that control heating/trvs/fans depending on a switch (for temperature setting) and a temperature sensor.
Right, hence why my proposal would be for integrations to be able to register multiple buttons (or possibly gestures, or other supported button-like events) on a device. They could give the “buttons” relevant names: “one”, “off”, “config”, “red”, “button 2”, “up button triple press”, “down button long-press”, “shake the wiimote”, or whatever.
Then a new “device button” trigger type would in the UI let you select a device, and it would provide a list of the registered buttons to pick from. If the trigger type under the hood took in an opaque button identifier, with the ui selection interface being a selector, then blueprints would be able to utilize this.
There must be a subsystem or layer somewhere that harmonizes those button names. If one device registers a button with the name “off”, but another with the name “OFF_BUTTON” you have the same problem yet again that a shared blueprint isn’t easily possible. There are certainly a bunch of ways to do that. Some examples
HA specifies how buttons must be called (downside: Your button may not match any of the existing names)
There could also be an easy way to let the user map buttons. In the HA settings each button could have a drop down where you get to specify the button’s type.
A blueprint reads all the possible buttons and gestures from the device and asks the user to map them (More work for the user but the solution is more “universal” than the aforementioned).
Probably an old and dead thread but I find it odd that every other device has it’s own entities but in the case of physical buttons I have to go digging through events to figure out if a button was pressed or not.
Two devices comes to mind: Zooz Zwave ZEN34 and The Aqara Zigbee mini “switch”.
Right now as it stands using the standard ZHA platform for the Aqara device, I cannot see if a button was pressed through the log book, and because it’s not an entity, I cannot filter it through history, I have to manually find it.
Clicking on the logbook and attempting to filter on the device doesn’t show anything. I mean at least allow us to filter it in both the logbook and the history.
Any integration can add events, those events are listed in the documents page. HA is working on making this easier, but you’ve always had to manually manage events in the past. So that’s what you have to do on most integrations. The event entity was added last release, I would expect more integrations will take advantage of this entity in the future. For now, you’ll have to manually do this yourself.
I am trying to understand what is written, but cannot find a solution. It is the case that so-called scene buttons are recognized. However, only one entity is offered for the firmware and the battery. Entities for the switch itself are missing. How are you supposed to work with this? Or can you simply not use scene buttons? Or what do you have to do to use them?
