Not sure what you mean, but like the name says, if the sensor gets updated the last_updated resets to zero.
Im using this as an alarm trigger if the temperature of the heating not changes in 20 minutes.
- alias: heizung notifier on
trigger:
- platform: time
minutes: '/5'
seconds: 00
condition:
condition: and
conditions:
- condition: template
value_template: '{{ (as_timestamp(now())-as_timestamp(states.sensor.hz_kessel_ist.last_updated)) > 1200 }}'
- condition: state
entity_id: input_boolean.hz_alarm
state: 'off'
action:
- service: homeassistant.turn_on
data:
entity_id: input_boolean.hz_alarm
the input_boolean triggers an alert till i set it to off.
Thanks for your reply and example. Let me explain what I mean.
I have a washing machine that I monitor with a WeMo Insight Switch that measures current/power usage. When the wash is finished I want a notification. Problem is that the washing washing machine after finishing keeps tumbling the wash from preventing wrinkling. So the wash is finished and the power drops --> I get notified, but than it uses some power again and then drops again --> get notified again, etc.
I have a solution using an input_boolean that I clear and set to prevent duplicate notifications. It’s ugly and I thought that maybe your condition could help out.
I have a state sensor that indicates what the washing machine is doing, returning “On” and “Ready”.
So, I want to use your example in my condition of an automation of this sensor to see how long the washing machine has been on (the from state). I thought that maybe “last_updated” would reflect the time when the sensor was put in the “On” state when the trigger is fired going to the “Ready” state and then measure how long it has been in this “On” state and if long enough send out the notification. This would filter out the short tumble dry cycles.
I am aware of the “for” keyword in the trigger, but that only let’s me trigger for a TO state.
I hope that clarifies it enough.
I also had this issue / requirement.,
Until now I had created an input_boolean that I used as a flag, but find it overkill
My current solution is a condition to check whether the automation ran in the last xx sec
- alias: 'Cellar door opened'
trigger:
- platform: state
entity_id: sensor.foobar
to: on
condition:
condition: template
value_template: '{{ as_timestamp(now()) - as_timestamp(states.automation.cellar_door_opened.attributes.last_triggered) > xx }}'
Correction to catch the last_triggered = “None” after you restart HASS
- alias: 'Cellar door opened'
trigger:
- platform: state
entity_id: sensor.foobar
to: on
condition:
condition: template
value_template: '{{ as_timestamp(now()) - as_timestamp(states.automation.cellar_door_opened.attributes.last_triggered) | int > xx }}'
that’s not going to work. a change on your binary_sensor triggers the automation. As such the condition cannot be true since the automation just got triggered by a change in the binary_sensor…
What are you trying to achieve?
Thanks for your reply, i want to trigger an action when i open the door, but only if XX seconds (now i set 3 just for test, the final value will be 30 minutes) are passed since last time i opened.
no, if i open the door and it’s XX seconds since last opening, then run the action. The opening/closing is approx instantly, it’s the front door…
@TheCondor
This is completely untested, but in your condition above using states.binary_sensor.door_window_detector_sensor.last_changed The condition tests against the current state object of the binary sensor (which as already mentioned has recently been updated to trigger the automation).
As you only have one trigger for your automation, could you change the condition to use the previous state using trigger.from_state:
This doesn’t quite fit your scenario of time since the door was last opened, as your trigger contains from: 'off' this will always test against when the door was last closed, but as you mention above the door pretty much opens and closes straight away.
You can set the automations mode to single, and have your last action a delay of XX seconds.
The combination of these two prevents the automation from being retriggered until the timer is finished.
The link will take you to an example automation with cool down timer.