Thatâs ultimately the issue. I have a list of lights I want to just switch on (either switches or lights) to 100%, some at 50%, some at 25%. I donât need them to change brightness, but some lights I just want to come on at a predetermined level, hence the scene. The scene has each light that requires a specific intensity set to that intensity in that scene.
Ah, it wasnât apparent to me that BOTH had to be true. I just set the 21:00 time because a start time was required. All I really cared about was the 3am time. So I guess I just set the on time to 17:00 or something super early, and then control them coming on with the toggle that gets activated by the normal lights routine?
The point here is that sometimes if itâs really cloudy or overcast itâs âdarkâ inside the house before itâs actually sunset (or whatever I have the sun elevation set to anyway), so I figured I have an illuminance sensor, might as well incorporate it? 500lux seems reasonably light but I will fine tune it yes.
Is there a way to just use a scene for either or both? I donât believe I have any 3am off entities that donât require dimming, and I definitely have some that run all night that require dimming, too. I donât believe thereâs a way to set intensity per device within the automation, right? they all have to be the same level?
Thanks Blacky. Really cool blueprint, just have to figure out how to use it. Is there any way i can test it each time I make a change or do I just have to wait until the conditions are right?
Aha. I think my logic might have been faulty. I will play with it according to your guidance when I get home. On vacation right now. It could be I set you on a wild goose chase due to my ignorance of the logic behind the blueprint. If so, I apologize in advance. Anyway I will report to you next week whether I need to put my dunce cap on or not. Many many thanks for your patience.
Thank you very much for the blueprint! Itâs truly the best Iâve seen so far. I do have one question: Why does the light turn off upon restart, even though it should be within the correct time frame? Is there a setting to adjust this? (Last Status)
Hi Blacky
So I took your advice and separated these into 2 automations. What iâm finding now is that in the morning when the sunâs coming up, the lights go off, but then the illuminance sensor turns them on about 40 min later? thatâs what I didnât realize was happening as to why Iâd wake up and the lights were on. I donât get why it would turn them on if the sun was already up? I donât ambient turn off, just ambient turn on, but if the sun isnât falling, then how could it evaluate both to true to turn on the lights?
This is a bit tricky in this blueprint⌠and I am trying to resolve this.
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.
This way I can better pinpoint what is happening and can you note when you restart it in time.
This is because they are triggers and not conditions.
So
Whatâs happening is your light is turning ON when the lux level drops below 1000 lux⌠you recently increased it from 500 lux. A lower threshold might be more appropriate. At 1000 lux, even a small dip to 900 lux can trigger the light, but depending on the conditions, the level may never drop as low as 500 lux.
To fine-tune this:
Iâve noticed your sun elevation settings for the âfallingâ trigger are set quite low. Take a look at this FAQ click here for guidance on how to configure them more effectively.
Also, try observing your sun elevation and lux sensor together one evening. With your current settings, thereâs a significant gap between the two, which may indicate you donât need both triggers. In fact, if the sun trigger alone gives you the behavior you want, you might consider removing the ambient (lux) condition altogether⌠that could simplify things and resolve the issue.
I noticed youâre using round numbers like 500 or 1000. Instead, observe your lux sensor over a few evenings and take note of the lux level when lighting actually feels needed. That value will help you set a more accurate Low Lux Value - ON. You might find the ideal level is even lower than 500 lux⌠but only you can decide what feels right in your space.
Then, consider enabling the High Lux Value - OFF option and setting it to about 100â200 lux above your ON threshold. This creates a buffer (hysteresis) that helps prevent the light from toggling ON and OFF due to temporary fluctuations like storms or heavy cloud cover.
First of all, thanks for your great workâyour automation setup works really well throughout my entire house!
However, Iâm running into some trouble integrating it into my living room setup. The issue revolves around the manual wall switch (Philips Hue Wall Switch), which is also used to control the lights when the automation doesnât kick in.
The Problem
I want to integrate the wall switch into your automation, but Iâm facing a few challenges:
Bypass mode: When I use the wall switch as a bypass, it disables the automation entirely until I manually turn the switch off again. Iâd prefer not to have to manually reset the switch every time.
Example: If I turn on the lights manually during the day and forget to switch them off before bed, the automation wonât resume until I manually deactivate the override.
I donât want to implement the auto turn-off feature since that behaviour is not what Iâm looking for.
Entity toggle: This could work, but it causes a logic mismatch. If the wall switch turns the lights on and the automation (based on sun elevation) turns them off, the entity stays in the on state. This leads to a situation where the next wall switch press doesnât do anythingâbecause HA thinks the lights are still on.
My Current Idea
Iâm considering writing a turn-off script that resets the wall switch toggle back to off whenever the lights turn off (either by automation or manually). That would keep the logic flowing properly.
However, this would also double-trigger the automation:
Once when the light is turned off by automation.
Again when the script forces the wall entity back to off .
Do you think the turn-off script is a good solution? Or is there a better way to approach this use case within your automation framework?
The wall swtich isnât operating like an actual switch in Home Assistant. Whenever I toggle my physicalâactualâwall swtich, the Hue Wall Swtich will generate a generic event in Home Assistant. The event doesnât include any information about the state of the physical switch, but that something has happend. This means that I canât directly interface this switch with any light entity to simply turn it on or off.
A work around for this behaviour would be to create a template binairy sensor which toggles the state of the sensor any time the Hue Wall Switch reports an event.
What entity is this? Can we wright a script that says if this entity is ON then turn OFF? Then use this script in the Scenes - Scripts To Turn OFF
Or
Can we wright a script that toggles your wall switch and fires the event to turn your light ON if âthe entityâ is OFF (used in Lights - Switches - Scenes - Scripts) and then another script to fire it to turn you light OFF if âthe entityâ is ON (used in Scenes - Scripts To Turn OFF)?
There is a way just need to find what works for you.
Thank you for the incredible work. Iâm successfully using it across a series of rooms. One use case Iâm trying to implement involves using the bypasses when I arm my alarm every night. I want to set the living room lights to red. I successfully set up the bypass with the current state and enabled the lights.
However, Iâm encountering an issue: when I disarm the alarm, the blueprint recognizes that the boolean value has changed to false, updates the color, and the lights stay on. I would prefer to have the lights turned off instead.
So my question is: Am I configuring this incorrectly, or is there an underlying condition or assumption that the lights should stay on? Iâve included my YAML for the blueprint below.
This could be that your sun elevation is within the falling and rising set points when you turn the alarm OFF. I also noticed you have a time turn OFF. Not sure if this is what your after.
Try adding your input_boolean.alarm_mode to the Trigger - Entity State and use the OFF State. Now when you turn alarm OFF the light should go OFF.
PS: You could also use nightlights and change the colour to red when you turn ON your alarm and not use the bypass. Here is an example. Copy paste it in but make a copy of your YAML settings before so you can revert back to your original settings if needed.
Question for you. Have you used your blueprint with Caseta switches. The api used by for access doesnât allow setting an initial brightness. Are you aware of any strategies to integrate Caseta into the blueprint?
No problem, I thought that may help you for what you said along with your YAML.
I am a Shelly man so most of my stuff is this. I do have a question though. Is your Caseta switch a âswitchâ in HA? To check this look at the entity ID. Example; this is one of your lights, light.multi_color_bulb_2 you can see it is a light⌠If your Caseta is a switch that then turns ON a light (light bulb) when you turn ON a switch in HA you donât send the same data you would to a light. Hope this makes sense.
Itâs a dimmer and the most reliable device I have found. It uses a low RF frequency (900 MHz) and a controller with an API for management. Iâm in a densely populated area, and 2.4 GHz is problematic for IOT. I manage Zwave/Zigbee devices successfully, but I must re-interview occasionally.
When you manually press on without any automation, the lights crank up to 100% (The one poor characteristic, IMHO). A direct light_on call to the switch entity will update brightness and appear like it was set from the beginning. Unfortunately, light groups will NOT set the brightness on the initial press and must be the direct entity.
My developed code is less flexible than your blueprint. I purposely execute a light_on call when an entity trigger occurs. I just tested the SMART light blueprint and it doesnât. Iâm assuming your code is more efficient than mine.
Maybe if you go into the entity settings of the switch and then change the Show as from switch to light. I think it will create a new entity and you may also need to change the entity in the blueprint to the new light one. The entity ID will go from switch.XYZ to light.XYZ. You need to select the light one.
Note: I not 100% sure if this will work so maybe do a backup of your HA first and if it doesnât work you can go back.
Unfortunately, the device integration automates the switch => light helper for those searching for a tolerable workaround.
The Caseta switches support âtrimâ function, allowing you to adjust the high and low brightness. I have used @Blackyâs blueprint and mirrored the trim brightness against the min and max in the circadian feature. This prevents the lights from blinding you, but it still must scale down to the setting for the appropriate time.
Maybe if you go into the entity settings of the switch and then change the Show as from switch to light. I think it will create a new entity and you may also need to change the entity in the blueprint to the new light one. The entity ID will go from switch.XYZ to light.XYZ. You need to select the light one.