Duration-based State Triggers and rapid "OFF" --> "ON" --> "OFF" changes question

Configuration
1

Sorry about the newb question but if I have a duration-bases state trigger, e.g.

platform: state
entity_id: sensor.some_data
for:
  hours: 0
  minutes: 0
  seconds: 20

If I have the following sequence of events
sensor.some_date=OFF @ time 0
sensor.some_date=ON @ time 10
sensor.some_date=OFF @ time 29 (10+19) <== SHOULD NOT FIRE as it wasn’t ON long enough

Will trigger fire @ time 49 (29+20) showing OFF since technically the value has changed from ON to OFF for 20 seconds, even though ON did not cause the trigger to trip?

What I want is to effectively ignore the ON value because it was only active for 19 seconds.

I’m going to try testing that but thought I’d ask as well.

2 
platform: state
entity_id: sensor.some_data
to: "OFF"
for:
  hours: 0
  minutes: 0
  seconds: 20

Also if your sensor only has two states (OFF and ON) it should be a binary sensor. How was this sensor created?

1 Like
3

Thanks – it is binary, I just wanted to keep the example as few characters as possible :)!

To be clear, I don’t just want it to trigger when it goes OFF, but when it is in a specific state for that duration, disregarding any temporary states in between. Not sure if I need two triggers for that?
But say I did a separate trigger for OFF → ON and ON → OFF, for each of those, am I guaranteed that the platform will ignore the intermediate ‘blips’?

Eg OFF for 1 hour, ON for 1 second, then OFF for another hour should NOT trigger either of those triggers (if I split them), correct?
I want a trigger only if OFF becomes ON for longer than 10 seconds and ON becomes off for longer than 10 seconds, while disregarding anything that does OFF → ON → OFF where the intermediate ON is <10 seconds (or conversely ON → OFF → ON where the OFF is <10 seconds).

Another way to think about it is to ‘clean up’ the data for any change in state that lasts < 10 seconds.

OFF (1hr) → ON 9 seconds → OFF (1hr)
I want to make sure the trigger(s) will not trip at all. It’s as of the ON never happened.
Thanks.

4

Your original trigger does this, though you specified 20 seconds. The state has to be in the stable on or off state for a continuous 20 seconds to trigger. Any change of state shorter than that will reset the state time listener and monitoring for a stable state for 20 seconds will begin again.

Though it would be best to exclude the unknown states if you only want on or off.

platform: state
entity_id: binary_sensor.some_data
not_from:
  - unknown
  - unavailable
not_to:
  - unknown
  - unavailable
for:
  hours: 0
  minutes: 0
  seconds: 20
1 Like
5

Oooh ok I’m being an idiot then.
For some reason, I thought this will ‘confuse’ the platform
I.e. I thought it works like this
OFF @ 0 - timer starts
OFF @ 10 seconds - Trigger! (OFF)
OFF @ 30mins etc - nothing happens
ON @ 1hr - timer starts
OFF @ 1hr:9secs - time resets (no trigger)
OFF @ 1hr:19secs - Trigger! (OFF)

I guess the platform is smart enough to not compare against the immediately prior ON but against the original OFF.

6

You are making this very confusing.

It only triggers if the the state is a constant value for 20 seconds. Any change of state interrupts that.

1 Like
7

ya’ll might be talking past each other. you WILL get 2 off notifications if this happens (i’m assuming 10 sec timeout. you originally said 20):
0 - off
10 ------- trigger (10 secs have passed)
11 - on
12 - off
22 ------- trigger ( 10 secs have passed)

however i also don’t quite understand what you want to happen, @ncd “pretending like on didn’t happen” has some cases that are undefined…

what happens in this case:

0 - off
9 - on
18 - off

when should off trigger? if you say “pretend like on never happened” then it should have triggered off at 10. but it can’t because it doesn’t know if on will stay or not. should it trigger immediately at 18? should it wait to trigger at 28? i suppose the off was not on for 10 secs, so perhaps the answer is 28?

8

or maybe i’m the one misunderstanding and you actually do want the double firing of events. but if my understanding is correct, consider this approach:

trigger:
  - platform: state
    entity_id:
      - input_boolean.testbool
    not_to:
      - unknown
      - unavailable
    for:
      seconds: 10
