logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

DDP protocol - a way to create real-time LED animations via WiFi - OBK, xLights, configuration

p.kaczmarek2 5658 32

TL;DR

  • DDP protocol enables real-time LED animations over WiFi using OpenBeken and xLights.
  • It sends 24-bit RGB or 32-bit RGBW data over connectionless UDP, with one packet covering multiple LEDs or WS2812 strips.
  • OpenBeken starts DDP with `startDriver DDP`, and strip setups can also use `SM16703P_Init 50` or `GRB`.
  • xLights groups independent LEDs, arranges them in 2D or 3D, and sends test animations to a device by IP address.
  • UDP brings no retransmission, so a lost packet can be missed; fixed IP or reservation helps keep controllers aligned.
Generated by the language model.
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • #31 21692065
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    Sure, but can you provide specifics? DDP driver may be running all the time, but light can be still controlled manually if nothing is sent via DDP. Do you want just an information whether given driver is running, or do you in fact want to check whether DDP is really currently active and in use, processing packets?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #32 21692097
    teri928tv
    Level 2  
    Posts: 2
    >>21692065 Thanks for the reply! I just mean if the DDP driver is active at all. Basically in my use case, I have a template switch in Home Assistant that sends startDriver/stopDriver commands to basically toggle DDP on/off for my device to put all my RGB lights into "light show mode."
    Specifically, I'm wanting to know if the DDP driver is running via MQTT, so I can use that as a 'state' in HomeAssistant for the template switch to track it's state correctly since DDP is reset on a reboot. Even something as simple as a binary value sent via MQTT if DDP driver is running or not.
    I'm new to OBK to be honest, and I'm coming from ESPhome. I'm really looking for any way to get more simple data available via MQTT about the drivers running, but ANY data about the DDP plugin over MQTT would be incredibly useful to me personally. I hope that makes sense. I'm forever thankful I found this project, but again I'm very new to OBK and I'm not sure what all is possible. I'll happily receive any direction.
  • #33 21693022
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    Well, I can easily add this for you, but the question is, should we also have it in the main release? You can create your own version of OBK easily with online builds:
    https://www.elektroda.com/rtvforum/topic4033833.html
    Or maybe you can do just a work around. I think OBK publishes uptime value. So, if uptime becomes smaller than before, then it means that reboot happened.

    Do you just want to listen to a topic to know whether DDP runs? Or do you want a request-response approach, like with Tasmota , where you can publish to cmnd topic and receive status?

    Added after 13 [minutes]:

    Maybe something like this?
    DDP protocol - a way to create real-time LED animations via WiFi - OBK, xLights, configuration
    Then you can add this in autoexec.bat after waitFor MQTTState 1...
    Helpful post? Buy me a coffee.
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
Report a violation of the law

Topic summary

✨ The discussion focuses on implementing and testing the DDP (Distributed Display Protocol) for real-time LED animation control over WiFi using UDP, particularly with OpenBK (OBK) firmware on GU10 RGBW and RGBCCT bulbs. DDP supports 24-bit RGB and 32-bit RGBW color formats, enabling control of LED strips like WS2812. A key issue addressed is that OBK bulbs remain off (black) after DDP animation stops, unlike WLED bulbs which revert to the previous state. The conversation explores adding RGBW support in OBK, with experimental firmware versions enabling parsing of 4-byte RGBW packets, splitting the white channel evenly between Cool White and Warm White at approximately 4000K. Testing with xLights revealed that channel 4 (white) control works for single channel tests but causes unexpected white illumination during RGB cycle animations, likely due to xLights packet formatting. Users shared hex packet dumps to aid debugging. The DDP driver was initially missing in LN882H builds but was added upon request, enabling DDP functionality on new BK7231-based GU10 bulbs from SmartLed. The discussion also covers firmware flashing via OTA, configuration templates, and the need for brightness override behavior by DDP. Overall, the thread provides practical insights into configuring DDP on OBK devices, troubleshooting xLights integration, and firmware development for enhanced RGBW LED control over WiFi.
Generated by the language model.
Today's popular

FAQ

