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

I’ve got the same issue

and the same workaround

I am using the ZBMINI, maybe it is the source of this issue …

Seems like it’s working now, thanks!

1 Like

@kimvic

Hi Victor, welcome to the community.

It shouldn’t it splits up all the domains.

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:

What are the key diffrences between Sensor Light blueprint and Smart Light blueprint ?

First of all thanks for the amazing work. I struggle with two things and wonder how to get it to work, i have searched in this topic a lot. Im sorry if the solution to this is already in here.

  • How to overwrite the brightness if the light has been turned on by the automation but then the brightness gets changed by anything else for example a user via UI or a voice change with google assistant.

  • How to save a brightness state, then detect motion and when motion is gone again go back to the initial brightness.

Thanks!

Hi Blacky! Thanks so much for this blueprint!

I’ve got an Ikea VALLHORN motion sensor for my trigger, a TRETAKT Smart plug that my target lamp is plugged into, and a RODRET Dimmer switch that manually controls the light through Zigbee/HA (not paired directly to the plug).

When I first set it up, the motion sensor was working well, but it was turning the light off while we were watching TV. So I set the RODRET switch to be a “keep current state” bypass, and set the “Bypass Auto OFF - Time Delay” to 2 hours, so that the motion sensor would resume activity at that time.

This worked for pausing the automation & resuming it, but it disabled the automation for the switch manual triggering, exactly as you state in the Bypass FAQ.

I then updated it so that the RODRET switch Automation is the entity for both “Bypass Switch - Turn lights ON” and “Bypass Switch - Turn lights OFF”, but that makes the motion sensor not trigger the light.

I’ve confirmed that if I disable all Bypass options, the motion sensor turns the light on as expected.

I’m completely stumped how to have the behaviour of “if the RODRET switch is used by a human to turn the light on or off, pause this automation for 2 hours, then resume normal function” implemented.


As an aside, I’m very confused on the bypass behaviour, and the bypass faq doesn’t help a lot. I think what could help would be to change the nouns in the blueprint? For example, is the bypass turning my Trigger device On, or is it pausing the Automation? I’m probably trying to think about it too deep, a problem i run into frequently, and I can tell you’ve tried to make the action description intuitive…

FAQ - Sensor Light Blueprint V Smart Light Blueprint

1. What are the primary differences between the Sensor Light and Smart Light Blueprints?

  • Sensor Light Blueprint is specifically designed for dynamic triggers like binary sensors (e.g., motion sensors, presence sensors, etc.). It includes a wide range of conditions such as sun elevation, ambient light, time-based options, and device tracking to control when the automation will activate. This makes it ideal for areas where lighting should respond to real-time, unpredictable triggers, such as motion or presence sensors that can change state at any moment.

  • Smart Light Blueprint is built for fixed triggers such as entity states, sun elevation, ambient light, and time-based options to turn lights on or off. Apart from the entity state trigger, all other triggers in this blueprint are based on fixed schedules instead of dynamic conditions. This means they activate lights based on predictable, scheduled events like sunrise/sunset, ambient light thresholds, or specific times. It’s best suited for scheduled, consistent lighting needs and is not designed for use with motion sensors or other dynamic triggers.

2. Trigger Type:

  • Sensor Light Blueprint is designed for dynamic triggers, which are typically binary sensors like motion sensors or presence sensors. These sensors can change state at any moment, making the lighting responsive to real-time events.

  • Smart Light Blueprint is intended for fixed triggers, such as entity states (on/off), sun elevation, ambient light levels, and specific times. These triggers are usually more predictable and occur on a fixed schedule.

3. Which blueprint is better for motion-sensor-based lighting?

  • Sensor Light Blueprint is optimized for motion sensors and other binary triggers, allowing detailed control over activation, time delays, and continuous lighting when sensors are re-triggered.

4. What are the different condition options available in each blueprint?

  • Sensor Light Blueprint offers a variety of conditions to control when the automation is allowed to run, including:

    • Sun Elevation: Based on the sun’s position in the sky.
    • Ambient Light: Based on light levels in the environment.
    • Time-Based Options: Allows you to define specific time periods on given days for activation.
    • Device Tracking: Uses presence detection to ensure automation only runs when someone is home.
  • Smart Light Blueprint, on the other hand, only has Weekdays as a condition to control when the automation is allowed to run, allowing you to specify the day of the week. As you can see, the conditions in the Sensor Light Blueprint (such as sun elevation, ambient light, and time) are essentially used as triggers in the Smart Light Blueprint.

5. How does each blueprint handle dynamic lighting?

  • Both blueprints support Dynamic Lighting, where brightness and color temperature can be automatically adjusted based on lux levels or sun position.

  • The Sensor Light Blueprint also allows fine-tuning of Dynamic Lighting based on sun elevation and lux, as these are added conditions that can further control how lighting behaves.

6. What is the difference in the manual override or bypass options?

  • Both blueprints have manual override/bypass options that work the same way. They allow you to manually control the lights and prevent automatic activation when needed. In both blueprints, you can bypass the automation rules and gain full control over the lights, ensuring they don’t automatically turn on or off based on the triggers or conditions set in the blueprint.

7. How do the blueprints handle Night Lights?

  • Both blueprints include a Night Lights Mode, which can be automatically enabled based on entity state, a given time period, or sun elevation. This ensures that the lighting behaves appropriately for nighttime use, offering a softer and more comfortable lighting experience.

