How can I configure a BK7231N CBU LED panel in OpenBeken when BK7231Flasher identifies it as a TuyaMCU device but does not extract GPIOs?
This lamp is a TuyaMCU-based device, so the right path is to map its dpIDs instead of hunting for raw GPIOs; the flasher did extract useful info, including the TuyaMCU baud rate, and the device can be driven with OpenBeken’s TuyaMCU support [#20610467] The important dpIDs are 20 = on/off, 21 = mode (0 white, 1 RGB), 22 = white brightness, 23 = white temperature, 24 = RGB color data, and 25 = scene data; the Tuya developer specification confirmed those values exactly [#20615058][#20649138] For a working setup, use `startDriver TuyaMCU` and `tuyaMCU_setupLED 24 1`, then let OpenBeken handle RGB/CCT through the TuyaMCU backend [#20646461][#20648624] The RGB color packet for dpID 24 is an HSV-style string, and sending colors through `tuyaMCU_sendColor 24 R G B 1` was verified to work; `tuyaMcu_sendState` works for dpID 22 and 23 with values in their documented ranges [#20616970][#20634848][#20663466] One practical fix was adding a short delay between TuyaMCU packets, because the lamp ignored or mis-processed back-to-back writes; a 50 ms delay made brightness and temperature control work reliably [#20656924][#20663295][#20663466] After that, the device worked in OpenBeken and Home Assistant, and the remaining tweak was reversing CCT because the warm/cold direction was swapped [#20648624][#20720643][#20721679]
Hello, first thanks for your great work. I tried to flash 3 different types of LED lamps so far with openbeken. 1 works great, 2 not. In this thread i ask for help for my first problem LED:
i identified the CBU chip, connected the serial adapter and saved the firmware. The BK7231Flasher was not able to extract the GPIO informations from the firmware.
Then i flashed the firmware suggested by the flasher. Success, but now i have to configure the GPIO pins, where i don't have experiences. I already tried the GPIO doctor, but i didn't get any reaction from the lamp while wildclicking.
From here i ask you how to go further.
If i remember correctly, i could open a tuya developer account, flash back the original firmware, register the device with the tuya developer account and try there to get more infomartions about the device. Would i get there the necessary informations, is this the way to go ?
I am really not sure.
I am attaching some pics and the saved firmware.
Greetings Torsten
Attachments:
readResult_BK7231N_QIO_CBU_2023-07-6--09-58-19.bin(2 MB)
You must be logged in to download this attachment.
and try to guess/play around with dpIDs, but I must admit, I haven't seen many LED TuyaMCU devices. So maybe original packets capture can help.
In general, it's a bit strange device. As I just said, most of LEDs devices are not TuyaMCU, they are either raw PWM or "I2C" LED drivers like SM2135, SM2235, BP5758D, etc.
In case of your lamp, if you don't want to use TuyaMCU, you could maybe inspect the PCB and with some electronics knowledge you could figure out which LED drivers are used and interface them with PWM IOs of the BK7231N. Maybe that could work. Just remove TuyaMCU and convert device to raw PWMs.
( startDriver TuyaMCU was already placed somewhere else, as the driver was already loaded )
In fact this works, although the respnsiveness is sometimes not the best.
Now i think the harder parts.
dpId 21, dataType 4-DP_TYPE_ENUM and 1 data bytes
raw data 1 byte:
dpId 22, dataType 2-DP_TYPE_VALUE and 4 data bytes
raw data 4 int: 367
dpId 23, dataType 2-DP_TYPE_VALUE and 4 data bytes
raw data 4 int: 182
dpId 24, dataType 3-DP_TYPE_STRING and 12 data bytes
dpId 25, dataType 3-DP_TYPE_STRING and 2 data bytes
21: probably switch between RGB and white ?
22: brightness ?
23: Kelvin value of white ?
24: RGB value in a string variable ?
25: ?
... yes, sniffing the MCU traffic would be helpful now
Edit:
yes, 21 switches the color modes, i use additionally in the autoexec.bat
If you link channel 15 to some dpID, and use this command, then value 200 will be send to dpID linked to channel 15.
You can use this during testing and development.
dpId 24, dataType 3-DP_TYPE_STRING and 12 data bytes
I think I will add a new channel type for you here. Don't worry, I am online every day, I will do my best to get your device running. It's just that.... it's a first TuyaMCU LED I ever saw. Your device is very unique, that's why we need to do some little work before it will be working.
I will now update tuyaMcu_sendState command to also support strings. Do you happen to know (or is it in Tasmota docs?) how the values of dpID24 looks like here? If it's a 12 bytes of data, then it's not just an RGB string like "FF0000" for red, because it is just 6 bytes. Is it RGBHSV?
With latest update (update your obk first), you can try:
this should send that string to dpID 25 (3 is a data type string). This will work without mapping. This is for testing only, I think. Let me know if that command works for you.
Setting 23 to a value sets the colormode (dpId 21) to 0 (white) and
changes the colortemperature of white.
The range is from 10 (ww) to 990 (cw).
How did i find the range ? I did set the value to 2000, which
is out of range. Then i changed the colormode in the webinterface
to RGB and then back to white and switched off and on (by using dpId 20).
It seems the TuyaMCU checks in this case
the entered min-max values and sets the allowed max and min value, if it's out of range.
So in my case, the value changed from 2000 to 990.
Setting 22 to a value sets the colormode (dpId 21) to 0 (white) and
changes the brightness of white.
The range is from 50 (dark) to 1000 (light).
TuyaMCU uses different types of RGB Hex format where the most recent is 0HUE0SAT0BRI0 (type 1) and the older being RRGGBBFFFF6464 (type 2). Depending on the MCU, code can be case sensitive.
After enabling the RGB function check the TuyaReceived information and use TuyaRGB to configure and store the correct (or the closest) format:
TuyaRGB 0 - Type 1, 12 characters uppercase. Example: 00DF00DC0244 (default)
TuyaRGB 1 - Type 1, 12 characters lowercase. Example: 008003e8037a
i ordered at amazon 2 of these lamps, so i flashed one lamp back
with the saved tuya firmware before flashing with openbeken.
I paired the lamp with the tuya app.
Then i paired the app (and the included devices) in the tuya developer account (i did this
to free my AirConditioner from the cloud some weeks ago, but using the LocalTuya plugin of Homeassistant).
So we get some more acurate informations regarding my lamps:
TuyaMCU uses different types of RGB Hex format where the most recent is 0HUE0SAT0BRI0 (type 1) and the older being RRGGBBFFFF6464 (type 2). Depending on the MCU, code can be case sensitive.
If not, you can just check them all and see which one is working ,right? Let me know.
I have the same device and the same problems. Did you have success in controlling the color and brightness?
Not yet, I was on vacation for some days, so I will continue investigating in the near future. As you can see from the last posts, we are near finding out how to control the color part of this lamp.
I can help with C implementation. I could add some kind of interface so we have a colour picker on the WWW page and it sends a proper TuyaMCU packet, but I need to know how to construct that packet.
So dpID 24 is colour in HSV, type string, Ascii code?
TuyaMCU uses different types of RGB Hex format where the most recent is 0HUE0SAT0BRI0 (type 1) and the older being RRGGBBFFFF6464 (type 2). Depending on the MCU, code can be case sensitive.
After enabling the RGB function check the TuyaReceived information and use TuyaRGB to configure and store the correct (or the closest) format:
TuyaRGB 0 - Type 1, 12 characters uppercase. Example: 00DF00DC0244 (default)
TuyaRGB 1 - Type 1, 12 characters lowercase. Example: 008003e8037a
00f903b6024d looks like 008003e8037a, 12 lowercase characters
I can help with C implementation. I could add some kind of interface so we have a colour picker on the WWW page and it sends a proper TuyaMCU packet, but I need to know how to construct that packet.
So dpID 24 is colour in HSV, type string, Ascii code?
Sorry, I forgot about this topic. You should feel free to remind me, when I don't reply for some time. I remember that I looked at your images and got confused by their order, but I can see that colors seem to be okay.
Sorry, I forgot about this topic. You should feel free to remind me when I don't reply for some time.
No problem, I respect that you invest your time in this project.
p.kaczmarek2 wrote:
Please test and let me know if there are any problems.
OK. I tested it and made a "factory reset" and started then with:
"Toggle Light" works. "LED RGB Color" - the color picker works, the chosen color will be presented by the LED. "LED Dimmer / Brightness" works, but values below 13 make the LED go off.
"LED Temperature Slider" doesn't work. Changing something there does turn off the LED, but I think this is not a problem, as this Slider should only work in the white mode of the LED, right?
Thank you for your kind words. If you like our project, please post a teardown in our IoT section if you encounter an undocumented IoT device. You can also subscribe to our Elektroda com YT channel: https://www.youtube.com/@elektrodacom
Regarding the testing, it seems your device is RGB only, right? So there is no way to display cool and warm white...
It seems we just have to hide the white temperature slider. The only question is, are there also TuyaMCU RGBCW lights? I do not currently have enough knowledge to judge.
Regarding the testing, it seems your device is RGB only, right? So there is no way to display cool and warm white...
It is an RGBCW lamp.
DP 21: switch between RGB and white mode: 1 -> RGB, 0 -> white DP 22: brightness: The range is from 50 (dark) to 1000 (light) DP 23: Kelvin value of white: The range is from 10 (ww) to 990 (cw) (see posts above https://www.elektroda.com/rtvforum/topic3982779.html#20612603)
Hmm, okay, so it seems that we need to support those extra dpIDs. Can you tell me whether dpID 22 (brightness from 50 to 1000) affects the colors sent by OpenBeken?
I am asking because currently OpenBeken does brightness internally and sends already scaled values as Tuya Color. We do not send anything to dpID 22 yet.
Can you tell me whether dpID 22 (brightness from 50 to 1000) affects the colors sent by OpenBeken?
dpID 22 affects only the brightness in white mode.
I want to summarize:
dpID 20: switch the lamp on and off. If the lamp is switched on again, previous color mode and brightness is restored. 0 -> off, 1 -> on dpID 21: switch between RGB and white mode: 0 -> white, 1 -> RGB dpID 22: brightness only in white mode: The range is from 50 (dark) to 1000 (light), NOTE: when changing this value, dpID 21 is set to 0 -> white automatically dpID 23: Kelvin value of white: The range is from 10 (ww) to 990 (cw), NOTE: when changing this value, dpID 21 is set to 0 -> white automatically dpID 24: color (and indirectly brightness) in RGB mode, handled by your code already fine dpID 25: scene management, not yet investigated more, at least for me not needed, so UNUSED
So, in white mode the "Toggle Light" switch does not work (I assume it sets the color to black?)
Hello @nethawk, I will try to add that dpIDs support for your device soon, it's just that I have very limited time and we are also working on simulator Release: https://github.com/openshwprojects/obkSimulator I can try to come up with something for those dpIDs today, but that may require some more testing.
But in general, if you like our project and want to help us, you can: 1. help us spread the word, post on some social media (they may be in your native language or international), or post on Youtube, maybe reach out to YouTubers, etc, so more people know that we are making multiplatform IoT firmware to help users regain their privacy 2. you can post another teardown of any IoT device on our forum, so we can grow this list: https://openbekeniot.github.io/webapp/devicesList.html (I am doing multiple teardowns per month, starting in 2021, so for 2 years already) 3. you can also post an IoT guide here: https://www.elektroda.com/rtvforum/forum517.html if you know something interesting or useful related to generic IoT, feel free to add a short article (or even a long one, if you have time) 4. you can make a donation at my Paypal here: https://www.paypal.com/paypalme/openshwprojects so I can invest more funds into development, mostly devices, parts, dev boards (for example, I recently bricked BL602 dev board by trying to add MAC change feature, silly me... have to buy a new one)
Of course, if you are a developer, you could also help maintain the code, but that requires some C knowledge.
Please keep in mind that the project is done by volunteers in their free time and is a non-profit open-source firmware, so it's often hard to get enough manpower and time to get features ready quickly.
tuyaMcu_sendState 22 2 50 -> white brightness to dark works
tuyaMcu_sendState 22 2 990 -> white brightness to light works
tuyaMcu_sendState 22 2 500 -> white brightness to mid works
tuyaMCU_sendColor 24 1 1 0 1 -> RGB mode, color near yellow works
tuyaMCU_sendColor 24 1 0 0 1 -> RGB mode, color red works
p.kaczmarek2 wrote:
PS: What's going on with dimmer on RGB? I thought it was reported to be working and I didn't change RGB handling.
with 1.17.182 the RGB part (on the web interface) is partly broken: the color picker: doesn't change the color at all the brightness dimmer: doesn't change the brightness at all
Can you check whether the dimmer and temperature behave differently in the latest release?
I am sorry, this didn't succeed.
To enter RGB mode, set the color to red: tuyaMCU_sendColor 24 1 0 0 1 In RGB mode: The color picker doesn't work. Changing the brightness dimmer causes the lamp to go into white mode and dim white correctly.
Now we are in white mode: The dimmer works, The temperature doesn't work.
I know, this is frustrating. Maybe we should calm down the TuyaMCU LED and wait a few days before continuing?
Or, for better debugging, I could:
1. If you like, I can send you the lamp by snail mail.
2. I can give you direct IP access to the lamp (via VPN or port redirection) and give you access to a webcam to see what happens.
Does temperature at least work with those commands then?
I have double checked my code in Simulator, and for this CCT color:
It sends:
55AA0006001016020004000003E817020004000000A5DE
which is:
55 AA 00 06 00 10 16020004000003E817020004000000A5 DE
HEADER VER=00 SetDP LEN fnId=22 Val V=1000,fnId=23 Val V=165 CHK
Maybe it also doesn't like compound packets and i will need to send two dpID values with some interval time... or maybe something else is wrong
Does temperature at least work with those commands then?
RGB mode:
Starting with 1.17.182 the RGB part does not work like it did with previous versions.
The color picker doesn't work and the dimmer doesn't work since 1.17.182
Now testing 1.17.186
RGB mode:
Using the webpage nothing new: color picker doesn't work, dimmer doesn't work.
Using the CMD works:
tuyaMCU_sendColor 24 1 1 0 1
-> RGB mode, color near yellow works
tuyaMCU_sendColor 24 1 0 0 1
-> RGB mode, color red works
white mode:
webpage dimmer for brightness works
webpage slider for temperature doesn't change something
Using the CMD works:
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 10 16 02 00 04 00 00 03 E8 17 02 00 04 00 00 00 6F AC
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 23 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 22, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 1000
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 23, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 111
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 05 15 04 00 01 00 28
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 12 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 21, dataType 4-DP_TYPE_ENUM and 1 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte:
So what is the difference between changing the brightness (white) and the tempearature (white)
Using the webinterface i changed again the brightness
-> works
setting the brightness using the slider i see in the logs:
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 10 16 02 00 04 00 00 03 E8 17 02 00 04 00 00 00 6F AC
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 23 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 22, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 1000
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 23, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 111
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 05 15 04 00 01 00 28
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 12 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 21, dataType 4-DP_TYPE_ENUM and 1 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte:
I see no real difference between changing brigtness and temperature (white) in the logs.
p.kaczmarek2 wrote:
Maybe it also doesn't like compound packets and i will need to send two dpID values with some interval time... or maybe something else is wrong
I am not an expert but if i would guess:
Probably there is an timing issue, TuyaMCU processes dpId 22 while it already
receives dpId 23 instruction. If that's true:
If you would first send dpId 23, followed by dpID 22 (in one command) the
temperature would be processed, but not the brightness.
Suggestion 1: Send 2 seperate commands for dpId 22 and 23, like you already
do for dpId 21, so you can include some milliseconds of sleep.
Suggestion 2: Send only the dpId to the MCU that was changed.
Added after 7 [minutes]:
I include one additional link, only to confirm, that we are right about the dpIds in use:
✨ The discussion revolves around the flashing and configuration of the YB8007/300 LED panel using the BK7231N chip and OpenBeken firmware. The user successfully flashed one LED lamp but faced issues with GPIO extraction using BK7231Flasher. Participants suggested trial and error with pin assignments for color control and identified the device as a TuyaMCU type, requiring specific commands for color and brightness adjustments. The conversation included troubleshooting steps, such as using dpIDs for controlling color modes, brightness, and temperature settings. The user reported mixed results with RGB and white modes, leading to further development of the firmware to improve functionality, including a color picker and adjustments for temperature control. The integration with Home Assistant was also discussed, highlighting the need for a queue system to manage command packets effectively.
TL;DR: This FAQ maps 6 core dpIDs and the expert finding "it’s a TuyaMCU device" for OpenBeken users flashing a BK7231N/CBU Amazon YB8007/300 RGBCW ceiling light when GPIO extraction gives no usable PWM pinout. [#20610467]
Why it matters: The lamp is controllable after flashing, but only when OpenBeken talks to the secondary Tuya MCU with the right dpIDs, HSV format, and packet timing.
Control method
What the thread found
Best use in this lamp
TuyaMCU UART
Baud found as 9600 and dpIDs expose lamp functions
Recommended path for this YB8007/300
Raw PWM GPIO
Needs PCB tracing and possible MCU removal
Hardware conversion only
I2C LED driver
Common chips include SM2135, SM2235, BP5758D
Not identified on this lamp
Key insight: Do not treat this device as a simple PWM lamp. Configure OpenBeken around TuyaMCU: dpID 20 for power, 21 for mode, 22/23 for white, and 24 for RGB color.
Quick Facts
The firmware config exposed UART baud 9600, which indicates TuyaMCU communication rather than direct GPIO PWM control. [#20610467]
The confirmed control map is: 20 power, 21 mode, 22 white brightness, 23 white CCT, 24 RGB HSV color, and 25 scene data. [#20649138]
White brightness uses 50–1000; white temperature uses about 10–990, with low values warm and high values cold. [#20649138]
RGB color on dpID 24 uses a 12-character HSV-style string, such as 00f903b6024d, sent as ASCII string data. [#20633912]
OpenBeken 1.17.187 with a 50 ms inter-packet delay made white brightness, white temperature, RGB color, and Home Assistant MQTT integration work. [#20662700]
How do I flash an Amazon YB8007/300 LED panel with a BK7231N CBU module using OpenBeken?
Flash it by backing up the original CBU firmware, flashing OpenBeken, then configuring TuyaMCU instead of GPIO PWM. 1. Connect a serial adapter to the CBU module and save the stock firmware. 2. Flash the OpenBK7231N build suggested by BK7231Flasher. 3. Add TuyaMCU LED setup commands and test dpIDs from the console. The user confirmed flashing succeeded, but GPIO Doctor produced no lamp reaction. [#20610350]
Why does BK7231Flasher fail to extract GPIO pin information from some Tuya LED lamp firmware?
BK7231Flasher may show no GPIO pinout because the lamp uses TuyaMCU, not direct BK7231N GPIO outputs. "TuyaMCU" is a secondary microcontroller interface that handles device functions over UART, letting the Wi-Fi module send dpID commands instead of driving LEDs directly with PWM pins. The extracted config still gave meaningful data, including baud: 9600, which pointed to UART MCU control. [#20610467]
What is TuyaMCU, and why would a BK7231N LED panel use it instead of direct PWM GPIO control?
TuyaMCU lets the BK7231N module command another MCU over UART instead of driving LED channels itself. "TuyaMCU" is a Tuya serial protocol architecture that maps functions to dpIDs, using packets over UART rather than exposing each LED channel as a raw GPIO or PWM pin. This lamp was unusual because many LED lamps use raw PWM or LED drivers like SM2135, SM2235, or BP5758D. [#20610467]
How can I identify TuyaMCU dpIDs for an RGBCW ceiling light after flashing OpenBeken?
Query TuyaMCU state, inspect logs, then compare dpIDs with Tuya IoT device specifications. The thread found dpIDs 20–25 from tuyaMcu_sendQueryState logs. A Tuya developer account later confirmed functions and status entries for switch, mode, brightness, temperature, color, and scenes. Serial sniffing with TuyaMCUAnalyzer then verified dpID 24 color payloads. [#20615058]
What do dpIDs 20, 21, 22, 23, 24, and 25 control on a TuyaMCU RGBCW LED ceiling lamp?
dpID 20 controls power, 21 selects mode, 22 controls white brightness, 23 controls white temperature, 24 controls RGB color, and 25 stores scene data. Mode 0 means white and mode 1 means RGB. dpID 22 uses 50–1000; dpID 23 uses about 10–990. dpID 24 also carries RGB brightness indirectly through its HSV value string. [#20649138]
How should I configure OpenBeken autoexec.bat for a TuyaMCU LED lamp with dpID 20 on/off, dpID 21 mode, dpID 22 brightness, dpID 23 color temperature, and dpID 24 RGB color?
Start TuyaMCU and set the RGB dpID with tuyaMCU_setupLED 24 1, then let current OpenBeken handle the hardcoded white dpIDs for this lamp. A minimal tested file was startDriver TuyaMCU plus tuyaMCU_setupLED 24 1. Earlier manual mappings linked dpID 20 as a switch and dpID 21 as a toggle, but later LED support handled the web UI and MQTT light controls. [#20656814]
What is the correct TuyaMCU HSV color string format for dpID 24 on Tuya RGB lights?
dpID 24 uses a 12-character lowercase HSV-style string formatted as three 4-hex-digit fields. Tasmota’s equivalent type 1 lowercase format uses %04x%04x%04x, meaning hue, saturation multiplied by 10, and brightness multiplied by 10. The captured value 00f903b6024d matched that pattern and was sent as ASCII string data. [#20633912]
How does the OpenBeken tuyaMCU_sendColor command work for controlling RGB colors on a TuyaMCU lamp?
tuyaMCU_sendColor converts RGB input into a Tuya HSV string and sends it to the selected color dpID. The command format is tuyaMCU_sendColor dpID red01 green01 blue01 tuyaRGB1. For this lamp, tuyaMCU_sendColor 24 1 0 0 1 sent red and encoded it as 000003e803e8. The final argument selected lowercase or uppercase Tuya RGB format. [#20633912]
Why does changing white brightness or color temperature on a TuyaMCU LED lamp require delays between dpID packets?
This lamp needs delays because rapid consecutive dpID packets can fail or overwrite each other. Manual commands to dpID 22 and 23 worked, but combined or immediate web-interface sends caused missing temperature updates. Adding a delay between packets fixed white temperature control in OpenBeken 1.17.187; a later reduction to 50 ms still worked. [#20662700]
How can I fix reversed warm white and cold white behavior on a TuyaMCU RGBCW lamp in OpenBeken?
Enable the OpenBeken CCT reverse option added for this TuyaMCU LED support path. The lamp showed cold white in the web interface while emitting warm white, and warm white while emitting cold white. A later OpenBeken change added CCT reversal, and testing confirmed it worked in both the web interface and Home Assistant. [#20721679]
What causes RGB dimming on a TuyaMCU lamp to shift colors toward blue at low brightness?
The thread did not isolate one confirmed cause, but the failure appears only at low mixed RGB brightness. The tester observed that values below 13 turned the RGB lamp off. Mixed colors such as red 30, green 40, blue 10 shifted bluish as brightness decreased. The cause may be lamp hardware behavior or OpenBeken’s RGB-to-HSV brightness calculation. [#20663466]
How do I integrate an OpenBeken TuyaMCU RGBCW LED lamp with Home Assistant over MQTT?
Integrate it as an MQTT light using OpenBeken command and state topics for power, RGB, brightness, and color temperature. The posted Home Assistant YAML used led_basecolor_rgb, led_enableAll, led_dimmer, and led_temperature topics. It set brightness_scale: 100 and used an RGB command template formatted as #%02x%02x%02x0000. The user confirmed Home Assistant integration worked after TuyaMCU LED fixes. [#20720527]
How can I troubleshoot Home Assistant color changes that make an OpenBeken TuyaMCU light become slow or unresponsive?
Test rapid color changes from the OpenBeken console and watch TuyaMCU logs before blaming Home Assistant. Run backlog led_basecolor_rgb FF0000; led_basecolor_rgb 00FF00; led_basecolor_rgb 0000FF only when you can power-cycle the lamp. One test caused about 1.5 seconds of web UI unresponsiveness, then recovered. The likely backend fix is a TuyaMCU send queue. [#20726537]
TuyaMCU vs raw PWM vs I2C LED drivers like SM2135, SM2235, and BP5758D — which control method is better for OpenBeken LED lamps?
Use TuyaMCU when the original firmware exposes a TuyaMCU UART config, and use PWM or I2C only when hardware confirms those paths. The developer said classic LED lamps often use raw PWM or I2C LED drivers like SM2135, SM2235, and BP5758D. This device was different: it used TuyaMCU at 9600 baud, so dpID control was the practical OpenBeken route. [#20610467]
How do I read or debug a new TuyaMCU dpID 49 DP_ERROR message after sending an invalid dpID 24 string?
Treat dpID 49 as an error response caused by an invalid TuyaMCU color payload, then retest with valid dpID 24 string length. The user triggered DP_ERROR after sending tuyaMcu_sendState 24 3 110000, which produced a malformed string case. Valid RGB color testing later used 12-character HSV strings on dpID 24, such as 00f903b6024d. [#20612603]