Trigger automation if ANY light turns on via dumb switch

Configuration
1

I want to make an automation to apply time of day based brightness and color to smart lights ASAP after ANY smart light is turned on by a dumb switch and connects to HA. My goal is to avoid bright lights at night, and dim lights during the day.

To make this work I need a trigger that has two properties I’m not sure can be done:

  1. a trigger that activates when a light connects to HA (e.g., after being offline due to dumb switch being off).
  2. a trigger that activates when ANY light changes (i.e., no specific entity or device is specified, instead trigger is based on device category, in this case ‘light’).

Any ideas how to create a automation trigger with these properties? If this can’t be achieved with triggers, is it possible with an integration (which would presumably have access to the lower level HA event stream)?

2 
trigger:
  - platform: state
    entity_id: light.foobar
    from: unavailable
  1. change of state (on/off) or attributes too (brightness, color_temp, etc…)?
1 Like
3
  1. Nice! I hadn’t thought of transitioning from ‘unavailable’ as connecting, but now it seems obvious.
  2. Not sure what you mean. I’m looking for a trigger that is basically like you have in 1, except it doesn’t require specifying an entity_id or device_id, and instead monitors all lights that Home Assistant knows of. I wish there was something like a category: lights trigger so I could do:
trigger:
  - platform: state
    category: lights
    from: unavailable

which would create an automation instance variable trigger.entity_id to indicate the specific light that triggered the automation.

4

I think a low-level event trigger like this might work to intercept all lights that re-connect to Home Assistant, but I suspect it would not be very efficient since it would check template conditions on every event HA processes, not just those for lights:

trigger:
  - platform: event
    event_type: STATE_CHANGED
    variables:
      event_data: "{{ trigger.event.data }}"
condition:
  - alias: is a light event
    condition: template
    value_template: "{{ event_data.old_state.entity_id.startswith('light.') }}"
  - alias: light was previously unavailable
    condition: template
    value_template: "{{ event_data.old_state.state == 'unavailable' }}"

Edit: While the documentation of state objects mentions a domain field, when I observed state change events none had domain so the documentation is likely out of date. A hacky check on the entity_id string to determine domain should work, edited above code.

5

That should not really be a problem, but your ASAP requirement indicates you want it fast and that will not be the case.

The light will probably turn on when it gets powered again, but it can take several second and even over a minute for it to register in HA, because it has to boot and then reconnect to the network, then reconnect to HA, then update the HA entity.

Smart lights are not meant to be powered off, so try looking into smart buttons instead.

6

This is a fair point, ASAP != instant which isn’t ideal, but availability usually takes only a few seconds for my Matter bulbs which is good enough for now. My lighting auto-adjust is set to 1min 30sec intervals, which is roughly the current upper limit of adjustment time, so I’d be happy with say a 5 second auto-adjustment.

I agree using smart switches / buttons is probably the optimal solution in terms of speed and automation, but I want lighting to be controllable even if HA is down so dumb switches probably aren’t going anywhere. I’ve seen smart switches with dumb fallbacks, but they are pretty pricey and have more complicated wiring schemes. If a more affordable option with dumb fallback becomes available I’d probably go that route, but I would still want lighting to be auto-adjusted ASAP in the situation when the dumb switch is turned on.

7

Well, now you know the limitations and then it is your choice.
I have no issue with the choice as long as it is done in enlighten grounds. :slight_smile:

8

Still looking for an efficient way to trigger an automation based on device type (e.g., lights) rather than entity or device IDs.

While the above solution I gave technically functions, triggering on every event is indeed inefficient and causes odd Home Assistant behavior with high system usage, so not a practical solution in most cases.

9

Not sure if you’re still looking for something, but this is how I did it:

Basically I used 2 template sensors, one that creates a list of lights that are both “on” and have a “circadian” label. The 2nd sensor detects when the list is updated then strips the new light entity from the light. I then use 2 automations, 1 that triggers when the new light turns on and fires the circadian macro once just for that light , the other updates ALL lights in the list every 5 min to the next color temp and brightness. so far it works awesome; I can give you my macros if you would like.

The only caveat to this is that you’re lights will be only circadian. I’m trying to work on the next step which is getting HA to know the difference between someone changing the light (i e. telling alexa to change color/brightness or by the UI) or the light just turning on ( which is when I’d want the circadian to fire). I’m not sure I’m going to be able to get this info from HA and may have to switch to NodeRed. I like, NR, but I believe it’s 1 more point of failure so I’d rather use the native automations.

10

there is also this blueprint that works pretty decent.

I wanted something more dynamic than this provides, which is why I created mine.