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

[Blacky]

@vgimbutas

No, when night lights is active then night glow can be active so night glow is active between 9pm to 6am.

Blacky

[richsimpson]

Ok, strange, i have added the auto off as a back up and resolved it (added a timer per light) so that separate automation survives a HASS restart. This blueprint should survive restart on its own though, is that right. I read the info right? Certainly wasnt happening for me.Latest HA and latest version.

[al3x1337]

For Dynamic Lighting or any other Lux field, is there really not a way to set a lower Lux value than 10?

Im not sure if something is off with my Hue sensor but most of the time the Lux value in my hallway is <10lux, closer to 1-4lux range.

I have 3 motion sensors in different parts of the hallway, 2 Ikea and 1 Hue that i want to use Lux for. If it’s below a certain value like 6lux, is when I want to trigger my lights so that even if it’s the middle of the day but just very dark outside, i want the hallway lights on.

[spacerunner (stefan)]

Bypass Problem

Hi Blacky,

first of all: thanks for the great work !

I do have a problem with “bypass”: All I want is Sensor Light to NOT DO ANYTHING at all if a certain condition matches. To do so, I assigned a binary sensor as bypass:

alias: sensorlight.bonnieflur
description: ""
use_blueprint:
  path: Blackshome/sensor-light.yaml
  input:
    motion_trigger:
      - binary_sensor.occupancy_group_bonnieflur
    light_switch:
      entity_id:
        - light.e27_hue_bonnieflur
        - scene.snapshot_lights_all_attributes_mittelflur
    ambient_light_sensor: sensor.sens_zb_light01_illuminance
    ambient_light_value: 5000
    ambient_light_high_value: 0
    include_ambient: ambient_enabled
    dim_before_off_time_delay: 20
    time_delay: 0
    light_transition_on: 0.1
    light_transition_off: 0.1
    include_light_control:
      - use_transition
    include_bypass:
      - bypass_enabled_stop
    motion_bypass_lights_stop:
      - binary_sensor.con_badtuer_inverted

However, when doing so, the sensor defined in motion_bypass_lights_stop actually triggers the script itself, resulting in Sensor Light turning off my light. So it actually does something.

As I understand, I can define multiple triggers but they are all “OR” logic, right?

Question: Is there a way to really, completely bypass the script based on external conditions?

[bjsassone]

Great blueprint! However, I’m seeing triggers when home assistant restarts that I don’t understand.

I have 3 identical door sensors and used 3 automations each configured in the same way: Door open, turn some lights on. I thought I fixed unwanted trigger at restart by setting the condition that door sensor has to be off first. But, with the recent core update, a restart triggered one, but not the others!

Is there a best practice to prevent triggers at restart? Ideally, I’d like to trip an alarm if the door opens when it’s not supposed to, but don’t want that happening everytime I have to restart!

Thanks for any help.

[Sir_Goodenough ((SG) WhatAreWeFixing.Today)]

@bjsassone

Is there a best practice to prevent triggers at restart?

@CentralCommand

trigger:
  - platform: state
    entity_id:
      - sensor.some_sensor
    not_from: ["unavailable", "unknown"]
    not_to: ["unavailable", "unknown"]

and this

@tom_l

triggers:
  - trigger: state
    entity_id: binary_sensor.your_entity_here
    to: "off"
    not_from:
      - unknown
      - unavailable

[maisun]

@Blacky

End Time

The end of when the automation can’t run.

Note: Think of the start and end times as a race. The start time is like the “starting line,” and the end time is the “finish line.” The automation will only run during this time frame, just as a race occurs between the starting and finishing lines.

Hi: I have a question regarding the time option.
The automation is triggered at end time to turn off lights, not sure it’s the expected behaviour? My understanding is that end time is only for enable/disable the automation and it shouldn’t turn on/off lights.

Edit: also noticed when “Dim Before OFF” is enabled, when automation triggers to turn on the lights, it turn on the lights with brightness 100%. This raises issue for adaptive lighting which I have configured to ignore turn_on command with brightness info. I have double checked “Use Brightness” under light control is disabled.

[cravevox]

Been using your blueprint for about a year or so and just wanted to say thanks for the great work and providing this to the community!

[Renekcl]

Is there a way of using beside a binary sensor an event? I want to activate lights based on events from a finger print sensor of our door.

[poupaerta (Andries Poupaert)]

Sorry for the late response. Have set it and will test it. (if I don’t repsond in the futher it means it worked). And thank you for the help!!!

