Considerate motion triggered lights with dim before turning off [Smartthings migration collection]

[busy996bot]

Background

I’m migrating away from Samsung Smartthings, there are automations I need to re-implement in Home Assistant.
One of the automations I have is following:

1. It will turn on lights when motion is triggered.
2. It will dim lights when motion is no longer detected for a certain period so you are aware it is about to turn off.
3. It will turn off lights after a longer period if there are still no motion detected.
4. It will adjust the initial brightness based on current time.
5. It will allow the automation to be completely bypassed, in case motion is triggered by curtains during midnight or there is a guest in motion detector area.

I’m not able to find similar solution here so I’m making my own.

Highlights

• Completely bypassing capability: allow bypassing turning on/turning off of the lights or completely put automation into “Dumb” state.
• Dim before completely turning off: for safety reasons this is highly recommended in areas such as bathroom.
• Choose color(for color changing lights) or color temperature(for tunable white lights) or keep the existing color settings.
• Day/night mode for common scenarios, can be overridden by adding luminous sensor.
• Does not schedule triggers that can cause undesired side effects.

Reminders

• You can group multiple motion sensors in a single area to be used with this automation.
• Lights turn off action may not execute due to following reasons: another motion on event is triggered, scheduled delay action is aborted due to system restart or failure, turn off bypass condition is met(even if the lights were turned on by this automation).
• It is highly recommended to bypass this automation with a “Dumb” mode in case of emergency.
• Do not use this automation in potentially life threatening areas, such as cooking area or pool side.
• Test the automation with a single non-critical deployment before moving on to larger scales.

Disclaimer

Use of the blueprint is at your own discretion and the authors are not responsible for the potential outcome caused by using of their work.

Release

I take home automation reliability, stability and security seriously and will only release blueprints passing tests.

• 20230506: Initial release - stable - 15 days testing
• 20230515: Add ability to set color temp by kelvin - 7 days testing
• 20230522: Add ability to retry failed actions(turn on/off) as well as logging failed device(s) to logbook - 7 days testing
• 20230904: Avoid turning up the lights when dim action is triggered - 2 days testing
• 20230906: Bugfix for dim action errors due to value not being comparable - 1 day testing

Test environment:

Home Assistant 2023.8.4
Supervisor 2023.08.1
Operating System 10.5
Frontend 20230802.1 - latest

Test hardware:

• Home assistant yellow
• Home assistant OS vm on ESXi + skyconnect
• Home assistant OS on NUC + skyconnect

Feedbacks and bug reports

Development status: Actively maintained

• You may leave your feedback below this topic.
• You may open a pull request on github.
• You may open an issue on github.

Feel free to click the button below if you find my works useful.

Special thanks:

Motion Activated Light with Conditions

Sorry for the delay Actually I might have misled you. I still think that the issue with your script is that when you write entity_id: !input light_target in your condition, you are expecting light_target to be an entity_id. That’s a mismatch. A target can be a list of entities, but it is actually meant as a bag of various stuff: areas, devices and entities… So, according to the Home Assistant selector schema: Targets are meant to be used with the target property of a service call in a script…

Using targets as conditions?

I have been working on that for the last day and I think I finally found a working solution. This seems to work as a condition that checks if any of the lights in the target group are on: # making the input variable usable in the condition variables: lights: !input "light_target" ... - "{{ expand(lights.entity_id) | selectattr('state', '==', 'on') | list | count > 0 }}" This is not very flexible (yet) though as I assume if you pick groups or devices instead of entities they would not be in t…

Select Selector SOLVED

I’m working on a Blueprint and can’t seem to find the proper way to handle something. Some of the options won’t make any sense and the user should not have to fill them out. Let’s say they are picking between a bicycle and a car. It makes no sense for me to present them with the option “Moon roof”. If I can’t hide the options that is fine but at the least I need a way to set a default option so the automation doesn’t fail. Some of the error messages aren’t that helpful to me as a newbie to …