In Closing:

  • The Sensor Light Blueprint is best suited for environments where lighting needs to react to real-time, dynamic changes, such as motion or presence detection. It’s ideal for scenarios where you need flexibility and immediate response to unpredictable events.

    Example: Walk into a room and the light turns ON. When you leave, the light will turn OFF with a delay. Open a door and the light turns ON, with the light turning OFF with a delay when the door is closed.

  • The Smart Light Blueprint, on the other hand, is designed for more predictable, scheduled lighting setups. It’s perfect for automations based on fixed events like specific times of the day, sun elevation, or ambient light levels, without the need for dynamic triggers. This blueprint offers a more consistent, scheduled lighting experience, where triggers occur based on fixed schedules rather than changing conditions.

    Example: Turn the light ON when the sun sets and turn it OFF at a set time, such as 11pm. Open a door and the light turns ON, close the door and the light turns OFF (no delay).

Enjoy

Blacky :grinning:

Back to FAQ: Click Here

@TheMinimalist

I did a FAQ for this now see above post.

Blacky :smiley:

1 Like

@Hilpas

Welcome to the community.

Currently if the light is ON and you change the brightness colour etc the light will stay that way until the light turns OFF and back ON again then it will revert back to you light settings in the blueprint.

You may be able to use a scene and create an automation that will save/update the scene every time you adjust the lights. Then use the scene in the automation this way it will turn the scene on with your adjusted levels.

Blacky :smiley:

@jacobmovingfwd

This could be the solution. When you are watching TV can HA see if the TV is ON or OFF? If so then use this TV state ON as the bypass. Then when the TV is ON the automation will be disabled and your lights will stay ON. If HA can’t see if your TV is ON or not you could use a smart plug with energy monitoring this way when the energy is above X turn binary sensor ON. Then use the binary sensor in your bypass.

Your next question is how do I create this binary sensor for the TV?

Once you have your TV plugged into a smart plug follow the steps

  1. Navigate to Settings > Device & Services > Helpers tab at the top.
  2. Click the Create helper button.
  3. Select Template and then choose Template a binary sensor.

Next, provide a Name and Device class of your choice. If applicable, you can link this template to an existing device so it appears under that device’s details.

In the State template field, add the code below, replacing sensor.current_consumption with your entity ID. This will be the current energy consumption when the TV is ON. the 85 will be what your smart plug reads so if it is 100 watts then set it to 85 and when you turn the TV OFF is should go below 85 watts.

{% if states('sensor.current_consumption')|float > 85 %}
  on
{% else %}
  off
{% endif %}

Regarding the bypass: The bypass temporarily disables the automation (not in Home Assistant UI disable / enable, but within the automation itself). When the bypass entity is ON, the automation will not trigger.

You have three options to choose from, which determine what happens when you activate the bypass:

  • Option 1: If the bypass is turned ON and your lights are OFF, they will be turned ON.
  • Option 2: If the bypass is turned ON and your lights are ON, they will be turned OFF.
  • Option 3: If the bypass is turned ON, it will leave your lights in their current state (ON or OFF).

Each option disables the automation, meaning you can manually control your lights (ON or OFF) without the automation interfering.

Additionally, there are options for a time delay and auto OFF. The auto OFF feature works in conjunction with your selected bypass option. For example, you might want Option 2’s bypass to automatically turn OFF once activated, while other bypasses may not have this behavior.

Hope this helps you.

Blacky :smiley:

Oh yeah, tracking against the TV is way better and more direct, thanks!

So if I set the TV as the entity in Option 3, without “auto Off” enabled, that means that when the TV is on, the automation is paused, and as soon as the TV is off, the automation is resumed?

I also have the same issue. I did a quick search in the script for switch.turn_off and there are 12 hits, and when I search for switch.turn_on, only 2 hits. My logic dictates that these hits should be equal, since we are turning both on and off an equal amount of times. So probably somewhere in the script we should have a switch.turn_on instead of light.turn_on. Can’t figure it out specifically since I’m pretty new to this, but yeah, replacing all the light.turn_on will fix the issue, but you will get into some other issue if you are also using lights, I guess

@jacobmovingfwd

Yep… just set the bypass time delay to same time delay you have in your lights this way when you turn the TV OFF and no motion is detected the lights will stay ON for the time delay. This way you won’t be in the dark and can exit the room or the light wont turn OFF before you trigger the motion sensor again.

Blacky :smiley:

@OverthinkingCAPTCHAs

Welcome to the community

No… this is not correct, that’s not how it works.

The automation splits all your domains into lists so if you have no light entity there will be none in the light.turn_on . Calling light.turn_on with no entity should not throw an error by default. I have tested it here many times.

HA have changed their code, I am on the latest HA and don’t have a problem. Make sure your HA is up to date.

Are you also using ZBMINI for light control and is the entity a switch?

Have you changed the entity to be Shown as and then selected Light changing it from Switch?

Please check what you are doing and the device. Make sure it has the latest firmware.

Blacky :smiley:

Thank you for your explanation! My mistake, I guess I have been using it incorrectly. I have an old lamp and I wanted to make it smart through a smart socket (Third Reality). I added it to the HA but I had no idea we can change the entity type by going to Settings → Devices and Services → Entities.

So I switched the Shown As from Switch to Light, updated the automation with the newly created entity which now starts with “ligh.”, et voila, everything works as expected.

@neoraptor123 maybe you could maybe try this as well, Blacky’s recommendations helped me!
@Blacky thank you for your patience and for your work!

I am having an issue with a single iteration of the sensor lights blueprint. I have it triggering off of a mmWave sensor, which is working perfectly. However it will not work with the night mode, I have it set to turn on at 10% with either my phone set to do not disturb or between the hours of 1am-8am. It will just turn immediately to 100% instead. I would absolutely love help to figure out what’s going on with it!