Why is this condition with template in this automation not working?

Configuration
1

Hi, I’ve set up an automation that was working fine as long as the condition wasn’t introduced.
I tested the template that’s used in the condition in /developer-tools/template and it is giving me the desired true/false outcome there.

- alias: kattenbakteller
  trigger:
    platform: state
    entity_id: binary_sensor.door_window_sensor_158d0003cb4f89
    from: 'off'
    to: 'on'
  condition:
    condition: template
    value_template: "{{ (as_timestamp(utcnow()) - as_timestamp(states.binary_sensor.door_window_sensor_158d0003cb4f89.last_changed)) > 900 }}"
  action:
    - service: script.turn_on
      entity_id: script.1573828382796

However when used in the automation the service never gets fired.

I’ve also tried with

{{ as_timestamp(utcnow()) - as_timestamp(states.binary_sensor.door_window_sensor_158d0003cb4f89.last_changed) > 900 }}

which also works in the dev-tools, but that makes no difference.

Thanks for having a look y’all.

2

The trigger says:

Did the window sensor just go from off to on

Then your condition says:

Did the window sensor last change state at least 15 minutes ago

If the first is true, the second can’t be :wink:

1 Like
3

This will trigger when the window is open for at least 15 minutes.

- alias: kattenbakteller
  trigger:
    platform: state
    entity_id: binary_sensor.door_window_sensor_158d0003cb4f89
    from: 'off'
    to: 'on'
    for:
      minutes: 15
  action:
    - service: script.turn_on
      entity_id: script.1573828382796
1 Like
4

I see my logic error now, thanks :stuck_out_tongue_winking_eye:

The last_changed will always be the timestamp when the automation fires like i’ve written it now. What I want is for it to check against the previous time the sensor state was changed.

5

But what are you trying to achieve?

Do you want to have it trigger if the window has been left open (as @123 posted), or something else?

It’s incredibly hard to help folks who say this isn’t working as expected without actually saying what they expected :wink:

6

adding my keep it short and simple OCD to @123’s automation:

- alias: kattenbakteller
  trigger:
    platform: state
    entity_id: binary_sensor.door_window_sensor_158d0003cb4f89
    to: 'on'
    for:
      minutes: 15
  action:
    service: script.1573828382796

Binary sensors ar either on or off, so no need to use to: and from: .
If you don’t need to pass further data to a script, simply call the script.
Only 1 action? no need for the list indicator -

cheers! happy automating

7

They can’t be unavailable?

1 Like
8

Depends on the platform, but yes they can.

9

I don’t want to check for how long the door/window is open.

I’ll try to be clearer: the action is incrementing a counter. But I don’t want to trigger that action every time the door/window opens. It should only trigger when the previous time the door/window opened was at least 15 minutes ago.

(it’s a litter box counter, the cat will make the sensor trigger multiple times during one litter box visit and I want to make the counter go up per visit and not for every time she makes the flap move)

10

Right, so you don’t want to check the current state, you want to check the previous state. That requires templating, and you’ll use the trigger.from_state state object.

  condition:
    condition: template
    value_template: "{{ (as_timestamp(utcnow()) - as_timestamp(trigger.from_state.last_changed)) > 900 }}"
1 Like
11

hmmm, must confess I’ve never given that any thought, since the only ones in my believe could be badly configured binary sensors template. That’s why there always should be a safeguard in those templates.

Other than that, I’ve learned here that they are either on or off, and use that for over 3 years now, without any flaw at all…
Which is not to say it can’t be of course… (#Popper)…:wink:

12

A loss of connection between Home Assistant and the MQTT Broker is sufficient.

Here’s a recent example, by Tinkerer, showing how to leverage the state-change from unavailable to on.

13

ok, thanks for pointing that to me. I do have a to of mqtt sensors and switches, and many binary sensors template based on these sensors, and haven’t seen issues with the binary sensors based on these, even after a loss of connection, or at restart for that matter, when the sensors re-initialize. Will keep it in mind though, and check if I haven’t overlooked the matter. Seems a viable enough scenario to be ware.

The example could be of use coming to think of it for several startup binaries that trigger on a to:on state when they shouldn’t because of that fact the system restarts. (should have a condition from state is not unknown added to that!

Learn every day, thanks @123 and @Tinkerer for that. Sometimes things are very simple and very powerful…