Delay light.turn_off, but dismiss when any other light command has been given

Feature Requests
1

I’ve got an feature idea that would solve many timer (and dismiss timer) use cases.

Currently I’m misusing the transition: 10 attribute to delay my night light turning off completely. The reason for that, is because I want to 1) turn on for 10 seconds a very dim light in my living room when I enter but 2) only when it’s currently off and it’s dark, and 3) I want to be able to “override” the 10 second timer by for example applying a scene, or turning it on (more brightness) manually.

This can be abstracted into this:

  1. trigger
  2. turn on a light
  3. start 10s timer*
  4. turn light off

[*] but also dismiss the timer when literally any other command is given to the light

Manually dismissing such a timer is not trivial, since many triggers could be a valid reason for dismissal. And when using such an automation the number of timer-dismissal -automations lines of code would get out of hand really quickly when you’d want to apply it to multiple lights.

Proposal: a new light.turn_on attribute: turn_on_for that accepts a number for the amount of seconds after which it turns off, unless the light has recieved any other instruction.

I think this pattern would fix many timer-related use-cases, for people using HA automations but also for people using Node-Red for automation. In my home alone, I would have more than 6 lights I’d apply it to.
What do you think? Is it a crazy idea?

2

not crazy, but you can do something like that in node-red

3

Just put the timer / delay in a script and use script.turn_off in the action of whatever over automation is sending a command to that same light. By the sounds of it what you are asking for is similar to how I control my lights

4

Thanks for the replies, but that is precisely my point because of two reasons:

The first is that probably close to 100% of the people encounter this problem so it should be built-in.

The second reason (and imho the biggest) is that while the timer is running, many other actions can happen that can trigger the lights. Making sure all those other actions call the right script.turn_off is manageable at first, but in a complex setup it becomes real spaghetticode.*

* The amount of code required in Node-Red or HA automations to dynamically keep track of which light were turned on “temporarily”, and which times should be called of if the light is turned on manually (by a scene or remote), is huge