Automation "Conditions:" section breaks script silently

Configuration
,
1

I have this automation script:

- id: '1784547837620'
  alias: Person on driveway notification.
  description: Detection of person on driveway.
  triggers:
  - entity_id: binary_sensor.oprijpad_person
    to: 'on'
    trigger: state
  conditions:
  - condition: template
    value_template: >
      {% set pause = 60 %}
      {% set secondsSincePerson = (as_timestamp(now()) - as_timestamp(states.binary_sensor.oprijpad_person.last_changed)) | int %}
      {{ secondsSincePerson > pause }}
  actions:
  - action: notify.send_message
    metadata: {}
    target:
      entity_id: notify.samsung_a71
    data:
      title: Home Assistant
      message: "Person on driveway {{ now().strftime('%H:%M:%S') }}"
  - action: mqtt.publish
    data:
      topic: "HA/Alerts/Driveway/Person"
      payload: "{{ now().strftime('%H:%M:%S') }}"
      retain: true
  mode: single

It either fails or doesn’t run at all. I can’t tell for sure because there is nothing in the log. I do know for sure the event fired, the last_changed property on the sensor does change.

When I take out the “conditions:” section, it works as expected. The code in the conditions section is good, it yields True when pasted into the template tester under developer tools.

What is wrong here?

2

I believe your condition is definitely the issue. secondsSincePerson last_changed will never be > than pause. Enter the fields separately in Developer tools. I think it will play out as 0>60

Test this as your condition :down_arrow:

conditions:
  - condition: template
    value_template: |
      {{ this.attributes.last_triggered is none or
         (as_timestamp(now()) -
          as_timestamp(this.attributes.last_triggered)) > 60 }}
3

I see… On every run of the script last_changed is already updated when the template is processed so it is rather useless in an automation triggered by the same event. I would need a prior_update (which does not exist) or use the mqtt value which was the original idea.

When run in the template tester the sensor value does not change so it looks good.

Thanks for making me feel stupid.

4

Generally not recommended, but you could use a delay here at the end of the automation. Then you do a single mode so that any future triggers get ignored if delay is still in process. You will not get notification more than 1 per minute.

5

Hopefully you’re being sarcastic as I was simply trying to assist!

{% set secondsSincePerson = (as_timestamp(now()) - as_timestamp(states.binary_sensor.oprijpad_person.last_changed)) | int % was always going to be zero. I took your logic in the post and tested it in Developer Tools…

When the binary sensor was triggered, the condition was 0>60 and failed.

6

@LiQuid_cOOled Hey, I was joking and I am truly grateful. I just feel stupid for not seeing this earlier myself.

I forgot to upvote your answer (too busy feeling stupid), fixed.

7

To get what you want, change your condition to:

  - condition: template
    value_template: >
      {% set last = trigger.from_state.last_changed %}
      {{ now() - last > timedelta(seconds=60) }}
8

One other thing: notifications are not pushed (in a meaningful way) to my phone. I only see and hear them after I wake my phone. I already changed the settings for the companion app to have it not ever go to sleep. I also found examples for setting priority to high for the notification like so:

data:
  title: "Security Alert"
  message: "Door opened!"
  data:
    ttl: 0
    priority: high

But that just makes the script fail with an error. “data:” is not valid under data. Putting priority directly under the first data as a sibling of message is not approved either.

Is there a way to use this properly? Is it a depricated thing that used to work with an older version perhaps? Is there a better way to make the notification make a sound while the phone’s screen is dark? It’s for Android.

9

@petro Awesome! So trigger.from_state.last_changed gives me last_changed at the time of the trigger. Just what I need and it seems to work.

10

Wouldn’t this.attributes.last_triggered still work so it’s not looking at how long the sensor was off? I referenced my saved Taras examples…

Your method is much cleaner!!

11

Your automation is triggered when binary_sensor.oprijpad_person changes state to on. trigger.from_state.last_changed represents the time when binary_sensor.oprijpad_person changed state previously. In other words, it’s the previous time when it triggered the automation and is effectively the same as this.attributes.last_triggered (which is the previous time the automation was triggered).

conditions:
  - condition: template
    value_template: >
      {{ now() - this.attributes.last_triggered > time_delta(seconds=60) }}

NOTE

A newly created automation does not have a value for this.attributes.last_triggered because it has not been triggered yet. To guard against the template’s subtraction failing, the default function can be used to supply a value.

      {{ now() - this.attributes.last_triggered | default(today_at(), true) > timedelta(seconds=60) }}
12

See here. You’re using notify.send_message in your actions, but that doesn’t support additional parameters. Even if you search the companion app docs, there’s no mention of it, so it looks like it’s pretty much in its infancy.

Switch to notify.mobile_app_your_phone_name like the notification docs tell you & you’ll be able to add priority & ttl.

13

@ShadowFist It works perfectly!