@Blacky Any chance you could reply to this? Thanks! ![]()
Sorry, I missed this one ![]()
Context ID, Parent ID and User ID can be tricky and confusing.
I have another blueprint
Manual Control Status Tracker but I have a beta one⦠I was developing an update and then I must of got detracted forgetting about it. I need to go through it again to see what I was doing but if you like I can send you a link so you can test the beta one. You said you have an automation for the bypass and this will replace your one.
Let me know if your keen and I will PM you the link to download it.
Blacky ![]()
Yes please!
Okay, I will set it up for you now.
Blacky ![]()
hey blacky, I have used this blueprint in various places in my home, and itās fantastic. But one thing is bothering me. For places like the bedroom where people stay for a long time, I want people to have manual control over the blueprintās automatic on/off function, but I also want the automation to turn on the lights the first time someone enters. So, using your blueprint, I have written the following automation.
This is the main code of blueprint config.
- alias: ZBL-MR Blueprint Motion Light Control - Master Room
description: Generated motion light automation for Master Room using blueprint.
use_blueprint:
path: Blackshome/sensor-light.yaml
input:
motion_trigger: group.master_room_motion_group
light_switch:
entity_id:
- light.master_room_ceiling_light
include_bypass:
- bypass_enabled_turn_on
- bypass_enabled_turn_off
- bypass_enabled_stop
motion_bypass_lights_on: input_boolean.master_room_motion_light_bypass_keep_on
motion_bypass_lights_off: input_boolean.master_room_motion_light_bypass_force_off
motion_bypass_lights_stop:
- input_boolean.master_room_motion_light_bypass_pause_auto
include_ambient: ambient_enabled
ambient_light_options: ambient_light_option_enabled
state_control_entity: input_boolean.master_room_ambient_light_control
ambient_light_sensor: sensor.master_room_average_illuminance
ambient_light_high_value: 80
ambient_light_value: 30
id: automation.zbl_mr_blueprint_motion_light_control_master_room
In addition, I also use an automation to manage bypass
- alias: ZMGR-MR Stay Type Light Manager - Master Room
description: Intelligently manages the sensor-light blueprint's bypass for bedroom scenarios.
trigger:
- platform: state
entity_id: input_select.master_room_occupancy
from: Outside
to:
- Just Entered
- In Sleep
id: person_entered
- platform: state
entity_id: input_select.master_room_occupancy
to: Outside
for: 00:10:00
id: person_left_long_time
action:
- choose:
- conditions:
- condition: trigger
id: person_entered
- condition: state
entity_id: input_boolean.master_room_motion_light_bypass_pause_auto
state: 'off'
sequence:
- service: automation.trigger
target:
entity_id: automation.zbl_mr_blueprint_motion_light_control_master_room
- service: input_boolean.turn_on
target:
entity_id: input_boolean.master_room_motion_light_bypass_pause_auto
- conditions:
- condition: trigger
id: person_left_long_time
sequence:
- alias: Turn light.master_room_ceiling_light switch.master_room_front_light switch.master_room_behind_light state=off
if:
condition: state
entity_id: input_boolean.always_on_constant
state: 'on'
then:
service: homeassistant.turn_off
entity_id:
- light.master_room_ceiling_light
- switch.master_room_front_light
- switch.master_room_behind_light
- service: input_boolean.turn_off
target:
entity_id: input_boolean.master_room_motion_light_bypass_pause_auto
mode: single
id: automation.zmgr_mr_stay_type_light_manager_master_room
This works fine under normal circumstances, but if HA restarts (unfortunately, my HA may have restarted in the middle of the night due to a virtual machine backup task), the light will turn on while I am sleeping. What should I do?
If you on a older version update the blueprint and there is a HA Restart section. Disable it.
Blacky ![]()
Sorry my bad, I thought I was on another blueprint thread.
Itās not there in this blueprint.
I had a look at your YAML and some of it seams odd. I fixed it up.
alias: ZBL-MR Blueprint Motion Light Control - Master Room
description: ""
use_blueprint:
path: Blackshome/sensor-light.yaml
input:
motion_trigger:
- group.master_room_motion_group
light_switch:
entity_id:
- light.master_room_ceiling_light
include_bypass:
- bypass_enabled_turn_on
- bypass_enabled_turn_off
- bypass_enabled_stop
motion_bypass_lights_on:
- input_boolean.master_room_motion_light_bypass_keep_on
motion_bypass_lights_off:
- input_boolean.master_room_motion_light_bypass_force_off
motion_bypass_lights_stop:
- input_boolean.master_room_motion_light_bypass_pause_auto
include_ambient: ambient_enabled
ambient_light_options: ambient_light_option_enabled
state_control_entity: input_boolean.master_room_ambient_light_control
ambient_light_sensor: sensor.master_room_average_illuminance
ambient_light_high_value: 80
ambient_light_value: 30
When you restart HA is anything ON in the trigger group? If it is then the lights will come ON. Maybe try this YAML.
Blacky ![]()
I think I can try it at night. But what I want to know is, if bypass is open, and I restart haos, will the light turn on with other conditions for turning on the light?
I asked gemini and it told me it is related to the initialization order of the components.
If any bypass is ON the automation will not run, even HA restart. If The bypasses are all OFF the automation can run.
Blacky ![]()
Everything is resolved. The reason is that in my automation, my manager manually triggered the blueprint to turn on the lights and it got blocked because the bypass was not opened in time. Thank you very much. In addition, I have used every blueprint of yours, itās simply unbelievable, all blueprints are very ingenious and elegant. Thank youļ¼ļ¼ļ¼
This is amazingāI canāt believe Iāve been using HASS for 2 years and never knew about this blueprint. Iām still exploring it, but Iām not sure if it can handle what I want.
My setup: I have a kitchen and dining room next to each other, with an Aqara FP2 to track presence (including when there are 2+ people). What Iād like is:
- When Iām in the kitchen ā kitchen lights go to 100%, dining room stays at 20%.
- When I walk into the dining room ā dining room goes to 100%, and after 5 seconds the kitchen dims to 20%.
- Works back and forth like this.
- Once I leave both areas ā both lights shut off.
Maybe this has already been answered somewhere, but the thread is massive to dig through!
Well then⦠welcome to the community!
You got a trick one for me ![]()
This is just how I picture it in my head, so I apologize in advance if I miss something.
- Youāll need two automations: one for the kitchen and one for the dining room. The kitchen automation will control the kitchen lights, and the dining room automation will control the dining room lights.
- Iām assuming you have a motion trigger for both rooms (kitchen & dining room). Create a group helper that includes both motion triggers. This group will be used as the Night Lights ā Entity State in both automations. Make sure you enable night lights and select the Enable entity state option with this group.
- Configure each automation: use the kitchen motion trigger for the kitchen lights, and the dining room motion trigger for the dining room lights. Set the lights to 100% in both the normal
lightsandnight lightssettings. - Enable Night Glow and set the lights to 20%.
- In Night Light Control, select If lights are ON, adjust the lights when crossing over.
- Adjust the Night Lights - Time Delay to sure your needs. Try 0.1 just type it in. That is 6 seconds. If you would like 5 seconds the 0.08.
Test it out
Let us know how you go.
Blacky ![]()
Hello @Blacky,
First of all, thank you for this amazing blueprint! It has been useful for many, many users.
Iāve come across a scenario where I think the functionality could be improved. I have a lamp, a light sensor, and a presence sensor in the same room. Since the lamp affects the light sensorās readings, I have the option āYES - My Ambient Light Sensor is affected by the Lightsā enabled.
Hereās the situation Iām encountering:
- I enter the room, the presence sensor detects me, and the automation correctly turns on the lamp.
- I leave the room and manually turn off the lamp.
- Almost immediately, the lamp turns itself back on.
My analysis is that when I manually turn off the lamp, the ambient light level drops below the āLow Lux Value.ā The automation sees this low lux level as a valid trigger condition. Because the presence sensor can take several seconds to update to an āoffā state, itās still āonā when the lux trigger occurs, causing the light to turn back on undesirably.
My proposed solution is to introduce a short bypass period immediately after any of the controlled lights are manually turned off or on. This would prevent the automation from re-triggering due to the immediate change in sensor values caused by the manual action.
Iāve attached a diff with the suggested changes, which includes adding a new property (manual_action_debounce_time) to manage this bypass time.
PS: The diff also includes a small correction to the t10 trigger. Removing the ambient_light_option_disabled check allows the āturn off light when lux is highā feature to work correctly, even when the āsensor is affected by lightsā option is enabled.
Thanks again for your great work!
@@ -161,6 +161,21 @@ blueprint:
max: 30
step: 0.5
unit_of_measurement: minutes
+ manual_action_debounce_time:
+ name: Manual Control Bypass Time
+ description: >
+ A short duration (in seconds) to prevent the automation from re-triggering immediately after a light has been manually controlled.
+
+
+ This is useful for avoiding undesired behavior in scenarios such as:
+
+ - **Turning a light OFF:** Prevents the sudden drop in brightness from immediately triggering the automation again.
+
+ - **Leaving a room:** Prevents a motion sensor from re-triggering the light if you pass by it a moment after manually turning the light off.
+ default: 2.5
+ selector:
+ number:
+ min: 0
+ max: 10
+ step: 0.5
+ unit_of_measurement: seconds
normal_lights_settings:
name: "Light Control"
icon: mdi:lightbulb-on-outline
@@ -1369,6 +1384,7 @@ variables:
boolean_scenes_scripts: !input boolean_scenes_scripts
end_scenes: !input end_scenes
time_delay: !input time_delay
+ manual_action_debounce_time: !input manual_action_debounce_time
include_light_control: !input include_light_control
light_brightness: !input light_brightness
light_transition_on: !input light_transition_on
@@ -1900,6 +1916,20 @@ triggers:
# All Conditions
condition:
+ # Manual control bypass: If any controlled light was changed recently, stop the automation.
+ - condition: or
+ conditions:
+ - "{{ manual_action_debounce_time == 0 }}"
+ - condition: and
+ conditions:
+ - "{{ expand(light_switch.entity_id) | selectattr('last_changed', 'gt', now() - timedelta(seconds = manual_action_debounce_time)) | list | count == 0 }}"
+ - "{{ (include_night_lights != 'night_lights_enabled') or (expand(night_lights.entity_id) | selectattr('last_changed', 'gt', now() - timedelta(seconds = manual_action_debounce_time)) | list | count == 0) }}"
+ - "{{ (include_night_lights != 'night_lights_enabled') or (include_night_glow != 'night_glow_enabled') or (expand(night_glow_lights.entity_id) | selectattr('last_changed', 'gt', now() - timedelta(seconds = manual_action_debounce_time)) | list | count == 0) }}"
#Trigger conditions
- condition: or
conditions:
@@ -2081,12 +2111,11 @@ condition:
{% if dynamic_lighting_boolean != [] %}
{{ is_state(dynamic_lighting_boolean, 'on') }}
{% endif %}
- - condition: and # trigger by rising of the ambient high lux value, the ambient site condition is set to NO & check if the lights are ON
+ - condition: and # trigger by rising of the ambient high lux value & check if the lights are ON
conditions:
- condition: trigger
id: 't10'
- "{{ include_ambient == 'ambient_enabled' }}"
- - "{{ ambient_light_options == 'ambient_light_option_disabled' }}"
- condition: or
conditions:
- "{{ (expand(light_switch.entity_id) | selectattr('state', '==', 'on') | list | count > 0) }}"
Hey Blacky,
This seems to be working now mate, thank you.
The only thing is, Im not sure the dynamic brightness is changing enough, I was wondering if the fibaro mutli sensor is reports in to long intervals for the dynamic lighting to track the Lux. Or is this handled in the blueprint??
Hello Blacky,
Thank you very mucht for (all) your blueprints!! I am just starting to use this blueprint and my question could have been asked before, but I use āpnbruckner/ha-illuminaceā integration as my lux-sensor. The value gives a lux from outside and can go up to 100000 lux. My treshold would be around 10 000 lux outside, but the treshold is capped at 1000 lux. Would it be possible to increase the upper limit of the lux treshold? (I can make a template sensor if needed, but avoid it if possible).
Ps. Have the same problem with the 5 degree limit on the sun elevation.
Kind regards
Hello @Blacky
thanks for this great blueprint!
After using it for the first time today, I have come into a situation where I have an idea for a small improvement with the state control.
The state control offers ON and OFF. But I am having a binary sensor, which is only available during Christmas season with the Christmas lights. Outside the Christmas season, the devices assigned to this sensor are offline, so the binary sensor is in āunavailableā state and the state control with set to OFF does not work.
So, in state control, something like āEverything but ONā would make sense. Meaning, the light will not turn on when the binary sensor is in ON state. But when it is in OFF state, or any other state like āunavailableā, it will still turn on.
What do you think of that?
Best regards,
Lorenz
Welcome to the community.
Thanks for your suggestion.
The blueprint is working correctly, the issue is that youāre manually turning OFF the light instead of letting the automation handle it. If you prefer the light to turn ON automatically but then require you to turn it OFF manually, you could try my
Smart Light
Itās great that your lux sensor reports quickly, but in your case it may actually work better if it reacts more slowly. This really depends on how your motion sensor behaves. For example, if your motion sensor remains in the ādetectedā state for a while after you enter the room, slowing down the lux sensorās reporting can prevent the light from turning back on too soon after you manually switch it off. By keeping the lux value higher for a little longer, it gives your motion sensor enough time to clear before the light is allowed to turn on again.
To achieve this, you can either adjust the reporting interval of your lux sensor or create a template sensor that smooths the lux readings, then use that template sensor in the automation.
This then would break the condition and why it is there.
Blacky ![]()
Your welcome glad it working.
Youāll need to check how often your lux sensor reports. In the blueprint, this is controlled by Dynamic Lighting - Heartbeat, which sets how frequently it checks. You also have Dynamic Lighting - Step Value and Dynamic Lighting - Dead Zone (±).
For example, if the step value is set to 4% and the adjustment needed is 30%, the blueprint will apply 4% steps repeatedly until the target is reached. This creates a smoother transition thatās easier on the eyes. Once the adjustment falls within the dead zone (e.g., the required change is 3% but the dead zone is 7%), no further changes will be made. This prevents small flickers or constant minor adjustments that can be distracting.
Blacky ![]()
