I stand here corrected.
But why are all those blueprints depending on the integration (zha,z2m) in this case? Why do they depend on the concrete device? What am I missing?
Correct. However, you’re not alone; many WTH proposals are a result of a limited understanding of Home Assistant. Nevertheless, it’s better to discuss it, and learn from others, than not at all.
1 Like
That’s right… It’s impressive how much I learned with those WTH…
After a bit of research it turns out that my initial WTH was correct. You can’t trigger on button events, just events that are custom per integration.
The UI allows to trigger events on button presses, sure but in the yaml you can see that it actually listens for either zha or mqtt events, not for some abstract button event. Further the button names are different between different remotes. This prevents sharing of any blueprints that depends on button presses.
My opinion stands that this is the biggest shortcoming of HA.
The ZHA integration is managed by the Home Assistant project. Zigbee2MQTT is a completely separate open-source software project. It would probably be nice if both projects used the same terminology to describe button events but I doubt, at this point, the developers of either project is willing to rename their events (it would represent a significant breaking change).
If there are integrations managed by the Home Assistant project that don’t use the same terminology for their button events, those integrations stand a better chance of standardization.
1 Like
This is a pretty fair assessment. Idk if I’d categorize as the biggest shortcoming of HA personally but it is significant.
It is definitely suboptimal that I cannot make a blueprint that asks the user for a button on any random device and does something they find useful when pressed. Instead you must ask the user for a device of a specific make, model and integration which makes the blueprint far less useful. Or ask them for details of an event which isn’t very discoverable and tough to configure.
It’s even more confusing because you can actually ask users for a button and that’s not what you want. Because physical buttons on devices are not represented as button type entities in HA, they are represented as device actions.
I have a similar problem with how notifications work. You have to ask for a mobile device instead of a notification channel or something more sensible. Because like physical buttons, devices represent the ability to send a notification to them with a device action. That’s if there’s a device at all, many times there is only a notification service which has no selector. I’d probably call this a bigger limitation personally considering how common notifications are in automations but idk if the community agrees given the votes.
That being said, I would suggest rephrasing the WTH a bit. Now that I get what you’re saying I agree. But it’s confusing because there are generic button and switch type entities.
EDIT: @Dominic3 Maybe the title should just be “WTH aren’t buttons on devices represented as button entities in HA?”
2 Likes
Isn’t the point of home Assistant to provide a common interface to devices that are connect through various integrations? It works for most device classes like lights. My elgato key light and my hue lights have the exact same interface in HA. Button events are. Strange exception.
That’s true but misses the important fact that it’s not z2m but the mqtt integration that defines how mqtt devices are represented in HA.
A change doesn’t have to be breaking. A new event type for buttons can be added in addition to the old ways.
If the button uses Zigbee and you use Zigbee2MQTT, the button event’s name is governed by Zigbee2MQTT. Home Assistant’s MQTT integration doesn’t impose a naming convention for button events, not for Zigbee2MQTT or for a device publishing directly via MQTT.
Changing a button event’s name is a breaking change. An existing automation with an Event Trigger listening for press won’t detect a button_press_short event. There are no aliases for button events (or any other kind of events).
1 Like
It is but it could be managed. Two events could be published for the same physical button press for a while, new name and old name.
Fwiw though I don’t think events are the whole solution here. Even if you standardize the name of the event you still have to make these events unique for the device. Unless I’m misunderstanding the op wants a system where a blueprint simply asks for a button press event from a physical piece of hardware. A user should be able to select the one button from this device or any one of the many possible button-like options from this device. Regardless of how many buttons the device has or even whether the physical action required is literally pressing a button (or shaking, turning, dropping, etc)
Ideally the user would have a way to select something that represents a button press type action irrespective of device, appearance or number of button-like actions it has. Or select an actual button entity and have integrations make button entities for these button like features.
I like the latter personally. Buttons already have their state equal to the date and time it was last pressed. Why couldn’t integrations translate physical button presses into button type entities? Just update the state any time the corresponding physical action is triggered
1 Like
Reusing the button entities would be a bad idea.
Button entities for home assistant are meant to be a way of triggering the device to do something.
But let’s imagine I have a device with a physical button, that does something to the device that cannot be remotely triggering for some reason (perhaps the button is mechanically linked with no electronic actuator). The integration exposes the button press as a device trigger to allow it to trigger additional automation.
In that scenario, creating a buton entity that the user could push would be super confusing, as it would not trigger the devices own action, but only your secondary automations.
1 Like
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
For reference, from the architecture discussion that introduced the button entities:
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.
1 Like
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
coverentity 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.
- … so much more
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.
Doesn’t HA do exactly this, here is a screenshot of the automation options from an opple remote device
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).
What about a new entity type: “physical button”?
A physical button is like a button but can’t be pressed from Home Assistant.
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.
Sounds like the new event entity that was introduced in 2023.8.0 is what you are looking for.
Just need to wait until ZWave and ZHA integrations implement those entities.
Agreed. I thought my Xiaomi Zigbee button was not compatible with HA because nothing showed up in the device like say a DHT sensor