INEFFICIENT - Detect and notify when entities become unavailable

Tags: #<Tag:0x00007f324ffc4738> #<Tag:0x00007f324ffc4648>

Blueprint to perform an action when an entity becomes unavailable.

Configurations:

  • Filter - regex over the triggering entity ID, I apply it mostly for ‘sensor’ entities but any regex will work.
    For example “light|sensor” for all lights and sensors or light.name for a specific entity
  • Action - select the action to execute when the automation is triggered, {{ trigger.event.data.entity_id }} will be replaced with the unavailable entity ID.
  • Max queued - as this can be triggered for multiple entities, you can set the maximum queue depth, defaults to 10.

gist url: https://gist.github.com/sagilo/9c5f85794fa8ee3427e7cdab27f573f5

3 Likes

The automation this blueprint creates relies on the following trigger:

trigger:
  - platform: event
    event_type: state_changed
    event_data: {}

This automation is triggered by every state_changed event produced by Home Assistant. In other words, it will be triggering very frequently.

There are several existing solutions to report unavailable entities and they typically rely on a Template Trigger that only monitors desired domains (light, sensor, binary_sensor, etc) as opposed to monitoring every event.

1 Like

Care to share some of these solutions?
Do note there are conditions to enforce the domain and entity

Each state_changed event is tested with the conditions to determine if the action should be executed. In other words, each event is processed.

The other solutions are readily available to everyone by using the forum’s search function. Here’s just one example implemented as an efficient Template Sensor (also supports a white list).

1 Like

In the template section of HA devtools, it has an example that goes through the weather domain.

IIRC this will only allow me to filter the events on the condition phase, not on the trigger phase.

I mean change your event trigger to a template trigger. I guess I might be confused though.

I’m not sure how this is more efficient, this will listen to all state_changed events behind the scene to update the sensor state, is it not?
I’ve tried to look that up, but I can’t find any reference to how filtering can be done on the trigger phase for state_changed event

It will still listen; however the automation itself will not be triggered as often.

Got it, so we should be looking at something like:

trigger:
    platform: template
    value_template: >
      {{ trigger.event.data.entity_id |regex_search(filter, ignorecase=False) and 
      trigger.event.data.new_state.state == 'unavailable' and 
      trigger.event.data.old_state.state != 'unknown' }}

And removing the condition altogether

It creates a listener for the specified domain.

Event Trigger can contain an event_data option. However, a state_changed event contains various keys in data but none are as general as domain.

Go to Developer Tools > Events, enter “state_changed” in Listen to Events, then click Start Listening. Either wait for a state_change or turn on a light to create one. The resulting event will show you what’s available. There’s entity_id but that’s impractical for this purpose.

The example you posted is a Template Trigger that references the Trigger State Object. How do you figure that can work?

The Trigger State Object can be referenced in the automation’s condition or action because it is a product of the trigger. The trigger itself can’t reference it because it’s the trigger that produces it.

Make sense, so the only option is either implement something that implicitly listens to state_changed and update something else or listen to specific entities, is that correct?