Dashboard layout problems

[Simon01011]

Hi Chris!

Thank you for this great color picker. Something that is very useful!

I try to use this color picker for my RGBW led strip. In fact, I use two color pickers, one for RGB (hue and saturation sliders for the red/green/blue leds) and one for W (value slider with all RGB values the same between 0 and 255 for the white leds)

The layout looks like in the picture Question: why do I have to set the components direction to "vertical" if I want to have horizontal sliders like in the picture? Maybe you should write "stacking" instead of "direction" 😃 The size in the picture is set to 6x2, but the sliders do not fill the entire width That would be nice. And a single slider does not fill the entire height of the cell. I supposed two sliders should fill a cell of 6x2 in a way that one slider has actually a width of 6 and a height of 1. As a side note: for people with big thumbs like me that would be easier to use 😊

If I use the horizontal direction the picture looks like below: What do I have to do to get sliders with full height? The size of both nodes was set to 3x6, but as you can see they do not fill the entire box.

So again, thank you for your work. If I can help testing, don't hesitate to ask!

[Christian-Me]

Thank you for your feedback.

A) The direction is intended indicate how the components are stacked. Vertical (default ) means that they are stacked like a burger ;) - The naming is given by iro.js to have the documentation in line. perhaps a little bit irritating, for me too. Have to think about it. But to label the parameter "stacking" is a good idea!

B) I tested it with always with an label and yes there is room left even if indent is set to 0 and the label is empty. Fixed in next release (or directly from github)

C) I designed the widget that auto should work in most cases (filling the group width and determine height necessary to fit all components.

Here 3 sliders in one widget in auto mode (horizontaly stacked) And yes if "rotated" there is space left empty: Should be fixed:

D) RGBW LEDs : I use the HSV color model to drive my RGBW LEDs - in this way I can use the combination either a color weel with a vlaue slider, color box with hue slider or three sliders in one widget. My (own) firmware converts HSV to RGBW quite nicely. (can share the C-code for this). if you like to use the separate slider for your white LEDs best to set the output to single value number. The latest (github) version have new input payload handling for single values (see readme.md)

Pushed the latest version on github. Perhaps you can install it from there: npm i Christian-Me/node-red-contrib-ui-iro-color-picker

[Simon01011]

Thank you. The dashboard now looks like

The corresponding flow is (almost the same flow twice to test horizontal/vertical layout)

Observations:

1. Filling the group now works as expected in the direction of the sliders 👍
2. And also 👍 for "stacking" 😃
3. RGBW mode: I have shellies (RGBW2) working with RGB values, white value (0...255) and gain (0...100). So I use two sliders with RGB output. In addition I have one value slider for white (set to single output "red") and one for gain (set to single output "value"). Almost works, see next

So, here come the problems

1. I only tested so far on a computer with the mouse. If I drag my RGB hue slider (the upper or left one) to the top/right, it sometimes jumps to the bottom/left. This does not happen, if I drag it to the bottom/left. It happens only if I relese the mouse button while dragging the slider to the end. If I drag it to the end, do not move the mouse and release the button, it works (i.e. does not jump to the other end). Might be some rounding error in the calculation?

2. A similar thing happens to the gain slider. At flow start I inject yellow (merely to distinguish it from white and to make it look like a dimmer). If I drag the slider to the bottom/left so that the value is zero, the color gradient changes from black-yellow to black-white. Even re-injecting the yellow color does not change it back.

Wishes: Filling the group perpendicular to the slider direction would be nice. Actually having the sliders distributed equally if two are used. For example In group "Slider v" for RGB to have them fill the given vertical space symmetrically.

[Simon01011]

One thing I forgot: whenever I restart node-red, I get in the console:

beforeEmit:  {
  socketid: undefined,
  state: '#ffff00',
  kelvin: undefined,
  value: undefined,
  enable: undefined
}
beforeEmit:  {
  socketid: undefined,
  state: '#000000',
  kelvin: undefined,
  value: undefined,
  enable: undefined
}
beforeEmit:  {
  socketid: undefined,
  state: '#ffff00',
  kelvin: undefined,
  value: undefined,
  enable: undefined
}
beforeEmit:  {
  socketid: undefined,
  state: '#000000',
  kelvin: undefined,
  value: undefined,
  enable: undefined
}

Seems to come from my inject nodes...

[Christian-Me]

First ... your last Message:

