💡 Sensor Light - Motion Sensor - Door Sensor - Sun Elevation - LUX Value - Scenes - Time - Light Control - Device Tracker - Night Lights


Agree, please see this feature request and vote on it as it is a limitation in HA.

It is under development so HA is onto it. GitHub Link. It is why we love HA they really listen to us all.

When HA release it it will be implemented.

Blacky :smiley:


First thing is to work out your trigger. Normally it is a motion sensor but it looks like you are asking for 3 things.

  1. Time
  2. LUX
  3. Device Tracker

Out of the 3 we can use time as the trigger and set LUX and Device Tracker as conditions. If you use a schedule helper for your time and enter it into the trigger. This will be the time you would like the lights ON when it is below 40lux and someone is home.

Then set 2 conditions. Both have to be met (True) for the automation to run.

  1. The Ambient Options
  2. The Device Tracker Options

Hope this helps… let us know how you go.

Blacky :smiley:

Hi Blacky,

Any luck on looking at the night lights crossover function?

I have sensor light in many of my rooms now and they all crossover to night light scenes (using the time option) even when the option is unchecked so I don’t think that check box is working.



100% that is the next thing on my list and I am back to normal now with work so I have some free time now.

Stay tuned

Blacky :smiley:

1 Like

Thanks very much :grin:

New update 6.4

Your lighting experience, your way – take control and customize it to perfection! :bulb::sparkles:

Bugs Fixes :bug:

  • Fixed bug when using scenes and crossing over from normal lights to night lights and vice versa. The option ‘If lights are ON, adjust the lights when crossing over’ now works with scenes but you must use ‘Scenes & Scripts - Toggle Helper’.

If you like this blueprint? Consider hitting the :heart: button in the top post :+1:

If you like my blueprints, and would like to show your support or just say thank you? Click Here :smiling_face_with_three_hearts:


Blacky :grinning:

1 Like

Newbie here. Your Sensor Light blueprint is awesome, and your user support is very kind. Thank you for everything you are doing for this community.

I have a Lutron Casetta inwall-switch, paired to a Lutron Casetta wireless pico-remote switch, and your blueprint is turning their light circuit on and off using a Hue outdoor occupancy sensor.

My wired Casetta in-wall-switch sometimes appears as an Entity in HA, but the wireless pico-remote I have paired to this wired Casetta in-wall-switch, does not. I suspect pico-remote switches are stateless togglers, although some pico-models include dimming and a favorite-dimness-button, so maybe they do remember something…? Anyway.

If I manually turn the light on, using the wireless pico-remote, your blueprint will soon turn the light off again, because no occupancy is being sensed. If I manually turn the light off, using the wireless pico-remote, your blueprint seems to disable itself. (BTW, to add to the confusion, I actually have several wireless pico-remotes paired to this wired switch, and all of them look identical to the wired switch because they are wall mounted with a faceplate).

I tried some of your very impressive bypass settings, trying to get the wireless pico-remote’s on-button to disable the occupancy automation – at least until the wireless pico-remote’s off-button is pushed. However, your bypass settings require me to select the in-wall casetta switch as a Device, and the pico-remote as an Entity, which it is not.

So, maybe wireless pico-remotes are not compatible with your blueprint? If so, would you suggest I simply unpair the (non-wired) pico-remotes from the light circuit, and replace them with a parallel-wired casetta switches? Hopefully there is a better solution, because that would require a lot of house re-wiring.


Welcome to the community.

Your welcome and thanks for your kind words.

This will only happen if the automation is triggered then the Hue outdoor occupancy sensor goes clear.

If you turn the light OFF and the Hue outdoor occupancy sensor is true/active/occupied then in order for the light to be turned ON again the Hue outdoor occupancy sensor must go clear then true/active/occupied.

Regarding your Casetta in-wall-switch or your pico-remotes they must have a entity and it must have an ON / OFF state. You also can have it connected to the light but I am assuming you are using your Casetta in-wall-switch in ‘Lights - Switches - Scenes - Scripts’ so that will make the automation work but if you turn the light ON or OFF using this switch then the automation will be active and work of your Hue outdoor occupancy sensor. If you would like manual control then you can use your pico-remotes to turn ON / OFF a bypass option and you would normally use option 1 for this. You wouldn’t link it to your Casetta in-wall-switch and keep it as a independent switch just to control the bypass for manual control. If your pico-remotes don’t have a state then you can create a toggle helper and use the toggle helper in the bypass and have your pico-remotes toggle the toggle helper ON and OFF. Also note that you can use the ‘Bypass Auto OFF Option’ so you don’t forget to turn the light OFF.

