Automation trigger when value is not changing for some time

[1mfaasj (Bowa)]

Hi

How can I make an automation/ trigger only when a sensor is not changing the (latest) value for a hour? So inactivity.

Thanks!

[tom_l]

trigger:
  - platform: state
    entity_id: sensor.whatever
    to:
    for:
      hours: 1

Then null to: monitors all state changes but ignores attribute changes. If you are interested in attributes of the sensor not changing as well then leave that part out.

[1mfaasj (Bowa)]

should I set the “to” to “unknown” status or “not available”? it seems that the state of an entity remains at the last value when I look at the history of the sensor.

[123 (Taras)]

@1mfaasj

trigger only when a sensor is not changing the (latest) value for a hour? So inactivity.

You can monitor the value of the entity’s last_changed property.

In the following example, if the value of the sensor’s last_changed property hasn’t changed in over an hour, it sends a notification.

alias: example
trigger:
  - platform: template
    value_template: >
      {{ now() - states.sensor.temperature.last_changed >= timedelta(hours=1) }}
action:
  - service: notify.persistent_notification
    data:
      title: Stale Temperature
      message: >
        {{ now().timestamp() | timestamp_local }} Value unchanged for the past hour.

Another example, demonstrating how to periodically check multiple sensors.

Polling Devices to Avoid Silent Failure

Paste this template into the Template Editor. It will list all sensors whose states have not changed in the past hour (3600 seconds, change it to whatever duration you prefer). {{ states.sensor | selectattr('last_changed', 'lt', now()-timedelta(seconds=3600)) | map(attribute='entity_id') | join(', ') }} You can use that as a starting point to create a template that checks for ‘stale’ entities. If you want it to check sensors and binary_sensors, use expand(). {{ expand(states.sensor, …

[tom_l]

@1mfaasj

should I set the “to” to “unknown” status or “not available”? it seems that the state of an entity remains at the last value when I look at the history of the sensor.

No leave it empty. That way HA will trigger on any state that persists for an hour. It will ignore attribute changes.

If you delete the to: altogether then HA only triggers if the state and attributes have the same values for an hour.

[1mfaasj (Bowa)]

Thank you both! I suppose both suggested solutions will accomplish the same?

[123 (Taras)]

I believe there’s a subtle difference that may or may not be important to you. The difference is how they initially behave upon implementation.

• After implementing the version employing a State Trigger, it will require the entity to undergo at least one state-change before it can detect if that state-change becomes stale (i.e. remains unchanged for an hour or more).

• After implementing the version employing a Template Trigger, it will immediately detect if the entity’s state is stale.

[mtrista]

And neither one will work after Home Assistant restarts, right? Because for some reason last_changed still doesn’t persist past restarts

[tom_l]

@mtrista

for some reason last_changed still doesn’t persist past restarts

For good reason.

When Home Assistant starts it has no idea what has happened to all the entities while it was off-line. So it makes them all unknown until they are restored or updated.

Changing from unknown → some state will cause the last_changed property to update.

[mtrista]

I don’t think it’s for good reason. It should be optimistic about last_changed. With every restart, we lose all states. Tons of other people agree

[tom_l]

@mtrista

It should be optimistic about last_changed.

Fortunately for us the developers disagree with you.

[mtrista]

Unfortunately for us, you mean. Nothing stopping them from adding an additional, optimistic field if they’re so worried about what happens to last_changed while HA is off

[tom_l]

@mtrista

if they’re so worried about what happens to last_changed while HA is off

That is not what they are worried about. The indeterminate state of all entities is the issue. Updating last changed is just a by-product of initialisation.