I just wanted to say thank you for this versatile node. I have spent a lot of time these days with it which has raised the look of my dashboard to a new level. My impression is that far too few people here have discovered/tested it.
I furthermore have found a smaller issue which I would like to share with you. It's about the color temperature slider which other than given in the node settings has a lower limit of 2000 K. Please have look at the figure attached. I have set the temperature minimum value to 1000 K but cannot move the slider further left than 2000 K.
Actually I have led-strips here which go down to 1800 K which I cannot set to this value.
One more point (not very critical) is that the payload-outputs never give the exact value which I have set as minimum or maximum. For the example given above the most left slider position (i.e. minimum value) gives 2000.2899... (should give 2000) and the most right slider position (i.e. maximum value) gives 6489.3646... (should give 6500).
I have to dig deeper into the library to see if this is really a hard limit perhaps due to some conversion algorithms (as the actual slider show up with 1000k temperature. But without modifying the library there is probably no quick fix. I already had some trouble with the temp / brightness combination and contacted the author of that wonderful library. He mentioned that the temperature is a quite simple representation of the base RGB color ... (I found a similar connection in the much worth implementation of a temperature picker in the Home App (I expected more Apple )
This is due to the fact that the base of iro.js is rgb color model. So all input manipulate the RGB values and will be converted to the selected output format. SO in your case tempKelvin > RGB > tempKelvin. with expected accuracy issues as on the top side. Again this is how iro.js works. On the top I expect these kind of values as the "air" gets thinner in the whites / blue
So this post is only a update - i will look into that ASAP
and in the source the min is defined as expected.
But before that ... I have to bake some pizzas for the family! Stay tuned
The problem is that iro.js works with converting everything from and to RGB. Where the conversion from Temperature to RGB is straight forward in all examples I could find (How to Convert Temperature (K) to RGB: Algorithm and Sample Code | tannerhelland.com) the conversion from RGB back to temperature is done in a linear approximation loop comparing red and blue. But below 2000k blue is constant 0 AND red 255!
So in the range below 2000k only the green component becomes relevant. The green component is neglected in all algorithms I found and the output simply limited to 2000k. So I took special care on the green component below 2000k. I could do an approach over the CIExy values but these are highly biased on the white point and gave me inaccurate results (see the ticks on every value marker). The curve is showing the "perfect" black body (should not be difficult but not worked with all "converters" I had as the apply a gamma value):
During research I found a site with pretty nice information on everything around color and leds. (you even can simulate why #FFFFF don't give you white light and the CRI of RGB led is so bad (LED Spectrum Simulator | Waveform Lighting) and many other resources.
was not expecting that this would be so challenging... Although reading your answer several times it's hard to understand. The world of digital colors was always a closed book from my persoective. However, you seem to understand what's going on here. Fortunately. I will test your update as soon as I am back home from my vacation. Greetings from the Harz...
Hi Christian,
back from vacation I tested the new version focusing on the temperature slider. Works really good, so all fine for me. Thanks again. It works all well from 1000 K to 10000 K (my actual test setup).
But to be honest, I am afraid I did not understand why or where a color conversion should take place at all. I understood that this was your basic point you struggled with. In my scenario I simply feed the MQTT-out node with HSB values OR color temp values using the respective sliders. Zigbee2Mqtt does the conversion internally, and simulanously reports back the respective values in the MQTT-in node.
So I use the sliders as pure sliders separately for HSB and alternatively for color temp. I hope you understood my points...
But back to the point where we started: The temperature slider now works as it should. So, feel free to release
The HSL if probably the best color representation for most usecases (HSV-Farbraum – Wikipedia) the lightness is defined as relative in 100% where brightness is mostly device dependent in byte 0-255 (or 0-1023 in 10 bit or ...)
Compared to RGB or other the HSL values are human readable. If you remember how the color circle looks like you can "read" the color by ° on the circle, the saturation (distance to the center) and lightness / brightness in 100% on a slider. Changing one value only effects that component and not the others. Try this with RGB! Changing one color intensity effects the brightness and saturation too (You can test this with a color picker setup with the picker circle (H+S) and a Lightness slider. And than add R + G + B sliders. if you move any sliders you get what I mean.
In an ideal world all lights should be able to receive HSL and do the conversion into RGB or RGBW just before driving the LEDs. Because only the "bulb" knows the wavelength and brightness of the build in LEDs and can tune them correctly. I have a project building myself a light spectrometer to calibrate my LEDs on my backlog but to be honest no time and no real need. I mostly tune my LEDs interactive with your eyes so an accurate screen representation is not so important.
Zigbee2Mqtt does a good job converting HS (+B) to device dependent format. (Only one output format can be selected with multiple components · Issue #10 · Christian-Me/node-red-contrib-ui-iro-color-picker · GitHub). There is a chance that device dependent gamma and white point values could be taken into consideration either by the bulb (best) or Zigbee2mqtt. The CIExy was developed for lighting purpose so it is understandable that bulb manufacturers stick to it but it brings no advantage over the HSL model and x and y have to read simultaneously on a chart (see above)
iro.js is not a color conversion tool. It only does it to link the different models together as accurate as possible internally based on HSV. The light temperature is only a "side value" transferred from HSV to RGB to Temperature and back. I haven't found better (implemented) algorithms as the linked above. The conversion from temperature to RGB is then quite crude (linear approximation loop). If someone need a color converter the chroma.js (inside this node) does a good job (but with the same crude temperature algorithms i will updated soon).
For tuneable white leds (a mix of warm white and cold white leds) you should choose brigness + temperature (and not HSL) in your system. Only the bulb (like this one I use) knows the mix of cold and warm white leds.
I implemented special code to pass the conversions as good as possible and liked together two instances of iro.js for brightness and temperature (see tuneable white example)
I use this for my DIY tunable LED strips:
But again. I still have have to measure the light intensity of the 2.800 and 7.000°K LEDs. As cooler the white is there is less phosphor involved and the LED (which are actually blue) is more effective = brighter = more lumen per watt. And you have to take into account that the midpoint (all LEDs on would be the brightest) ... All complicated stuff as if you don't take care the temperature slider effects the lumen emitted by the strip light / bulb.
as always, I am deeply impressed by your answers and your efforts. There is nothing I can further add/contribute. Just feeling confident that this contrib-node (not the only one btw) is in the right hands. With the latest version 0.1.7 my issues are solved.
)
