[BK7231N - CBU] Teardown of Aldi (Australia) CasaLux Smart Led Corner Lamp

MnM1 29 Nov 2023 18:05 30 7161 Cool? (+1)

📢 Listen (AI):

TL;DR

Teardown of the Aldi Australia CasaLux Smart Led Corner Lamp, a Tuya-based corner lamp built around a BK7231N CBU module.
The lamp exposes Tuya controls for switch, work_mode, colour_data, music, RGB_order, LED_QTY, dynamic_mod, and scene_mod, with the PCB driving an LED strip.
Tuya IoT lists DP IDs 20, 21, 24, 28, 102, 103, 104, 106, and 108, including LED_QTY set to 30 and bv 40.00.
A Tuya firmware backup and OBK config extraction found no meaningful pin or module data, suggesting TuyaMCU or a custom controller; OBK has not been flashed yet.

Generated by the language model.

I got a couple of Aldi (Australia) CasaLux Corner Lamps.

There is no product URL that I can find anymore but the box looks like this:

After I added it to Tuya app this is what options are in it:

The DP Ids I have found in Tuya IoT are:

{
  "result": {
    "properties": [
      {
        "code": "switch_led",
        "custom_name": "",
        "dp_id": 20,
        "time": 1701165459278,
        "value": false
      },
      {
        "code": "work_mode",
        "custom_name": "",
        "dp_id": 21,
        "time": 1701163432151,
        "value": "dynamic_mod"
      },
      {
        "code": "colour_data",
        "custom_name": "",
        "dp_id": 24,
        "time": 1696248937973,
        "value": "003d03d40386"
      },
      {
        "code": "control_data",
        "custom_name": "",
        "dp_id": 28,
        "time": 1696232883464,
        "value": ""
      },
      {
        "code": "music",
        "custom_name": "",
        "dp_id": 102,
        "time": 1696247788543,
        "value": "424"
      },
      {
        "code": "RGB_order",
        "custom_name": "",
        "dp_id": 103,
        "time": 1701163432162,
        "value": 1
      },
      {
        "code": "LED_QTY",
        "custom_name": "",
        "dp_id": 104,
        "time": 1701163432172,
        "value": 30
      },
      {
        "code": "dynamic_mod",
        "custom_name": "",
        "dp_id": 106,
        "time": 1701163432151,
        "value": "043263000003e803e8007803e803e800f003e803e8"
      },
      {
        "code": "scene_mod",
        "custom_name": "",
        "dp_id": 108,
        "time": 1696247502001,
        "value": "CJ_YS"
      }
    ]
  },
  "success": true,
  "t": 1701276246105,
  "tid": "829cbbd58ed611ee83c62e7e80387ed3"
}

When turned on this is how the device works:

After opening a few screws from the base I got to the PCB:

And there is a CBU module:

Below are some pics of the led strip used in this device:

Next got my hacking kit out and got a Tuya firmware backup (attached):

OBK configuration extraction did not reveal anything useful - must be TuyaMCU in there somewhere

{
	"abi":"0",
	"id":"null",
	"swv":"1.0.0",
	"bv":"40.00",
	"pv":"2.2",
	"lpv":"3.3",
	"pk":"didby1zofoliihp5",
	"firmk":"null",
	"cadv":"1.0.4",
	"cdv":"1.0.0",
	"dev_swv":"1.0.0",
	"s_id":"null",
	"dtp":"0",
	"sync":"0",
	"attr_num":"1",
	"mst_tp_0":"9",
	"mst_ver_0":"1.0.0",
	"mst_tp_1":"0",
	"mst_ver_1":"null",
	"mst_tp_2":"0",
	"mst_ver_2":"null",
	"mst_tp_3":"0",
	"mst_ver_3":"null }`)LAgw_wsm3&WAwf_start_mdll",
	"md":"0",
	"random":"0",
	"wfb64":"1",
	"stat":"0",
	"token":"null",
	"region":"null",
	"reg_key":"null",
	"dns_prio":"03{nc_tp",
	"ssid":"null",
	"passwd":"null",
	"ap_passwd":"null",
	"country_code":"null",
	"bt_mac":"null",
	"bt_hid":"null",
	"prod_test":"false",
	"fac_pin":"mzlyh8vz7p33qbz9 "
}

Sorry, no meaningful pins data found. This device may be TuyaMCU or a custom one with no Tuya config data.
No module information found.
And the Tuya section starts, as usual, at 2023424

I have not flashed OBK to it yet.
Just wanted to see first what is possible to do with this device.

@pkaczmarek2 - again looking for your guidance to see how I can config this device with OBK.

Attachments:

readResult_BK7231N_QIO_AldiCornerLamp_2023-29-11-23-47-46.bin (2 MB) You must be logged in to download this attachment.