Hope this all make sense

Blacky :smiley:

Thanks Blacky,

I’ve just seen this update - thanks I’ll give it a try this evening - I’m sure it’s work…

I’ll also adjust the Sun elevation as you suggested and the on/off Helper so as to not miss the Sun trigger time…

When I said I managed to get option 4 in Dynamic Lighting going I was just experimenting and didn’t copy you the YAML…

One last question (I hope): Is the ‘Transition’ the total transition time from ‘off’ to ‘on’ say or the step transition from one light level to the next in the transitioning sequence?

Thanks again for your help - very much appreciated.

@Bobie No problem… I think the dynamic lighting option 4 may be opposite to what you are after though. If so just let us know as I may need to make another option.

Blacky :smiley:

Hi :wave:

sometimes the bp sends multiple OFF and ON command to my devices. That’s pretty bad if the last command is the OFF command :confused:

The motion sensor one from Hue connected to a Hue bridge.
The light is served by Zigbee2MQTT, it’s this one: Lidl 14153806L control via MQTT | Zigbee2MQTT

The following log entries are from Zigbee2MQTT. It send 2 times OFF and 1 time ON. All at the same time?!

Debug 2024-04-14 18:47:09Received MQTT message on 'zigbee2mqtt/Light Staircase FF/set' with data '{"state":"ON","transition":5.0,"brightness":254,"color_temp":153}'
Debug 2024-04-14 18:47:09Publishing 'set' 'brightness' to 'Light Staircase FF'
Info 2024-04-14 18:47:09MQTT publish: topic 'zigbee2mqtt/Light Staircase FF', payload '{"brightness":254,"color":{"h":212,"hue":212,"s":10,"saturation":10,"x":0.3131,"y":0.3232},"color_mode":"color_temp","color_power_on_behavior":null,"color_temp":153,"do_not_disturb":false,"last_seen":"2024-04-14T18:47:10+02:00","linkquality":255,"state":"OFF"}'
Debug 2024-04-14 18:47:09Publishing 'set' 'transition' to 'Light Staircase FF'
Debug 2024-04-14 18:47:09Publishing 'set' 'color_temp' to 'Light Staircase FF'
Info 2024-04-14 18:47:09MQTT publish: topic 'zigbee2mqtt/Light Staircase FF', payload '{"brightness":254,"color":{"h":212,"hue":212,"s":10,"saturation":10,"x":0.3131,"y":0.3232},"color_mode":"color_temp","color_power_on_behavior":null,"color_temp":153,"do_not_disturb":false,"last_seen":"2024-04-14T18:47:10+02:00","linkquality":255,"state":"OFF"}'
Info 2024-04-14 18:47:09MQTT publish: topic 'zigbee2mqtt/Light Staircase FF', payload '{"brightness":254,"color":{"h":212,"hue":212,"s":10,"saturation":10,"x":0.3131,"y":0.3232},"color_mode":"color_temp","color_power_on_behavior":null,"color_temp":153,"do_not_disturb":false,"last_seen":"2024-04-14T18:47:10+02:00","linkquality":255,"state":"ON"}'