These are console log I left in for debugging the state data on backend feature. You can ignore them as I think the initial problem is solved. You should see them every time you or the dashboard send something to the widget. (removed the console.log)

To your observations / problems

1) Horizontal hue slider. Actually the hue is a circle 0-360° (in reality it is not but a common approximation) so pure red is at the beginning and the end of the slider at 0°. Depending on your output format this can cause problems because iro.js can't determine which red it should indicate if you send 255,0,0 and it picks 0°. Secondary it is a dashboard "thing" to update ALL connected clients , even the one who sent the data. have to think about a solution here. So I filter out the bouncing messages if they match the sent message. Hole this helps and does not filter out important updates - I left in debug messages to be able to see when various filter conditions kick in when a message is received.

2) This corresponds to 1) as if a "value" (gain?) is applied purely the color information may be lost depending on your output format. by ignoring backloop messages this will be avoided (but this don't work on other connected clients as the take in all messages. But reapplying the color works on my side.

1&2 has a lot to do how iro.js works. i.e. a value of 0 resets the color information. I have a similar problem with a value and temperature slider combined as temperature and value is not connected as I like it to be.

To your your whish: I don't know what you exactly like to see. I personally like the extra spacing between widgets. Components within a widget stay closer together as they represent a single color. Perhaps i can make the css parameters spacing, slider width and corner radius available via ui_control messages?

updates are on github

Chris

[Simon01011]

You seem to have a lot of free time during the nights 😄

1. Yes, I see the point, mapping a circle to a line has of course one point of discontinuity. But I cannot see any filter message. And the behaviour is still the same. But I can live with that, if math tells us it is okay 😁
2. Gain is (in shelly language) the effective brightness of the led strip. So it seemed reasonable for me to have a slider going from black to yellow reflecting this brightness. I tried it (see video below) with a switch node detecting "rgb(0, 0, 0)", setting it in a change node back to "rgb(255, 255, 0)" and feeding it back to the picker node. As you can see on the bottom of the video the output value is passed through as "rgb(255, 255, 0)", but the slider does not change... I initially thought that capturing "rgb(0, 0, 0)" and setting to "rgb(1, 1, 0)" prevents the slider to change from black-yellow to black-white...

Regarding my wish: with some gimp-magic I tried to show what I mean: On the right is my favourite appearance with the sliders centered inside there box, so that they are centered in relation to my separate label fields. For me it looks/feels better. But that's of course only my feeling and there are for sure many people around who have the contrary feeling. That's life. But maybe a checkbox that says "center sliders in box"? Though might not work if size is set to auto, don't know... Or a checkbox with "distribute sliders evenly in box", so that in my case the space between the sliders is the same as to the edge of the box.

But ignoring my little worries and wishes it's a great node and far better than my previous implementation 👍

[Christian-Me]

Hi ... The only time left over until someone invents the 30h day. (or during boring video conferences)

You find the debug messages in the debugger (Developer tools) in your browser:

1) the jump form 360° to 0° or for RED=255 to the beginning of the slider should be solved (in the emitting dashboard) simply by ignoring the feedback from the backend 2) Strange I do the same and the injected yellow colour value stays if the value (gain) changes (as long as you do not reload the browser if you have only value output. If you have an output containing colour information (RGB HSV ...) the colour data is persistent). The output data is the data the backend stores and replay on new connections) - So I would uses HSV Output if you single S or V Sliders 3) I will work on positioning the Label nicely and consistent to default dashboard widgets. I will address label for vertical sliders too. For v-align = center or top (default) we will need a config parameter (don't know if I like to add another option in the config dialog as it is already quite crowded (perhaps a third tab for all the fine tuning options like slider width or padding). 4) there are so many Features I like to add ... Custom sliders, multi Color pickers and many more ...

Perhaps npm did not installed the latest version? ... i pushed to version 0.0.5 perhaps this blocked the update

[Simon01011]

So you are in a boring video conference right now? 😁

Ah, the debugger in the browser, I thought you meant the output in the console window after starting node-red

Seems like I have a problem with the version. Your github page shows 0.0.5, then I see 0.0.3 here (https://www.npmjs.com/package/node-red-contrib-ui-iro-color-picker) and if I do a npm i ... and list the modules I get 0.0.4. Confusing to me as I am not really a programmer comfortable with npm

I hope I find the time on the weekend to test a little bit more

[Christian-Me]

I have not transferred the latest version to npm - this is where node-red gets the nodes when you use the palette manager or npm i node-name To install a node from github directly you have to use: npm i Christian-Me/node-red-contrib-ui-iro-color-picker from your .node-red dir and restart node-red

[Simon01011]

Sorry, but I'm not a programmer as I said. Forgot that I have to install it from github...

Installed without error message, but restarting node-red gives me

21 May 12:58:00 - [warn] [node-red-contrib-ui-iro-color-picker/ui_iro-color-picker] SyntaxError: missing ) after argument list (line:415)
21 May 12:58:00 - [warn] ------------------------------------------------------
21 May 12:58:00 - [info] Einstellungsdatei: /home/debian/.node-red/settings.js
21 May 12:58:00 - [info] HTTP-Statisch: /home/debian/.node-red/public
21 May 12:58:00 - [info] Kontextspeicher: default [module=memory]
21 May 12:58:00 - [info] Benutzerverzeichnis: /home/debian/.node-red
21 May 12:58:00 - [warn] Projekte deaktiviert: editorTheme.projects.enabled=false
21 May 12:58:00 - [info] Flow-Datei: /home/debian/.node-red/flows_debian.json
21 May 12:58:00 - [info] Server wird jetzt auf http://127.0.0.1:1880/ ausgeführt
21 May 12:58:00 - [warn] 
---------------------------------------------------------------------
Die Datei mit den Flow-Berechtigungen wird mit einem vom System
generierten Schlüssel verschlüsselt.
Wenn der vom System generierte Schlüssel aus irgendeinem Grund
verloren geht, kann die Datei mit den Berechtigungen nicht
wiederhergestellt werden. Sie muss dann gelöscht und die
Berechtigungen müssen erneut eingestellt werden.
Es sollte ein eigener Schlüssel mit Hilfe der Option
'credentialSecret' in der Einstellungsdatei vorgegeben werden.
Node-RED wird dann die Datei mit den Flow-Berechtigungen
bei der nächsten Übernahme (deploy) einer Änderung erneut
verschlüsseln.
---------------------------------------------------------------------
21 May 12:58:00 - [info] Warten auf Registrierung fehlender Typen:
21 May 12:58:00 - [info]  - ui_iro-color-picker

So there is this syntax error in the first line. Node-red did start, but it complains about missing node type "ui_iro-color-picker". What can I do?

[Christian-Me]

Ups sorry ... please try again to get version 0.0.6

[Christian-Me]

Next timer you can uninstall with npm uninstall Christian-Me/node-red-contrib-ui-iro-color-picker and install the npm version via palette menu (that is why I'm cautions pushing updates to npm to fast)

BTW I'm not a programmer, too - I'm an architect with an old passion for coding ... but this is a total different story ;)

[Simon01011]

Yeah, those are the interesting stories 😀

Everything works now, thanks a lot! 👍

So, from my point of view, this issue can be closed

[Christian-Me]

cool, than I can push it to npm - That others can play with it over the weekend.

You can always reopen it or open a new issue if you like. I'll inform you if I've got further things to test - if you don't mind.

[Simon01011]

Sure, no problem 😃

[Christian-Me]

Hi @Simon01011, I fixed a lot off issues and picked some ideas from your wish list 👍 If you like you can give version 0.1.0 a try (install it from my repo)

[Simon01011]

Hi!

I'm sorry, something is going wrong. I uninstalled and installed with npm install Christian-Me/node-red-contrib-ui-iro-color-picker. The palette shows version 0.1.0. Node-red was restarted.

But there is no placement option underneath the label. There is an initial color picker. But that in turn does not work as expected. This results in a black and white slider (see last picture, third slider from top) ... And the RGB slider is broken as well. Configured as before like: This results in these sliders (the both on top): I'm really sorry, but it seems something got mixed up. But I'm sure you can fix it 😃

[Christian-Me]

A) type in a label and the opions will/should appear 😬 B) for a hue you should choose an initial color (no shades of gray) I had red before for all but decided to make the user able to decide. I expect that if the node is wired in a working flow it will receive a valid color on startup.