condition: []
action:
  - service: input_boolean.turn_{{ states('input_boolean.testbool') }}
    target:
      entity_id: input_boolean.testbool2

this is just a software version of a dampener.
do this and then trigger your automation on the dampened entity (in my case testbool2)

trigger on it’s immeidate change, it’s got the 10 sec buffer built in.
of course change to sensor. i just did input_boolean for my own testing.

9

Yes, pls assume it’s 10 pls, apologize for switching from 20 to 10 midway through my examples :man_facepalming:t2:

If I get two OFF notifications then it’s what I was afraid of and it’s not what I want :(.

In the case of your example
0 off
10 ------- trigger for OFF (10 secs have passed)
11 on
12 off
22 ------- trigger for OFF ( 10 secs have passed)

I don’t want the second trigger because the “on” was short lived. I want something that will treat the “on” as if it didn’t exist in which case OFF shouldn’t trigger the 2nd time because the entity really “never” changed state if you ignore the super short lived 1-second ON blip.

You can think of it as filtering out the data or cleaning up outliers.

Is it possible to express that?

EDIT: I’m staring to think to get the behavior I want is to move the trigger from an automation do a template sensor. Then I could take advantage of the fact that HA automatically “disregards” updates to sensors that are to the same value. I can use the trigger platform + a template sensor where the output of the binary sensor will be the value of the original sensor, hidden behind these triggers. Then on the second OFF trigger, it will be “ok” since the output will still be OFF which is fine. I’m fairly certain in those cases any automation depending on this new template sensor will not trigger in the above case since the value remains OFF.

10

holler if my sample above doesn’t do what you want.

11

Hmm tricky. I think maybe this might do what you want:

trigger:
  - platform: state
    entity_id: binary_sensor.some_data
    not_from:
      - unknown
      - unavailable
    not_to:
      - unknown
      - unavailable
    for:
      hours: 0
      minutes: 0
      seconds: 10
condition:
  condition:
  - condition: template
    value_template: "{{ now() - this.attributes.last_triggered|default(as_datetime(0),1) >= timedelta(seconds: 10) }}"

This condition will prevent your automation from triggering more often than every 10 seconds. This eliminates triggers shorter than that.

Automations are not considered triggered until all conditions have passed.

12

haha @armedad i think we arrived at the same solution! i was getting a beverage and there it is – your example is what I was thinking but instead I’ll move my stuff behind a template sensor

(in reality my example is a bit more complicated so this helps me in other ways as well)

13

Thanks @tom_l – appreciate your engagement on this.
What do you think of my idea with the trigger+template sensor?
I see your solution, it’s pretty clever but I think will be a bit too complicated to remember why I’m doing it in a few years (hrmph months probably)

14

I don’t understand how your template sensor would work. The state is changing, all be it briefly. Unless you are going to use the delayed on/off options?

15

From the “outside” (i.e. anyone reading the sensor value) the sensor will change from OFF… to OFF.
It will be OFF at time 10 seconds and then OFF again at time 22 seconds (using our latest examples).
I’m fairly certain HA will not even record the second update in history (nor will it cause any triggers) because it disregards updates to an identical value. I’m not 100% certain… but fairly certain :D.
I think it’s the same idea as what armedad has.

16

sorry, i’m slow. i’m not sure how this solves this case:
0 off
10 ------- trigger for OFF (10 secs have passed)
11 on
12 off
22 ------- no trigger because of the tom_l trick above.
23 on
24 off
34 ------ trigger for OFF. won’t this trigger because it’s been > 10 seconds since the trigger at 10 secs?

am i missing something?

17

@ncd i think you still need to do what i have and then you can write a template sensor to wrap input_boolean.testbool2 if you’d like. i don’t understand your concept of doing this directly in a sensor without a helper boolean of some sort.

yes, you are correct that we set testbool2 to false when it’s already false, that won’t trigger. but in case it does, it’s easy to check first in the automation and not call the set_value.

18

You can use the trigger platform coupled with template sensors, it’s pretty powerful!
That’s why I don’t think I need your solution or rather it’s identical to yours but just wrapped into one.

1 Like
19

ah, i get it now, thanks. an area of the product i haven’t explored yet.

20

This is why I said:

It depends if the ignored trigger affects the trigger listener. It needs testing.

1 Like