The following works as expected if done from the UI, see examples:
if I switch on and set 50% brightness, then 153 mireds (6500K) only the cold one switches on, at 100% brightness, which is correct
if I switch on and set 50% brightness, then 333 mireds (3000K) only the warm one switches on, at 100% brightness, which is correct
if I switch on and set 50% brightness, then 210 mireds (4750K) both the warm and cold ones switch on, at 50% brightness, which is correct
Now, there is still something I don’t understand. If I change brightness only form UI, the behaviour is not logic. For example, if I’m in any state, then I change brightness, whatever is the temperature, the warm light get switched on at full brightness, the cold one gets switched off. If I then change the temperature, the brightness of each of the two lights goes back to correct relative values, but with overall brightness at 50%.
I think this is due to the template not having the temperature attribute, in fact if I try the following in template on the developers tools, I get None:
When off it gives an error “Division by zero” (which is something that should probably be managed later), otherwise it gives the temperature in kelvin. I modified to convert in mireds and now the template light has the color_temp attribute and current state of the light. When changing the temperature on the UI the behavior is still not correct, but I think this can be related to the same issue (kelvin vs. mireds).
Will let you know, thanks for the good hints so far!
I’m happy to report that the template light works as intended now.
The key was to use color_temp everywhere and use mireds in every formula.
Now setting brightness and temperature work, included the fact that due to the nature of how this light is made, the extremely warm or extremely cold can’t be set at more than 50% brightness. Also, since the warm white is at 3000K or 333 mireds, warmer whites cannot be achieved, but the max_mireds attribute is equal to 500. I did not find a way to correct this
Here is the config:
2022-03-04 17:41:53 WARNING (MainThread) [homeassistant.helpers.template] Template warning: 'float' got invalid input 'None' when rendering template '{{ 1000000/(((state_attr('light.livingroom_light_01_white_warm', 'brightness')|float*3000 + state_attr('light.livingroom_light_01_white_cool', 'brightness')|float*6500)/((state_attr('light.livingroom_light_01_white_warm', 'brightness')|int + state_attr('light.livingroom_light_01_white_cool', 'brightness')|int)))) }}' but no default was specified. Currently 'float' will return '0', however this template will fail to render in Home Assistant core 2022.1
2022-03-04 17:41:53 WARNING (MainThread) [homeassistant.helpers.template] Template warning: 'float' got invalid input 'None' when rendering template '{{ 1000000/(((state_attr('light.livingroom_light_01_white_warm', 'brightness')|float*3000 + state_attr('light.livingroom_light_01_white_cool', 'brightness')|float*6500)/((state_attr('light.livingroom_light_01_white_warm', 'brightness')|int + state_attr('light.livingroom_light_01_white_cool', 'brightness')|int)))) }}' but no default was specified. Currently 'float' will return '0', however this template will fail to render in Home Assistant core 2022.1
2022-03-04 17:41:53 WARNING (MainThread) [homeassistant.helpers.template] Template warning: 'int' got invalid input 'None' when rendering template '{{ 1000000/(((state_attr('light.livingroom_light_01_white_warm', 'brightness')|float*3000 + state_attr('light.livingroom_light_01_white_cool', 'brightness')|float*6500)/((state_attr('light.livingroom_light_01_white_warm', 'brightness')|int + state_attr('light.livingroom_light_01_white_cool', 'brightness')|int)))) }}' but no default was specified. Currently 'int' will return '0', however this template will fail to render in Home Assistant core 2022.1
2022-03-04 17:41:53 WARNING (MainThread) [homeassistant.helpers.template] Template warning: 'int' got invalid input 'None' when rendering template '{{ 1000000/(((state_attr('light.livingroom_light_01_white_warm', 'brightness')|float*3000 + state_attr('light.livingroom_light_01_white_cool', 'brightness')|float*6500)/((state_attr('light.livingroom_light_01_white_warm', 'brightness')|int + state_attr('light.livingroom_light_01_white_cool', 'brightness')|int)))) }}' but no default was specified. Currently 'int' will return '0', however this template will fail to render in Home Assistant core 2022.1
Another possible solution is to create two helper variables that control the color and temperature.
The input of the sliders update the helpers variables first. Then the values for the warm and cold white is calculated from the helpers.
Hi. Trying your code for myself, but seems that сode needs editing now. HA says that there is error in "data: value: " blocks. Have you edited the code for yourself?
Seems to be working well for me. @gaggio code had served me for a year pretty well but would return log errors I was never able to resolve. My suspicion is that with a more talented person than me, either one of these solutions could work well.
This worked well for me (after fixing a couple small errors on the syntax).
However it didn’t let me set the LED strip to max power, e.g. CW 100% + WW 100%, or anything above 50% total power.
I created a new template that solves the original problem in addition to unlocking the option to set the strip up to full power.
The problem is less trivial than it can sound, here is my blog post with a detailed explanation, link to the template code and instructions.
@gfra firstly, I just wanted to say what an incredible job you did with writing this post. It is precisely what I wanted/needed for my shelly RGBW2 LED lights with CC/WW lights.
I do have a question/favour to ask. I’m hoping you can help. I’m trying to use the Adaptive Lighting integration to control the Template Light I’ve created using your code. However, it’s not working. I’ve done some troubleshooting and it seems that there is a few problems when calling the services for brightness and colour in Developer Tools and targeting the Template Light.
I initially through this was a problem with the Adaptive Lighting code and I’ve documented what I’ve found as much as I can in their GitHub here. So I’m going to direct there for all the logs etc. I’m hoping this is a quick fix, and appreciate any suggestions for any others here as well. Thanks!
To further add to this, I think the issue is that when calling the turn_on service for the Template Light and attempting to set brightness and colour temp at the same time, the service call fails if the settings are out of bounds for the template light
Happy to know you found it useful
I’m not familiar with AL, but my bets are on the issue with the out of bound values you described.
At the moment some color temperature parameters are hard coded in the template. I guess it’s possible that something breaks if values outside the range are used.
Making the template parametric for any value of color temperature would require a couple of more input helpers I guess. Not the cleanest solution, maybe it’s worth spending the time integrating the whole thing into a native component.
However the fact that HA still uses mired internally for color temperature is a bit of a show stopper imho.
Thanks for replying and sharing your thoughts on this @gfra. Making this into a full-blown parametric integration is beyond me at this stage. But I was wondering if - as a short term solution - we could make some small tweaks to the yaml for the template so that any out of bounds values are captured and set to their max allowed for that temperature/brightness combination? But I need help with the syntax and logic.
I guess one parameter would have to take precedence of the other in that decision tree? Maybe temperature could always have the highest priority and brightness must follow?
Hi, I did a couple of tests and updated the template, see this commit or the repository.
Now if you force an out of bound color temperature (e.g. calling the service from dev tools) it defaults to the upper or lower limit, depending if you overshot high or low.
This behaviour should be now consistent with how other CWWW lights work (e.g. my shelly duo works like that).
In the previous version the template was just throwing an error, now it sets the max/min temperature. Anyway, it would probably be a good idea to always respect the limits used by the slider in the “light: turn on” HA service (2000K - 6500K).