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
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.
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.
Here’s some evidence for the need of triggers (of all kinds) on a binary_sensor:
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
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:
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?
Completely agree - a binary_sensor with the ability to use the trigger platform would be really helpful. Even though I am not (yet?) using ESPHome, I found a use-case while using the Doorbird integration. It uses events to notify HA of for example motion or the press of a button.
Basically I suspect there are a lot of use-cases for different integrations outside of the mentioned ESPHome or Doorbird. But I just wanted to chime in on this feature request (?).
Right now I have to resort to several ‘helper’ automation scripts and an input_boolean. It would be really awesome if I could do just this:
---
# binary_sensor. See: https://www.home-assistant.io/integrations/binary_sensor/
binary_sensor:
platform: trigger
name: Frontdoor motion
icon: mdi:motion-sensor
timeout: 10 # or maybe 'off_delay'
trigger:
platform: event
event: doorbird_doorbird_motion
That would also be wery usefull for sonoff zigbee switch SNZB 01 when using as a doorbell or some other notification purposes.
how would you turn “pub/sub” events into a traditional sensor?
I have a nest doorbell, and it returns motion detection as events (you can see them in developer tools → events and subscribe to nest_event )
the doorbell sends an event every time a motion is detected, but that’s it really nothing else…
i want to create a custom motion sensor such that:
default state: OFF
when a motion even is received , change state to ON and start a timer. if another even is received while the timer is running, reset and timer. If no even is received and the timer reach 0, change the state from ON to OFF.
is that possible in any way?
that’s the thing, the binary_sensor + trigger doesn’t exist.
If you read the thread you’d see that people are describing how they would use it if it was supported
Template sensors and binary sensors now allow attaching triggers for updates in Home Assistant 2021.5.
template:
trigger:
platform: event
event_type: my_event
binary_sensor:
- name: Event recently fired
auto_off: 5
state: "true"
