OpenBeken adds a new WS2812B-style LED driver and PixelAnim animation system for BK7231T/BK7231N WiFi modules, targeting per-pixel RGB strips and cloud-free Action/LSC devices.
The setup uses autoexec.bat with startDriver SM16703P, SM16703P_Init 16, and startDriver PixelAnim, with no separate pin assignment because the LEDs use hardware SPI pin P16.
The feature is said to be enabled in releases past 1.17.600, and SM16703P_Init 16 configures the LED color format.
After rebooting, the HTTP panel shows single-color control and predefined animations, and the effects also run in the OBK simulator.
PixelAnim may still be missing from the main release, so it may require a custom build or a PR-enabled binary; Home Assistant discovery lacks animation control yet.
OK so the WS2813 and WS2815 LED strips have backup data lines, but does the backup data line have to be used? can you connect it up to a WS2812B (with correct voltage appropriate for the strip type) controller with one data line and expect it work? Will it work but just be dimmer because of the difference in operating frequencies?
OK so the WS2813 and WS2815 LED strips have backup data lines, but does the backup data line have to be used? can you connect it up to a WS2812B (with correct voltage appropriate for the strip type) controller with one data line and expect it work? Will it work but just be dimmer because of the difference in operating frequencies?
Initial assessment You’re comparing WS2812B vs WS2813/WS2815 strips and asking: - Do WS2813/WS2815 require the backup data line (BI)? - Can you drive them from a “WS2812B” one-wire controller? - Will they be dimmer due to different operating frequencies?
Direct answer - No, the backup line is not required. You can leave BI unconnected. - Yes, you can drive WS2813 and WS2815 from a single-data-line WS2812B-style controller, provided voltages and timings are correct. - No, they won’t be dimmer because of protocol/data frequency. Brightness is set by current and PWM duty, not by whether BI is used or by the 800 kHz data rate.
Detailed technical analysis - Protocol compatibility - WS2812B, WS2813 and WS2815 all accept the same 1‑wire NRZ protocol at ~800 kbit/s. Libraries/drivers that work for WS2812B typically work unchanged for WS2813/WS2815. - One caveat: WS2813/WS2815 specify a longer reset (latch) time after a frame (≈280–300 µs) than WS2812B (≈50 µs). Most modern drivers already use a long-enough reset; if yours hard-codes 50 µs you may see occasional glitches on WS2813/15.
- Backup line (BI) function - BI is a redundancy path (“break‑continue”) so downstream pixels can keep receiving data if a single LED’s main DI/DO path fails. - Leaving BI floating at the strip input is fine; the strip will operate normally via DI. - If you want first‑pixel redundancy, you may feed the controller’s data to both DI and BI at the strip input (often just tie them together near the connector, optionally via 100–330 Ω). That way, if pixel 1 dies, pixel 2 can still receive data on its BI line.
- Brightness vs “frequency” - Data rate (800 kHz) only determines how fast you can refresh the pixels; it does not change per‑pixel brightness. - Perceived brightness is determined by each IC’s constant current and PWM duty for R/G/B. Different families may have slightly different per‑channel current and gamma, so absolute max brightness can vary a bit between WS2812B vs WS2815, but that difference is not caused by data frequency and not by using or ignoring BI.
- Voltage and signal‑level points - WS2813: 5 V strip. Data input is 5 V‑logic compatible; many runs work with 3.3 V data over short distances, but a 5 V level shifter is safer. - WS2815: 12 V strip (three LEDs in series per color). Data input is 5 V‑logic compatible. 3.3 V data sometimes works but is marginal; prefer a 5 V data level (use a 74AHCT125/74HCT14 or a MOSFET level shifter) especially with longer leads. - Always share ground between controller and strip. Add a 220–470 Ω series resistor in the data line at the strip end and a bulk capacitor (e.g., 470–1000 µF) across V+ and GND at the strip input.
Current information and practical notes (OBK context) - In OpenBeken, the “SM16703P/WS2812” backend drives WS281x‑type strips. Typical steps: - startDriver SM16703P - SM16703P_Init <pixelCount> [colorOrder] (color order often GRB) - Optional: Anim/AnimSpeed for built‑in effects. - If you switch between WS2812B (5 V) and WS2815 (12 V) hardware, only power wiring changes; data/control commands are the same. Ensure your power supply and injection plan match the strip voltage and length.
Practical guidelines - Short runs, hobby setups: connect DI only; leave BI unconnected; it will work like WS2812B. - Reliability-sensitive installs: tie controller data to both DI and BI at the head of the strip to gain “first‑pixel” redundancy. - Long cables or 3.3 V MCUs: use a 5 V level shifter; keep signal ground solid; add the series data resistor and bulk cap; consider data re‑buffering every few meters.
Possible disclaimers - Vendor “WS2815/WS2815B” variants and clones can differ slightly in timing and max current. If you see odd behavior, increase reset time and verify color order and timing in your driver.
Summary - Backup line: optional. - WS2813/WS2815 work from a WS2812B‑style one‑wire controller. - No dimming due to data frequency; any brightness differences come from LED/driver current characteristics and power distribution, not from using/ignoring BI.
Questions for you - What MCU/controller and data voltage (3.3 V or 5 V) are you using? - Approximate strip length and cable length from controller to strip? - Do you want first‑pixel redundancy, or is basic operation sufficient?
You can call me in any topic by writing @ElektrodaBot. Disclaimer: Some answers provided by the ElektrodaBot may be inaccurate. Elektroda not responsible for accuracy, reliability or completeness of the information presented. All ElektrodaBot responses should be verified by the user. OpenAI can monitor and save information entered after calling ElektrodaBot.
Considering how long are those AI-generated replies, maybe it is easier to just check datasheet:
It seems that BIN (Backup In) is just an optional shortcut around the previous LED, which is used when previous LED is broken, so the signal can continue. A very clever solution, I must admit...
Added after 2 [minutes]:
So, let's consider two scenarios:
1. L2 on my schematic is working - then it gets signal from DI and uses one pixel and forwards rest of the data on DO - ok, everything works. Then Ln on my picture receives that signal and continues
2. L2 on my schematic is broken - then signal on DI gets ignored and output on DO is dead - the strip would usually break at this point, but Ln (next LED) has BI connected to DI (the input) of L2, and Ln detects that L2 didn't send anything on DO, so it switches to DI, and gets signal from before L2. So, one pixel is skipped (L2 is dead), but strip works
Added after 9 [minutes]:
My conclusion: when connecting two strips together, connect DO to DI and BO to BI.
When connecting strip to OBK/WLED/ESP/any controller, connect both DI and BI to signal output.
Otherwise , if you don't connect BI to signal output, and first LED breaks, then you won't get any other LEDs to work (backup lane not connected)
We can try that as well with GPT, altough I would say it does not "create new ones" anyway, it just generates code that statistically fit the patterns from learning data. Still, maybe it would be better to guide it better, as you said.
Good question, I don't have a final idea for that. The main question is whether we put single RGB+CW animations in PixelAnim or separate them? Maybe it would be better to separate them.
I never really give much tought to single LED RGB animations, I feel like there is lesser demand for them. I am rather thinking about "DDP send" backend for PixelAnim or something. I would need to think of code organization for that, but basically, try to design a pluggable system where we can set:
- first 50 LEDs are WS2812
- next 5 LEDs are single DDP packets (specified IP) - RGB bulbs
However I haven't tried it yet, and I don't know much reasonable would that be, how many UDP (DDP runs on single UDP frame) packets can we reasonably send at which framerate
yes, I would like 'new', more, animations. I wonder what that would look like on the main GUI. A drop-down of ones to choose from? A long list of buttons like existing pixelanim?
Could some small code provide a crude sample animation for each on a page full of tiles from which the user can select? hmm
✨ OpenBeken firmware, designed for Chinese WiFi modules with BK7231T, BK7231N, and similar chipsets, introduces a new WS2812 LED driver with an integrated animation system supporting WS2812B and compatible LED strips such as SM16703 and SM15155. The PixelAnim driver, enabled from release 1.17.600, allows per-pixel color control without scripting, and supports RGB IC plus dual PWM channels for Cool White (CW) and Warm White (WW) integration, useful for devices like Action and LSC lights. Users confirmed stable long-duration animation runs and correct color rendering, including GRB strip configurations. The firmware now officially supports SM15155 LEDs, making OpenBeken the first open-source project with this capability. Discussions include hardware considerations for adding CW/WW channels via transistors and resistors, and the possibility of swapping red and green channels for certain strips. Integration with Home Assistant (HA) is under development; currently, manual MQTT button creation is required to control animations, with documentation available for command usage. Future plans include exploring DDP protocol support and expanding animation options, with ongoing testing of RGBCW LED strips (1m, IP65, white PCB) ordered from China. Generated by the language model.
TL;DR: OpenBeken PixelAnim is ready for addressable LEDs: since release 1.17.600, "no scripting is needed" for many WS2812B and SM16703P setups. This FAQ helps OpenBeken users enable the driver, fix GRB color order, wire backup-data strips, and plan MQTT or Home Assistant control from the HTTP panel. [#21101527]
Why it matters: It turns cloud-tied RGBIC devices into locally controlled OpenBeken lights with built-in animations, HTTP control, and expanding multi-backend support.
Option
Setup method
Pin/config detail
Current status in thread
Older per-pixel scripting
Manual scripting
User-defined logic
Already documented separately
PixelAnim + SM16703P
Built-in driver + autoexec.bat
Hardware SPI on P16
Enabled from 1.17.600
RGB IC + double PWM CW
PixelAnim update
RGBIC plus 2 PWM white channels
Added in later thread update
Future DDP/DMX direction
Shared LED backend work
Network or RS485 backend concept
Under active development
Key insight: For most supported strips, PixelAnim works by starting SM16703P and PixelAnim together, then setting the correct color order. The most common real-world fix is changing the strip format to GRB when colors look wrong. [#21115800]
Quick Facts
PixelAnim was explicitly enabled in OpenBeken release 1.17.600 after initial testing, moving it from PR-only availability into release builds. [#21101527]
The minimal startup script uses 3 commands: startDriver SM16703P, SM16703P_Init 16, and startDriver PixelAnim. [#21101474]
The default addressable LED path in this setup uses hardware SPI on pin P16, with no extra pin mapping required. [#21101474]
Long-run stability was confirmed after an animation ran all night and was still working roughly 7 hours 31 minutes later. [#21101563]
BK7238 timing for WS2811 was reported OK again in general release 1.18.159 after appearing too fast in 1.18.145. [#21646220]
How do I enable and configure the PixelAnim driver in OpenBeken for a WS2812B or SM16703P LED strip?
Enable PixelAnim by using a build that includes it, then start both the LED transport and animation driver. In release builds, it was enabled from 1.17.600. Configure the strip with SM16703P_Init, then use the HTTP panel for color or effect control. "PixelAnim" is an OpenBeken animation driver that generates built-in effects for addressable LED strips, using the existing per-pixel LED backend instead of user scripts.[#21101527]
What is PixelAnim in OpenBeken, and how does it differ from the older per-pixel scripting approach?
PixelAnim is the built-in animation system for addressable LEDs in OpenBeken. It differs from the older method because you do not need custom scripting for basic effects. The original post states, "no scripting is needed", while older per-pixel LED control was documented in a separate scripting topic. PixelAnim also integrates with the extended HTTP panel, where you can select single-color mode or predefined animations directly. [#21101474]
Why doesn’t PixelAnim start in some OpenBeken builds, and how can I check whether my firmware includes it?
PixelAnim may not start because some older or custom builds did not include the driver. Check it by opening the command executor and trying to start PixelAnim directly. If it fails, use a build from a PR or compile your own with the required define enabled. Before release 1.17.600, the thread clearly warned that PixelAnim might not yet be available in the main release. [#21101474]
What should an autoexec.bat file look like to start SM16703P and PixelAnim on pin P16 in OpenBeken?
Use this 3-step startup file:
startDriver SM16703P
SM16703P_Init 16
startDriver PixelAnim
That is the exact example shown in the thread. It uses hardware SPI on P16, so no extra pin assignment is required for that setup. After saving autoexec.bat, execute it or reboot the device to expose the extended HTTP panel. [#21101474]
How can I fix wrong colors on a GRB LED strip in OpenBeken using SM16703P_Init?
Fix wrong colors by setting the strip’s color order explicitly to GRB. A user reported that animations looked wrong until they realized their strip was GRB, then confirmed SM16703P_Init GRB made the animations look correct. This is the key fix when red and green appear swapped on WS2812B-like strips. [#21115800]
Why are SM16703P_Init color format arguments case sensitive, and what problems can lowercase values cause on ESP builds?
They are case sensitive because the driver expects uppercase channel letters like R,G,B,C,W. A lowercase format such as grb triggered an explicit parser error, then caused an ESP panic when the user tried Toggle Light. The logged error said Invalid color 'g' in format 'grb', and the device later rebooted after a Guru Meditation Error on 2025-08-17. [#21637465]
How does OpenBeken handle RGB IC plus double-PWM CW devices, such as Action LSC lights with RGBIC and warm/cool white channels?
OpenBeken added PixelAnim support for devices that combine addressable RGB IC LEDs with two PWM white channels. The thread describes these as devices with two PWM pins for cool and warm white plus a WS2812B or similar strip. The author first modeled the setup in the simulator, then posted that PixelAnim had been updated to support RGB IC + double PWM (CW) devices used in some Action LSC lights. [#21101720]
What is DDP in the context of OpenBeken lighting, and how could it be used for bulbs or distributed animations?
DDP is discussed as a future network-based way to distribute animation data between OpenBeken devices. The thread proposes two models: one OBK unit sending pixel data to around 5 to 10 bulbs over UDP, or chained bulbs forwarding the remaining pixel stream. The goal is distributed animations where one controller coordinates multiple RGBW nodes, but the posts present it as an idea under exploration, not a finished feature. [#21646236]
How can I control PixelAnim animations from Home Assistant over MQTT before Home Assistant Discovery support is added?
Control them manually by creating a Home Assistant button that sends OpenBeken commands over MQTT. The thread says Discovery support for animation selection is not ready yet, so you must define the control yourself. The maintainer explicitly told users to build the button manually and test commands first in the OBK command line before moving them into Home Assistant. [#21384322]
Where can I find the OpenBeken commands for selecting or triggering PixelAnim effects from the command line or Home Assistant?
Find them in the OpenBeken commands.md documentation and test them first in the device command line. The maintainer answered this directly when asked what MQTT command exposes individual animations for Home Assistant. That makes the command-line interface the first validation step before using the same commands through MQTT automation or dashboard buttons. [#21386723]
How does SM15155 support in OpenBeken compare with SM16703P or WS2812B support for addressable LED strips?
SM15155 support was added later as an extension of the same addressable LED work, not as a replacement for SM16703P or WS2812B support. After refactoring the SPI DMA backend, the maintainer added SM15155 support and then merged it. A WS2812B user tested the related binary and reported animation colors and the color picker still behaved correctly after the change. [#21116231]
What troubleshooting steps help when WS2811 or WS2812 animation timing looks too fast or inconsistent on BK7238 and other OpenBeken targets?
Start by comparing behavior across firmware versions and hardware targets. One tester reported BK7238 WS2811 timings were too fast on 1.18.145, but looked correct again on 1.18.159 and the related PR build. Cross-checking another target also helped: the same PR was later confirmed working on BK7231N, BK7238, BL602, and ESP32-C3. [#21646220]
How could support for RGBIC + CCTIC LED strips based on SM16703 be implemented or configured in OpenBeken?
The thread suggests implementing it by extending the same combined architecture already used for RGB IC plus dual-PWM white channels. That means reusing the addressable RGB path and pairing it with separate white-channel control, rather than treating it as a basic single-mode strip. A later user asked specifically about RGBIC + CCTIC on 2024-12-22, but the thread does not show a final, published configuration example for that exact strip class. [#21359224]
When wiring WS2813 or WS2815 strips, how should DI, BI, DO, and BO be connected for first-pixel backup and controller compatibility?
Connect DO to DI and BO to BI between strips. At the controller end, connect the controller signal to both DI and BI if you want first-pixel backup. The thread’s conclusion says leaving BI unconnected at the first pixel removes the backup path if that first LED fails. This wiring preserves the bypass behavior that keeps the rest of the strip working when one pixel dies. [#21653933]
What naming makes the most sense for shared per-pixel LED APIs in OpenBeken: LED_Start, Strip_Start, PIX_Start, or something else?
Strip_Start and related Strip_ names were the preferred direction in the thread. The maintainer considered renaming core per-pixel functions to LED_Start, then to Strip_Start, while another participant argued strip could imply non-addressable LEDs and suggested ALED_, PIX_, or DLED_. The latest stated preference was clear: "I will probably use Strip_ prefix". [#21647617]
