logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Query: Tuya Led Controller DC5-12v Compatibility with Cloudcutter Flash BK7321 and OBK Drivers

MnM1 10497 136
Best answers

Can I flash this Tuya LED controller with Cloudcutter on BK7231N/BK7231T and get the needed OpenBK drivers and GPIO settings working?

Yes — the device in the thread was ultimately identified as a BK7231N TuyaMCU-based controller, and Cloudcutter was used successfully to detach it from Tuya and flash OpenBK [#20661998][#20684927][#20685629] The important catch is that it is not a simple direct SM16703 LED-output device; the attempted SM16703 driver path did not work because the LEDs are driven through TuyaMCU, so the right approach is the OpenBK TuyaMCU driver rather than raw GPIO mapping [#20685629][#20685646] Once the fnIDs/DPs were captured, it became controllable with `startDriver TuyaMCU`, `tuyaMcu_defWiFiState 4`, `tuyaMcu_setBaudRate 115200`, and `tuyaMCU_setupLED 24 1`, plus scripts/buttons for the different modes and scenes [#20720196][#20720438] The device was later described as fully supported in OpenBK, with power, scenes, color picking, brightness, and music mode working, although warm/cold white handling was still not working and does not seem to be present in the original Tuya app either [#20713971][#20721021][#20817640] If you want to check Cloudcutter compatibility first, the advice was to use the cloudcut-only option and select the matching N/T profile based on the Tuya firmware prefix [#20661998]
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • #1 20661258
    MnM1
    Level 10  
    Posts: 175
    Help: 4
    Rate: 13

    Hi,

    Got this light from AliExpress:

    https://www.aliexpress.com/item/1005005338731...order_list.order_list_main.100.21ef1802s6ff4A

    It is a waterproof light and I really can't open and see the inside components. Plus, it is not that cheap and I don't want to ruin it.

    I am trying to see if I can use cloudcutter to flash BK7321 (which version?), if the required drivers are supported, and maybe some GPIO settings.

    The LEDs on the light can display different colors:





    The LEDs are controlled by this device:

    Query: Tuya Led Controller DC5-12v Compatibility with Cloudcutter Flash BK7321 and OBK Drivers

    After I added it to the Tuya app, this is the firmware version it shows:

    Query: Tuya Led Controller DC5-12v Compatibility with Cloudcutter Flash BK7321 and OBK Drivers

    Is there any way from the above to know if

    - use cloudcutter to flash? N or T version?
    - after flashing, will OBK have the drivers required to run it?
    - hopefully the GPIO (I understand that maybe possible after it's been flashed to OBK via GPIO doctor an existing config if available)

    Thanks again, guys.
  • ADVERTISEMENT
  • #2 20661340
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12631
    Hello, individually adressable LEDs are planned, but not yet supported. Providing information what kind of driver is used there can help (is it WS2812B or something else), but still, it's currently not implemented in the codebase. Same with binary dump - if you can read flash by wires, it will help us to extend the template importer.
    Helpful post? Buy me a coffee.
  • #3 20661998
    ferbulous
    Level 18  
    Posts: 419
    Help: 8
    Rate: 56

    To verify if it works for cloudcutter,
    Pick the cloudcut option only (not firmware flashing), you need to avoid picking the wrong firmware type first.
    Select the T & N profile for that firmware version. If it gets an 'A-xx' prefix for the N profile (for example), then you can proceed flashing N firmware.
  • #4 20662154
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12631
    But would that provide us a 2MB firmware backup? We don't have addressable LEDs support yet, so backup is recommended so you don't get stuck with device that is still waiting for driver implementation.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #6 20663283
    MnM1
    Level 10  
    Posts: 175
    Help: 4
    Rate: 13

    Thanks for the information, guys.

    I will look and see what I can do. The AliExpress seller is very helpful too. They said they "manufacture" the lights. I suspect they put them together. So if they have access to the "raw" materials, I think that if they can, they will tell me the name of the chips used for the LEDs.
    I have asked them, and I will see what they will say - probably on Monday, I suspect.

    With cloudcutter, I have never used it to cut the device from Tuya only. I have always flashed 3rd party firmware.

    @ferbulous - if I cut the devices from Tuya, will they still have full functionality? Or does it need a cloudcutter profile for that?

    I am careful as these 2 lights I got were not cheap, and I don't want to have them not working.
  • #7 20663292
    ferbulous
    Level 18  
    Posts: 419
    Help: 8
    Rate: 56

    @mnm11 yes, it retains the full function but you'll need to use localtuya to control it since it won't connect to Tuya cloud anymore.
  • #8 20663323
    MnM1
    Level 10  
    Posts: 175
    Help: 4
    Rate: 13
    @ferbulous - so the process will be
    - install localtuya in HA
    - get this device connected and configured in localtuya in HA (and use the Tuya IoT platform to get it configured properly or is that Tuyalocal that needs the Tuya IoT configuration? LOL I get confused between them 2)
    - then cut the device from Tuya an it will still retain full functionality? as if it was connected to Tuya cloud?
  • ADVERTISEMENT
  • #9 20664358
    ferbulous
    Level 18  
    Posts: 419
    Help: 8
    Rate: 56

    @mnm11
    Yes, after detaching from the cloud, you'll get the device ID to use with localtuya and just need to figure out the dpids.
  • #10 20667402
    MnM1
    Level 10  
    Posts: 175
    Help: 4
    Rate: 13

    The information I have from the vendor is that they are "3535-96 beads, the lamp beads are 3535" - not sure if that helps or not.

    If it doesn't help, can someone help phrase my question to the vendor as I am not sure I am asking him the right way. What exactly should I ask him?
  • #12 20668251
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12631
    If you want to experiment ,get latest build and try:
    Code: text Expand Select all Copy to clipboard
    
1. Start driver
startDriver SM16703P

2. Init Driver
SM16703P_Init [[pixelcount]]

3. Set Pixel
SM16703P_SetPixel 1 255 0 0
SM16703P_SetPixel 2 0 255 0
SM16703P_SetPixel 3 0 0 255

4. Start Output (each call will trigger one
SM16703P_Start

    I can't test it myself because I don't have this device... make sure you have Tuya firmware backup!
    Helpful post? Buy me a coffee.
  • #13 20668775
    MnM1
    Level 10  
    Posts: 175
    Help: 4
    Rate: 13
    On step 2 I get this error:

    Error:CMD:cmd SM16703P_Init NOT found (args [[pixelcount]])
    Unknown command
  • #14 20669153
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12631
    Sorry, it seems that the automatic build didn't catch last commit. Let me check...
    Helpful post? Buy me a coffee.
  • #15 20669511
    MnM1
    Level 10  
    Posts: 175
    Help: 4
    Rate: 13

    Latest build 202 - can't download the file = 404 error

    Edit: OpenBK7231T_1.17.202* = file not available. The files for N are OK.
  • #16 20669569
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12631
    Yes, it seems that the LED driver contributor currently provided a version only for N. Are you possibly on T platform?

    If so, I would need to try to fix T compilation first. I assumed you're on N, because N is most popular these days.
    Helpful post? Buy me a coffee.
  • #17 20669573
    MnM1
    Level 10  
    Posts: 175
    Help: 4
    Rate: 13

    Yeah, I am on T - however, I am not testing on the device in this thread. As mentioned before, this device is too expensive for me to test on.
    I have ordered a shorter one (the one in the pic is 1.2M long) which is much cheaper, so I can test when it arrives - around 10 days.

    I am testing on this one at the moment - see if I get lucky :) and it uses the same LEDs

    https://www.elektroda.com/rtvforum/topic3990174.html
  • #18 20669723
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12631
    Driver would work on N, I am not sure about T. Let me try to port it and we will see.
    Helpful post? Buy me a coffee.
  • #19 20679360
    MnM1
    Level 10  
    Posts: 175
    Help: 4
    Rate: 13

    @p.kaczmarek2 - Is the 205T version supposed to have the SM16703 feature enabled?
    Just tried it and the drivers are not loading.
  • #20 20684890
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12631
    For now, only basic build was fixed. I will try to port the SM16703 feature to T in the following days.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #21 20684927
    MnM1
    Level 10  
    Posts: 175
    Help: 4
    Rate: 13

    I have received my test device today.
    According to the manufacturer, it uses SM16703. It also uses BK7231N.
    I added it to Tuya, and I got a cloud cutter supported firmware on it.

    I have added it to HA with LocalTuya and have got a list of dp_ids from the Tuya IoT site.

    As per my previous 2 devices, these are really sealed and weatherproof - so I have no chance in opening it without destroying it. And as I really don't want to kill it, I went ahead and uploaded 1.17.206 to it. Complete the upload and initial setup, and I have the device on my wifi now.

    I went ahead and ran the commands as instructed. I can see the driver loaded now:

    Web interface of the OpenBK7231N device with visible buttons and status information.

    But I am not seeing anything else in the menu (Toggle, dimming/rgb/temp options, etc.)

    What do you advise I should do next?
    Or if you need any logs or anything from me, please let me know.
  • #22 20684938
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12631
    This is a good news, we can test finally that SM16703P driver from contributor.

    His comments says:
    Configuration instructions for SM16703P driver to control LEDs
    Please do steps from the image and let me know if anything lights up. Those commands show turn on 3 LEDs. There is no GUI for that yet. We can work on GUI once we know that at least LED communication is working.
    Helpful post? Buy me a coffee.
  • #23 20684981
    MnM1
    Level 10  
    Posts: 175
    Help: 4
    Rate: 13

    I have tried the commands and this is what I get from the last one (SM16703P_Start):

    Code: text Expand Select all Copy to clipboard
    Error: CMD: before enable tx 0x0000020c
Error: CMD: enable tx 0x0000020c


    This device is behaving funny. As soon as I start it, the LEDs are blinking blue on it.
    It also has an IR remote control that is still fully functional even with BK7231N 1.17.206 on it. I guess it must have an additional module for it somewhere.
  • #24 20685168
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12631
    Can you post a video of that blinking? Do they always blink? Or maybe it's blinking as in "pair mode"?

    According to the contributor, those commands should enable first 3 LEDs. If they doesn't, please get Tuya Config partition so I can check it for TuyaMCU traces:
    https://www.youtube.com/watch?v=WunlqIMAdgw&ab_channel=Elektrodacom
    You not getting correct colors lit may mean multiple things:
    - this is not a SM16703P
    - this may be a TuyaMCU device (maybe even with SM16703P, but not connected to Beken)
    - SM16703P driver is broken (no one tested it yet except the original contributor)

    I may try to check this driver with ws2812b soon, maybe fix T port, etc, but it all depends on my free time, I am just a one person, and for now I was making some new vids (with little help of my assistant!) for our YT channel: https://www.youtube.com/@elektrodacom maybe this week I will manage to look into addressable LEDs more

    Added after 3 [minutes]:

    MnM1 wrote:

    This device is behaving funny. As soon as I start it, the LEDs are blinking blue on it.


    As soon as you start the driver, or as soon you power device?

    If as soon you power device, even with OBK, leds are blinking blue, then it would mean it's a TuyaMCU device.
    Helpful post? Buy me a coffee.
  • #25 20685572
    MnM1
    Level 10  
    Posts: 175
    Help: 4
    Rate: 13

    The LEDs turn on and start flashing as soon as I turn the power on the device.
    In the attached video, I turn the power on and the LEDs blink, and then I turn the power off:





    This is what Tuya showed me in the app:

    Update message in the Tuya app indicating No updates available.

    Here is the Tuya Config partition:


    Thanks again for your help, I know you are very busy.

    Edit: The device is not in pairing mode. It is not broadcasting a WIFI AP. As mentioned, it has been flashed with BK7231N version 1.17.206
    Attachments:
    • BK7231N_TuyaConfig_obkFFA14151.bin (72 KB) You must be logged in to download this attachment.
  • #26 20685592
    MnM1
    Level 10  
    Posts: 175
    Help: 4
    Rate: 13

    Not sure if it helps - these are the dp_ids I got from Tuya IOT:

    Code: text Expand Select all Copy to clipboard
    {
  "result": {
    "properties": [
      {
        "code": "switch_led",
        "custom_name": "",
        "dp_id": 20,
        "time": 1691419039226,
        "value": true
      },
      {
        "code": "work_mode",
        "custom_name": "",
        "dp_id": 21,
        "time": 1691419328172,
        "value": "scene"
      },
      {
        "code": "colour_data",
        "custom_name": "",
        "dp_id": 24,
        "time": 1691419314227,
        "value": "000303e803e8"
      },
      {
        "code": "scene_data",
        "custom_name": "",
        "dp_id": 25,
        "time": 1691419366859,
        "value": "000d0d00002e03e803e800000000"
      },
      {
        "code": "countdown",
        "custom_name": "",
        "dp_id": 26,
        "time": 1691418854707,
        "value": 8000
      },
      {
        "code": "music_data",
        "custom_name": "",
        "dp_id": 27,
        "time": 1691418746551,
        "value": ""
      },
      {
        "code": "control_data",
        "custom_name": "",
        "dp_id": 28,
        "time": 1691418746551,
        "value": ""
      },
      {
        "code": "mic_music_data",
        "custom_name": "",
        "dp_id": 42,
        "time": 1691418746551,
        "value": ""
      },
      {
        "code": "dreamlight_scene_mode",
        "custom_name": "",
        "dp_id": 51,
        "time": 1691418849564
      },
      {
        "code": "dreamlightmic_music_data",
        "custom_name": "",
        "dp_id": 52,
        "time": 1691418849564
      },
      {
        "code": "lightpixel_number_set",
        "custom_name": "",
        "dp_id": 53,
        "time": 1691418854707,
        "value": 300
      }
    ]
  },
  "success": true,
  "t": 1691421341635,
  "tid": "45cd0986353511ee94e0a2e0adfc0b14"
}

  • #27 20685629
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12631
    The SM driver will not work for this device, as it's a TuyaMCU device.
    Your Tuya config even shows the baud rate:
    Screenshot of BK7231 Easy UART Flasher with a TuyaMCU device configuration in JSON format.
    The LEDs are blinking because MCU thinks it's in pairing mode. They will stop blinking as soon as you do:
    Code: text Expand Select all Copy to clipboard
    
tuyaMcu_defWiFiState 4

    to tell MCU that is "paired and connected to the cloud".

    First of all, are you sure this device has individually addressable LEDs?
    Helpful post? Buy me a coffee.
  • #28 20685636
    MnM1
    Level 10  
    Posts: 175
    Help: 4
    Rate: 13

    Hi - yes, I have made some progress - as per my post above yours.

    In regards to the individually addressable LED - I was only going by what you said in post number 2 in this thread (https://www.elektroda.com/rtvforum/topic3990646.html#20661340) :) and from the information I got from the sellers - "New information - they tell me that the driver is 16703. I assume it's SM16703."
    But maybe it is not?
  • #29 20685646
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12631
    Are you able to control this device with IR remote? I saw something like that mentioned in previous posts.

    If so, do a methodical test of changing, let's say, first colors, and copy the log from the Web App, and write down what each packet does. Something like:
    Quote:

    Info:TuyaMCU:TUYAMCU received: ?? ??? ??? ??? <--- this sets RED
    Info:TuyaMCU:TUYAMCU received: ?? ??? ??? ??? <--- this sets BLUE

    etc, etc.

    Try to capture dpID 24, dpID 28, etc, and always make sure to write down which particular TUYAMCU event does.

    I haven't seen yet an individually addressable LEDs with TuyaMCU, but they should be supportable.

    We could also use this command to manually send packets from OBK to the MCU to check what is working:
    A fragment of a documentation table showing the tuyaMcu_sendState command highlighted in orange.
    but first we need to know what to send.
    Helpful post? Buy me a coffee.
  • #30 20685661
    MnM1
    Level 10  
    Posts: 175
    Help: 4
    Rate: 13

    While I can control the device with the remote, it doesn't show anything in the logs.
    I can only see

    Code: text Expand Select all Copy to clipboard
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 00 00 01 01 04 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 0 (Heartbeat) with 8 bytes


    Code: text Expand Select all Copy to clipboard
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 03 00 00 05 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 3 (WiFiState) with 7 bytes


    When I press the OFF button

    Code: text Expand Select all Copy to clipboard
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 05 14 01 00 01 00 24 
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: 
Info:GEN:CHANNEL_Set channel 20 has changed to 0 (flags 0)
Info:MQTT:Channel has changed! Publishing 0 to channel 20


    And when I press the ON button

    Code: text Expand Select all Copy to clipboard
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 0 (Heartbeat) with 8 bytes
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: 
Info:GEN:CHANNEL_Set channel 20 has changed to 1 (flags 0)
Info:MQTT:Channel has changed! Publishing 1 to channel 20 



    I can't see anything else in the logs (I have all features selected including IR)
Reply | New topic
Report a violation of the law

Topic summary

✨ The discussion centers on the compatibility and firmware flashing of a Tuya waterproof LED light purchased from AliExpress, featuring BK7231N chipset and controlled via a TuyaMCU with an SM16703 LED driver. The main focus is on using Cloudcutter to flash OpenBK (OBK) firmware, determining whether the device uses the N or T version, and verifying driver support and GPIO configurations. Initial attempts to use the SM16703P driver in OBK showed limited success due to the device employing a TuyaMCU protocol rather than direct LED driver control. The device supports multiple DPIDs for functions such as power toggle, mode selection, color, scenes, timer, and music sync via microphone. Users successfully detached the device from the Tuya cloud using Cloudcutter, retaining full local functionality controlled through LocalTuya in Home Assistant (HA). Color control commands were developed and tested, revealing color channel mismatches (BGR vs RGB) adjustable via remote settings. Warm/cold white temperature control is not supported in the original firmware and remains unimplemented in OBK. Firmware backups were made to facilitate analysis. Advanced users explored hardware modifications to bypass TuyaMCU for direct SM16703 or WS2812B LED control, but this requires complex soldering due to unavailable SPI pins on the CB2S/CB3S modules. A comprehensive autoexec.bat script was shared to enable LED control, scene selection, and music mode via OBK commands. Issues such as LED blinking during pairing, color inversion, and device behavior after mode changes were addressed with command sequences and flag settings (e.g., TuyaMCU queue flag 43). Integration with HA was improved with MQTT commands and button configurations. The community continues to refine support, with ongoing development to rewrite the TuyaMCU driver and enhance device functionality, including animation triggers and improved color temperature handling. The device's IR remote has advanced features that can alter button functions and color mappings, which may cause unexpected behavior if misconfigured. Overall, the device is now operable with OBK firmware, supporting most Tuya app features locally, though some advanced functions like color temperature remain under development.
Generated by the language model.
Today's popular

FAQ

TL;DR: For owners of sealed DC 5–12 V Tuya dreamlight controllers, the safest path is: verify Cloudcutter first, then treat the device as TuyaMCU-based, not direct SM16703. As one developer put it, "The SM driver will not work for this device"; working control came from dpIDs, scene scripts, and Flag 43 queue support. [#20685629]

Why it matters: This thread shows how to free a waterproof Tuya light from the cloud without opening it, while avoiding the biggest failure mode: flashing a device that still lacks the right driver path.

Option What the thread found Practical result
BK7231N + TuyaMCU path Working support arrived first; test device reported BK7231N and later got scenes, color, brightness, and music mode working Best current route for this light
BK7231T + direct SM16703 tests Early SM16703 builds for T were missing or not ported; 202 T even returned 404 for one file Not the safe first choice
Direct SM16703 control Promised more customization, but this device turned out to use TuyaMCU in front of the LEDs Not the right control path for this product
Tuya app / LocalTuya only Full original behavior stays after cloud detachment, but you still rely on TuyaMCU datapoints Useful for testing before flashing

Key insight: The breakthrough was identifying the controller as a TuyaMCU light with dpIDs and 115200 baud, not a simple BK-to-LED direct driver design. Once the project switched from SM16703 experiments to TuyaMCU scripting, core functions started working. [#20685629]

Quick Facts

  • The Tuya IoT dump exposed 11 functional dpIDs on this device, including 20, 21, 24, 25, 26, 27, 28, 42, 51, 52, and 53, which made reverse-mapping possible in OpenBeken. [#20685592]
  • The pixel-count datapoint reported dpID 53 = 300, giving a concrete strip-length parameter for scene logic and timing tests. [#20685592]
  • The working TuyaMCU setup used 115200 baud and required tuyaMcu_defWiFiState 4 to stop the power-up blinking that looked like pairing mode. [#20720438]
  • A tested product variant was the RGB, 30 cm, 9 W, waterproof model from AliExpress, used as the sacrificial device for reverse-engineering. [#20686151]
  • Early queue-related instability showed up after roughly 7–8 color changes in Home Assistant on one tester’s setup, which is why Flag 43 became important. [#20722415]

1. How can I tell whether a Tuya LED controller on firmware 1.1.12 is compatible with Tuya Cloudcutter, and how do I choose between the BK7231N and BK7231T profile?

Use Cloudcutter in detection mode first, not full flashing. 1. Select the Cloudcutter-only option. 2. Try both the T and N profile for that exact firmware. 3. If one profile shows an “A-xx” prefix, use that platform for flashing. The thread’s practical rule was to avoid guessing before detection, because picking the wrong platform can strand a sealed device with no easy recovery path. [#20661998]

2. What is OpenBeken (OBK), and how does it work with TuyaMCU-based LED controllers like BK7231N or BK7231T devices?

OpenBeken is replacement firmware that runs on Beken Wi‑Fi chips and can control a separate TuyaMCU over serial. "TuyaMCU is a serial control MCU that handles device features through dpIDs, while the BK chip provides Wi‑Fi, scripting, and UI logic." In this thread, OBK worked by starting the TuyaMCU driver, setting Wi‑Fi state, mapping dpIDs, and sending scene or color commands instead of talking to LEDs directly. [#20720438]

3. What is an individually addressable LED driver such as SM16703P, and how is it different from simple RGB or CCT LED control?

An individually addressable LED driver such as SM16703P lets one strip show multiple colors on different LEDs at the same time. "SM16703P is an addressable LED driver that controls per-pixel color data, unlike simple RGB or CCT control where the whole strip changes together." The thread used a simple test: if one device can display several colors at once, it is addressable; if it only changes as a whole, it behaves like basic RGB/CCT lighting. [#20685681]

4. Why did the SM16703P test commands fail on some OpenBK builds, and which builds added working support for BK7231N versus BK7231T?

They failed because support landed unevenly across platforms and some builds missed the latest commit. One tester got SM16703P_Init NOT found, then found 1.17.202 T unavailable with a 404, while the maintainer confirmed the contributor had only provided a working version for N at that point. Later, a tester on BK7231N flashed 1.17.206 and could at least load the driver, while T support still needed porting. [#20669569]

5. How do I safely test a sealed waterproof Tuya light with Cloudcutter and OpenBeken without opening the device or risking permanent loss of functionality?

Test cloud detachment first and keep original behavior available as long as possible. 1. Verify Cloudcutter compatibility without flashing. 2. Add the light to Tuya and, if needed, LocalTuya first so you can inspect dpIDs. 3. Do not flash experimental direct LED drivers unless you have a backup or a cheap sacrificial unit. The maintainers explicitly recommended a 2 MB firmware backup before risky tests because support was incomplete early on. [#20662154]

6. Why do the LEDs start blinking blue immediately after power-up on this Tuya light, and how does the tuyaMcu_defWiFiState 4 command stop the pairing-style blinking?

They blink because the TuyaMCU thinks the device is still in Wi‑Fi pairing mode. The fix is to tell the MCU it is already paired and cloud-connected by sending tuyaMcu_defWiFiState 4. In the thread, the maintainer identified the blue blinking as MCU-side status behavior, not LED driver failure, and said the blinking would stop as soon as that command was applied. [#20685629]

7. How can I determine from Tuya Config data and dpIDs whether a light uses direct SM16703 control or a separate TuyaMCU controlling the LEDs?

Look for Tuya serial metadata and stateful dpIDs instead of raw LED pin control. In this case, the Tuya Config partition exposed a baud rate, and the live device reported dpIDs such as 20, 21, 24, 25, 51, 52, and 53, which confirmed a TuyaMCU path. The maintainer concluded that direct SM16703 commands would not work here because the LEDs were not being driven straight from the BK chip. [#20685629]

8. What do the Tuya dpIDs 20, 21, 24, 25, 27, 28, 51, 52, and 53 do on this dreamlight-style TuyaMCU LED controller?

They map the device’s main functions. 20 is power, 21 is mode, 24 is color/brightness data for light mode, 25 is scene data, 27 is phone-microphone music data, 28 is color-wheel control data, 51 is dreamlight scene mode, 52 is dreamlight music data, and 53 is pixel-number or timing-related control. The reverse-engineering notes also tied 21 values to 1 = light, 2 = scenes, and 3 = music. [#20720196]

9. How do I create a working autoexec.bat for this TuyaMCU RGB light in OpenBeken with Light mode, Music mode, and custom scene buttons like Curtain, Rainbow, and Firework?

Start with TuyaMCU, set Wi‑Fi state and baud, then bind HTTP buttons to mode and scene scripts. The working template used startDriver TuyaMCU, tuyaMcu_defWiFiState 4, tuyaMcu_setBaudRate 115200, tuyaMCU_setupLED 24 1, then scene buttons that first sent tuyaMcu_sendState 21 4 2 and next pushed scene payloads on dpID 25. A published example already included Music mode, Light mode, Curtain, Collision, Rainbow, Pile, Firework, and Chase buttons. [#20721021]

10. Why does the warm white and cool white temperature slider turn the LEDs off in OBK or Home Assistant on this device, and what does that imply about native Tuya support?

It turns the LEDs off because this device does not expose a real warm/cool white channel in its native Tuya behavior. After reviewing the original app, the developers concluded there was no CW slider at all there, only a color picker and preset modes. That means OBK or Home Assistant may show a white-temperature control, but on this product it is not backed by a valid Tuya datapoint and should not be treated as supported. [#20777571]

11. How can I fix swapped colors such as red showing as blue and blue showing as yellow on a TuyaMCU light, and when is the remote's RGB order setting involved?

Fix the RGB order in the remote’s hidden configuration, not in OBK first. One tester proved the mismatch was local to the lamp because tuyaMCU_sendColor 24 1 0 0 1 produced blue, 0 1 0 1 produced green, and 0 0 1 1 produced red. Later, the same user corrected the order by revisiting the remote/manual settings and confirmed the colors became correct without a firmware rewrite. [#20721099]

12. What is the difference between LocalTuya and TuyaLocal in Home Assistant, and which one fits a cloud-detached Tuya light after using Cloudcutter?

LocalTuya was the path discussed for a cloud-detached light in this thread. After detaching from the cloud, a contributor said the device would keep full functionality, but you would need LocalTuya to control it because it would no longer connect to the Tuya cloud. The thread mentions confusion with TuyaLocal, but the only concrete recommendation here was LocalTuya plus the device ID and dpIDs discovered during setup. [#20663292]

13. How do I use Home Assistant and MQTT to trigger TuyaMCU animations from OBK, including scene commands that need manual YAML or dashboard buttons?

Use MQTT publish actions from Home Assistant buttons and send the same OBK commands that work in the web UI. The maintainer said animation triggering still needed manual YAML or dashboard-button service actions, and later showed Home Assistant buttons sending MQTT commands. For example, scene buttons can publish a mode change to dpID 21 = 2 and then the required dpID 25 scene payload for Curtain, Rainbow, or Firework. [#20818136]

14. Why would color changes stop working after several tries in Home Assistant, and how does enabling OpenBeken flag 43 'TuyaMCU Use queue' affect reliability?

They can stop because back-to-back TuyaMCU writes collide or arrive in the wrong order. One tester reported color changes failing after about 7 or 8 tries until the lamp was power-cycled, which led to a test build and the new Flag 43: TuyaMCU Use queue. After enabling that queue flag, another tester reported that color changes and dimming worked every time from both the device page and Home Assistant. [#20766386]

15. What can I do if a TuyaMCU light powers back on after a reboot or power cut even with startup settings changed, and how can autoexec or SetStartValue be used as a workaround?

Use autoexec to force an OFF command after boot, because SetStartValue did not solve this TuyaMCU case. The reported workaround was: query state, wait about 1 second, then send tuyaMcu_sendState 20 1 0. The maintainer called it a temporary fix and noted the lamp may flash on briefly before turning off again, but it reliably restored the desired post-reboot OFF state until a firmware-side fix could be worked on. [#21275570]
Generated by the language model.
ADVERTISEMENT