#Motion-resettable timer to switch off light - do I have to code it in yaml?

1 messages · Page 1 of 1 (latest)

tawdry kayak
#

Hey - I'm trying to create a simple automation - when movement is detected, we start counting down 15 minutes. If movement is detected during that time, we reset to 15 minutes. Once the timer is finished, we switch off the light. I've been able to do the set/reset part, but am unsure on how to switch off the light. Do I need to create another "When" block with a custom event? The timer entity only allows me to read the duration, which I think is static.

vocal warren
tawdry kayak
#

Right, so what I had before was:

  • turn light on
  • wait 15 min
  • turn light off
#

I want that time to be 15 minutes from the last motion detected

vocal warren
#

what you want instead is

when motion goes from clear to detected - switch on light
when motion goes from detected to clear for 15 mins - switch off light

tawdry kayak
#

OK, I think I get it, let me try it.

vocal warren
#

this would be an example of a switch off trigger

#

you should really avoid "long running automations" with waits, and instead use additional triggers.

ripe heath
#

Your initial message doesn't state that the lights are ever turned on. I assume you turn them on when movement is detected?

#

In that case the easiest way would be to create an automation that turns on the light, waits for 15m and turns it off again. The whole set/reset part can be avoided if you switch the automation mode to restart

#

Every movement will abort and restart the automation and with that also the 15m delay. It doesn't matter when the lights are already on and you "turn them on again"

#

However what Michael said is true long running automations should be avoided

vocal warren
tawdry kayak
#

Why are long-running automations discouraged?

#

I'd trigger on timer.finished, but I'm not sure how to do that.

#

I like your idea with a restartable automation, I'll do that because it's conceptually the simplest.

vocal warren
#

if something goes wrong or there are restarts for updates and stuff, things may get stuck in unexxpected states.

#

specially for something simple like this: there is in essence already a timer because its baked into how long the motion sensor has been clear which you can trigger from. by adding a new timer your adding needless complication

tawdry kayak
#

I see your point.

#

What is preferrable? Create one automation per trigger (motion detected, motion clear), or create an automation on state change and then create subconditions to key on the changed state and attach actions to that?

vocal warren
#

i would have 1 automation with 2 triggers with ID's then use a choose block to decide which actions to run based on trigger ID