Identify unchanged state for time

Configuration
1

Dear all,

to address a connection loss to a Homematic server (CCU or Homegear) I want to identify an entity that has been unchanged for a given time. However, I cannot figure out an appropriate trigger for this.

In other words: How do I trigger an automation, if a sensor’s state has not changed for a given time? Would this work?

automation:
  - alias: 'reconnect to homegear'
    trigger:
      platform: state
      entity_id: sensor.my_temperature_sensor
      for:
        hours: 1
    action:
      service: homematic.reconnect
2

Does not work: Configuration validation says ‘for’ requires presence of ‘to’ keyword.

3

Okay, this should work, but it doesn’t (does not trigger), even if the value_template returns True in the HA template test console. Any clues?

automation:
- action:
    service: homematic.reconnect
  alias: 'reconnect stale homematic connection'
  condition: []
  trigger:
    - platform: template
      value_template: "{{ now().timestamp() - states.sensor.my_temperature_sensore.last_updated.timestamp() > 600 }}"
4

That all looks good to me, especially because you’ve tested the template separately.

I assume you’re using the automation editor? Perhaps try to duplicate the format of another automation that you’re using that works.

5

I think the issue is, that - in case of a lost connection - the sensor.my_temperature_sensor does not change at all. The template platform watches for changes on the identified entities in the value template and obviously now() is not taken into consideration.

I changed the automation now to trigger every 5 minutes, but only act on an actual connection loss.

- action:
  - service: homematic.reconnect
  alias: reconnect stale homematic connection
  condition:
  - condition: template
    value_template: '{{ now().timestamp() - states.sensor.my_temperature_sensor.last_updated.timestamp()
      > 600 }}'
  trigger:
  - minutes: '/5'
    platform: time

Let’s see if that works …

6

Hi, i recently looked into this issue of identifying stale devices as well.

While there is a timestamp that indicates when an entity has last changed, this does not help the cause because the value may stay the same for a while (e.g. temperatures, lock state, etc.). You would need to have a timestamp that is updated every time a value is received /polled even when the value itself is the same.

Apparently there is no such timestamp. The only workaround for this is to set up the entities to update every time a value is received. This updates the timestamp but also the value itself even of it has not changed. Thus there are more logbook entries, more strain on the DB, useless time series values etc…

In my opinion this is a design flaw in the current implementation. If you integrate devices that communicate via RF, the detection whether a device has disappeared or is not sending info in the expected frequencies is essential for monitoring the health of such devices.

7

@jo-me While you are correct, the pattern still is applicable for my setup, as “my_temperature_sensor” is a device, that periodically sends a value, updating the last_updated value.

However, if no more data is received, because the gateway becomes unresponsive, the last_updates remains the same as well and that’s why my original trigger does not … trigger.

8

Jesus, that didn’t work out well. Returned from home I have 1200 persistent notifications and there is no ‘dismiss_all’ available.

Need to figure out something else.

9

create a template sensor that updates every minute while checking the problem sensors. Something like:

sensor:
  platform: template
  sensors:
    my_sensor:
      value_template: '{{ now().timestamp() - states.sensor.my_temperature_sensor.last_updated.timestamp()
      > 600 }}'

trigger off that turning ‘on’.

Just want to verify that now().timestamp() - states.sensor.my_temperature_sensor.last_updated returns a float/int. You may have to jog that syntax around a bit.

10

I think I need more than this. The sensor would stay “on” for some time after a re-connect, because the affected sensor sends periodically, not on demand

I go with periodic reconnects …

11

And is it working as expected? I want to do the same with my power consumption sensor wich updates every 1 to 2 minutes.

12

No, it didn’t. I am doing periodic, unconditional reconnects now every 3 hours.