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.
