INEFFICIENT - Detect and notify when entities become unavailable

[sagilo]

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

[123 (Taras)]

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.

[sagilo]

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

[123 (Taras)]

@sagilo

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).

Sensor - Unavailable/Offline Detection

Nothing too crazy and I’m sure it’s been done to death but I was inspired by a question in a thread earlier so I put this together and thought I’d throw it out there, maybe someone will find it useful.

[KTibow (Kendell R)]

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

[sagilo]

@KTibow

HA devtools

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

[KTibow (Kendell R)]

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

[sagilo]

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

[KTibow (Kendell R)]

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

[sagilo]

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

[123 (Taras)]

@sagilo

this will listen to all state_changed events behind the scene

It creates a listener for the specified domain.

@sagilo

I can’t find any reference to how filtering can be done on the trigger phase for state_changed event

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.

@sagilo

we should be looking at something like

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.

[sagilo]

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?

[xefil (Simon)]

Hello @sagilo , thanks for the BP, it’s what I was serching for.
Only a question: it’s possible to insert a delay? I’ve a remote sensor which sometimes is not available for some seconds, and would be notified only if it’s not available over some minutes in example.
Is that possible? Thanks!
Simon

[jazzyisj (Jason)]

@xefil I know this is a pretty old thread but it looks like you never got your answer.

If you haven’t figured out how to do this yet this template sensor implements a configurable delay which you could use to trigger your automations.

However, if you’d like to stick with the automation(s) you’re using now - you can just add a wait_template that evaluates to true if the trigger entity state is NOT unknown/unavailable with an appropriate timeout as your first action step.

Then add a condition right after the wait_template that evaluates to true if the sensor state is unknown/unavailable.

This will prevent the automation from doing anything unless the sensor stays unknown/unavailable longer than the wait_template timeout.

Also specifying a for: time on the condition: would probably also work.

[Michael_Baadsgaard]

It could be great if you can do so it only triggers if the sensor is unavailable for eg 5 minutes

[xefil (Simon)]

Thank you for the hints. Meanwhile I’ve changed sensor and found what was causing this flaps, btw that could become helpful anyway for the future.
Cheers and happy new year!
Simon