BK7238 LED Ceiling Light (RGBIC+CCT) – Home Assistant Integration?

Hi,

I bought 3x of these ceiling lights from AliExpress:
https://www.aliexpress.com/item/1005009635507929.html

Specs:
• WiFi + BLE (2.4GHz)
• Chip: BK7238 (Beken)
• 5 channels: RGBIC + CCT
• Main white panel (3000K / 4000K / 6000K)
• Secondary RGBIC ring (effects / ambient light)

⸻

Current situation
• Device works fully in the BRITURN app
• Also discovered via Magic Home app, but:
• Only ON/OFF works
• No control of RGB / CCT / effects
• Home Assistant:
• Tried Flux LED (Magic Home) integration → fails: "Unknown Model FBF615. Cannot determine protocol"

Observations
• Device exposes a local WiFi AP (unconfigured mode)
• After pairing → gets IP, but protocol seems non-standard
• Likely custom firmware, not pure MagicHome-compatible

According to HA docs, Flux/MagicHome only works if the protocol matches known controllers... which doesn’t seem the case here.

Any clue how to flash it, integrate it?

PLEASE HELP

You can flash it with OpenBK7238, but doing so requires desoldering the module. RX/TX pins are on the back of the module.
RGB would be easy, since it uses addressable LEDs (DO pin). You would only need to count how many RGB LEDs there are.

If you decide to go that way, always take backups of the original firmware.

>>21884139 >>21884139

Thanks @insmod!!

Yesterday night, I flashed it with OpenBK7238.

Instead of desoldering the module, I tried the side GPIOs, and it worked great!!

1. I made a backup of the original firmware (attached file).
2. Flash with OpenBK7238 old version > boot crashed.
3. Flash again with your last version of OpenBK7238 merged > all working!! Great job @insmod

4. Now the challenge is setup the modules of it.

I will count the LEDs and try to discover more...

Hi all,

I wanted to share my findings after spending quite a bit of time trying to get a BK7238-based RGBIC CCT ceiling light working with OpenBeken.

This is the typical Tuya-style unit with:
• Main CCT white panel (warm/cold)
• Outer addressable RGB ring (RGBIC)

⸻

Hardware details
• Module: WB43-M5 v1.2
• Main chip: Beken BK7238
• PCB: HD-ZJZM24W-HC
• RGB ring: 38 LEDs (addressable, likely SM16703P or similar)

What works ✅

After a lot of trial and error, I managed to get the main white light fully working.

Pin configuration:

P6 -> PWM -> channel 1 (cold)
P8 -> PWM -> channel 0 (warm)

Startup command
backlog setChannelType 0 cwww

This gives full control of:
• Brightness
• Colour temperature

So the CCT driver side is confirmed working and stable.

⸻

What does NOT work ❌

The RGBIC ring does not work at all with the current firmware build.

Attempted configuration

Tried assigning GPIOs as:
SM16703P_DIN

Attempted commands:
SM16703P_Init 38 GRB
SM16703P_SetPixel all 255 0 0
SM16703P_Start

All return... cmd ... NOT found
CMD: cmd SM16703P_Init NOT found

It looks like:

The “merge” build fixes BK7238 booting, but was compiled without addressable LED (pixel) support.

any clue @insmod on these??

>>21884507
Update to last OpenBK7238 version, 1.18.287
Before using SM16703P commands, first use "start driver SM16703P"

Thanks again @insmod, updating to the latest firmware did indeed enable the RGB driver.

I’ve updated to the latest OpenBeken version:
• Version: 1.18.287
• Driver init: startDriver SM16703P; SM16703P_Init 38 GRB

Hardware observation

This appears to be a 2-in-1 lighting device controlled by a WB43-M5 v1.2 (BK7238):
• Channel 1: Main white LED (CCT / brightness)
• Channel 2: Addressable RGB LEDs (SM16703P)

So physically, there are two independent lighting systems behind a single controller.

What works
• SM16703P driver is functioning correctly
• RGB strip responds properly to: SM16703P_SetPixel all R G B; SM16703P_Start
• White channel works, but only if the driver is stopped. So with driver stopped white works in full (control colour and brightness sliders), when driver start, the white colour slider disapear and a box, that when clicked opens a colours picker for the RGB lights.

The issue (firmware-level)

The firmware exposes everything as a single light entity.

As a result:
• The device behaves like a merged light
• Only the primary (white) channel is properly represented
• The RGB strip is not mapped to its own logical light

Root limitation

The current firmware model seems to assume: One device = one light

But this hardware is clearly: One device = two independent lights

Because of this:
• The RGB driver works, but has no entity-level representation
• There is no separation between white and RGB control paths

Expected behaviour

Ideally, the firmware should allow:
• Multiple light entities per device, e.g.:
• Light_Master_Bedroom_White
• Light_Master_Bedroom_RGB
• Binding SM16703P to its own logical light output
• Independent control of both channels

P26 is set to use the SM16703P_DIN

On Home Assistant mqtt this is the discovered attributes:

min_color_temp_kelvin: 2000
max_color_temp_kelvin: 6493
supported_color_modes: color_temp
friendly_name: Light Master Bedroom Light
supported_features: 0
color_mode: color_temp
brightness: 255
color_temp_kelvin: 2000
hs_color: 30.601, 94.547
rgb_color: 255, 137, 14
xy_color: 0.598, 0.383

Added after 3 [minutes]:

This is how it looks like working:

Yes, it shows as a single light entity, and using RGB disables CW and vice-versa.
But only if cold white is set to channel 3, and warm - channel 4. That way there's no need to disable SM16703P driver.

@p.kaczmarek2
Any suggestions?
At the very least it would've been good to be able to control SM16703P via channels, and be able to manually set up 2 separate entities in HA.

I started to make some AI slop here to maybe address the issues with the odd LSC devices with WS2812B+PWM CW/WW RGBIC+CCT strips https://github.com/openshwprojects/OpenBK7231...p/compare/main...divadiow:OpenBK7231T_App:lsc

but I lost confidence and interest, so dunno.

The main issue is backwards compatibility. We can't break existing configs so we would need to update LED driver carefully.

Maybe add a flag to allow split?

Question: do we want two separate light entities or a single light entity that can work in RGBCW mode (all LEDs on)?

Maybe we could instead add a custom WS2812 HA integration that works separately and keep main LED driver intact?

>>21884900

Current scenario: global controls

Device
└── ONE Light (global & messy controls)
├── PWM warm white (P6)
├── PWM cold white (P8)
└── SM16703P_DIN (P26)

Result:
- All control happens at the same global light level
- RGB is not isolated from the white channels
- Enabling RGB affects white light control on UI (the slider works only for the RGB, not the white)

A few options would be:

Proposed solution 1: one light with sub-controls
Device
└── ONE Light
├── White controls
│ ├── PWM warm white (P6)
│ └── PWM cold white (P8)
└── RGB controls
└── SM16703P_DIN (P26)

Result:
- One light entity kept for compatibility
- White and RGB can be controlled independently inside the same light
- Both systems can coexist. Home Assistant MQTT could create a virtual device if needed

Proposed solution 2: split into two lights
Device
├── Light 1: White light
│ ├── PWM warm white (P6)
│ └── PWM cold white (P8)
└── Light 2: RGB light
└── SM16703P_DIN (P26)

Result:
- Two separate light entities
- White and RGB are fully independent
- Matches the hardware layout more directly

A flag that allows any of these solutions would be great!!

Or the attribution of a different channel for the P26 > SM16703P_DIN > Channel 2, for example, to isolate it from channels 0 and 1 (cold/warm whites)?

On BK7238 SM16703P_DIN is hardcoded to P16, no matter what is set in GUI.
If you remove it, nothing would change.
Internally, it uses channel 0, 1, 2 for RGB, meaning you can't use them while the driver is running.
Channels 3 and 4 are reserved for cold and warm white.

You can set warm/cold channels to anything higher than 4, and then manually create a light in HA configuration.yaml that would use them.

excuse the interruption. just adding the dump boot log for the record

Hey guys,

I’ve been experimenting with the firmware and managed to put together a solution that better reflects how these hybrid RGB + CCT devices are actually wired.

What I did

I introduced a new driver concept called virtualLights, which splits the global light control into two independent logical lights.

Instead of a single combined entity, the device is now exposed as:

Device
├── Light 1: White light
│ ├── PWM warm white (P6)
│ └── PWM cold white (P8)
└── Light 2: RGB light
└── SM16703P_DIN (P16)

How it works

* White (CCT) → standard PWM channels
* RGB → handled by SM16703P (addressable LEDs over SPI)
* virtualLights driver → splits control into two independent entities

Startup configuration

This is the current startup setup:
backlog startDriver SM16703P; SM16703P_Init 38 GRB; SM16703P_Start; startDriver VirtualLights; VirtualLights_Enable 1;

Result

* Two separate light entities
* White and RGB fully independent
* No mode conflicts (e.g. white vs RGB overrides)
* Better alignment with the actual hardware design

Design note

The virtualLights split can be optional.

The idea is to make it a flag-based feature, so users can choose:

* VirtualLights_Enable 1 → split into two lights
* VirtualLights_Enable 0 → fallback to classic single light behavior

This keeps backward compatibility while enabling a more accurate setup for devices that need it.


Next steps

If there’s interest, I can prepare a pull request with the changes (driver + integration).

Happy to get feedback or adjust the implementation 👍

How it looks like:


Firmware > OpenBeken7238 OpenBeken7...Lights.zip (2.1 MB)You must be logged in to download this attachment.

oh wow. this looks cool.

and if you decide not to start VirtualLights driver, does SM16703P behave as it did originally in all ways? I'm just wondering what the impact would be for anyone with a fully-configured device for basic SM16703P operation if they OTA to a release that includes code changes for this if it was merged.

Please open a PR so I can compare it, also, does it still pass self tests?