["for" inside conditions already look to the past] Automation conditions that filter based on previous state time periods

Feature Requests
1

Edit: ignore this request. for already looks into the past.

Event triggers have a “for” statement that looks forward and waits for something to be true for a given period time before triggering

I would love to have a previous state or “in the last” filter in conditions so that I could look back in time to check states.

For example, let’s say I trigger on the END of a motion event and want to see if in the last X min someone did something in that room like open a door or turn on a light.

Or I have a door bell camera and want to look for motion events ending where the door bell rang or did not ring or where a person was detected, or the door opened etc.

2

No they don’t. State triggers do. Events are instantaneous occurrences.

That would be the state trigger from: combined with a for:.

You are thinking about this backwards. Trigger on the start of the motion event and use a wait_for_trigger action to check if “someone does something”.

3

Example.

I want to detect if someone was at the front door based on the camera detecting motion, DOODS detected a human, but DID NOT ring the doorbell and DID NOT open the door.

Using the built in states and events is that even possible? Using a FOR for the motion state will it not just check the conditions at the end? or will any state change during the for trigger the condition?

4

Yes it is possible.

Trigger on motion.

Action is a wait_for_trigger (doorbell press) with a timeout. The timeout actions would be what you want to do in case of motion and no doorbell press.

5

How do you handle the OR in that case? I only want to be notified if there was a motion event but NO doorbell OR NO door opening AND if there was a human. Also a long motion event will break any fixed timeout logic.

That is why I was thinking looking at the end state and looking back X min would be far easier logic especially since HA keeps history of states

6

Triggers (and wait_for_trigger) are OR by default.

  wait_for_trigger:
    - platform: state
      entity_id: binary_sensor.doorbell
      to: "on"
    - platform: state
      entity_id: binary_sensor.door
      to: "on"

However…

I just realised that the wait timeout actions are the same as the trigger actions. Still thinking about how to solve that.

EDiT: there is a wait.completed variable you can test with a choose action.

7

The ‘history of states’ is recorded in the database and none of Home Assistant’s Automation Triggers refer to the database.

What you are asking for can be done the way tom_I described.

8

Snippet of YAML that employs wait_for_trigger

         - wait_for_trigger:
           - platform: state
             entity_id: binary_sensor.whatever
             to: 'off'
           timeout: '00:15:00'
         - choose:
           - conditions: "{{ wait.trigger == none }}"
             sequence:
             - service: persistent_notification.create
               data:
                 title: On Time Out
                 message: "Timed out after 15 minutes."
           default:
           - service: persistent_notification.create
             data:
               title: On Trigger
               message: "Triggered"
9

Ok @123 The choose condition was not something I was aware of in the default actions.

I might be able to string something together with the detection of a human and timing the whole thing out by triggering on the camera returning to the idle state.

10

And this will not work as it will go off every time someone leaves the house. HENCE looking back in time is useful.

Request stands, I had figured that out before but when I sat down to write it and go through the real-world cases it failed.

11

You can add a condition to prevent that case.

e.g. door state closed for x minutes.

12

The recording may not start until after the door has already closed due to the position of the camera as the motion recording trigger catches the person just after they step through the door and there is sometimes a delay. If we are starting the automation on the recording starting, I don’t see how that condition would work if all conditions are current or forwarding looking.

Still think historic or query based filters would be useful in automations.

13

It may trigger late when leaving but the recording will never start if the door has been opened in the last x minutes if you add that condition. That’s what you wanted. To prevent it occurring when people leave.

14

The door event happens before the automation would start from motion so this isn’t going to work.

Someone leaving the house and someone walking up to the door and leaving would look the same to the automation as in both cases the door state would not change from the forward only looking automation.

would be far simpler logic if we had some way to query a state at the end instead of trying to figure out all branching sequencies possibilities.

Might be time to crack open node red.

15

I could ask “Let us know if it works out” but I already know the answer. Good luck.

16

Yes it will. As long as you make the condition for: long enough. That’s what “reaches back into the past”.

Consider this timeline:

Door opens.
Door closes.
Delay x
Camera motion trigger occurs.
Automation triggered.
Condition door closed for >x prevents automation actions (it has been open in this time).

17

OK, that might be where I was not understanding it. I thought for would just wait into the future X to ensure that that condition didn’t happen not that it would check in the past for X.

18

If you use a condition like this:

condition:
  condition: state
  entity_id: binary_sensor.door
  state: 'off'
  for: 
    minutes: 2

At the time the condition is evaluated the door has to have been closed for 2 minutes (or longer) for it to pass. If not true the automation stops. It won’t wait around until that time in the future.

19

The simple answer to this whole thread is that “for” already looks into the past for conditions and the feature request is redundant.

The misunderstanding comes from the fact that “for” is forward looking in triggers and backward looking in conditions and I thought it was forward looking in both.

1 Like