For_less_than: time

Feature Requests
1

To reduce the use of complicated jinja templates like this:

  - condition: or # moisture limit off or only on for less than 2 hours (previous zone may cause level to rise)
    conditions:
    - condition: state
      entity_id: binary_sensor.moisture_limit
      state: 'off'
    - condition: template
      value_template: "{{ is_state('binary_sensor.moisture_limit', 'on') and ( as_timestamp(now()) - as_timestamp(states.binary_sensor.lawn_moisture.last_changed)|int < 7200 ) }}"

it would be nice if there was a for_less_than: option for conditions (and triggers?) that support for:

e.g. the template above becomes:

  - condition: or # moisture limit off or only on for less than 2 hours (previous zone may cause level to rise)
    conditions:
    - condition: state
      entity_id: binary_sensor.moisture_limit
      state: 'off'
    - condition: state
      entity_id: binary_sensor.moisture_limit
      state: 'on'
      for_less_than:
        hours: 2
2

Lol. I literally just helped a fella out with a template exactly like this 10 minutes ago. This definitely would have simplified it for him. +1

3

Excellent idea; you have my vote.

Now for a question about implementation. How would this work:

    - condition: state
      entity_id: binary_sensor.moisture_limit
      state: 'on'
      for:
        minutes: 5
      for_less_than:
        hours: 2

This combination presents a greater challenge for the developer to implement. The listener condition needs to check if the input_boolean is on for at least 5 minutes but only within 2 hours since the last time it triggered. :thinking:

EDIT
Replaced ‘listener’ with ‘condition’ to avoid confusion.

4

I hadn’t actually considered using both options for and for_less_than together but it seems pretty simple logic:

On for more than 5 minutes and less than 2 hours.

5min < Ton < 2hours

Not sure it would be so simple for a trigger, as opposed to a condition.

5

That won’t work, you can’t use for_less_than in triggers it will have to just wait on the for. Conditions maybe but not triggers

6

The other option would be to only allow one of for: or for_less_than, not both.

7

No, because it’s valid in the conditional usage

Edit because it makes absolutely no sense in a trigger as you are triggering on it becoming the thing you are timing it being less than

8

Perhaps I misled you when I used the word ‘listener’ but my post was about the proposed feature’s use in condition, not trigger. I amended my post to avoid causing more confusion.

I think the proposed feature may be problematic for a trigger but a good fit for condition.

9

Maybe I’ve misinterpreted your feature request but my understanding was as follows:

for_less_than:
  hours: 2

means the entity’s changed to the desired state within the last 2 hours.

In contrast, this:

for:
  minutes: 5

means the entity’s has maintained the desired state for at least 5 minutes.

Using my example (posted above) the entity’s state has to remain on for at least 5 minutes and this 5-minute period must occur within the last 2 hours.

Here’s a visual example of the entity’s state being on for a 5-minute period within the last 2 hours. This would satisfy the condition.

8:00 AM               5-minutes                    now (10:00 AM)
 --|---------------------|-|-----------------------------|--

If it was on for less then 5 minutes, then it would not satisfy the condition.

8:00 AM               3-minutes                    now (10:00 AM)
 --|---------------------|-|-----------------------------|--

If it was on for at least 5 minutes but more than 2 hours ago then it would not satisfy the condition.

7:30 AM       5-minutes    8:00 AM                     now (10:00 AM)
 --|-------------|-|---------|---------------------------|--

That’s more complex than 5min < Ton < 2hours which simply means the entity has been on anywhere between 5 minutes and 2 hours ago.

1 Like
10

I would interpret it differently.

Trigger
Switch light 1 on
When light 1 on for 5 minutes:

Condition
Light two has been on for less than 1 hour

Action
Switch on light 3

11

means the entity’s changed to the desired state within the last 2 hours .

Yes, sorry, you are right. That fits in with my first post.

Maybe for_less_than would be better represented by the option key within: instead.

12

Yes, the trigger can have a for option but so can the condition and that’s where things get complicated when combined with this Feature Request.

13

But anything that has been in “zzz” state for between 5 mins and 2 hours will ALWAYS Trigger at 5 mins. Unless it’s self state is not the condition being tested ie another entity.

1 Like
14

Forget triggers, I’m convinced this is only of value for conditions.

15

Yes that’s what I’m saying in the above and of how this would be used, ie not as a self entity state condition

16

What I had in mind was to incorporate your Feature Request into the existing for option. Some (yet to be devised) syntax would be required. The challenge would be create a convention that is backwards compatible to avoid creating a Breaking Change.

Just off the top of my head:

for:
  minutes: 5
  within:
    hours: 2

or if the state-change simply has to occur within the last 2 hours:

for:
  within:
    hours: 2

EDIT
No idea how this would be expressed using the compact form. On second thought:

for: "00:05:00"
  within: "02:00:00"

other example

for:
  within: "02:00:00"

EDIT #2
If this Feature Request gets implemented (and I hope it does) it presents users with an incredibly powerful new capability that can be achieved with just two lines of YAML. Wow!

1 Like
17

The “maintained” interpretation is only valid for triggers (i.e., if it changes to that state, and stays, aka maintains, that state for X then trigger.) For conditions it means if it’s been that state for at least X (i.e., it changed to that state at least X ago.) The difference is, for a trigger, the range of time that it cares about ends when the period ends, whereas with a condition the range of time is from now back to X ago, and in that period it must have always been the given state.

I see absolutely nothing wrong with allowing for or for_less_than or both for conditions. And it would mean it’s been in that state for at least X and/or no more than Y. Or, to put it another way, it’s currently in the specified state AND it changed to that state more than X ago, and/or but not longer than Y ago.

So one of:

state == Z and last_changed < now - X # for: X
state == Z and now - Y < last_changed # for_less_than: Y
state == Z and now - Y < last_changed < now - X # for_less_than: Y, for: X
18

Another vote for this as I need this functionality (see Triggering if a sensor has been ON for over X minutes during the last Y minutes)

The other way to implement it would be via a template sensor with an “integrate” function (“integration” in the mathematical sense, not the HA sense) that would return the area under the sensor history curve for the last specified time window. For a binary sensor or condition, it would simply return the total time a condition has been true during the last ‘HH::MM:SS’. You then use this computed sensor as the triggering condition.

sensor:
  - platform: integrate
    name: "Rain time during last hour"
    window: 01:00:00
    - condition: state
      entity_id: binary_sensor.rain_sensor
      state: "on"