logo elektroda
logo elektroda
X
logo elektroda
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam

[BK7231N/CBU] LED Panel YB8007/300, BK7231Flasher Extraction of config, TuyaMCU LED?

nethawk 5856 46
Best answers

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]
ADVERTISEMENT
  • #31 20662494
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14654
    Help: 655
    Rate: 12661
    nethawk wrote:

    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.

    At first I was sending dpID 22 and dpID 23 separately. It didn't work back then so I hoped that maybe I can combine those two dpIDs into one packet, but that, surprisingly, doesn't seem to work as well. This is not what I expected.

    Your suggestions are basically the steps that I was planning to take next. Option 2 seems very attractive and easy to do but I don't think that we can guarantee that the two variables will never change at the same time.

    I think I will plug a simple delay milliseconds between sends for now and later I will implement some kind of simple send queue for TuyaMCU.

    Let me do that simple delay milliseconds test first:
    https://github.com/openshwprojects/OpenBK7231...mmit/7e3da5e69fe028b8ebd9d9cc0feca04bdebfad82
    Can you check latest build? I am really not sure if it will work... this delay would also delay the HTTP response, it's a bad practice in general, but let's try it first just to know if it helps.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #32 20662700
    nethawk
    Level 3  
    Posts: 23

    p.kaczmarek2 wrote:
    Your suggestions are basically the steps that I was planning to take next. Option 2 seems very attractive and easy to do but I don't think that we can guarantee that the two variables will never change at the same time.


    Agree with you. In this sense it might be necessary to send dpId 21 the same time too.

    p.kaczmarek2 wrote:
    Can you check latest build? I am really not sure if it will work... this delay would also delay the HTTP response, it's a bad practice in general, but let's try it first just to know if it helps.


    Bad practice, but sometimes necessary while talking with unbuffered serial devices.

    Great work, this does help.

    Testing now 1.17.187

    white mode:
    Now i can change the temperature of white by using the webinterface:
    -> works perfectly, optical tuning of the webinterface slider possible

    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 16 02 00 04 00 00 03 E8 18 
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 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 received: 55 AA 03 07 00 08 17 02 00 04 00 00 00 72 A0 
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 23, dataType 2-DP_TYPE_VALUE and 4 data bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 114
    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: 


    white mode:
    change the brightness by using the webinterface
    -> works perfectly

    white mode:
    Toggle light button
    -> doesn't work

    RGB mode:
    Toggle light button
    -> works

    RGB mode:
    brightness slider
    -> works, but could be improved

    RGB mode:
    color picker
    -> works

    To have full functionality i would suggest to implement the
    'Toggle light button' by using dpId 20, which should work for
    color and white mode.

    Depending, how perfect it should be, you could fix some smaller things too.
  • #33 20662786
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14654
    Help: 655
    Rate: 12661
    Toggle is not implemented so no wonder that's not working.

    Hmm, so we have good news, in general. I'll finalize this hacky code tomorrow morning and later I can think of a better solution than this delay. I will just implement a send queue, like I did for Tasmota Device Groups.
    Helpful post? Buy me a coffee.
  • #34 20663295
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14654
    Help: 655
    Rate: 12661
    I have pushed that on/off send for TuyaMCU. I also reduced delays between packets to 50ms. Let me know if it's still working. Thanks!

    I will need to optimize it later, will you be still around for some testing?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #35 20663466
    nethawk
    Level 3  
    Posts: 23

    p.kaczmarek2 wrote:
    I have pushed that on/off send for TuyaMCU. I also reduced delays between packets to 50ms. Let me know if it's still working. Thanks!


    It works, the 50ms delay seems to work.
    Integration into HomeAssistant works too.

    p.kaczmarek2 wrote:
    I will need to optimize it later, will you still be around for some testing?


    Sure.
    In the next days, I will continue with the next LED freedom act, so I am here.

    I have seen a bug, I call it the white-temperature-reverse bug:

    The web interface shows cold white, but the lamp gives out warm white
    [BK7231N/CBU] LED Panel YB8007/300, BK7231Flasher Extraction of config, TuyaMCU LED?

    The web interface shows warm white, in reality, it is cold white now.
    [BK7231N/CBU] LED Panel YB8007/300, BK7231Flasher Extraction of config, TuyaMCU LED?

    Added after 15 [minutes]:

    Another thing is the brightness/dimmer in RGB mode.

    1. If the value is set below 13, the lamp is off (instead of darker). So the usable range starts at 13

    2. If the brightness of a "mixed" RGB color goes down, the color tends to go bluish.
    With "mixed" color, I mean when more than only one base color is used, for example: red: 30, green: 40, blue: 10
    I don't know if the effect comes because the lamp has quality problems in low brightness situations or the
    calculation of the real color (based on the color + brightness).
    Please see the pictures to see what I mean. I only changed the brightness.

    [BK7231N/CBU] LED Panel YB8007/300, BK7231Flasher Extraction of config, TuyaMCU LED?

    [BK7231N/CBU] LED Panel YB8007/300, BK7231Flasher Extraction of config, TuyaMCU LED?

    [BK7231N/CBU] LED Panel YB8007/300, BK7231Flasher Extraction of config, TuyaMCU LED?

    [BK7231N/CBU] LED Panel YB8007/300, BK7231Flasher Extraction of config, TuyaMCU LED?

    [BK7231N/CBU] LED Panel YB8007/300, BK7231Flasher Extraction of config, TuyaMCU LED?

    [BK7231N/CBU] LED Panel YB8007/300, BK7231Flasher Extraction of config, TuyaMCU LED?

    [BK7231N/CBU] LED Panel YB8007/300, BK7231Flasher Extraction of config, TuyaMCU LED?
  • #36 20718373
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14654
    Help: 655
    Rate: 12661
    So we need an option to reverse the CCT?

    Can you post your full current config?
    Helpful post? Buy me a coffee.
  • #37 20720527
    nethawk
    Level 3  
    Posts: 23

    p.kaczmarek2 wrote:
    So we need an option to reverse the CCT?


    I think, this would be great.

    p.kaczmarek2 wrote:
    Can you post your full current config?


    Really nothing special there:

    Screenshot of IoT device configuration interface showing MQTT data.
    Text editor with open autoexec.bat file containing code related to TuyaMCU.

    mqtt:
      light:
      - unique_id: "Rundlampe01_OpenBK7231N_5526BA59_light"
        name: 0
        rgb_command_template: "{{ '#%02x%02x%02x0000' | format(red, green, blue)}}"
        rgb_value_template: "{{ value[0:2]|int(base=16) }},{{ value[2:4]|int(base=16) }},{{ value[4:6]|int(base=16) }}"
        rgb_state_topic: "obkrundlamp01BA59/led_basecolor_rgb/get"
        rgb_command_topic: "cmnd/obkrundlamp01BA59/led_basecolor_rgb"
        command_topic: "cmnd/obkrundlamp01BA59/led_enableAll"
        state_topic: "obkrundlamp01BA59/led_enableAll/get"
        availability_topic: "obkrundlamp01BA59/connected"
        payload_on: 1
        payload_off: 0
        brightness_command_topic: "cmnd/obkrundlamp01BA59/led_dimmer"
        brightness_state_topic: "obkrundlamp01BA59/led_dimmer/get"
        brightness_scale: 100
        color_temp_command_topic: "cmnd/obkrundlamp01BA59/led_temperature"
        color_temp_state_topic: "obkrundlamp01BA59/led_temperature/get"
    

  • #38 20720643
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14654
    Help: 655
    Rate: 12661
    Ah okay, we still have other dpIDs hardcoded. Sorry, I work too much and I kinda forgot about! We will try to finalize it soon.

    I am also working on another TuyaMCU LED, but the individually-addressable one, in this topic:
    https://www.elektroda.com/rtvforum/topic3990646-60.html#20720640

    I pushed CCT reverse, can you check if it works for you?
    https://github.com/openshwprojects/OpenBK7231...mmit/40fcd158d3c93ad7583a9c3d85f8e7950537477d
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #40 20721757
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14654
    Help: 655
    Rate: 12661
    So you're saying HA works good for you?

    @DeDaMrAz recently reported some issue that happens with HA, but does not appear when using OBK web panel directly.
    Helpful post? Buy me a coffee.
  • #41 20722411
    DeDaMrAz
    Level 22  
    Posts: 612
    Help: 34
    Rate: 130
    @nethawk can you change color in HA in a repetitive manner - like multiple times in a row.

    I have some issues where I can change color a certain number of times and then it will stop responding until I power cycle the device (light on/off)
  • #42 20722970
    nethawk
    Level 3  
    Posts: 23
    DeDaMrAz wrote:
    @nethawk can you change color in HA in a repetitive manner - like multiple times in a row.

    I have some issues where I can change color a certain number of times and then it will stop responding until I power cycle the device (light on/off)


    I have to check this for some days to give a correct answer.
    Can you describe more, what you did to force unresponsiveness ?
  • ADVERTISEMENT
  • #43 20722974
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14654
    Help: 655
    Rate: 12661
    I was testing with @DeDaMrAz and on his device our original driver that we've made together with @nethawk was working kinda like 1 per 10 tries. It looked like HA is sending two packets to OBK and OBK tries to send too many packets to TuyaMCU despite my best efforts to add extra delays between them.

    I am most likely going to rewrite TuyaMCU backend to have a queue of packets to send. That is the correct way to solve it.

    Added after 10 [hours] 58 [minutes]:

    I've added tuya color preview to analyzer so we can test this device more easily:
    Screenshot of TuyaMCU Explorer Analyzer for OpenBeken showing data packets.
    See more at:
    https://github.com/openshwprojects/TuyaMCUAnalyzer
    Helpful post? Buy me a coffee.
  • #44 20726434
    nethawk
    Level 3  
    Posts: 23

    DeDaMrAz wrote:
    @nethawk can you change color in HA in a repetitive manner - like multiple times in a row.

    I have some issues where I can change color a certain number of times and then it will stop responding until I power cycle the device (light on/off)


    In my case the lamp stays responsive and doesn't stop working.

    I tested with the Home Assistant 2023.8.4
    Supervisor 2023.08.3
    Operating System 10.5
    Frontend 20230802.1 - latest

    Lamp control interface in Home Assistant with color and brightness level.

    and the OBK webinterface Version: 1.17.233

    Web interface for lamp control with brightness and color settings.

    and the NsPanel Lovelace UI on the nextion screen inside of NSPanel
    https://docs.nspanel.pky.eu/

    Touchscreen display showing a lighting control interface with a color selection option.

    On the NsPanel it is a little bit slow responsive, but I have this with other lamps too on NsPanel.
  • #45 20726466
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14654
    Help: 655
    Rate: 12661
    How your lamp behaves if you do:
    
    backlog led_basecolor_rgb FF0000; led_basecolor_rgb 00FF00; led_basecolor_rgb 0000FF
    

    NOTE: make sure you can repower it before you try.

    PS: I am also working on NSPanel: https://www.elektroda.pl/rtvforum/topic4001021.html
    Helpful post? Buy me a coffee.
  • #46 20726537
    nethawk
    Level 3  
    Posts: 23
    p.kaczmarek2 wrote:
    How your lamp behaves if you do:
    
    backlog led_basecolor_rgb FF0000; led_basecolor_rgb 00FF00; led_basecolor_rgb 0000FF
    

    NOTE: make sure you can repower it before you try.


    O.k., color changed to blue, for around 1,5 seconds the OBK webinterface was unresponsive, but "it came back"
    and worked like before.

    In my case, it doesn't look as bad.

    
    Debug:API:POST to api/cmnd
    Debug:CMD:cmd [backlog led_basecolor_rgb FF0000; led_basecolor_rgb 00FF00; led_basecolor_rgb 0000FF]
    Debug:CMD:backlog [led_basecolor_rgb FF0000; led_basecolor_rgb 00FF00; led_basecolor_rgb 0000FF]
    Debug:CMD:cmd [led_basecolor_rgb FF0000]
    Debug:CMD: BASECOLOR got FF0000
    Debug:CMD:Changing LightMode from cw to rgb
    Info:TuyaMCU:Color is sent as 000003E800DC
    Info:MQTT:Publishing val FF0000 to obkrundlamp01BA59/led_basecolor_rgb/get retain=0
    Debug:CMD:cmd [led_basecolor_rgb 00FF00]
    Debug:CMD: BASECOLOR got 00FF00
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obkrundlamp01BA59/led_basecolor_rgb/get
    Debug:MQTT:channelSet topic 4215108 with arg FF0000
    Info:TuyaMCU:Color is sent as 007803E800DC
    Debug:CMD:cmd [led_basecolor_rgb 0000FF]
    Debug:CMD: BASECOLOR got 0000FF
    Info:TuyaMCU:Color is sent as 00F003E800DC
    Debug:CMD:backlog executed 3
    Info:CMD:[WebApp Cmd 'backlog led_basecolor_rgb FF0000; led_basecolor_rgb 00FF00; led_basecolor_rgb 0000FF' Result] OK
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 10 18 03 00 0C 30 30 30 30 30 33 45 38 30 30 44 43 C7 
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 23 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 24, dataType 3-DP_TYPE_STRING and 12 data bytes
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 10 18 03 00 0C 30 30 46 30 30 33 45 38 30 30 44 43 DD 
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 23 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 24, dataType 3-DP_TYPE_STRING and 12 data bytes
    ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 1, product_information_valid=1, self_processing_mode = 1, wifi_state_valid = 0, wifi_state_timer=43
    Info:MAIN:Time 251676, idle 188886/s, free 62296, MQTT 1(9), bWifi 1, secondsWithNoPing 1, socks 3/38 
    Info:MQTT:Publishing val 0000FF to obkrundlamp01BA59/led_basecolor_rgb/get retain=0
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 05 14 01 00 01 01 25 
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 12 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 20, dataType 1-DP_TYPE_BOOL and 1 data bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte: 
    Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 20 with value 1 is not mapped
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 05 15 04 00 01 01 29 
    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: 
    Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 21 with value 1 is not mapped
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 10 18 03 00 0C 30 30 46 30 30 33 45 38 30 30 44 32 CC 
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 23 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 24, dataType 3-DP_TYPE_STRING and 12 data bytes
    ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 1, product_information_valid=1, self_processing_mode = 1, wifi_state_valid = 0, wifi_state_timer=44
    Info:MAIN:Time 251677, idle 176950/s, free 70920, MQTT 1(9), bWifi 1, secondsWithNoPing 1, socks 2/38 
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obkrundlamp01BA59/led_basecolor_rgb/get
    Debug:MQTT:channelSet topic 4215108 with arg 0000FF
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 00 00 01 01 04 
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 0 (Hearbeat) with 8 bytes
    ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 1, product_information_valid=1, self_processing_mode = 1, wifi_state_valid = 0, wifi_state_timer=44
    Info:MAIN:Time 251678, idle 163150/s, free 70920, MQTT 1(9), bWifi 1, secondsWithNoPing 1, socks 2/38 
    ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 1, product_information_valid=1, self_processing_mode = 1, wifi_state_valid = 0, wifi_state_timer=45
    Info:MAIN:Time 251679, idle 186105/s, free 70920, MQTT 1(9), bWifi 1, secondsWithNoPing 1, socks 2/38 
    ExtraDebug:TuyaMCU:TuyaMCU heartbeat_valid = 1, product_information_valid=1, self_processing_mode = 1, wifi_state_valid = 0, wifi_state_timer=46
    Info:MAIN:Time 251680, idle 193463/s, free 70920, MQTT 1(9), bWifi 1, secondsWithNoPing 1, socks 2/38 
    Info:GEN:dhcp=0 ip=192.168.11.65 gate=192.168.11.1 mask=255.255.255.0 mac=a8:80:55:26:ba:59
    Info:GEN:sta: 1, softap: 0, b/g/n
    
  • #47 20726587
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14654
    Help: 655
    Rate: 12661
    This is probably because OBK sends commands "in place" instead of using a queue. I will look into it soon. I will just need to test the new approach very well before pushing it to the production.
    Helpful post? Buy me a coffee.

Topic summary

✨ 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.

FAQ

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]
ADVERTISEMENT