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.
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”.
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?
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.
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
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.
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.
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.
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.
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).
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.
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.
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.