I think the real problem that is raised is not that we need an event binary sensor.
First to recap WHY you cannot define a binary sensor for devices like remote controls (switches you put on the wall with buttons you press).
Quite many real life remote controls do not have a primitive on/off state.
First let is look at the entire switch. Let us take a Philips Hue 4 button remote.
First the top level, the entire remote.
The remote does not go in an ON state when you press ON and an off state when you press OFF. The thing you control like a group of lights go on and off. But you can have multiple switches controlling the same light.
A remote control is a device on its own. And each button has its own life.
So let us look at a button on a remote.
I can press it and hold it down. And I can release it and it turns off. Electrically you can think of this as a thing with a binary state on and off. But reality is that the physical electrical switch is not what you see on the Zigbee network. The button creates messages. A message when you press the button. Another message when you release it. A third message if you release it after having held it down for a longer time (long press).
I have a 6 button zigbee remote that sends a separate event message if I double press it. So same button can send on, off short, off long, and double press.
They are not binary
So WTH don’t we have Event Binary Sensors? Because most of those are not even binary.
OK. Now the natural reaction could be, well make it a sensor then with multiple states. But that is still misleading. If I press a button and release it with long press am I then in a long press state until next day when I press the button again? Not really.
An event is a thing that happens in a zero duration atomic moment if time.
There is a real problem. And it has been attempted fixed in the Automation editor.
I can select a trigger type Device
I can select a remote control switch
I can select the exact button press
It looks great until now. And then BUH!
This gets saved in automation.yaml (trigger part only)
trigger:
- device_id: 7f8fff2db7ad4db9b20fe1396cdcd147
domain: deconz
platform: device
subtype: turn_on
type: remote_button_short_press
If you only live and breath in the automatin editor and its limitations then you probably do not care. But the minute want something advanced and organize your automations in files and folders then this feature has been implemented in a way that is not really user friendly in that context
The issue is the device_id. 7f8fff2db7ad4db9b20fe1396cdcd147
There are two things that would have made this perfect in both worlds.
- You should be able to use a human readable name. The device_id is not for humans. That same device is called “Bed Right Switch” in my installation. When you add devices, HA should create event entities with the same name rules that we know from all other entities. It would be a stateless entity obviously (see above why)
- You should be able to see the list of events using the same friendly names as we have available already in the automation editor.
It seems to be all there. The UI that was added to the integrations like Deconz from which you can create automations are a great feature for basic level users.
To create same feature with the event syntax you do this
trigger:
platform: event
event_type: deconz_event
event_data:
id: bed_left_switch
The id is human friendly. It takes the friendly name and create the bed_left_switch using the well known rules used for entities.
Problem with the event syntax is the geekly way people have to know how to listen to events and press the buttons on the remote and write down the id and event codes (4 digit numbers for deconz devices)
If you could use this device trigger syntax already made in the automation editor but with a human friendly device name which you could find in the integration UI, then you would address the real problem behind this WTH.
