Repository navigation
ddp from openRGB to wled stopped working in some later v16 nightly version #5532
Description
Activity
please share the exact DDP header that is output by openRGB. Either they violate the protocol or WLED is not properly handling all possible valid formats.
im sorry that I dont understand what it means to share "the exact DDP header that is output by openRGB" but if you can give me instruction then I will do it.
also I believe i misstated the problem so i'm updating the report. specifically, the problem is happening when using openRGB to control wled device. openRGB works to control wled device when wled is v15.4. openRGB fails to control wled device when wled is v16- changed the title
[-]ddp to openRGB stopped working in some later v16 nightly version[/-][+]ddp from openRGB to wled stopped working in some later v16 nightly version[/+]on Apr 24, 2026 either need to search the source code or use a network packet sniffer. I never did this so can't tell you exactly how. DDP uses a 10byte (or 14byte) header with info about the data that follows. if that header has incorrect information, WLED rejects the packet.
okay well without instruction then i cannot give you that information. should i just close this issue or something else?
they do send "undefined LED type" which WLED now rejects as undefined can not be parsed.
edit: the protocol must specify what type of data it is, RGB, RGBW.
@softhack007 should we allow "undefined" and fallback to RGB for the sake of compatibility?edit2:
its not only "undefined", it is datatype=1, which is just plain wrong:byte 2: data type set to zero if not used or undefined, otherwise: bits: C R TTT SSS C is 0 for standard types or 1 for Customer defined R is reserved and should be 0. TTT is data type 000 = undefined 001 = RGB 010 = HSL 011 = RGBW 100 = grayscale SSS is size in bits per pixel element (like just R or G or B data) 0=undefined, 1=1, 2=4, 3=8, 4=16, 5=24, 6=32"0x01" means "standard type" with an "undefined data type" and "1 bit per color" , which is not supported by WLED. This question on why they use this incorrect format needs to go to openRGB devs.
thanks for this information although I dont fully understand it..
if it is decided that no wled change will be done, could you please share precise wording that I will then send to openRGB and ask them for a change ?
otherwise, if change in wled, i could think of looking at the first output in order to determine what type to use. maybe its not desirable but seems like it could work.. although simply reverting back to allowing undefined would also work in this usecase - was that causing problems?
simply reverting back to allowing undefined would also work in this usecase - was that causing problems?
yes, it was causing problems, that's why we decided to change it. A protocol is well defined, if unsupported data is sent, it should not just be accepted.
Reacted by Will Tatamwe need to check this more thoroughly and then decide what to do. But ultimately openRGB may need to fix the bug on their end.
EDIT: i reported the issue to openRGB but did so in the wrong place resulting in closed issue. still trying to understand how to properly raise this with openRGB...
looking into this in more detail.
@netmindz the DDP protocol DOES have 2bits to ID the version but it is not being used, it is and always has been "version 1" even though the header definition has changed.
Here is what I have done (PR almost ready):- not reject any malformed
dataTypein the header but always assume RGB24 except if type=RGBW - always assumes 8bit per color channel
- instead, the packet size is checked against the required data length for the assumed format, if it is too small, it is rejected (OOB read safety)
I also found that for artnet and E1.31 packets, no checks against incomplete or malformed packets was done. I added checks to make sure that no OOB reads are possible anymore.
- not reject any malformed
edit2:
its not only "undefined", it is datatype=1, which is just plain wrong@DedeHai (just back from a nice week off-line) yes, this seems to be a mistake that was copy&pasted between several DDP tools - I've made a similar bug report in another DDP tool that supports WLED (ppamment/wledcast#6).
Maybe for the time being, we should
- allow "0x00" (undefinded) and "0x01" (legacy) and assume they are 8bit RGB
- or reject only some unsupported formats (HSL, grayscale) and unsupported bitdepths ( 4, 16,24,32)
and add a new error status ("unsupported format of external data") so users get an indication of what went wrong.
- unsupported bitdepths ( 4, 16,24,32)
Edit: bitdepth = 24 seems to be another common misuse of the specs, maybe we need to include "SSS = 0x05" into the whitelist, too
@softhack I did implement a relaxation in PR #5547 , basically "accept all, assume RGB24 unless its explicitly RGBW then assume RGBW32"
when you dig out older versions of the DDP specification using the way back machine, all these definitions are "TBD" and datatype=1 may at one point have been a valid RGB24 definition. unfortunately, the "protocol version" is always 0x40 (=version 1) so it can not be used to determine which definition other software is using.
what I did add in #5547 is overflow checks for all supported protocols: if a packet is malformed, for example claiming a length of 256 but only sending 100 bytes of data, the packet will now be rejected instead of just reading out of bounds (I am surprised this has not led to more crash reports)Reacted by Frank Möhle@DedeHai yes, makes sense
🤔 my conclusion was: either "people can't read specs" or "specs have been totally volatile" (or both 😉 ).So maybe better to ignore all legacy misinterpretations - as you suggested 👍
Reacted by Damian Schneiderthank you to all for your work.
i will be keeping an eye out for the soonest release this will be available in and test it out and let you know the result or you can please feel free to reach out to me ask me to test it. i have several wled devices, some with mixed strip types, and one with almost 3,000 leds over 4 outputs which might be considered very good test case (assuming i test all 4 devices).
also just want to add my 2 cents which has probably already been considered but i would be remiss to not mention it.
i started digging into information on the PR which was created as a result of this PR, and I noticed that several other vendors appear to be part of wled development test cases for connectivity, such as hyperion/signalrgb/etc.i noticed that openRGB is not on that list.
without knowing how much extra work it would be to add the case of openRGB, I would consider adding it as the only real alternative to signalRGB but with a huge advantage of completely free and opensource - that might mean that potentially more users will be using openRGB vs signalRGB so that openRGB might be better or good as a use case. asking google which of the 2 are more widely used doesnt show a clear winner, and also the future is uncertain too. ive tried both and neither seemed much better than the other, and ultimately i refuse to pay when there is similar option free of cost(hence I settled on openRGB), which is ultimately the only reason I ever considered using WLED in the first place, which, now i cant even live without WLED (THANK YOU GUYS SO MUCH!!!!).@greekthano as with every PR, you can get the bins with its changes included: https://github.com/wled/WLED/actions/runs/25007402089?pr=5547#artifacts
the changes are not specific to any external software so openRGB should work even though they use the wrong header.
- linked a pull request that will close this issueless restrictive DDP header acceptance, add safety checks to all protocols #5547
on Apr 28, 2026 thank you I did not know that I could find such bins but now I see how I can find them for future reference - thank you very much for the link to the bins.
confirmed DDP with openRGB is now working again! closing this thank you again for all your effort.
Reacted by Damian Schneider
EDIT: updating typos and misstates
What happened?
one of the later v16 nightly versions broke ability to control wled device using openRGB ddp. i had been updating nightly v16 versions over the last few months without issue and i only recently observed this problem, so it must be in one of the later v16 nightly but unfortunately i cant tell which one.
rolling back to v0.15.4 resolves the problem.
switching from DDP protocol to E1.31 in openRGB is a workaround unless you exceed max leds supported by E1.31
very basic config with 2 outputs of same type, attached configs
wled_cfg_stripscase.json
wled_cfg_stripscase.json
To Reproduce Bug
install latest pawnio version of openrgb and add manual ddp device and point it to wled esp32 controller. this works in v0.15.4 but doesnt work in v16 although it did work in v16 one of the earlier nightly versions.
Expected Behavior
ddp should continue working
Install Method
Binary from WLED.me
What version of WLED?
v16 beta
Which microcontroller/board are you seeing the problem on?
ESP32
Relevant log/trace output
Anything else?
No response
Code of Conduct