Feedback

The recommended automation structure for an event entity includes a step "4. Prevent the automation from running on unavailable or unknown states."

This successfully prevents the automation running when the entity becomes unavailable, but when the entity goes from unavailable to available, the automation runs, which is probably unwanted in most cases.

My use case is ESPHome's event component detecting a doorbell (on a Sonoff RFBridge). When I change the YAML for the RFBridge I have to reflash/reboot it, causing the entity to go unavailable and come back, causing an automation run when it comes back. Or this could also happen during HA reboots.

I would happily do a PR but it requires a decision on what method to recommend:

1. My personal preference is to use not_from and not_to in the trigger YAML, which unfortunately are not supported in the visual editor.

   trigger: state
   entity_id:
     - event.rfbridge_doorbell
   not_from:
     - unavailable
     - unknown
   not_to:
     - unavailable
     - unknown

   Incidentally, is this what was meant by the line about "the not_state attribute of the state trigger", or is that line stale? Because I can't see a not_state attribute in the YAML docs.

2. Alternatively, you could use from_state a template condition like:

   {{ trigger.from_state.state not in ["unavailable", "unknown"] and trigger.to_state.state not in ["unavailable", "unknown"]}}
   

   I figured if you're going to have a template you may as well handle the to_state there, instead of separate conditions.

I haven't found any "no code" alternatives to the above two: it seems to me the previous state of the entity is not exposed in pure-visual editing of triggers or conditions, and when I compare the traces of "came back from unavailable" and "doorbell actually pressed" then the only difference I can see is in the previous state (e.g. last_changed is updated in both cases). I suppose you could check that the timestamp itself is recent, but that just feels messy.

I think the ideal would be to implement a device-level trigger for event like the one for button, and recommend the use of that instead. So create homeassistant/components/event/device_trigger.py if I've understood correctly, and include the declared event_types from ESPHome as a subsidiary dropdown? That seems like it could entirely avoid these issues of going to/from unavailable.

URL

https://www.home-assistant.io/integrations/event/

Version

2025.12.3

Additional information

No response