Why is there no such thing as a switch/button entity type??
What I find a bit strange is that there is no standardized way to represent a button pressed (long press, double press, press-and-hold etc) events and as a result the various blueprints are all tailored for their respective integration. (I only tried ZHA and Z2M, but I’m sure there are more format like a shelly button, zwave et al).
The bare minimum:
A new entity type “button” that can fire events like button pressed, long press etc. to the event bus. A hue light switch would expose 4 of them etc.
Stretch Goal:
Create switch devices that have button-entities of various types, e.g. a hue light switch would expose a ON_BUTTON, OFF_BUTTON, UP_BUTTON and DOWN_BUTTON. Once you have that you can start building blueprints that work for all light switches that expose those 4 buttons.
I believe that would bring the blueprint community to a new level. Right now the blueprints are mostly about enabling to use the light switches at all. But if there was no need for device-tailored blueprints we would start building blueprints that configure a light switch entirely (e.g. only provide the light entity and the switch device to the blueprint and all the buttons get their functionality for free)
And could you please elaborate a bit more about it?
I agree it’s a mess not having standardised events between the distinct Zigbee implementations, but I’m not sure this is what your WTH is about.
You are mistaken. There is no way to listen for ‘button commands’ to trigger an automation. Each combination of integration and concrete device needs custom handling.
Tbh I think this is the biggest shortcoming of HA since it prevents reusability and sharing of automations.
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.
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.
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?”
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).
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
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.