The initial color is important to all configs (black will make a hue saturation combination difficult to use as hue defines all colors exempt black) Examples Hue and saturation needs a value slider to render all colors A picker circle needs value (HSV) A box (saturation and value) needs a hue slider A hue slider with lightness on will always render black if the initial color is Back ...

Can you test this on your side

[Simon01011]

Ahh, I need a label... I didn't realize that. But as I saw I can delete the label afterwards and the settings still apply.

The initial color seems to be a bit touchy. The setting is like shown in the first picture of my previous post. It is set to yellow. If I start on the command line with node-red and look at the dashboard, the color is set correctly. Any subsequent deploy or restart of flows sets it to a black and white slider like on the last picture. Do you have an idea?

[Christian-Me]

I didn't realize that. But as I saw I can delete the label afterwards and the settings still apply.

I assume in you mean this effect (both 5 units in height): Yes I have to scale the vertical sliders correctly if there is no label .... will do ASAP (the size calculation code is already a mess and have to many exceptions and workarounds ... need to be redesigned!) In vertical stacking (horizontal direction) it seams it work correctly:

The initial color seems to be a bit touchy. ... Do you have an idea?

A Kind of ... do you feed any color into the node? Than the last received color overwrites the initial color - until restart! That is how connects of new clients work ... (the node init function is called and uses the initial color and then the last known value is replayed overwriting this).

