FAQ
TL;DR: With a 2MB backup already secured, this Aldi Australia CasaLux corner lamp is a good OpenBeken test case: "the proof of concept works" for direct BK7231N-driven RGB pixels plus a separate white PWM channel. This FAQ helps modders identify GPIOs, confirm PWM vs addressable LEDs, and debug SM16703P/Pixel Animation issues before or after flashing. [#20839567]
Why it matters: This thread shows a practical path from safe teardown to partial OpenBeken support on a mixed RGB plus white smart lamp, including the exact failure modes that matter during real device conversion.
| Aspect |
Direct BK7231N drive |
Separate TuyaMCU |
| LED data path |
Suspected from BK7231N P16 to LED driver area |
Would pass through a dedicated MCU |
| OBK pin extraction |
May show no useful pins |
Often also hides usable GPIO mapping |
| White channel |
Confirmed as PWM on Pin 6 |
Often abstracted behind MCU commands |
| Best test method |
GPIO Doctor + SM16703P driver |
Protocol analysis first |
Key insight: The lamp does not behave like a pure TuyaMCU design. The thread confirms one white channel on PWM Pin 6, while the RGB section behaves like directly driven addressable LEDs that became much more stable after the February 2024 SPI DMA fix. [#20966217]
Quick Facts
- The device backup was treated as valid because a full 2MB flash dump existed before OpenBeken testing, which was explicitly called "very important" for restoring Tuya later. [#20839047]
- Tuya IoT exposed these notable datapoints: DP 20
switch_led, DP 21 work_mode, DP 24 colour_data, DP 102 music, DP 103 RGB_order, DP 104 LED_QTY = 30, DP 106 dynamic_mod, and DP 108 scene_mod. [#20838962]
- GPIO Doctor identified Pin 6 = PWM, and that PWM controlled the lamp's white LEDs with both toggle and brightness working correctly. [#20839555]
- OpenBeken test commands initially used SM16703P_Init 64, then 87, then the exact strip length 90 LEDs; wrong behavior included white groups, color shifts, pauses, and freezes. [#20839562]
- A later test used firmware 1.17.764 for BK7231N with
startDriver SM16703P, SM16703P_Init 90, and startDriver PixelAnim, but the fire animation still looked wrong and Flag 4 made the Color Temp slider turn LEDs off. [#21286785]
How do I identify the GPIOs on a BK7231N CBU module in an Aldi Australia CasaLux Smart LED Corner Lamp before flashing OpenBeken?
Identify GPIOs by tracing PCB connections from the CBU module pads, not by guessing from the lamp app. In this thread, the critical check was whether the LED data line reached BK7231N P16, while the white channel was later found separately with GPIO Doctor. A safe workflow is: 1. Photograph both PCB sides. 2. Trace pads from the CBU module to the LED driver area. 3. Verify candidates after flashing with diagnostic tools. That avoids mislabeling pads and missing the real LED path.
[#20839065]
What is TuyaMCU, and how can I tell whether a CBU-based smart lamp uses TuyaMCU or drives the LEDs directly from the BK7231N?
"TuyaMCU is a control microcontroller that handles device functions behind Tuya commands, hiding direct GPIO behavior from the Wi-Fi module." A CBU lamp likely drives LEDs directly when a BK7231N pin, such as P16, traces toward the LED driver area and OpenBeken can control outputs locally. In this case, the expert suspected direct BK control because P16 appeared connected toward the black chip under HR1, not a visible TuyaMCU control path.
[#20838967]
Why did the OBK configuration extraction show no useful pin data on this CasaLux corner lamp even though a Tuya firmware backup was made successfully?
The backup succeeded because flash reading and pin extraction are different tasks. OpenBeken extracted the Tuya section starting at
2023424, but reported no meaningful pin data and warned that the device might use TuyaMCU or a custom layout. That means the flash contained firmware data, yet not a usable GPIO map for automatic configuration. A valid backup does not guarantee a readable pin template.
[#20838962]
What is GPIO Doctor in OpenBeken, and how do I use it to find which pin controls the white LEDs on a BK7231N device?
GPIO Doctor is an OpenBeken test tool that probes pins to find real hardware functions, such as PWM outputs. In this lamp, it showed
Pin 6 = PWM, and that PWM controlled the white LEDs correctly. Use it in three steps: 1. Flash OpenBeken after making a full backup. 2. Run GPIO Doctor and test available PWM-capable pins. 3. Watch for white LED toggle and brightness response. That gives a direct pin assignment instead of relying on Tuya metadata.
[#20839555]
How can I confirm whether the white channel on this RGB plus white corner lamp is PWM-controlled while the RGB LEDs are individually addressable?
Confirm it by checking whether all white LEDs dim together while RGB behavior stays per-pixel. In this thread, the user reported that all white LEDs changed brightness together in the Tuya app, and GPIO Doctor later confirmed the white output on
Pin 6 PWM. Separately, SM16703P pixel tests changed RGB groups independently, which is the hallmark of addressable LEDs rather than one shared analog RGB channel.
[#20839071]
What is the correct OpenBeken startup script for testing an SM16703P LED strip with 90 LEDs on a BK7231N CBU module?
The thread's clean 90-pixel startup script was:
startDriver SM16703PSM16703P_Init 90startDriver PixelAnim
This exact script was used later on firmware 1.17.764 for BK7231N when testing Pixel Animation on the CasaLux lamp. Earlier ad hoc scripts also worked for proof-of-concept testing, but this three-line startup was the stated baseline for a full 90-LED configuration. [#21286785]
Why do SM16703P test commands on this CasaLux corner lamp make the first groups of LEDs stay white while red looks purple and the animation later freezes or crashes?
Those symptoms point to an early driver or timing mismatch, not a simple GPIO mistake. The lamp showed grouped whites, a red channel that looked purple, long pauses, and freezes after loops when tested with
87 or
90 LEDs. Later, the maintainer stated that individually addressable LEDs were fixed and then confirmed the
SPI DMA driver bug had been fixed, specifically improving SM16703P and WS2812-class LEDs. That makes the original white-group and freeze behavior consistent with a pre-fix driver issue.
[#20966217]
How do I safely back up the full 2MB Tuya firmware from a BK7231N CBU device so I can restore it after OpenBeken testing?
Make the full flash backup before any OpenBeken write, and verify that the dump is
2MB. The expert explicitly said this size was very important so the original Tuya firmware could be restored later. A safe process is: 1. Connect your BK7231N flashing adapter. 2. Read and save the entire 2MB flash. 3. Confirm the file size before testing OBK. In this thread, that backup was accepted as correct before flashing continued.
[#20839047]
What’s the difference between pin 16 on the CBU module drawing and BK7231N P16, and why does that matter for tracing the LED data line?
They are not the same thing, and mixing them up breaks tracing. The maintainer corrected the user by explaining that
BK7231N P16 is a GPIO function name, shown on
pin 2 of the CBU module image, while the user's first red mark pointed to
RX1 instead. That matters because the LED data path needed to be traced from BK P16 specifically, not from the module's physical pad numbered 16 or a nearby serial pin.
[#20838996]
How does driving addressable LEDs directly from BK7231N P16 compare with using a separate TuyaMCU for an RGBW smart lamp?
Direct BK7231N drive gives you a clearer OpenBeken path because the Wi-Fi SoC can generate LED data itself. In this thread, the maintainer suspected P16 might drive the RGB pixels directly, while the white LEDs sat on a separate PWM output. A TuyaMCU design would instead hide those details behind MCU messaging and make pin extraction less useful. For mixed RGBW lamps, direct BK control simplifies RGB testing, but the separate white channel still needs its own PWM mapping.
[#20839019]
Why does the Pixel Animation fire effect look wrong on the CasaLux Smart LED Corner Lamp under OpenBeken 1.17.764, especially with the white LEDs behaving oddly?
Because this lamp mixes addressable RGB pixels with a separate white channel, generic pixel effects can map poorly if CW handling is not separated correctly. On firmware
1.17.764, the user reported that the fire effect looked visibly wrong, even without flags enabled, and that white behavior remained suspicious. Earlier thread history already showed mixed-channel quirks on this lamp, so a bad fire effect is consistent with unresolved RGB/CW separation rather than a total driver failure.
[#21286785]
What happens when I enable Flag 4 in OpenBeken Pixel Animation on this lamp and the Color Temp slider turns all LEDs off, and how should that be debugged?
Flag 4 made the Color Temp slider turn all LEDs off, which suggests the lamp's white path does not match the expected Pixel Animation CW mapping. Debug it by isolating functions: 1. Test plain RGB colors from the web UI. 2. Test the white PWM channel separately. 3. Re-enable Flag 4 only after confirming both paths. The user reported that without flags the animation still ran, but enabling Flag 4 made the Color Temp control extinguish the LEDs instead of adjusting white output.
[#21286785]
How should SM16703P_SetPixel commands be used after starting SM16703P and PixelAnim, and why might commands like SM16703P_SetPixel all 255 0 0 appear to do nothing?
Use
SM16703P_SetPixel only after the driver is started and initialized, and verify no other animation layer is overriding the output. The maintainer explicitly questioned whether
SM16703P_SetPixel all 0 0 255 was being run after
startDriver SM16703P,
SM16703P_Init 90, and
startDriver PixelAnim, because PixelAnim or smooth transitions could mask the manual command. In this thread, web-interface color changes worked, but the direct
all commands appeared inactive under that active PixelAnim setup.
[#21384688]
What is SM16703P, and how is it different from WS2812B when configuring addressable LEDs in OpenBeken?
"SM16703P is an addressable LED driver class that OpenBeken can drive similarly to WS2812B, but device-specific timing and implementation details still matter." In this thread, the maintainer said the current SM16703 driver had once worked only imperfectly with WS2812, then later stated that the fixed SPI DMA path made
SM16703P/WS2812B/etc work well. In practice here, OpenBeken treated them as related pixel-driver families, but stability depended on firmware maturity.
[#20966217]
What exact reproduction steps and wiring details should I provide when reporting an OpenBeken LED animation bug on a mixed CW plus addressable RGB lamp?
Provide a minimal startup script, exact firmware version, LED count, command sequence, and a wiring description of how CW LEDs connect. The maintainer asked for reproduction steps and specifically requested a schematic or clear drawing showing how the CW LEDs were attached, because he could not diagnose the issue without the device on site. Include at least these facts:
firmware 1.17.764,
SM16703P_Init 90, whether web colors work, whether
SetPixel all works, and what Flag 4 does.
[#21384688]
Generated by the language model.
