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

Blueprints Exchange
, , , ,
2646

@muratcesmecioglu

Welcome to the community.

If the touch sensor is used in the bypass and it is night mode then it will control the night mode lights (LED). I not sure what bypass option your using but you may have to create another automation that when you are in night mode the tough sensor turns ON your ceiling light.

I assume your touch sensor has an ON / OFF state. That is when you touch it is becomes ON and when you touch it again it is OFF. Depending on what condition you are using for night lights will depend on how you set this up. Example if time is used for night lights then you could use this blueprint again, copy paste your touch sensor into the trigger set your ceiling light then use the time condition (not night light time condition) to be the same as night lights. Now your ceiling light will turn ON / OFF with your touch sensor at night time only.

Blacky :smiley:

1 Like
2647

@Stefan_Fasth

Thanks for your YAML.

You are using a switch in dynamic lighting. Dynamic lighting only supports a light entity not a switch.

Please disable dynamic lighting as your switch will not have brightness control and it will only be ON / OFF.

Blacky :smiley:

2648

@wagnerks1990

The trigger you are seeing is because you have your sensor.bedroom_mmwave_ltr390_light is in the Ambient input and this option is disabled. If you don’t what to use this option and you don’t want to see this entry then remove your sensor.bedroom_mmwave_ltr390_light sensor in Ambient condition. Nothing is wrong it is just doing what you asked.

Because you are using dynamic lighting option 1 if you adjust your lights brightness then if it is out of the range (your settings) it will readjust them back to dynamic lighting. During nigh lights if you adjust your light they should stay as is until they go OFF and turn back ON again.

Blacky :smiley:

2649

Thank you for your reply. I think i will add another automation to bypass.

I’m thinking to implement double touch feature to touch sensor for enable/disable light automation.

1 Like
2650

Of course! Thanks (however I did work for like a month or so!)

1 Like
2651

I’ve got the same issue

and the same workaround

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

2652

Seems like it’s working now, thanks!

1 Like
2653

@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:

2654

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

2655

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!

2656

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…

2657

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

2658

@TheMinimalist

I did a FAQ for this now see above post.

Blacky :smiley:

1 Like
2659

@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:

2660

@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:

2661

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?

Screenshot 2024-11-15 at 08.48.09
Screenshot 2024-11-15 at 08.48.093104×1974 561 KB

2662

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

2663

@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:

2664

@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:

2665

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!