How to create multiple timers for light objects

I have 30 different lights objects.
I’d like to have them switched off after 5 minutes.
I do not want to create 30 timers one per light.
I was wondering if I can have an automation that says:
“when one of the 30 lights is on, start a timer 5 min with the light that is on as parameter”
“when the instance of the timer goes off it switches off the light that is in the parameter”

is it possible?

Also I’ve seen that now in the conditions I can put “is on for 5 minutes” but how it will work if I put all 30 lights in the condition?
I do not think is the correct way to do it as if I switch on the first one and then after 3 min the second one the two conditions will clash.
Expected behavior is the first one be off at min 5 and the second one to be off at min 8

1 Like

I don’t have a solution for you, but I would guess that it would start with leveraging templates @ Templating - Home Assistant

Also, regarding your 5 minute off desire, you should also probably consider the many exceptions you will encounter, when your lights keep turning off when someone is still using or needing the light on.

What is turning these lights on in the first place?

Maybe there’s a better option than timers…? If you can give us a more detailed description of what you have running currently and what your goal is, we may be able to offer other options.


Yes, it’s possible to use fewer timer entities that are used in a rolling fashion. But, you are going to need either an equal number of Input helpers or multiple attributes in a Template sensor to map the light/timer pairs. Then you’ll need extra automations and/or scripts to handle resetting or cancelling the timers…

IMO, if you are going to use timers, you will probably be better off just using the 30 timers. Since they can be created in YAML, it’s pretty easy to copy/paste 30 of them into existence.

1 Like

Its unlikely you need to control all your lights independently.

In my case I only have 15 lights, but they are grouped into 6 rooms. “Room” is a loose description in that I divide up an open plan layout into arbitrary areas, but I still only have 6 of them.

I put my lights into scenes, you could also use light groups (either HA or Zigbee) if you want to set colors / dim lights as a group and I put my sensors into groups as well. Finally I use a naming convention for my scenes: kitchen_off,kitchen_bright, etc, that way I can create automations that build the names dynamically.

You could create arbitrarily complex automations such as firing every minute and checking how long lights have been on for, but I find that a bit of cut and pasting can be the quickest and easiest solution to maintain.

Give them all the same label, automate on the label…

1 Like

Did not understood this one, what you mean with Same Label?

This is not a “light” in the sense of the light bulb but is the “light” functionality of the Sonoff TX Ultimate. So I need all of them independently :slight_smile: I cannot use the rooms

1 Like

Wow, thank you.
But if I do 1 timer will it create multiple instances?
Because if I group all the “light” in the same label and 2 are switched on at 2 min distance I need 2 instances of the timer to run accordingly

No, there is no way to have 1 timer entity running multiple instances of itself.

Ok, thank you! that’s what I expected.

So this leads to another question:
In the past I did this:

  1. Event switch/light on → start timer
  2. switch off → cancel time if still on
  3. Timer complete → switch off
    This was safe and when I added the keep timer over restarts worked perfectly even on updates etc.

Now I’ve seen that in the event we have the “for” in the event:

does it work in the same way? is resilient at restarts?

Thanks
M

No.

From the documentation:

Important

Use of the for option will not survive Home Assistant restart or the reload of automations. During restart or reload, automations that were awaiting for the trigger to pass, are reset.

A third “middle ground” option is to use template binary sensors with the delay_on or delay_off option.

They are not perfect, but I have found they are resilient “enough” for my use cases and less hassle than messing with timers.