I have an RGBW DALI Stripe with a Theben DALI Gateway which should be controlled via the dashboard. For this I installed the "ui-iro-color-picker 0.1.6".
Unfortunately the KNX node needs a validation bit (mR:1, mG:1, mB:1, mW:1)
Does anyone have an idea how I can control the light?
thank you
LG
The dashboard supplies a colour picker widget which will output R G B values. Then just have a second slider node that controls the white value. You should then be able to use a join node to combine the 2 outputs.
I have tried the following without success
Are the validation bits (mR:1, mG:1, mB:1, mW:1) realy necessary?
In the ETS it only works if i set the (mR:1, mG:1, mB:1, mW:1) on valid
Hi,
I'm not int KNX / DALI but into colors and light 
Looking at your screenshots above it seams that values in % and not bytes are expected.
You might try to use the range node (4x)
or a little bit of javascript in a function node:
let factor = 100 / 255;
msg.payload.r = Math.floor(msg.payload.r * factor);
msg.payload.g = Math.floor(msg.payload.g * factor);
msg.payload.b = Math.floor(msg.payload.b * factor);
msg.payload.w = Math.floor(msg.payload.w * factor);
return msg;
If this is not the problem you have to dig into what format the KNX node expect. I don't know which knx node (there are so many) you use but the first one I picked expect colors different:
But here it seems that the input expects RGB in bytes float (nice) and not RGBW ... Evtl hilft ja auch die angebotene "Hilfe beim formatieren von aufgewähltem payload"
Thanks for your help.
The KNX Node Help says:
msg.payload={red:90, green:200, blue:30, white:120, mR:1, mG:1, mB:1, mW:1};
return msg;
That´s what I am sending here:
or am I wrong?
err no - you are sending r not red, etc.. and floats not ints... but apart from that it looks ok... 
So as @dceejay pointed the finger at your issue where I gave you only a hint hidden in a screenshot and a unnecessary comment - sorry for that. You can use a change node or a little bit of JavaScript
let factor = 1; // values are already bytes let the js on the fly compiler optimize this away ;)
msg.payload.red = Math.floor(msg.payload.r * factor);
msg.payload.green = Math.floor(msg.payload.g * factor);
msg.payload.blue = Math.floor(msg.payload.b * factor);
msg.payload.white = Math.floor(msg.payload.w * factor);
return msg;
KNX define a value and than declare it invalid? Is this done to transfer only single components?
Understandable if knx uses hsl as their color model but in rgb every color change effects all channels.
And what does the resolution of 0.4% means if you transfer bytes? Do they expect 10bit ADCs in the end but don’t provide the data?
Only curious how „professional“ systems handle things.
Ok in simple terms trad KNX was byte oriented protocol (will be nailed for saying this)
All products need to be certified which means they would fail certification if they did send incorrect value. Looking at the DataPoint Type the device expect an 8 bit integer scaled 0-100% for each RGB(W) value. The data point type for this is new to me as I don't do much KNX anymore where trad bits (switch object) have been a single byte here they are grouped for validity.
The DataPoint Type is interpreted at he application layer so if it was a pure KNX LED driver it would use PWM for either a constant current or voltage LED for intensity. I don' know how they do RGB(W) mixing. In this use case the RGB(W) values are passed to a DALI bus and to a Dali Ballast to drive the LED.
I doubt this answers the question I hope those with more current knowledge than me might be able to.
That’s all clear to me. In my job as an Architect working mostly as an Interior Designer I‘m often in contact with KNX Dali and other systems. They often come from a technical IT point of view and not from a lighting design or artistic view on things. Think this results in bad light design and appearance these days. Bad user experience over all. And we all know it is possible to do better.
In an ideal world the fixture will do the mixing of the light sources they have and know about. The control system should only send the color (preferable in HSL) to a fixture and the endpoint do the mixing of RGB + CW / WW / Amber or Yellow or what not. The linearity of the PWM dimmer, the intensity of the chips the wavelength or spectrum is unknown to the controller. This is why I don’t get that RGB is still the preferred color model - as there was CIExy+z defined by the light industry. Sending RGBW is even worse as it don’t take the color temperature of the white LEDs into account.
Sorry for going of topic again
So I'm going to go Even further off topic....
Got you there, most KNX techs can't string a sentence together if it's not technical !!
Joking but have worked on many high end ressi in London, last big one was by David Chipperfield https://tinyurl.com/5d3rpw83
For Architectural lighting we used use KNX to DMX especially for outdoor washes and a bit of colour change internally for scenes. KNX is over 26 yrs old and maintained by tech committees. That said the Theben DALI GW does ref CIE 1931 colour spaces on page 10
Thanks for your help guys
If I use your Srcipt i get the following back
how i can ignore the first 4 lines?
// this should do it
let factor = 1; // values are already bytes let the js on the fly compiler optimize this away ;)
msg.payload.red = Math.floor(msg.payload.r * factor);
msg.payload.green = Math.floor(msg.payload.g * factor);
msg.payload.blue = Math.floor(msg.payload.b * factor);
msg.payload.white = Math.floor(msg.payload.w * factor);
delete msg.payload.r
delete msg.payload.g
delete msg.payload.b
delete msg.payload.w
return msg;
Or
let output = {};
let factor = 1; // values are already bytes let the js on the fly compiler optimize this away ;)
output.red = Math.floor(msg.payload.r * factor);
output.green = Math.floor(msg.payload.g * factor);
output.blue = Math.floor(msg.payload.b * factor);
output.white = Math.floor(msg.payload.w * factor);
msg.payload = output;
return msg;
something like this.
[edit] please give the solution to @Christian-Me, I just showed how to remove the unwanted properties.
Didn't know that it is so old. These days you could not expect that the fixture / endpoint as the computing power to do the final calculations (gamma, white point, different luminous flux ...) there. I even might expect the used some color filters in front of halogen lights or even electric arc bulbs (which are quite good giving full spectrum lights - used in film projectors or your digital projector). So let's the computing done somewhere in a decent CPU was the way to go. Today every minature GU10 Ikea zigbee bulb does the job transfereing CIExy to their 3,4 or 5 LEDs quite well.
I'm waiting for RGBY (RGB+Yeloow / Amber) fixtures as the available RGB wavelength don't mix well together to decent yellows - But we all love the cozy feeling of a fire place in our ancestors cave burned into our DNA. Yesterday I changed back form 2700K LED E14 filament bulbs to high voltage halogen (yes I saved a box spare) to get back the nice effect of incandescent filaments from 3000K down to 2???K whenn dimmed. OK you can do it with tunable whites but who likes the plastic cases?
Speaking about architectural lights , here is one of my latest projects:
Every window is tilted with a LED strip on the edge. all individually controlled via DMX. A great experience was that on an event the lighting guy plugged his theater light mixer into the DMX bus and created a impressive light show in a few hours.
big thanks to you too
@Wurmi You can add the valid flags right here and get rid of the change node
return {
payload : {
red : Math.floor(msg.payload.r),
green : Math.floor(msg.payload.g),
blue : Math.floor(msg.payload.b),
white : Math.floor(msg.payload.w),
mR: 1,
mG: 1,
mB: 1,
mW: 1
},
topic: msg.topic
}
is perhaps the shortest version (hope I didn't do any typos) but you perhaps miss some other parameters existed in the original message. So the solution of @iiLaw is fine.
@Wurmi : the "left" over r, g, b values should not cause any harm (JavaScript usually don't read any additional now unnecessary parameters as long as nothing unexpected is happening in the KNX node). But this is all academic you can delete them for clarity in your debug nodes.
There is an unwritten "rule" to only add or modify the original message as needed and don't create new messages as you then might loose the ability to pass extra parameters you add later on through your node.
But we all make the rules to break the rules I love clean messages brought down to the necessary essence even it give extra work for node red and the JS engine (allocating new memory and getting rid of the old msg object during garbage collection)
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy