Only enable light control when below minimum lux level

[bmcclure]

I'd like to set a target lux or luminance level below which my lights automate, and above which they do nothing.

Is this what the Dark state is meant to be used for? It seems like I could set a template sensor to on or off depending on aggregate lux level of the area.

Or I could toggle the area light control switch on or off via separate automations based on lux. However, I wonder if I may be missing an option that wouldn't require writing code for each sensor or creating separate automations for each area to handle it.

[jseidl]

Is this what the Dark state is meant to be used for? It seems like I could set a template sensor to on or off depending on aggregate lux level of the area.

Exactly. Just beware that that might flip on and off as lights turn on and the lux level rises. What I do is to do that but with the external aggregate lux sensors.

There's a feature request for aggregates to create that light sensor which I'll work whenever time permits!

[bmcclure]

It seems like the best way around the lux level raising when the lights turn on is only checking that sensor when the lights are off, but I'm not sure if that's possible with MA currently.

It would be nice if you could either

1. have a generic way to define a condition which is checked once before running light automations, vs the only option being tracking a state (which in this case is inherently unreliable for the duration of the lights being on), or
2. have a maximum lux level slider to abstract the logic from the user--less flexible but easier to use, and I assume a common use case

If a light level option is ever implemented, I think as basic logic, it would be sufficient to check if the lights that it's about to turn on are already on, and if not, optionally check the lux level of a selected light sensor (such as the aggregate sensor from that feature request, but that might not always make the most sense--for example maybe the task area is in a dark corner of the room and would be better off using a specific light sensor in that area).

[jseidl]

It seems like the best way around the lux level raising when the lights turn on is only checking that sensor when the lights are off, but I'm not sure if that's possible with MA currently.

You could use a template for that. Pseudo code would be something like

if lights on:
    return dark
else:
    return (lux < threshold)

But even then you might have other problems with other scenario configurations. I personally just deem individual dark state tracking to be something that requires a lot of work for little value.

What I do is short circuit by:

• Does this room have windows / receive exterior light? (e.g. Bathrooms and pantry maybe be always dark).
  • If yes, use exterior light sensor
  • If no, don't use a dark entity, assume always dark

have a generic way to define a condition which is checked once before running light automations, vs the only option being tracking a state (which in this case is inherently unreliable for the duration of the lights being on), or

Well :) I would say that using template binary sensors is a generic way to define a condition for that. Then you can make as reliable as you please. It would be very cumbersome to add some kind of language interpretation (for conditions) inside the component.

have a maximum lux level slider to abstract the logic from the user--less flexible but easier to use, and I assume a common use case

That's the experience I foresee for that feature. Still user has to select either this newly created sensor or the area light aggregate as the dark entity.

One overall caveat is that due the concept of area states + events + features listening to those events, I need to keep the area state tracking generic, without changing it too much in favor of a specific feature. All features are optional so an user might not want aggregates but want Light groups, and track the dark state, say, by the sun sensor.