[Simon01011]

As you can see, I do not feed a color into the node anymore: This is just my test setup. My wife will not be very happy if I do experiments on the live system... So you say that if I don't feed a color into the node then it will not work? The live system has MQTT input and output nodes attached for the connection to the RGBW controller. Might be it works in this setup. I have to check that - deep in the night when everybody else is asleep 😄

[Christian-Me]

So you say that if I don't feed a color into the node then it will not work?

Not really ... The main problem is that to make iro.js work as expected you either have a complete color model (i.e. RGB, Picker circle + Value, Box+Hue, Hue + Saturation + Value Slider ...). If not you can end up with an unusable widget. i.e. A hue circle alone with black as initial color can't be used as black can't be manipulated in a color circle and the circle will stay black:

As many people start with the widget to play around it is hard to determine the right "initial color" - this depends on the components the select.

1. if possible have a complete set. For your RGB setup the value slider seems to be missing (you like to dimm your LEDs?)
2. If you don't have White in your LEDs then Saturation makes no sense (in additive color space) because you cant blend in white ... please test with Hue + Value. On paper you always have the white paper to control the saturation

If you feed in color make Shure that it works with the components you have.

But in the end ... iro.js seams not to be build for partial color models or LED specific tasks ...

So I have to see what I can do here - I done a workaround for tuneable white ... and RGBW and RGB LEDs are next

or join the conversation here ...

[Simon01011]

Hmm, maybe I was on the wrong track, don't know. What I have is a shelly, connected via MQTT. What I can set is:

{
    "mode": "color",    /* "color" */
    "red": 0,           /* red brightness, 0..255 */
    "green": 0,         /* green brightness, 0..255 */
    "blue": 255,        /* blue brightness, 0..255 */
    "gain": 100,        /* gain for all channels, 0..100 */
    "white": 0,         /* white brightness, 0..255 */
    "effect": 0,        /* applies an effect when set */
    "turn": "on"        /* "on", "off" or "toggle" */
}

So my imagination was:

• have something to control RGB --> slider with components "hue" and "saturation" --> RGB object output
• have something to control W --> slider with component "value" and white as initial color--> R value output (of course the same as G or B)
• have something to control G --> slider with component "value" and yellow as initial color --> value output

This way I can control the white LEDs separately (for me it seems they are brighter than the colored ones). And - maybe even more important - it is more intuitive than using three HSV sliders. Changing the saturation does change the whole color and not just the white portion of it. But I saw your conversion function in the other conversation. Maybe that's what I need, I will try in real life. It works in my virtual machine, but I'd like to see if it is usable in terms of different brightness of RGB and W LEDs.

If you're interested, for testing purposes I wrote a conversion function from RGBW to HSV:

let r = msg.r;
let g = msg.g;
let b = msg.b;
let w = msg.w;

let argH;
let argI;
let add2H;

let pi = Math.PI;

// check what sector we are in
if (b == 0) {
    // between 0 and 2*pi/3
    argH = (g+r) / (2*r-g);
    argI = r;
    add2H = 0;
}
if (r == 0) {
    // between 2*pi/3 and 4*pi/3
    argH = (b+g) / (2*g-b);
    argI = g;
    add2H = 2*pi/3;
}
if (g == 0) {
    // between 4*pi/3 and 6*pi/3
    argH = (r+b) / (2*b-r);
    argI = b;
    add2H = 4*pi/3;
}