TL;DR: DDP sends 24-bit RGB or 32-bit RGBW LED data over WiFi using UDP, and one expert calls it "extremely easy-to-use." This FAQ helps OpenBeken and xLights users configure single lamps, strips, RGBW bulbs, packet debugging, and MQTT-visible DDP status without extra wiring. [#20989597]

Why it matters: If you want fast WiFi LED effects on OBK devices, DDP gives simple setup and low-latency animation, but you must plan for packet loss, RGBW quirks, and driver-state handling.

Option Transport Best use Main advantage Main limitation
DDP UDP Continuous LED animation Fast, lightweight, multi-pixel packets No retransmission if a packet is lost
MQTT TCP Reliable state changes Better delivery reliability Less suited to rapid frame-by-frame effects
HTTP TCP Simple command-based control Reliable single actions Not ideal for real-time animation

Key insight: DDP works best when software keeps sending fresh frames. If you need a bulb to remember or restore a stable state after animation stops, use extra OBK logic or switch to a TCP-based control path. [#20989597]

Quick Facts

  • DDP packets in the thread use UDP port 4048, and both Tasmota and OpenBeken examples read color bytes starting at payload offset 10. [#20989597]
  • The thread compares xLights packet sizes directly: an RGB test packet was 13 bytes, while an RGBW test packet was 14 bytes. [#21335096]
  • For OBK LED strips, the example startup uses startDriver DDP, startDriver SM16703P, and SM16703P_Init 50, which configures a strip with 50 pixels. [#20989597]
  • Experimental RGBW support in OBK 1.17.795 mapped the fourth DDP byte to 50% cool white + 50% warm white, targeting about 4000K on an RGBCCT bulb. [#21336347]
  • One LN882H test bulb that needed a custom DDP-enabled build was described as a 5W, 500 lm, GU10 smart lamp. [#21358155]

What is the DDP protocol, and why is it useful for real-time LED animations over WiFi?

DDP is a connectionless UDP protocol for LED lighting that sends color data fast enough for real-time animation over WiFi. "DDP" is a lighting-control protocol that transports pixel color data in UDP packets, avoids connection setup, and can carry multiple LED values in one frame for responsive effects. In the thread, it commonly uses 24-bit RGB or 32-bit RGBW, and one packet can control whole LED strips, not just one lamp. [#20989597]

What does xLights do, and how is it used to send DDP effects to OpenBeken devices?

xLights creates, groups, and transmits LED effects to OBK devices over DDP by targeting the device IP address. The thread shows xLights arranging LEDs in 2D or 3D, assigning channels, and sending test effects from the Tools menu. A fixed IP or DHCP reservation matters, because a router reboot can otherwise change addresses and break the mapping between xLights outputs and OBK lamps. [#20989597]

How do I configure OpenBeken to receive DDP packets for a single RGB lamp?

You enable the DDP driver and then send xLights output to the lamp’s IP address. 1. Add startDriver DDP to OBK startup commands. 2. Reboot the device so the driver starts automatically. 3. In xLights Tools, test the lamp’s channels and verify the lamp is powered on in OBK. The thread’s OBK example then accepts RGB bytes from the DDP payload and plays the test animation. [#20989597]

What steps are needed to control a WS2812B or SM16703P LED strip over DDP with OBK and xLights?

You must enable both DDP reception and the strip driver, then set the pixel count and matching xLights channels. 1. In OBK, run startDriver DDP. 2. Start the strip driver with startDriver SM16703P. 3. Initialize the strip, for example SM16703P_Init 50, or SM16703P_Init 50 GRB if color order is wrong. The thread shows this working for a 50-pixel strip and notes that xLights channel counts must match the configured pixels. [#20989597]

Why does DDP use UDP instead of TCP, and what are the trade-offs for LED animation reliability?

DDP uses UDP because animation needs low overhead and constant updates more than guaranteed delivery. UDP lets OBK receive frames quickly without connection management, which keeps effects responsive. The trade-off is clear: if one packet is lost, DDP does not retransmit it. That is usually acceptable for continuous animation, but it becomes a problem if you send one color-setting packet and expect the light to hold that state reliably. [#20989597]

How does DDP compare with MQTT or HTTP for controlling LEDs when I need reliable state changes instead of continuous animation?

MQTT or HTTP fit reliable state changes better than DDP. The thread explicitly recommends TCP-based MQTT or HTTP when you need a bulb to keep a commanded state, because TCP offers better transmission reliability than UDP. DDP is better for rapid, repeated frame updates. If your use case is one command, one result, and no continuous stream, MQTT or HTTP is the safer control path. [#20989597]

Why does an OpenBK RGBCCT GU10 bulb stay black after DDP packets stop instead of returning to its previous color like WLED?

It stays black because OBK, as discussed in the thread, did not automatically restore the pre-DDP state after the stream ended. A user reported that when DDP reception finished, the GU10 bulb remained black instead of returning to the previous color or white mode. The discussion framed the desired behavior as restoring the earlier state after about a minute of animation, but no completed restore-state mechanism was shown in the thread. [#21333950]

How can RGBW DDP packets from xLights be parsed in OpenBeken, and how is the white channel mapped on RGBCCT bulbs?

OBK can parse RGBW by treating a 4-byte color payload as RGB plus one white byte. In the thread, experimental support added RGB parsing when color length is 3 and RGBW parsing when length is 4. For an RGBCCT bulb, the fourth byte was mapped to both cool and warm white at 50% each, aiming for roughly 4000K. That was released for testing in OBK version 1.17.795. [#21336347]

Why does channel 4 white work in xLights single-channel testing but behave strangely during the A-B-C-All RGB cycle on an RGBW bulb?

xLights appears to send a 4-color packet during that RGB cycle, so OBK correctly lights white when the packet says four channels exist. The thread showed channel 4 working in single-channel tests, but during A-B-C-All, red also lit white. The follow-up conclusion was that this was driven by packet content, not random bulb behavior: the packet still contained 04 where a 3-channel RGB cycle would have been expected to use 03. [#21344435]

How can I capture and analyze raw DDP packet hex dumps in OpenBeken to troubleshoot RGB vs RGBW behavior?

Use the DDP debug build that logs raw packet bytes in the OBK Web App console. 1. Flash the special build from the DDP dump pull request by OTA. 2. Enable the DDP driver and send a single RGB packet, then a single RGBW packet. 3. Copy the hex dumps from the log and compare payload length and byte count. The thread used this method to isolate RGB versus RGBW packet structure from xLights. [#21333957]

What do DDP packet length and payload differences mean when comparing RGB packets with RGBW packets in xLights?

They show how many color bytes xLights is actually sending per pixel. In the thread, the RGBW example 410F0001000000000004000000FF had length 14, while the RGB example 41030001000000000003FFFFFF had length 13. The practical meaning is simple: one extra payload byte indicates a fourth channel. That gives OBK a concrete way to distinguish 3-byte RGB from 4-byte RGBW traffic. [#21335220]

How should DDP brightness interact with the existing OBK light brightness setting when xLights sends animation data?

DDP should override the existing OBK brightness when xLights sends animation data. The user explicitly requested that behavior, and stated that brightness should follow the xLights configuration rather than stay at a prior OBK setting such as 50%. That makes DDP act like the active frame source, not a tint layered on top of manual brightness. The thread presents that as the expected control model for animation playback. [#21335708]

Why won’t the DDP driver start on an LN882H OpenBeken build, and how do I enable it in a custom firmware build?

The DDP driver will not start if the LN882H firmware build does not include that driver. In the thread, entering startDriver DDP at runtime showed that the driver was missing from the build. The fix was to enable DDP in obk_config.h and build custom firmware, or use a prepared DDP-enabled build. After flashing that custom compilation, the LN882H GU10 bulb started working as expected. [#21358147]

What can I do in OpenBeken so a bulb switches cleanly from WLED/DDP control back to normal cool-white manual control without needing to move the temperature slider first?

You currently need extra OBK logic, because the thread reports no finished automatic handoff for that case. A user described losing normal cool-white behavior after stopping DDP, then having to move the temperature slider before the bulb lit again. The stated goal was a script or flag that restores manual control cleanly and prevents DDP and manual white mode from being active together. The maintainer replied that DDP improvements were under active review, but no final solution was posted there. [#21647952]

How can I publish the OpenBeken DDP driver running state over MQTT so Home Assistant can track whether light show mode is enabled?

You can expose a binary DDP-running state over MQTT, and the maintainer indicated this was easy to add. The Home Assistant use case in the thread toggled startDriver and stopDriver to enter light-show mode, then needed MQTT state tracking because DDP resets after reboot. A proposed workaround used OBK uptime to detect restarts, and a proposed solution showed publishing driver state after waitFor MQTTState 1 in autoexec so Home Assistant can mirror the switch state. [#21693022]
Generated by the language model.
ADVERTISEMENT