trace json: { "trace": { "last_step": "action/0/default/3/parallel/1/sequence/10", - Pastebin.com

Thank you so much for getting back to me – so crazy fast. You must be chained to your monitor, with your eyes glued open.

So… I will unpair the Lutron picos from the circuit that the Hue occupancy sensor is controlling, and pair these picos up to a circuit that turns something else on/off instead, like an unused Lutron plug-in dimmer which is not controlling anything. Then, I will use this plug-in dimmer as the Entity required in your blueprint’s bypass off (option 1).

However, you suspect I need a toggle-helper attached to this unused plug-in dimmer entity. That way, multiple picos, all paired to this same plug-in dimmer, can control the toggle state. Yet, if the toggle type is a boolean input helper with either a value of on, or off, any use of any pico would trigger this toggle. So, conditions may need to be attached to the toggle-helper to make it work more sensibly.

Blacky, this work-around had not occured to me. I was thinking software, without thinking about reconfiguring the hardware connections. Yet, this is likely a mental hurdle faced by most folks who use bypass switch devices. It is obvious, in hindsight, but it had me stumped for days.

Maybe a teaching version of your blueprint would help educate folks about bypass switches? When these folks have their hardware properly connected, your full blueprint could be loaded, along with all its incredible options, and the teaching blueprint could help populate it, and get out of the way.

Meanwhile, I do not recall setting your blueprint to respond to a clear status from the Hue occupancy sensor. Your blueprint seems to default to turning the lights back off again, after the Hue occupancy sensor shows clear. And when a pico is pressed-off, it seems to permanently bypass the blueprint. I wonder if this bug-like behavior is caused by same object being listed with different labels, under target device and bypass entity? If so, I’m surprised the blueprint allows me to misconfigure it this way.

Hi Blacky,

In some of your explanation I think you say the light(s) will Decrease as the sun drops below the horizon. Again, I might be reading this all about face - I was thinking “why would anyone want to turn off lights as the Sun is going down”. I would have thought that one would want the lights to come on as the Sun sets.

I gave your YAML a go yesterday evening but I think I messed with the Sun elevation too much and screwed it. I’ll see what happens this evening.

Your support for this Blueprint is magnificent - I really hope I/we can get this going to suit my needs, odd as they are.

Light’s getting slowly brighter as the Sun goes down (1/2 hr perhaps) - then at a fixed time the lights Dim down slowly, 10mins perhaps, to a low light level and stay ON but dim - Then at a set time all go OFF.



Very interesting: ESRL Global Monitoring Laboratory - Global Radiation and Aerosols

Hey Blacky! I found issue/bug with your blueprint and latest HAOS but not sure what exactly cause this, could you help please?
Using your blueprint with mix of zigbee/wifi lights (aqara) and motion/light PIR sensor, they are added as entity; dynamic light enabled as first option (lux controlled brightness). Before 2024.4 everything was fine: light could be switched on when motion detect and stay at brightness value based on dynamic light (50% for example), changing only when lux value changes too.
After 2024.4 HAOS update my light turning on with brightness based on dynamic light but right after it always goes up to 100% brightness according to step and heartbeat values. Looks like it ignoring my lux sensor after light turning on initially.
Nothing was changed from my side from february, only updates comes from HAOS. Restarting HAOS doesn’t help with this, 6.3


This seams strange as in normal function the OFF is the last thing once motion is cleared and the time delay has passed. Is there something else controlling it?

Could you please provide us your YAML of the automation? This YAML code are the settings you have selected in the automation so I can help. To do this go into your automation, top right 3 dots, Edit in YAML, copy all the code, come back to the forum and in your reply at the top tool bar click on “</>” and paste code in there.

Blacky :smiley:

1 Like


Maybe a easy way to see how the bypass works is to create a toggle helper and use it in the bypass. You then can try it out in different bypass options. It a lot to get your head around as the blueprint has so many options.

Blacky :smiley:


Yep as I thought option 4 works the opposite to what you are after. Good news is I have developed a new option yesterday and the sensor works, the blueprint has been updated and I just need to do the final live testing before I release it.

This option mimics the sun so what happens as the sun rises you have a low brightness level and warm temp then a midday you have a high brightness and a cool temp and as the sun sets you go back to a low brightness and a warm temp. You can wake up to a sun rise effect. If you have dark rooms like basements it can be used to mimic the sun. Also google ‘circadian rhythms’, light can be one factor and although this is very basic some people like it.

Yep, keep an eye out for the next release 6.5 and then you will use option 5 once you update.

Blacky :smiley:


I am just about to test Dynamic lighting again (tomorrow) and will look into it to see if this is the case. Once I test it I will get back to you. I am currently on 2024.4.3.

Could you please provide us your YAML of the automation? This YAML code are the settings you have selected in the automation so I can help. To do this go into your automation, top right 3 dots, Edit in YAML, copy all the code, come back to the forum and in your reply at the top tool bar click on “</>” and paste code in there.

Blacky :smiley:

That is such a profound realization, that you might consider adding a toggle-helper widget, by default, to your blueprint. It can always be deleted, right? Maybe it could be a virtual-only dial-entity, called a blacky.

The blacky would be a home screen widget with a rotary-dial ist of labelled states, for an entiry or device that only exists virtually. Picos would pair to the blacky, and would be the only thing that could change the blacky’s state. Much better than using a physical $120 Lutron plug-in dimmer which is othewise not physically in use.

Not sure how relevant these posts are, but this implies Lutron pig- used to show up in HA without this.

EDIT: Lutron Pico remote switches are zigbee. So, If you unpair them from the non-pro version of the Lutron Bridge/Hub (because it uses HA-incompatible-SSH, not HA-friendly-Telnet), then you can connect these picos to HA via LEAP. This requires some kind of CASETA LEAP ADD-ON thingy, I am still researching that… Stay tuned.