[kools (ryan)]

Hi I have just found the same issue. Ive just setup a schedule helper for when i don’t want to lights to change state and added it to the by-pass section. hopefully it works and if it does it’ll give more flexibility to when the lights are activated

[amatt09]

sorry if this was already asked in the thread but is there a way to adjust the color of the lights based on time of day or sun position?

[ryanmccullough]

Bug: Dynamic Lighting crashes when light entities lack brightness attribute

Problem

The Dynamic Lighting feature crashes when any light entity in a group doesn’t have a brightness attribute — this happens when a light is unavailable or off.

Error:
UndefinedError: ‘homeassistant.util.read_only_dict.ReadOnlyDict object’ has no attribute ‘brightness’

Root cause

12 places in the blueprint use map(attribute='attributes.brightness') on the expanded entity list without first filtering to lights that are actually on. When a light is off or
unavailable, its attributes dict doesn’t contain brightness, and HA’s ReadOnlyDict raises before Jinja2 can handle it.

Note: Adding default=None to the map() filter does not fix this — it’s a known HA/Jinja2 quirk where ReadOnlyDict raises an error before Jinja2’s default mechanism
kicks in.

Fix

Add selectattr('state', 'eq', 'on') before the brightness access so only lights that are on (and guaranteed to have the attribute) are included:

# Before (crashes)
expand(le) | map(attribute='attributes.brightness') | reject('equalto', None) | ...

# After (safe)
expand(le) | selectattr('state', 'eq', 'on') | map(attribute='attributes.brightness') | reject('equalto', None) | ...

This is the same change in all 12 locations. I've been running a patched version and it's solid — available lights work normally, unavailable/off ones are skipped.

Forked gist with the fix applied: https://gist.github.com/ryanmccullough/f1505b1f3d9542299e8d76c80a9490fc

[Nickduino]

@Blacky

I would recommend when using a LUX sensor that you have a separate LUX sensor outside that only reads the natural light and is not effected by any artificial light source. You then can use it for any automation, like this blueprint. Maybe don’t use LUX option and use the Sun Elevation option.

I think you should make it work with a lux sensor that’s in the room you want to control with the automation. Because it might be reasonably bright outside but already dark enough inside in this room to require the lights to be turned on (while other rooms are still bright enough for the lights to stay off).

To turn the lights on (so they are currently off), that’s a no brainer: the lux sensor tells you the real illuminance of the room. Once the lights are on, I get why you don’t like that very much but you could make decisions based on the lux value minus an offset (so we need the offset variable available in the blueprint). So, in essence, turn the lights on when illuminance is below 80 lx and turn them off when they’re above 180.

[Nickduino]

@Blacky

So, there is currently no way to base the colour temp on the time of day and the brightness on the illuminance sensor? Would you consider adding this option?
(Or maybe separate this into two options: a ‘Dynamic brightness’ option that could be controlled by lux/sun/time and a ‘Dynamic colour temp’ option that could be controlled by lux/sun/time)

Here is my reasoning: I want the colour temp to be fixed everyday because it helps align my circadian rhythm with my daily schedule (I don’t want to go to sleep at 6 o’clock in winter and 11 in the summer) but the brightness should depend of the daily conditions.

[wrobelda]

Hi there.

Is there a way to have automation switch off the lights automatically if they were switched on manually (as opposed to by motion sensor)? Or do I have to use another automation to handle this? Problem here is I don’t want them to interfere.

[wrobelda]

Sorry for the late reply. Thanks for checking and yes, it turned out the switch itself was pressing against the cables and would randomly switch itself off.

[strumf666 (Peter Štampfel)]

Hello,

I am having a werid problem with my shelly rgbws - Shelly RGBW2 multi channel control problem · Issue #165532 · home-assistant/core · GitHub
Would it be possible to have a configurable option to introduce a delay between sending commands to multiple light entities in the blueprint?

Kind regards,
Peter

[dlarkinsPonderosa]

@Blacky I have selected a script under Lights to run when triggered. Works as intended. It is a very quick script that turns on a scene based on time of day.

I have created an input toggle helper for tracking the state (not clear if this is the state of the script, or the automation, that this helper represents?)

Regardless I note that the helper does turn on when the automation is triggered.

However the helper does not seem to ever turn off? The automation finishes and the helper is still on.

I am using a scene for the Off. (so script for on, scene for off).

I have added the helper to my Off scene as a workaround, but I assume this isn’t intended?

[amatt09]

+1 on this