WTH don't we have Event Binary Sensors?

We have Template Binary Sensors and MQTT Binary Sensors (and Sensors and Switches and Locks, etc). They’re great!

What we don’t have are the equivalent for events.

I recently tried to help someone who had used ESPHome for a door sensor. They chose not to use MQTT and the door sensor reported its data directly to Home Assistant as an event.

That sounds really efficient, until you try to configure a binary_sensor entity to receive those events … no such animal exists in Home Assistant.

The workaround involves automations and input_booleans and oh my! It would be so much easier if we had something like an Event Binary Sensor that could receive directly from the event bus.

The answer is pretty simple, events don’t have a state; binary sensors do.

There are many reasons not to implement those events as binary sensors (and templating them into one, is actually not a good idea). Instead, handle/listen for the event directly. It is much more efficient, less prone to errors as well.

His door sensor was sending its state as events. The event data contained its current state.

It would be like subscribing to an MQTT topic and receiving a device’s current state.

The workaround involves automations that call input_boolean.turn_on (or off) but an input_boolean isn’t a proper model for a door sensor.

Yes I agree that in that case (the door), the binary sensor would make sense. But that can be implemented in ESPHome itself right? I’m not sure what HA’s role in this part is…

When it comes to MQTT, Home Assistant’s role is to provide components for sensor, binary_sensor, etc that can receive MQTT payloads.

The same idea is suggested for events.

Unless, of course, there’s another way to consume the event data directly into a binary_sensor.

NOTE
If I was in his shoes, I would’ve chosen MQTT. The workaround is a Rube Goldberg contraption.

I don’t think there is anything against a binary sensor that wraps an event and timeout as long as it’s just user configurable.

We don’t want integrations that pull in data do it, as that means adding state that’s not there.

I agree 100%. It should be like an MQTT Binary Sensor that simply listens for incoming payloads via a specified topic. The Event Binary Sensor would be configured (by the user) to listen for specific events whose event data can be used (via a template) to produce ON or OFF.

Anyway, just tossing it out there; I don’t use ESPHome so my interest in this is superficial.

With Home Assistant 115 triggers are reusable outside of the automation integration. I think that this should become just a trigger configuration + a timeout for maximum flexibility

binary_sensor:
  platform: trigger
  trigger: # standard trigger validation
    platform: event
    event: esphome_movement
  timeout: 20 # standard duration config
6 Likes

Integrations like rfxtrx already struggled and made something in the past to convert event to binary sensor with off delay, would be nice to have a generic solution.

So today I learned how to listen to the event bus and extract events, such as Zigbee button presses.
Moving this to NodeRed I built the below event to Boolean flows.
It’s a shame this is not available natively within HA. and yes, I’ve heard the excuses about why it’s not, but forcing users into the world of the event bus is never going to win any usability prizes despite the huge gains made elsewhere…

Sorry to drag up something old (forwarded from the other thread that was closed as it was a duplicate of this one).

Something isn’t right with that persons ESPhome node / the info they were telling you if they didn’t have an entity for that data coming in. I use ESPhome with the HA API (so also not via MQTT) and I have entities for my sensors. ie: they should have actually had a binary_sensor already, created by the HA API from the ESPhome node

I recently ran into a problem using ESPHome API to generate ESPHome events on HASS. The documentation needs to be more clear, I should put a PR in, that events have to be named esphome.<some string you define> as in they must be the esphome domain.

So, the event named esphome_movement does not pass the check that ESPHome has defined to limit events generated by ESPHome to just the esphome Domain.

Code from components/esphome/__init__.py:

        if service.is_event:
            # ESPHome uses servicecall packet for both events and service calls
            # Ensure the user can only send events of form 'esphome.xyz'
            if domain != "esphome":
                _LOGGER.error(
                    "Can only generate events under esphome domain! (%s)", host
                )
                return
            hass.bus.async_fire(service.service, service_data)
        else:
            hass.async_create_task(
                hass.services.async_call(
                    domain, service_name, service_data, blocking=True
                )
            )

Only related to ESPHome, but you can not use device_name in the event data, I figured this out the hard way. I think only device_name key was affected as it seemed to be reserved key in certain areas for HASS. I need to return to the code to really understand what was occurring around this.

Pretty excited that triggers are being implemented outside automations! Looking forward to playing with the possibilities!

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.

This thread has taken a detour into topics unrelated to the original WTH.

Forget about ESPHome; it’s secondary to this WTH. It was mentioned only to illustrate what got me thinking about Event-based entities.

To re-iterate, the inspiration for this WTH is that there exists a REST API that can be used to send custom events to the event bus:
POST /api/events/<event_type>

However, these custom events cannot be consumed by an entity, only by automations using an Event Trigger. This WTH is why not have Event-based entities that can consume custom events.

Home Assistant already has an MQTT platform where received data is consumed directly by sensors, binary_sensors, fans, locks, etc. Home Assistant has the potential to support custom events in the same fashion; an Event platform that permits you to define, for example, a temperature sensor that receives its values from a custom event. Balloob provided an example above using a platform: trigger and that’s the direction I had in mind.

1 Like

Here’s some evidence for the need of triggers (of all kinds) on a binary_sensor:

#1

A trigger for a ZHA Event looks like this:

  trigger:
    platform: event
    event_type: zha_event
    event_data:
      device_ieee: 28:6d:97:00:01:03:32:ad
      command: button_single

That’s A LOT. If I could contain this within a binary_sensor, it would be easily reusable:

binary_sensor:
  - platform: trigger
    sensors:
      button_press:
        trigger:
          - platform: event
            event_type: zha_event
            event_data:
              device_ieee: 28:6d:97:00:01:03:32:ad
              command: button_single
        delay_off:
          seconds: 30

#2

I often want to know if a door has been opened or a light has been turned on in the last, say, minute. Outside of something like AppDaemon, there are only 2 ways to do this:

  1. A timer and an automation to turn on the timer when the door opens. This is tedious because adding the timer requires a restart of Home Assistant. On top of that, this means having two things (a timer and an automation) for what is really a single task.
  2. An input_boolean and an automation that triggers on the door opening, turns on the input_boolean, and then waits 60 seconds before turning it back off. While the input_boolean can be created without a restart (thank you, thank you, thank you), an input_boolean is not really the right answer because it doesn’t have all the features a binary_sensor has (like a device_class). And, again, this requires two things for a single task.
3 Likes

think I was searching for something like this, but the example provided there isn’t yet available isn’t it? Though 115 is mentioned, a config error is thrown on the platform: trigger…

hasn’t been implemented?