Buttons as binary_sensors problem about architecture

[ciotlosm]

That beats the purpose of auto-discovery of entities, and you can't reuse that entity in multiple automations, you would have to reuse the topic manually

[MartinHjelmare]

We usually implement buttons that are stateless as events and not entities. That solves the problem I think. Events can have whatever event data that is needed, ie button press characteristics.

[cgarwood]

The only problem with events is then you can’t trll how long a button is held down. I’m using a Lutron Caseta custom component that uses sensors for the pico remotes and if I press and hold a button the sensor stays active until I release it, so I could theoretically do something different for a long press. The actual remotes themselves don’t report special long press events, just key down and key up events

[ciotlosm]

@MartinHjelmare does it matter if a button has support for state or not? Very few button types are going to have a "pressed" state for long (there are a few red emergency buttons that stay locked once pressed).

Also how would "events" be implemented in an "auto-discovery" component like mqtt?

@cgarwood as long as you receive both events, you can get around it with automations and timers but that would again be workarounds for something that is basic to some buttons.

If we would have a new type of entity based on a sensor that has knowledge of key up/ key down and always publishes events for automation, would make life easier for a lot of things.

[balloob]

I think for Z-Wave, the button itself will recognize if it's pressed once, twice or 3 times and notify us of that and we translate that to an event. From a signal sending perspective, that also makes the most sense.

[ciotlosm]

Thank I guess this is more an MQTT binary_sensor problem because we don't have events triggered on messages?

[balloob]

You can have an automation listen to messages on an MQTT topic, that would solve that?

[balloob]

You can write an automation that

• listens to a wildcard topic on MQTT
• fires an event with that message

That will work like auto-discovery and you can build automations on top of that event. Also, you can just listen multiple times to the same wildcard topic in automations.

[MartinHjelmare]

I think we should close this.

• Stateless buttons should be implemented as events.
• MQTT now writes the state change immediately to the state machine, so has less risk of loosing quick state changes.
• Integrations that use MQTT as transport should implement new components, that depend on the mqtt component, that support buttons as events. The new components can handle discovery as they need.
• We don't need to support auto discovery of every type of device in the general mqtt component.