For-statement for automation with numeric state

Feature Requests
33

maybe try this:

      - >
          {{is_state('binary_sensor.XXXXX','off') and
            (now() - states.binary_sensor.XXXXX.last_changed).total_seconds() >
             states('input_number.interval')|int}}

unless you’re specifically interested in the syntax request, this would come close to what you are looking for?

got to remember though this is a condition checked on the moment of the trigger. It won’t wait for the time being set in the input_number if it hadn’t yet reached that. It would simply be false.

if you want to check that, you got to reference the last_changed.

34

It appears that you can template for when used in a State Trigger but not when used in a State Condition.

This passes Check Configuration:

- alias: junk1
  trigger:
    platform: state
    entity_id: input_boolean.switch1
    for:
      minutes: "{{ states('input_number.interval') | int }}"
  condition:
    - condition: state
      entity_id: binary_sensor.whatever
      state: "off"
  action:
    service: persistent_notification.create
    data:
      title: foo
      message: bar

This does not:

- alias: junk1
  trigger:
    platform: state
    entity_id: input_boolean.switch1
  condition:
    - condition: state
      entity_id: binary_sensor.whatever
      state: "off"
      for:
        minutes: "{{ states('input_number.interval') | int }}"
  action:
    service: persistent_notification.create
    data:
      title: foo
      message: bar
35

Yes I tried this and it worked,
but there is a problem doing the “elapsed time check” in the trigger,
because if I remember, if HA restarts in-between (after the on-off state change),
it doesn’t work anymore, or the time is not respected (I don’t remember the exact effect)

36

Hum, OK, I’m gonna test this, thank you… I don’t see exactly where to embed it…

I’m not specifically interested in the syntax request if you found a way to do it (but I think it would be cool if it worked with this simple syntax)

37

At startup, the entity’s last_changed is set to the startup time so that screws up ‘elapsed time’ calculations. There’s been a long-standing request to preserve the entity’s last_changed time (like its state) but, for whatever reason, it’s never been implemented. I believe the most recent request was made during the Month of What the Heck.

38

I think you’re right, must be that…
so I use a periodic trigger instead :

trigger:
    - platform: time_pattern
      minutes: "/1"

Edit : ow wait… well I think it won’t work neither, in fact !

39

Given that you can’t template for in a State Condition and elapsed-time calculation based on last_changed can be unreliable, can you explain how you are using the Time Pattern Trigger as a way of getting around those two limitations? I’m not seeing how a Time Pattern Trigger can do that …

EDIT

Here you go:

225 votes in favor of the proposal to allow last_changed to survive a restart.

40

Yes, my analysis of the cause of the problem was wrong !

And maybe I didn’t test if it works with this change… my bad

(now 226 votes)

41

OK, so since there is no way to overcome the last_changed problem anyway (for the moment) :

trigger:
    - platform: state
      entity_id: binary_sensor.XXXXX
      to: "off"
      for: "00:{{ states('input_number.interval') | int }}:00"

So, no need for the “for” template in condition (even if it would be nice)

Thank you guys for your eyes-opening help :slight_smile:

EDIT: ah, there is a problem when this is a trigger and not a condition :
the automation must be ON when the state is changing, if not, it won’t go and check the ‘last_changed’.
(so the time trigger is an improvement in my case, even if the HA reboot problem remains )

42

I’m curious, do you know if this works if the input_number’s value is less than 10?

      for: "00:{{ states('input_number.interval') | int }}:00"

For example, if it’s 5 then the time string will look like this:

      for: "00:5:00"

I think that’s acceptable (it doesn’t need to be 00:05:00) but I’m not certain.

43

yes it works (tested with a value of ‘1’) :slight_smile:

1 Like
44

Thank you! Saved me some time testing it.

45

How is this still not implemented after 7 years? Why I can’t use for at numeric_state condition? It works with normal state check and even with the numeric state check in the trigger! Why it does not in conditions?
I would really need this and unable to find a workaround without creating unnecessary entities just for this simple specific check.

46

You should really check your stuff, before complaining… :slight_smile: Simply opening the documentation and read up:

PS: reviving a thread that is nearly three years from the last post…best way to get current information - NOT

48

That’s about triggers. I want to check if a state has been at least x in x minutes in conditions.

I tried it with templates but that also does not work because it does not know if it was below a specific state. Probably I need to add for each check an extra binary sensor like the answer of this thread is.
Not a good solution but at least it should work.

Edit: Sorry, my fault. This is about the for check in triggers. I misread that an thought it is about that it works in trigger but not in conditions because he compared the two.

49

All good, so what’s your actual problem? Think about opening a new thread, this is very outdated. :slight_smile: And feel free to tag me, I’ll be happy to jump in, if I can give a quality answer. :slight_smile:

1 Like
50

Sorry for necroposting, but do we have a more elegant solution for the problem in the meantime?
The previous answer is an answer - but only a workaround in my eyes.
It’s neither pretty nor intuitive and the use friendliness is pretty limited as well.

51

You can do for on numeric_state triggers. That’s what this feature request is about. If you want this on a condition, it’s not possible at this time.

It’s actually unlikely to ever get implemented for a condition due to the limitations of the system. It would need to traverse the database and look at all values over the specified duration. The limiting factor is that it would require users to use history and recorder, which are optional integrations.

52

Well, triggers won’t do the job.

I do understand that it’s not trivial to do that like you explained.
What I do not get: why can’t it do what is explained above in the background? Create hidden sensor or the like that.

53

The point is, the data won’t always exist for all home assistant users, so it’s unlikely it would be added as a core condition.

What’s described above is an sql sensor that looks in the database. The database won’t always exist. That’s why.