Would that be Bypass - Time Delay with no Bypass selected? If I reread the instructions correctly.
I’ve just added a number of door contact sensors that I would like to use as triggers with this blueprint. I was hoping it would trigger the automation just on the change of state to allow faster response when someone enters the room by opening a door. The way it seems to be set up however is if any door contact sensor stays on (open) then the lights won’t turn back off. Am I reading things correctly and if so can the behavior be adjusted to allow only a momentary change of state on the door sensors?
Hi Blacky, following up on the post from @fixer about HA 2026.4 breaking sun elevation conditions, I think I’ve found a related issue that might help pinpoint the root cause.
Setup:
- HA 2026.4.4
- Sensor Light Blueprint v8.5
- Zigbee2MQTT with IKEA bulbs
- Night lights enabled with
sun_enabledcondition
Symptom:
Lights turn on correctly at sunset/night (when the sun condition passes and the Night Lights branch fires), but do not turn on during the day. The lights also turn off correctly after the time delay, so the automation is definitely triggering.
What the trace shows:
When motion fires during the day and the sun condition is not met, the automation falls to the default branch. In this branch the only service calls made are:
scene.turn_on(empty entity list)switch.turn_on(empty entity list)script.turn_on(empty entity list)
There is no light.turn_on call anywhere in the default branch. The light_entities variable is correctly populated and light_data has the right values (e.g. brightness_pct: 100, color_temp_kelvin: 4000) but they are never used.
The light.turn_on for regular bulbs only exists in the choose/0 (Night Lights) branch, so lights only turn on when that branch fires. i.e. at night when the sun condition passes.
Timeline:
Worked correctly before upgrading to HA 2026.4. Broke immediately after. No changes to blueprint or automation config.
Workaround:
Switching night_lights_conditions from sun_enabled to time_enabled with a 00:00–00:00 window forces the Night Lights branch to fire at all times, which gets lights turning on again. This loses the sun-based day/night distinction but at least restores basic functionality.
I suspect this is the same state template framework change @fixer mentioned. I have several traces clearly showing the empty service calls in the default branch.
Thanks for all your work on this blueprint!
Service calls made by default branch:
- scene.turn_on: target={entity_id: []}
- switch.turn_on: target={entity_id: []}
- script.turn_on: target={entity_id: []}
Variables at trigger time:
- light_entities: ['light.hallway_light_1', 'light.hallway_light_2']
- light_data: {transition: 0.5, brightness_pct: 100, color_temp_kelvin: 4000}
1 Like
First off thank you for this series of blueprints they are very robust and you clearly put a ton of effort into them !
I have am trying this one in my pantry. I have both a motion sensor and a door contact sensor on the door. I would like the following the change the state of the light switch in my pantry:
- Contact sensor goes from closed to open → light on 5 mins
Motion sensor goes from clear to occupied → light on 5 mins - Motion sensor triggers again while still on → reset 5 min timer
- Door contact sensor goes from open to closed → turn off lights
- Contact sensor goes to unknown or unavailable → nothing
I thought about adding the Manual Status Control tracker as well to use the manual toggling of the light switch but opted to skip that for the time being until I get the basics worked out above.
Here is the yaml I have so far which seems to be close but doesnt turn off the lights when the door closes
alias: Closet, Pantry, and Cupboard Lighting - revised
description: ""
use_blueprint:
path: Blackshome/sensor-light.yaml
input:
motion_trigger:
- binary_sensor.zigbee_pantry_door_contact
- binary_sensor.zwave_pantry_motion_home_security_motion_detection
light_switch:
entity_id: light.zwave_pantry_light
light_transition_on: 0
light_transition_off: 0
include_bypass: []
Hi, can I prevent the light from turning off when the State Control turns off? My use case is that I use the State Control with a dummy helper switch. This helper is on when I want the lights to be motion activated and off when I want them not to be (usually when we are getting ready for sleep). But when I turn off the helper and the light is on, I want it to stay on. Maybe the behavior is normal and I should use another option for my use case? Thanks!
Should the Time condition trigger the lights to turn off?
I have a time condition set from 09:00-23:30. The lights in a room trigger on when the room occupancy turns on.
With the time condition set, I’d assumed the lights wouldn’t ever turn off if the room was still occupied at 23:30. However, today the time hit 23:30 and the lights auto turned off, even when the room was occupied.
Is this to be expected?
@Blacky Is there already a solution to the problem???
What an amazing blueprint! After a convoluted automation I configured that only just works, thank you for your automation and what I consider a work of art.
I have a use case I can’t figure out based on existing features:
- I like my hallway lights to be on and in a colour of my choosing between dusk and 11pm - I successfully configured Night Glow for this.
- However, if the TV is turned on / already on, I would like the hallway lights to turn off / stay off.
- The hallway lights should still trigger per my Night Lights sensor settings regardless if the TV is on or off.
I am wondering if it would be possible for Night Glow settings to include an on/off option based on an entity’s on/off state?
Hi @Blacky,
First of all, great blueprint — it covers an enormous range of use cases and is very well built.
I'd like to suggest a feature that I think would make the bypass system even more powerful:
"Sensor Active" tracking — knowing who turned the light on
Currently, the bypass options control whether the sensor can turn the light OFF, but there's no built-in way to know whether the sensor itself was the one that turned the light ON in the first place.
The use case I'm trying to solve:
- If the sensor turns the light ON → normal behaviour, auto-off after the time delay
- If something else turns the light ON (a wall button, the app, another automation) → Sensor Light should leave the light alone entirely until the light is turned off by the user, then resume normal sensing
The cleanest way I can think of to implement this would be an optional input_boolean helper ("Sensor Active Helper") that the blueprint manages itself:
- Set it ON when the sensor triggers and turns the light on
- Set it OFF when the blueprint turns the light off (after the time delay)
This boolean could then be exposed so it can be used as a bypass condition in other automations, or the blueprint itself could check it — if the light is ON but the boolean is OFF, it means something else turned it on, and Sensor Light should not run its auto-off timer.
This would make the blueprint much more reliable in mixed environments where lights can be turned on by multiple sources (buttons, voice, apps, other automations).
Perhpas it is already supported and I missed, thanks again and I hope to hear from you.
Regards Mike
Hi All,
I've been using this blueprint for a long time and I really love it, thank you so much for all the hard work that was put into it. However, I've been having an issue that I ended up solving by making my own copy of the blueprint with a small edit. I'm going to detail this below, as others might benefit from it as well.
I have some IKEA motion sensors and they all tend to go to sleep once there's been no motion detected for a continuous 6 hours. The blueprint in its current state will only work if the motion status change is off > on and won't fire if the change is unavailable > on.
In the triggers we currently have:
triggers:
- trigger: state
id: "t0"
entity_id: !input motion_trigger
from: "off"
to: "on"
The from filter doesn't really do anything other than prevent the light from turning on when the from status is unavailable or unknown, which is likely not desirable behaviour in all cases. The relevant trigger should be replaced with:
triggers:
- trigger: state
id: "t0"
entity_id: !input motion_trigger
to: "on"
Additionally there's an off trigger where an edge case could cause lights to stay on indefinitely (although I personally never ran into this with my motion sensors). The current trigger is:
wait_for_trigger:
- trigger: state
entity_id: !input motion_trigger
from: "on"
to: "off"
The issue with this is that if the motion status changes are on > unavailable > off, the lights will not be turned off. Again, the unnecessary from filter can safely be removed, resulting in:
wait_for_trigger:
- trigger: state
entity_id: !input motion_trigger
to: "off"
Hi All, firstly thank you so much for these blueprints I have just found them and really hope I can get it working at which point i think ill slap that coffee button quite a bit given how amazing these sound in theory.
In execution I feel I am doing something wrong but in all my reading it appears to be correct, but I am having an issue with the nightlights
I have my main settings as 2 separate downlight entities on @ 20% and then my night lights I have set to 5% and between 10pm and 8am...what I am finding is that unless I add these same 2 light entities in the night light field it doesnt seem to trigger the lights to come on only in that period. Am i doing something wrong?
Hi, been trying out this (along with your Smart Light BP) and I've run into a hiccup I can't seem to resolve with the Sensor Light BP.
For my test automation I have a trigger which is a MMWave presence sensor and some WLED cupboard and plinth lights I'd like to turn on/off.
When the MMWave sensor triggers I'd like it to turn on the WLED lights. I have enabled "Sun Elevation" and "Time" controls enabled so I can test with either. However with both enabled, the Trace run fails on the Sun test (as it's during the middle of the day) and doesn't execute any further, so ignoring the fact the Time window is valid which I've set for the entire afternoon.
The BP says both are global and can be used together but maybe I'm misunderstanding that??
I've attached the BP config below.
Any ideas gratefully received.
I’m running Sensor Light Blueprint v8.5 and I’m seeing an intermittent issue with one of my motion-light automations.
Config:
alias: Kitchen Lights - Motion
description: ""
use_blueprint:
path: Blackshome/sensor-light.yaml
input:
motion_trigger:
- binary_sensor.grouped_kitchen_motion_sensors
light_switch:
entity_id:
- light.kitchen_ceiling_lights
- light.kitchen_island_bulb
time_delay: 0.5
include_light_control:
- use_brightness
- use_transition
include_dim_before_off: dim_before_off_disabled
light_transition_off: 5
include_light_colour_control: use_colour_temperature
light_colour_temperature: 3000
include_night_glow: night_glow_enabled
night_lights:
entity_id:
- light.kitchen_ceiling_lights
- light.kitchen_island_bulb
night_time_delay: 0.5
include_night_light_control:
- use_brightness
- use_transition
- if_lights_are_on_adjust_when_crossing_over
night_light_brightness: 100
night_light_transition_on: 1
night_light_transition_off: 5
night_glow_lights:
entity_id: light.kitchen_ceiling_lights
include_night_glow_light_control:
- use_brightness
- use_transition
night_glow_light_brightness: 20
night_glow_light_transition_off: 2
night_glow_light_transition_on: 2
include_night_lights: night_lights_enabled
night_lights_conditions:
- sun_enabled
night_lights_after_time: "19:00:00"
night_lights_before_time: "07:00:00"
night_lights_sun_elevation: 0
night_lights_sun_elevation_rising: -1
The issue seems to happen when motion goes off , the delay expires, and the lights start turning off. If motion is detected again at almost the same moment, the automation restarts and enters the turn-on path, but the light.turn_on service call has an empty target:
target:
entity_id: []
So motion is detected, but the lights stay off until motion clears and is detected again later.
From the trace, it looks like light_entities_off is evaluating to an empty list at the moment motion re-triggers. My guess is that Home Assistant may still see the lights as on or transitioning off because of the 5-second off transition.
This is happening during the middle of the day, so night light transitions shouldn't be playing any role either.
Has anyone else seen this behavior when motion re-triggers right at the off-delay boundary?
I've been getting errors on startup since the most recent version of HA was pushed out yesterday. All my automations (I have three) that use sensor light are now getting an error and I don't think I have changed anything. The automations themselves still seem to work fine so just flagging for reference.
The automation "Bathroom lights (new) inc night lights" (`automation.bathroom_lights_new_inc_night_lights`) has an unknown action: `input_boolean.turn_on`.
This error prevents the automation from running correctly. Maybe this action is no longer available, or perhaps a typo caused it.
Hey Blacky,
After upgrading to HA 2026.5.1, the Sensor Light blueprint v8.5 causes
all automations to become unavailable (not just the ones using this
blueprint). The system log shows:
Setup failed for 'automation': Invalid config. TypeError: string indices must be integers, not 'str'
Root Cause
The blueprint uses shorthand template conditions (bare Jinja2 strings) in
conditions: lists throughout the YAML — for example:
- condition: or
conditions:
- '{{ ''time_enabled'' in night_lights_conditions }}'
HA 2026.5 tightened validation and now requires the explicit format:
- condition: or
conditions:
- condition: template
value_template: '{{ ''time_enabled'' in night_lights_conditions }}'
There are 204 instances of shorthand template conditions in the blueprint that need converting.
The Fix
I've patched my local copy by converting all 204 bare template strings to explicit condition: template / value_template: format. The fix is mechanical — every instance of:
- '{{ expression }}'
becomes:
- condition: template
value_template: '{{ expression }}'
After patching, all automations load correctly, including ones with night_lights_conditions enabled.
Impact
This is critical because HA's automation config validator fails globally — one invalid automation from this blueprint makes all 40 automations unavailable, not just the blueprint-based ones.
Affected Inputs
The issue is triggered when using any of these blueprint inputs:
night_lights_conditions(e.g.,time_enabled,entity_state_enabled,sun_enabled)
But the shorthand conditions exist throughout the blueprint, so the fix should convert all 204 instances for full HA 2026.5 compatibility.
Happy to share my patched YAML if helpful. Thanks for the great blueprint!
I'm having the same issue. Have you figured out why?
Hi Blacky, I do also face this issue.
There's a way to make the blueprint adaptable for the unavailable sensors? I do have some battery pir sensor beside the usb powered ones and as soon as one become unavailable due to battery all the automation stop to work
Thanks