hass-circadian_lighting
hass-circadian_lighting copied to clipboard
Suggestion: circadian light entities
Instead of having separate switches for circadian lighting and the actual light, I like to create template lights that transparently include circadian lighting. My implementation looks like this:
switch:
- platform: circadian_lighting
name: Office
lights_ct:
- light.office_light
light:
- platform: template
lights:
circadian_office_light:
friendly_name: Circadian Office Light
level_template: "{{ state_attr('switch.circadian_lighting_office', 'brightness') | int }}"
value_template: "{{ states('light.office_light') }}"
turn_on:
service: script.circadian_lighting_office_turn_on
turn_off:
service: homeassistant.turn_off
data:
entity_id:
- switch.circadian_lighting_office
- light.office_light
script:
circadian_lighting_office_turn_on:
sequence:
- service: homeassistant.turn_on
data:
entity_id: switch.circadian_lighting_office
- service: homeassistant.turn_on
data_template:
entity_id: light.office_light
kelvin: "{{ state_attr('sensor.circadian_values', 'colortemp') | int }}"
brightness_pct: "{{ state_attr('switch.circadian_lighting_office', 'brightness') | int }}"
This solves multiple issues, most importantly it will guarantee that the lights come on in the correct state and that they can be turned off properly. It also makes it easier to include them in automations, groups, or whatever else people usually want to do with their lights.
The example above could probably be improved a little by making the turn_on script more generic, however it is still quite cumbersome to define these entities for every light. So I was thinking, would you be interested in adding something like this to the component?
It would be even greater if the virtual light would disable circadian lighting when colortemp or brightness have been set explicitly, until the light is turned off again.
So this circadian light entity would pass turn_on, turn_off, etc commands to the actual light, in addition to turning on/off the circadian adjustments? This is an interesting idea and may solve some issues. The only real negative is that if a light was blue for example, then turned off, when turned back on it would be set to the circadian values rather than back on to blue. 🤔
Thinking about it, my dream would be to have a light entity that exposes all the attributes of the actual light like brightness, rgb_color, etc plus an additional attribute circadian: true|false
, so you could do something like this:
service: light.turn_on
data:
circadian: true
Thinking about it some more, it would be great if the component could auto-detect whether the underlying light supports rgb, color_temp, xy, ... and automatically pick the best option.
Thinking about it super much, if all of the above is possible, you could simply add the circadian attribute to all lights with a one central config entry. Circadian lighting would be just another feature of all lights, in addition to the features they have out of the box.
I'm just getting started with Home Assistant, so I have no idea how feasible this is.
This actually would be super awesome! Is there any update on this? Or something one can help with maybe?
I am willing to pay/donate for this feature.. Been bashing my head for months trying different things, none quite work as well as this.
So I think duplicating all light entities is a bad idea that will cause a lot of confusion, I don't think that's a good solution. The idea of CL automatically being available for all lights is a good idea however some users still want to be able to have different settings for different lights so that would have to be handled somehow. The best solution would be to extend the light component directly to allow for a circadian parameter in all lights, but that would require being a native component.
What I could do that might be better would be to create a circadian_lighting.light_turn_on
service that would turn on light(s) to the correct settings, however this wouldn't work for the front-end without a lot of customizations. The reality is that no matter what approach is taken HA doesn't really have any provisions for a component like this and the only good solution is to integrate natively but I've reached out twice about that and there doesn't seem to be a whole lot of interest for that.
Shame, but I'm sure they have a road map to try and stick to as well.