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
This combination presents a greater challenge for the developer to implement. The listenercondition 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.
EDIT
Replaced ‘listener’ with ‘condition’ to avoid confusion.
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.
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.
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.
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!
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
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"