Repository navigation
RGBW via DDP from XLights #4141
Description
Activity
Most of the effects do not take separate W channel into account. So there is no way, unless those are rewritten, to have them use W channel except in Auto Calculate White mode.
As for RGB vs. RGBW DDP support, those exclude each other.
The data structures are different.Dynamically switching between RGB & RGBW as far as LED types go, is impossible but manipulating RGB to be displayed on RGBW strip is possible, the other way around may produce unwanted output.
We will welcome a PR that does that if you wish to tackle it.
I have a falcon board that handles it just fine.
My assumption is it stills sends the 4th channel but sends it 0 while R G B are all 255 the controller doesn't interpret that as white and light the white channel since it's expecting the 4th channel to be the data for white.
The sequences are saved and rendered this way and no changes are done to the controller dynamically.
Because WLED is interpreting the full RGB as white I lose the ability to have a bright white and warm white.
I unfortunately do not have the skill to help write the code.
Tested again today and have some more feedback.
This would be fixed if WLED simply handled 4 channel DDP data. It seems as if WLED is only able to handle 3 channel DDP data. When I set XLights to 3 channel (even though theyre 4 channel nodes) I have to manually go into WLED and set the total pixels since I can no longer use the Upload Outputs from XLights as by going from 4 channel to 3 channel I lower the total "pixel" count.
IE 100 pixels of 4 channel is 100 pixels.
Changing that same pixel to identify as 3 channel makes it appear as 75 pixels.
This causes an obvious issue that channels dont line up with their corresponding pixel.If this one change was made that when a 4 channel pixel is selected the DDP input is expected to handle 4 channels. Then Auto Calculate white channel wouldn't be needed. It would simply assign the 4th channel to the white led only.
This would allow users to do as I mentioned above, change their sequences to support the white channel when desired and not use it when not desired. Because when XLights is set to 4 channel but RGB only, it sends all 4 channels but doesnt send any values down the 4th channel just RGB.
Reacted by LawrenceLaxdalI am a little confused as while there is a comment at the top
handleDDPPacketsaying "handles RGB data only"There is also code that calls
setRealtimePixelpassing the white value from the DDP data.What happens when you configure XLights to send RGBW data @Fonzi03 ?
@netmindz RGBW has been implemented in DDP not so long ago. It is handled correctly AFAIK.
The issue, as I see it, is to have WLED configured as RGB and send it RGBW via xLights (or the other way around).
This is doable but needs correct handling in the code.If you could tell me which settings to use in WLED to accept 4 channel RGBW DDP I will try that.
The way I see it up is because it was messing up the channels if I had the auto calculate to white my channels were off.
I can try again today and take some pictures/screen shots.
My preference would be for 4 channel DDP to work as expected and let XLights handle choosing if the 4th channel goes high or if just the RGB channels do.
If it works that way I get to use the warm white channel when I want and use theoxed RGB (without warm white) at other times which is exactly what I'm looking for.
There isn't a config option as such, the code just looks at the data and calls setRealtimePixel with the data you sent.
So if you can try sending RGBW and see if that works as expected.
If not then we can look into if/why the white value is being recalculated deeper in the code
@netmindz
With XLights set to the following:
And WLED set to:
I set color bars to:all White, then Red, then Green, then Blue
XLights preview
Actual output on LEDs (board is in the attic so this is just a small test strip hooked up:
As you can see I am not getting solid color bars and the white channel seems to always be off.
FYI I have checked the code and WLED will correctly display either RGB or RGBW DDP packets received. Regardless if that particular WLED device has RGB or RGBW LEDs attached. They have to be configured correctly though.
The information of channels is part of the DDP packet and if your receiving WLED is correctly configured (correct LED type attached) it will either disregard W channel or display it as it was sent from sender if sender is configured as RGBW. If sender is configured as RGB the W channel on receiver will always be 0 (unless you configured auto white calculation in which case W will be calculated from RGB information).
There is clearly something going wrong with more than just white @Fonzi03 given you are getting RGB LEDs lighting up got anything other than their own colour.
I am assuming that if you use WLEDs own effects you see exactly what you expect? E.g setting solid red then you see only red lighting up etc?
I'm not familiar with xlights so I can't confirm your settings listed are appropriate for RGBW DDP, so I would advise you double check these with that community
@netmindz yes I believe effects from WLED are accurate.
It's only incoming DDP data that's incorrect. When I use these exact same settings on a Falcon F16v4 the white channel lights as expected. It's just in WLED that it's doing as above images show. I know the XLights side very well and when the settings are set to what they should be in XLights it doesn't work properly.
I posted my WLED settings above, if something is wrong please let me know and I'll correct it. Otherwise I understand your saying WLED should handle the white properly so long as the pixel type is accurate and the data coming in is good but it doesn't seem to be doing that subjectively.
These are my current setting in WLED for the non test port. In XLights I have to set the pixel type to RGB to get this to work instead of RGBW.
What I assume is happening is that when auto calculate white is selected, if R=G=B --> W. At least that's the behavior I'm seeing, regardless of my XLights setting I cannot get it to light the white channel properly.
43 remaining items
Hey! This issue has been open for quite some time without any new comments now. It will be closed automatically in a week if no further activity occurs.
Thank you for using WLED! ✨Just dropping a comment here to keep it open. I may have some time to put a pull request together, but it will be a while. If someone else happens to have time that's cool too.
Reacted by Fonzi03Just dropping a comment here to keep it open. I may have some time to put a pull request together, but it will be a while. If someone else happens to have time that's cool too.
I am not skilled enough to write the code changes but am more than willing to do any testing that can help if you do get time to write a fix for this. I'm fairly technical and understand reading through code just can't write it from scratch.
Hey! This issue has been open for quite some time without any new comments now. It will be closed automatically in a week if no further activity occurs.
Thank you for using WLED! ✨- linked a pull request that will close this issueDDP input: reject packets with unsupported data type or non-display destination #5390
on May 15, 2026 @Fonzi03 maybe I misunderstood what you were asking for?
The PRs listed above make sure that non-display DDP (status information, etc.) is not treated as RGB (or RGBW) pixel data.
It would be best if WLED could handle XLights/DDP data sending RGB and RGBW allowing the use of different sequences to have different effects.
RGB and RGBW formats (8 bits per color; i.e. RGB = 24bit total and RGBW=32bit total) are supported since long time already.
"HUE" and "Grayscale" formats are not supported, and there are no plans to add them. The same for formats with bits-per-color other than 8.At the same time it would be nice for WLED effects to work properly when not receiving DDP data. IE being able to add/remove/exclusively use the white channel.
WLED effects will resume when not receiving DDP data; there is a timeout that you can set in Sync Settings.
Edit: if your question is about "DDP RGBW on an SK6812 RGBW strip" - please try WLED 16.0.0. White Channel handling has been improved since 0.15.x, and you should now be able to control the white LEDs directly (LEDs settings: auto white mode = none).
If you have RGBW LEDs but DDP arrives as RGB, then the behaviour depends on "auto white mode" - in mode "none", the white LEDs will stay off. In other modes, the white LEDs will be auto-calculated from RGB.If still no success, try to uncheck "use main segment only" in sync settings. This enables a direct render path to your LEDs, instead of an indirect one via segments.
**Is your feature request related to a problem?
Yes
Normally in XLights I can save a sequence with the "String Type" as RGBW, and "RGBW Color Handling" to either one of the RGBW settings (I typically advanced or R=G=B->W) or RGB Only depending on what sequence I am running.
For accent lighting I like to use the Warm White channel, but for musical sequences I like to use RGB only.
Right now the way I have it working I have to set XLights to
String Type: RGB Nodes
RGBW Color Handling: RGB Only
Then in WLED I have:
Auto-calculate white channel from RGB: Accurate
This works, kind of. It lets XLights/DDP data send accurate colors with the expectation that White will always light the 4th channel instead of mixed RGB.
When I try to use WLED though it always lights the White and RGB pixels simultaneously when trying white.
**Describe the solution you'd like
It would be best if WLED could handle XLights/DDP data sending RGB and RGBW allowing the use of different sequences to have different effects.
At the same time it would be nice for WLED effects to work properly when not receiving DDP data. IE being able to add/remove/exclusively use the white channel.
addressed in #5390 (reject non-display destinations) and #5554 (relax restrictions for legacy implementations).