About Author

MnM1 wrote 175 posts with rating 13 , helped 4 times. Been with us since 2023 year.

Comments

Add a comment

p.kaczmarek2 29 Nov 2023 18:08

Hello, can you check where is the data signal of LEDs connected? I think it may be connected to P16, which means there is a WIFI module driving LEDs directly, without TuyaMCU. Check Tuya docs to see where... [Read more]

MnM1 29 Nov 2023 18:24

The data pin seems to go into the unmarked black chip. Not sure if it goes to P16 (marked in red which actually is RX1) from there. https://obrazki.elektroda.pl/3997244000_1701278465_thumb.jpg ... [Read more]

p.kaczmarek2 29 Nov 2023 18:32

You have marked RX, not P16. There is a difference between pin 16 on image and P16 of BK: P16 (SPI_MOSI) used to control LEDs directly is a pin 2 on the CBU image. https://obrazki.elektroda.pl/... [Read more]

MnM1 29 Nov 2023 18:40

I see what you mean - my bad There seems to be a trace coming out of P16: https://obrazki.elektroda.pl/4514204600_1701279587_thumb.jpg Seems to be going to the black chip under HR1 [Read more]

p.kaczmarek2 29 Nov 2023 18:43

This is RGB + W device, right? So RGB LEDs are addressable and W is driven via PWM? [Read more]

MnM1 29 Nov 2023 18:45

RGB LEDs are addressable. But not sure if W is PWM - how can I tell? The device is still hooked up - if you think there is something to work on I can flash it to OBK. I have a tuya backup as a last... [Read more]

p.kaczmarek2 29 Nov 2023 18:55

Does the brightness of all white LED always change together? Or can it display different brightness levels per LED? I don't know if OBK supports it, I think we can do some short tests and then restore... [Read more]

MnM1 29 Nov 2023 18:59

As attached to the original post - I think I have the correct back up? https://obrazki.elektroda.pl/7394011900_1701280755_thumb.jpg [Read more]

p.kaczmarek2 29 Nov 2023 19:03

It seems correct, you can try to flash OBK and for a good start play with GPIO doctor, maybe one of the pins is a simple PWM to control white level. There is 6 available PWMs on CBU, so there is not... [Read more]

MnM1 29 Nov 2023 19:10

OK will do. I tried to dim the white light via Tuya app and all whites dimmed together. We will see what happens in OBK next :) BTW - so you dont end up waiting for me - Ill flash it and go to bed.... [Read more]

p.kaczmarek2 29 Nov 2023 19:30

Once we finish testing with the GPIO doctor, we will also proceed to test the LEDs with current SM16703 driver. I tested it with WS2812 once, and it was somewhat working, but it wasn't perfect. [Read more]

MnM1 30 Nov 2023 01:30

GPIO Doctor shows that PIN6 = PWM. It controls the white color. https://obrazki.elektroda.pl/8478829600_1701304234_thumb.jpg Toggle and brightness work fine. [Read more]

p.kaczmarek2 30 Nov 2023 01:46

Ok, now try: 1. Start driver startDriver SM16703P 2. Init Driver - replace 64 with number of LEds SM16703P_Init 64 3. Set Pixel SM16703P_SetPixel 1 255 0 0 SM16703P_SetPixel 2 0 255 0 SM16703P_SetPixel... [Read more]

MnM1 30 Nov 2023 01:59

OK, I get this: https://obrazki.elektroda.pl/9989825700_1701305873_thumb.jpg The first 3 LEDs are cool white. The second lot of 3 LEDs are RED. The third lot of LEDs are GREEN. The fourth lot of... [Read more]

p.kaczmarek2 30 Nov 2023 02:08

You can try script from this post: https://www.elektroda.com/rtvforum/viewtopic.php?p=20734037#20734037 So the proof of concept works... [Read more]

MnM1 30 Nov 2023 02:50

OK, if I add that code below to autoexec.bat, I restart the device and nothing happens. I think I am doing something wrong. setChannel 10 1 again: addChannel 10 1 SM16703P_SetPixel $CH10-2 0 0 255 SM16703P_SetPixel... [Read more]

MnM1 07 Dec 2023 00:52

@pkaczmarek2 - Would you have some time to see if we can progress the work on this? Cheers :) [Read more]

p.kaczmarek2 07 Dec 2023 09:08

I will try to look into it soon, but today I am finishing RN8209C driver: https://www.elektroda.com/rtvforum/viewtopic.php?p=20840241#20840241 On your side, I will most likely first do that CW/RGB separation... [Read more]

MnM1 31 Dec 2023 03:12

Hi @pkaczmarek2 - any progress on this yet? [Read more]

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 SM16703P
SM16703P_Init 90
startDriver 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.