…and may others who helped me learn Jinja2 template language as well as gaining better knowledge about how trigger, condition and blueprint works.

[shep]

@busy996bot thanks for this great blueprint! It’s exactly what I’m looking for, but trying to understand one thing. When I implement this blueprint, what does " Daytime Start" refer to? As an example, It would be great if this blueprint could run according to a condition like sun elevation as an option, or a “is it dark” sensor, but when I select Daytime start of 6:00 PM as an example, the lights still come on during the daytime when it’s light out outside. Any way to fix that? Perhaps I’m not understanding those values. Thanks again!

[busy996bot]

You can use Day mode bypass condition.
If the condition returns true, for example, Lux reading is lower than a certain value then the automation will turn on lights using night time brightness and color.
It would be even easier to use sunset timestamp:
{{ as_timestamp(now()) > sunset_today_timestamp }}

Make sure sunset_today_timestamp variable is set by whichever source you get your sunset timestamp for your location.

You still need to put in Day time start time and Night time start time as a fallback. But be aware of something is wrong and your condition is always return True then you never get the lights to be turned on with Day time brightness and color.

[busy996bot]

So obviously there are some misunderstanding how this automation would work here:

The blueprint configures 2 mode and alternate between them if no other options are used.

Let’s say we set day time start to 6AM and night time start to 8PM, then:

During 6AM and 8PM, day time mode will kick in, normally you want full brightness and 6500k color to ensure you see things clearly and walk around freely.

After 8PM and 6AM next day, the night time mode will kick in, normally you don’t want it to be as bright and maybe use 2700k color so your body less likely to be kept awake due to the atmosphere.

To completely bypass the automation, for example your motion sensor is used in area where people stay during night, use master bypass condition, if the condition returns True, the automation is completely bypassed, be careful because using this logic may result in lights turning itself on but never turns itself off!

A much safer approach would be using turn on bypass condition, I think this is what you want, you want to stop lights from turning on itself after a certain condition is met? Either it is a Lux reading or sunset timestamp.

In short, if no master bypass/turn on bypass is specified, the automation alternates between day and night mode, and both will turn on your lights, as intended.

[shep]

@busy996bot Thanks so much for the reply, and thanks for the blueprint, it is REALLY awesome. I thought I would share how I am using it after testing it for a few days. I wanted a motion sensor to control two lights, but only at night. The room is bright with windows during the day, and therefore I do NOT want the lights to be on during the day, only when it’s darker outside. When we are NOT in the room, I want them to ramp down and dim to a certain percentage, and then ramp back up when someone enters the room. With your suggestions above, I got this working perfectly using the Master bypass condition with {{ state_attr('sun.sun','elevation') > -0.90 }}

If you think there’s a better way of doing this, please let me know, but this seems to work great currently for my use case.

Thanks again!

[nhk (Nabeel)]

I love your Blueprint it make my life much easier
one thing I would like to know
my background I am totally new with almost Zero information about automation and smart home

I have sensors that support Lux is there anyway that I can control in the same blueprint lux values or sun information could help too.

Thanks

[busy996bot]

You can put a condition {{ states('sensor.your_sensor_illuminance') }} > 60 here,
Where the sensor.your_sensor_illuminance should be replace with the desired sensor ID, if you’re not sure, go to “Developer tools - STATES” and search for it.
The value 60 indicates the threshold value, usually in Lux, if your sensor is getting a reading larger than that lights won’t turn on even if motion is detected.

[GuruX (Gustav Brogren)]

Very nice blueprint! I just started testing it out with my Zigbee network and Z2M.

I have previously set up a threshold sensor that indicates wether it is dark or not. In my case, it reads the value from the same sensor as occupancy.

I think adding a threshold sensor to this blueprint would make it even better. It could use a default threshold sensor already in HA, but expose fields for upper/lower and hysteresis. Then people would not have to fiddle around with code in the master bypass condition.