Reverted some changes back because of unexpected behavior with the workday and person sensors.
Having multiple sensors were treated like ‘and’ not like ‘or’ and required all all of them to pass the ‘on’ or ‘home’ condition torun the automation.
If anyone has an answer for this please let me know or contribute to the repo!
To get this same functionality you can use groups. Unfortunately a group of person is consider legacy.
For the workday sensor you can easily create a group of binary sensors, and they don’t even have to be a specific workday sensor. Or you could template your own.
Bonjour, j’ai mis en “start time” mon alarme de mon telphone (next_alarm_pixel_6a) mais cela n’a pas déclencher le blueprint…
Un idée ?
Merci
Are there any traces for the automation that was created from the blueprint?
To anyone interested, I’ve also create a sunset blueprint.
This solution works perfectly! Thank you so much!! it’s exactly what we needed. It’s also very user-friendly, especially when compared to other popular blueprints available.
In our setup, we use two automations. The first one starts 15 minutes before our alarm and ends by playing the radio on our speaker. The second automation begins at the alarm time, gradually increasing the brightness of the lights while the radio is playing, and concludes by turning off the radio.
Thank you for the easy to use blueprint! When I was playing around with this blueprint, I was wondering if it could be possible to change colors as wel when the brightness is changing; like the ‘sunrise’ style in the Hue app?
The color is changing via the kelvin settings. It would only be warm to cold hues and not any other colors.
When using the automation (and script), my light starts with a very high brightness - although I am using the default values in the BP.
Any ideas @steriku ?
Secondly would you mind adding a version to the BP’s description? Then we could easily tell if we are using the most recent version.
@chris400 does your light support color_temp_kelvin? You can see this in the developer tools menu on the state tab.
Yes, it does. It’s a hue, using the official bridge and integration.
min_color_temp_kelvin: 2000
max_color_temp_kelvin: 6535
min_mireds: 153
max_mireds: 500
effect_list:
- "off"
- candle
- fire
- prism
- sparkle
- opal
- glisten
- underwater
- cosmos
- sunbeam
- enchant
- sunrise
- sunset
supported_color_modes:
- color_temp
- xy
effect: null
color_mode: null
brightness: null
color_temp_kelvin: null
color_temp: null
hs_color: null
rgb_color: null
xy_color: null
mode: normal
dynamics: none
friendly_name: Lampe Schlafzimmer Decke
supported_features: 44
It does actually change the color and brightness while running the automation. But it does start with an way to high brightness
Unfortunately, I don’t have a Hue bridge/bulb to test with. Have you looked at the trace for the automation created by the blueprint?
When developing, I also created a template sensor to verify it was doing what I thought it was supposed to be doing. This allowed me to create a history graph of the brightness attribute and view as a percentage.
{{ (state_attr('light.master_lamp', 'brightness') | int / 255) * 100 | int}}
Thx for the suggestions.
I have created a template sensor and will analyse the trace.
I love this blueprint, use it constantly.
I’d have 2 requests in case you plan future update.
First one is to add the custom conditions possibility. For example, sometimes i go to bed outside typical night time and I still use the alarm, but there is no real need for lights to go on for me. This could technically be solved with the template sensor and merge with workday sensor or person sensor.
Second one is to add the possibility to select lights by advanced selector (instead of a single entity, allow selection by area or, more and more popular option with labels).
Love to hear it is useful to more people than just me! I’ve had requests for different conditions multiple times and decided it was time to look into this.
I’ve updated the blueprint so that the conditions are now fully user defined and have removed the workday and person conditions. Workday and Person can be added back in this is something that you use.
If you are updating and you are using the workday and person condtions you will need to update all automations base off this blueprint to include them again.
I did briefly look into using the new advanced picker for areas and labels and this would require a bit more thought as entities change to targets and need to be handled differently in condtions and possibly when passed to the script. This may come in a later update. For now just use light groups.
Thanks everyone for your feedback!
According to the selector for target, it seems it is possible using target option. But I don’t know what is the content of it.
It’s not just about the selector. It’s not really compatible with how the automation and script are coded up now. With a light or light group I can access its properties such as brightness and kelvin and use the light/group as the state of the these items.
If I use the target, the referencing different and stored in a list to be iterated through. Each entity has it’s own state to be managed or assumed from one of the resources. You now need to use templates to get the properties of each entity for the condition and current state of brightness and kelvin. Not saying it isn’t possible, it will just take some time to research and implement.