I would like to set up a timer that starts counting (1440 minutes) from the last detected motion (‘on’).
If there is a new motion within the 24 hours (1440 minutes) window, reset the timer and start over.
If the timer then hit 1440 minutes, I want to run an automation.
This is how far I’ve come:
Configuration.yaml:
timer:
motion:
duration: '24:00:00'
Automations.yaml (start timer on motion):
- alias: Timer
id: 'Timer'
trigger:
- platform: state
entity_id: sensor.motion
to: 'on'
action:
- service: timer.start
entity_id: timer.motion
Just an FYI, the state trigger’s “for” parameter uses the entity’s last_updated field, which effectively gets reset when HA restarts. That means after a HA restart, the automation won’t trigger for at least 24 hours, even if the motion sensor has been off for 24 hours sometime before that. This isn’t much of an issue if HA doesn’t restart often. But when it does restart, just be aware it will cause this automation to take at least 24 hours before it can trigger.
One way to get around that is to use the History Statistics Sensor. This sensor uses data stored in the database, which spans restarts. You can define a sensor whose value will be the amount of time sensor.motion has been ‘on’ in the last 24 hours. Then you can trigger your automation when the value of that sensor becomes zero. (You might even define a template binary_sensor that is ‘on’ whenever the history sensor is non-zero, and then trigger the automation when the binary_sensor changes to ‘off’.)
Just an idea. And although this solution is less vulnerable to HA restarts, it’s not entirely unaffected by them either. Obviously while HA is not running (which is at least a small amount of time while HA restarts, but can be longer if HA is stopped and later started again) it can’t know what the motion sensor is doing. But at least it’s slightly better than a simple state trigger w/ the “for” parameter.
BTW, I only mention this because the period of the “for” parameter is relatively large. If it were a few seconds or minutes, it might be “good enough.” Then again, it’s probably good enough if your system doesn’t often restart, or if the side effect I described is not an issue for you.
@pnbruckner I have your solution working but have a strange problem;
The motion sensor itself (‘sensor.motion’) kick off immediately, but, the sensor created under ‘history-stats’ takes approx 30-32 seconds to pick up the motion (and of course, the binary sensor kick off at the same time as the ‘history_stats’ sensor).
@petro, could I insert a template in this automation (picked up from input_numer ‘motion_timer’)?
Meaning, replace the minutes part with a template like (this one I didn’t get to work);
for: 00:{{states ('input_number.motion_test') | int }}:00
- alias: 08 - Timer Test Motion
id: Timer Test Motion
initial_state: 'off'
trigger:
- entity_id: sensor.hue_motion_sensor_1_motion
for: 00:02:00
platform: state
to: 'on'
action:
- data:
message: 08 - Timer Test Motion is finished
service: notify.stigh
EDIT: Changed the automation, now slider works by changing ‘for’ in the trigger to using ‘delay’ in the action like this:
- id: 09 - Timer Test Motion using Slider
alias: 09 - Timer Test Motion using Slider
trigger:
- entity_id: sensor.motion_stue
platform: state
to: Klar
action:
- delay: '00:00:{{ states.input_number.motion_timer.state | int }}'
- data:
message: 09 - Timer Test Motion w/Slider is finished
service: notify.stigh
Of cource, the delay get screwed up if it is at ex 24 hrs and I do a reboot within that delay. This is where the ‘history_stats’ from @pnbruckner comes in. Though, as stated in another post; I’m hit by the fact that is the motion sensor is passed a few seconds after last scan_interval and changes state back to ‘off’ before next scan_interval, the ‘history_stats’ is not triggered.
Like most sensors, they update periodically, with the default being every 30 seconds. This would be when it queries the database to see what recent changes have happened with the entity it’s monitoring. You can change the update rate using the standard scan_interval configuration variable.
Ah, okie - but increasing scan interval will impact the entire HA and hardware resources as the load will be a lot heavier on the system (I guess).
The thing is that if the flag is not raised to ‘on’ from the motion sesnor at the moment the scan interval occur, it will not be picked up. This means you can actually pass the sensor 3 seconds after last scan interval and the motion sensor changes from ‘on’ to ‘off’ before next interval = no triggering.
Yes, that’s how you would change the polling interval for that one particular sensor. It will cause it to query the database every 5 seconds instead of every 30 seconds, and of course will add some load to the system. But, depending on the hardware you’re using, and what else your system is doing, it may not even be noticeable.
No, that’s not how this works. Whenever the motion sensor changes state (to ‘on’, or to ‘off’), that will be recorded in the database. The history_stats sensor periodically queries the database to see how long the sensor was (cumulatively) ‘on’ during the last 24 hours (or whatever period you specify.) If it goes ‘on’ at all, the history_stats sensor will see it, no matter when it polls/queries, even if it was only on for a few milliseconds.
That can’t be true, as I’m fully able to trigger the motion sensor (I see it go from ‘off’ to
on’ and back to ‘off’) without triggering the ‘history_stats’ and according binary_sensor that should be triggered by the history_stats’ sensor (hope you understand what I’ trying to tell )
- alias: 99 - Do something when no motion for 24 hours
id: Do something when no motion for 24 hours
trigger:
- entity_id: binary_sensor.motion_siste_24t
platform: state
to: 'off'
action:
- data:
message: Timer history_stats are finished
service: notify.stigh
What does the history of binary_sensor.hue_motion_sensor_1_motion, sensor.siste_24_timer_motion & binary_sensor.motion_siste_24t look like when motion is detected?
I will test this now…
)