H = Math.atan((2 / Math.sqrt(3)) * (argH - (1/2)));
H = H + add2H;
H = H / pi * 180;
if (H < 0) {
    H = H + 180;
}

I = (((3 * argI) / (1 + 1/argH)) + w) / 255;
I = I * 100;

S = 1 - w / (255*I/100)
S = S * 100;

msg.H = H;
msg.S = S;
msg.V = I;

return msg;

Try it if you like. It has no checking of bounds, i.e. it fails for both black and white RGB input. But that was not important for testing 😀

[Christian-Me]

it is more intuitive than using three HSV/I sliders.

not sure ... To control an RGBW (full color) LED I think the HSV model suites me the best. Pick a color (hue slider only shows full saturated colors. Mix in white with the saturation slider and use the value slider to dimm the complete setting. I use a very similar function to convert from HSV/I to RGBW (normally directly on the device in c). It is not calibrated for different intensities of the LEDs itself. For now I do it with factors on the "idealized"=all channels have the same power RGBW output, mostly white I have to dim with the exception of low saturations ... then I tune up the white again to get full power white when there is no (less) color (tinting a white little bit).

There is a difference in HSV and HSI ... Sorry that I mix both a little bit - the difference is not great on the endpoint where on the input the HSI has to much white

So all my light settings are in HSV/I - only inside the device I translate that into RGB or RGBW with some tuning depending on the hardware if nessesary. So I never have to translate back from RGBW to HSV ... But nice to have! Now I have both directions and can perhaps include the RGBW model into iro.picker as an option (if both approximation is not to far off)

Here is the node-red version (without tuning).

[{"id":"fc452e55.ebdd1","type":"function","z":"7fd2ef10.d1106","name":"hsv 2 RGBW","func":"fmod = function (a,b) { \n    return Number((a - (Math.floor(a / b) * b)).toPrecision(8)); \n};\n\nvar input = msg.payload;\nvar color = {r:0, g:0, b:0, w:0};\nvar cos_h, cos_1047_h;\nvar H = fmod(input.h,360); // cycle H around to 0-360 degrees\nH = 3.14159*H/180; // Convert to radians.\nvar S = input.s / 100;\nS = S>0?(S<1?S:1):0; // clamp S and I to interval [0,1]\nvar I = input.v / 100;\nI = I>0?(I<1?I:1):0;\n\nif(H < 2.09439) {\n    cos_h = Math.cos(H);\n    cos_1047_h = Math.cos(1.047196667-H);\n    color.r = S*255*I/3*(1+cos_h/cos_1047_h);\n    color.g = S*255*I/3*(1+(1-cos_h/cos_1047_h));\n    color.b = 0;\n    color.w = 255*(1-S)*I;\n} else if(H < 4.188787) {\n    H = H - 2.09439;\n    cos_h = Math.cos(H);\n    cos_1047_h = Math.cos(1.047196667-H);\n    color.g = S*255*I/3*(1+cos_h/cos_1047_h);\n    color.b = S*255*I/3*(1+(1-cos_h/cos_1047_h));\n    color.r = 0;\n    color.w = 255*(1-S)*I;\n} else {\n    H = H - 4.188787;\n    cos_h = Math.cos(H);\n    cos_1047_h = Math.cos(1.047196667-H);\n    color.b = S*255*I/3*(1+cos_h/cos_1047_h);\n    color.r = S*255*I/3*(1+(1-cos_h/cos_1047_h));\n    color.g = 0;\n    color.w = 255*(1-S)*I;\n}\n    \nreturn color;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":869,"y":119,"wires":[["2902caad.e9ebf6"]]}]

I don't know what gain should do ... as rgbw is complete? Is it an overall dimmer factor? Another point ... limiting to 8bit is a little bit odd. ESPs are capable of 10bit PWM! So you maybe loose 2 Bits resolution. Again that's why translating "last minute" has big advantages .... 8bit for addressable LEDS and 10bit for PWM ...

So perhaps try a Picker circle with a value slider, a box with hue slider (not bad in handling too) or 3 sliders HSV. All with HSV output and then translate it whenever needed (when you send the value to your hardware).

Perhaps something to read

To make it clear, I'm not an expert in these things ... This is all based on my experiences

[Simon01011]

There is a difference in HSV and HSI ... Sorry that I mix both a little bit - the difference is not great on the endpoint where on the input the HSI has to much white

Yes, I know. But I deliberately ignored it. Your conversion to RGBW (from the ressource you linked) works well and I just used the formulas and inverted them to get the opposite conversion. For your case, if you do it on your hardware, it is of course sufficient to have HSV. But I'm sure there are other guys around who - like in my case - need to feed RGB or RGBW values into their devices. You could add a conversion node to your project. So one can define input and output format (and even 8bit or 10 bit or whatever resolution). This way you have standard output from the picker (HSV, RGB) and for everything else you have an additional node. Sounds like a little bit of work for a rainy evening 😁

I don't know what gain should do ... as rgbw is complete? Is it an overall dimmer factor?

Yes, the gain in my case seems to be a simple overall scale factor. As far as I can see it applies to all channels. Seems to be redundant if you control the RGBW channels with the HSV picker...

We've come a little bit off topic regarding the title I gave this issue upon creating. Thank you for your work on the layout option. But there is one thing (maybe just a check box) I'm missing:

I have my four sliders (see image 1), three of them for HSV in a 6x3 card (see image 2) and one for gain (see image 4) in a 6x1 card. The wish is:

• The HSV sliders are stacked quite dense. For me it would be nice to have them with equidistant spacing. Now we can think of a distribution like (1/1/1/1) or (1/2/2/1). I've made two images below, first with (1/1/1/1) and second with (1/2/2/1) I like the second version more.

The problems are:

• The gain slider is placed in a 6x2 card with a lot of margin (see image 4) on top and below of it. Would be great to have it in a real 6x1 card. As far as I figured it out the effect comes from my settings. I put in a label, then set it to be above and then deleted the label. Yet the card is set to height 2. I think you need a check when computing the sizes to not enlarge the card if the label is empty. Workaround for me was to set a label, changed it to be placed left end deleted the label again (see image 5)
• And third: as you can see there is a discrepancy in width. The gain slider is as wide as the HSV sliders in image 1. If, like in the workaround described, I set the (empty) label to be left, the slider gets wider. The same applies to the HSV sliders, if I set the empty label to be left (not shown)

I hope I'm not too demanding. But it's all your own fault, you asked me to test it 😄

[Christian-Me]

Hi ... Thank you for your input, highly appreciated!

To keep you in the loop ... I'm rewriting the size calculation of all elements - It was a mess ... think I need some time as I have other things to do. But there is already progress and the code looks much cleaner. I have to avoid shortcuts and workarounds this time.

[Simon01011]

Thanks for your work on it. Just drop me a line here and I will test it. But also don't forget to enjoy the good weather 🌞

[Christian-Me]

Hi ... wow ended up with nearly the same amount of code .. but in the end nicer structured. If you don't enjoy the good weather perhaps you can take a look on version 0.1.2 from github (RGBW is started but not finished and many console.logs are active)

[Simon01011]

Looks good to me! RGBW payload output doesn't work, but I think that's what you meant with

RGBW is started but not finished

But that's okay for me. As far as I'm concerned: I'm happy 😃

[Christian-Me]

Hi,

great to hear that the layout problems are solved. Thank you for testing. 👍

I hesitated to issue the RGBW output because the RGBW output only makes sense if I can convert back form RGBW to RGB or any other supported format. Otherwise the flow can't replay data on page refresh, multiple clients or stored data in RGBW format.

Finally I managed to get a rgbw to hsv working (somehow still some glitches in low value or saturations). So I leave it marked as experimental for now. In the end the widget is not intended to do color conversions ... Perhaps I will build a custom node around chorma.js for this purpose looking great to do the job "professionally".

And in the end I'll perhaps better move the conversion part better to the backend ... when I have time ...

For now 0.1.3 is on github

[Christian-Me]

As discussed I think it makes no sense to "misuse" a ui widget for color conversion for many reasons. Here is a solution which can do that and many other nice things.

https://flows.nodered.org/node/node-red-contrib-chroma

Have fun (happy for any kind of feedback)

[Christian-Me]

Think we can close this?

[Simon01011]

So I finally tried the node-red-contrib-chroma and it works without problems. The layout problems that initially made me open this issue are solved as well. So there is no reason to keep this open. Thanks for all the work!

[Christian-Me]

Thank you for all your feedback!