Avatto DMS16-W1 CBU Dimmer + Puya PY32F002A MCU: OpenBeken Flashing and Autoexec Setup

divadiow 23 Jul 2024 08:20 62 4668 Cool? (+2)

📢 Listen (AI):

TL;DR

Avatto DMS16-W1 1-channel dimmer smart switch uses a CBU module talking to a Puya PY32F002A TSSOP-20 MCU.
The CBU riser was de-soldered, the factory firmware dumped with Easy Flasher, and TuyaMCU traffic captured with TuycaMCU Analyser and dual USB-TTL adapters.
The extracted firmware config showed baud 115200, and the full dpID map includes values the user still never saw for dpIDs 13 and 47.
OpenBeken autoexec now works for most functions and mirrors factory MCU communications, but mains testing is pending and the brightness-range dpID3 behavior remains unresolved.

Generated by the language model.

Hello. It's me again with another device. This is the Avatto DMS16-W1 1-channel dimmer smart switch with CBU talking to a Puya PY32F002A (TSSOP-20) MCU.

The Puya MCU is well documented and has had some interesting followings on Elektroda https://www.elektroda.com/rtvforum/topic3946116.html

CBU log out from power-on

After de-soldering the CBU riser the factory firmware was dumped using Easy Flasher, attached. The extracted config was "baud":"115200".

With a multimeter I determine the following traces

so I have everything I need to capture communications between the Puya and the CBU and potentially to use J-Link to read the flash of the Puya. Sadly I was not able to get a connection from J-Link to the MCU despite my best efforts. Even with NRST-reset pulled low.

Moving onto the communication between the CBU and the Puya, TuycaMCU Analyser was a winner for capturing all I could toggle and set within the official Tuya app. Those features being:

And with the CBU rise de-soldered we can easily switch between OpenBeken and the factory firmware to recheck default behaviour by removing the Puya from the equation in this setup:

And with two USB-TTL adaptors in the mix we can capture communications in real-time when setting up OBK autoexec.

The full extent of the dpIDs being

I did not see dpIDs 13 and 47 in all my fiddling in the Tuya app trying every function, boot communication or tuyaMcu_sendQueryState.

Fast-forward to the current state of the autoexec

which gives us

The countdown to power-on timer field numerical value will change every ~30s as the CBU receives an update from the MCU on time remaining.

This is as far as I have gone for now. Most functions appear to be working in OpenBeken, though I've not yet tested with mains power and an incandescent bulb. Certainly the communications I'm watching in the MCU analyser mirror what was seen in factory firmware.

There is one thing I don't yet know how to replicate. The brightness range, dpID3, allows you to customise the range from both ends. This is this screen in the Tuya app

The yellow indicator can be toggled from the left to right to reduce the minimum, as well as from right to left to reduce maximum. This can be seen in factory with these comms. It also involves dpID 2, I'm not sure how this can be replicated in OBK.

One thing I did notice was that although I've set the dimmer range to tuyaMcu_setDimmerRange 200 1000, same as factory, OpenBeken only displays a fixed 0-100 value range in the GUI for that channel when using the slider. It does however communicate the right values to the MCU.

suggestions for improvement welcome!

Attachments:

readResult_BK7231N_QIO_2024-14-7-11-17-17.bin (2 MB) You must be logged in to download this attachment.
PY32F002A_Datasheet_V0.2.pdf (2.98 MB) You must be logged in to download this attachment.

About Author

divadiow wrote 4859 posts with rating 860 , helped 424 times. Live in city Bristol. Been with us since 2023 year.

Comments

Add a comment

p.kaczmarek2 23 Jul 2024 13:55

Thank you for detailed presentation. This min/max (range) control seems like a very custom component, we don't have such channel type in firmware yet, especially that it would need to handle two dpIDs...... [Read more]

tomik67 30 Jul 2024 01:11

I recently received an identical AVATTO dimmer with the designation DMS 16-Y1 instead of W1. An interesting feature of this version is a timer that counts down the time until the light is switched off. I... [Read more]

groove6j 15 Feb 2025 16:58

I have the same dimmer switch, only it's the 2CH model. So I see mostly things are working fine with the 1CH unit, I will try out flashing my unit and report my findings. Seems like just the right dpIDs... [Read more]

divadiow 15 Feb 2025 19:52

you could sniff out the additional dpID(s) https://www.elektroda.com/rtvforum/topic3970199.html https://www.elektroda.com/rtvforum/topic4038151.html https://github.com/openshwprojects/OpenBK7231T_App?tab=readme-ov-file#features or... [Read more]

groove6j 15 Feb 2025 21:34

I already flashed it. Here is the full 2MB dump of Tuya FW. I had it connected to WiFi if it matters. Anyways it seems that things are very similar, because when using your autoexec.bat: *both physical... [Read more]

przemsi_ele 09 May 2025 12:57

Good job TuyaMCU is a great tool. I found another CBU and restore original tuya firmware for testing. My 2 channel wifi avatto dimmer software version https://obrazki.elektroda.pl/8674940200_1746889358_thumb.jpg... [Read more]

sp4rk1e 01 Oct 2025 07:33

thanks for your autoexec.bat files. I recently bought the 1CH and 2CH version of this dimmer. Both basically work. https://obrazki.elektroda.pl/1528888000_1759296745_thumb.jpg What I don't... [Read more]

p.kaczmarek2 01 Oct 2025 09:50

Did you check them with factory firmware first? I didn't have this particular model on my side, but the physical switch is connected to the MCU and not to the WiFi module, so I would assume that functionality... [Read more]

sp4rk1e 01 Oct 2025 09:59

That's what I think even the behavior is strange though.. After unpacking, I went straight to the flashing :-) So I unfortunately have no comparison to the factory firmware [Read more]

p.kaczmarek2 01 Oct 2025 11:53

I don't remember seeing dimmers controllable with brightness via toggle switch. I only saw them with buttons. So: 9. **DP 47:** - **Code:** switch_type (开关类型 [switch type]) ... [Read more]

sp4rk1e 01 Oct 2025 12:02

that's what I already tried. It took me a while to figure out what 'sync' should mean in this context. But finally all 3 worked. But none was suitable to dim the light. Just switch on/off. [Read more]

p.kaczmarek2 01 Oct 2025 12:09

Well, what are your DIY skills? Maybe we could try to connect button directly to WiFi module and then program it to change brightness? [Read more]

sp4rk1e 01 Oct 2025 12:31

ah, good idea directly connecting the switch/button to the WiFi module is easy for this hardware. In particular terminal 'N' is already connected with the ground of the 3.3V circuit. It means digital... [Read more]

p.kaczmarek2 01 Oct 2025 12:43

Ok, so your brightness control already works from OBK, right? So, in which channel is the brightness? Can you run: addChannel 2 10 to, for example, add 10 to channel 2, to increase brightness... [Read more]

sp4rk1e 01 Oct 2025 13:18

I'm completely new to openBK. I first had to remove some leftovers from my previous tries :-) Finally I setup everything new. What now works is: 'addChannel 2 10' increases the brightness by 10.... [Read more]

p.kaczmarek2 01 Oct 2025 13:23

Now, the addChannel is smarter than just adding value. It can also wrap around. Look: https://obrazki.elektroda.pl/1520117900_1759317688_bigthumb.jpg What is the range of dimmer here? 0 to 1000? So,... [Read more]

sp4rk1e 01 Oct 2025 13:36

nice! I first set tuyaMcu_setDimmerRange 0 1000 it appears something with wrapping is going wrong: AddChannel 2 10 0 1000 0 Debug:TuyaMCU:ApplyMapping: mapped dp 2 value... [Read more]

p.kaczmarek2 01 Oct 2025 13:52

Ok, you also need to be able to do on and off. Do you have a command for that? Probably toggleChannel? And then, look here: https://www.elektroda.com/rtvforum/topic3946427.html You can script it to: -... [Read more]

sp4rk1e 01 Oct 2025 14:05

ok, sometimes simply adding 1 by: AddChannel 2 1 causes huge steps in brightness change. The same with small negative values like 'AddChannel 2 -1' I first will have a look what's going... [Read more]

FAQ

TL;DR: For OpenBeken users modding Avatto dimmers, the proven path is 115200 baud with a TuyaMCU mapping; as one expert put it, "the ignore flag support is the only change really required" for stable scripted dimming. This FAQ shows how to flash the CBU, map 1CH/2CH dpIDs, and build reliable autoexec dimming with MCU feedback control. [#21711817]

Why it matters: This thread turns a partly working Tuya dimmer conversion into a repeatable OpenBeken setup, including stable dimming, dual-channel mapping, and custom button behavior.

Wariant	Kanały	Kluczowe dpIDs jasności	Baud TuyaMCU	Stan w wątku
Avatto DMS16-W1	1	2, 3, 5	115200	Działa z autoexec; min/max nadal niestandardowe
Avatto DMS16-Y1	1	2, 3, 6	115200	Potwierdzony timer i test z żarówką tradycyjną
Avatto 2CH	2	CH1: 2/3/5, CH2: 8/9/11	115200	Działa po mapowaniu dpID 7–12
Moyes MS-105	1	2	niewskazany w cytowanym skrypcie	Użyty do porównania zachowania ping-pong

Key insight: Najlepsze efekty dało przeniesienie przycisku z MCU na GPIO modułu BK7231N/CBU i sterowanie jasnością zdarzeniami OpenBeken. Gdy MCU odsyła opóźnione poziomy dimmera, flaga mapowania 2 może ignorować ten odczyt i wygładzić działanie. [#21708368]

Quick Facts

Puya PY32F002A to MCU ARM Cortex-M0+ do 24 MHz, z do 20 KB Flash, 3 KB SRAM i zasilaniem 1.7–5.5 V; w tym dimmerze współpracuje z modułem CBU przez UART. [#21164436]
Dla Avatto DMS16-W1 autor potwierdził konfigurację fabryczną "baud":"115200", a ten sam baud wykorzystano potem w tuyaMcu_setBaudRate 115200. [#21164436]
Zakresy DP dla 1CH są konkretne: jasność 10–1000, timer 0–86400 s, a pamięć stanu po zasileniu ma trzy tryby: off / on / memory. [#21164436]
W wersji 2CH drugi kanał kontynuuje numerację logicznie od dpID 7 do 12, co pozwoliło uruchomić osobne On/Off, brightness, min, max i countdown dla CH2. [#21441155]
Dla szybkiego ściemniania po przepięciu przycisku na GPIO działały ustawienia SetButtonTimes nawet 2 3 2 lub 10 3 1, ale stabilność zależała od ignorowania sprzężenia zwrotnego dimmera i czasem od kolejki TuyaMCU. [#21711591]

How do I flash OpenBeken onto an Avatto DMS16-W1 dimmer with a CBU module and a Puya PY32F002A MCU?

Flash the CBU, not the Puya MCU. 1. De-solder the CBU riser so you can dump or flash the Wi-Fi module separately with Easy Flasher. 2. Read the factory dump first and note the extracted UART config, which was 115200 on this device. 3. Reinstall the CBU, boot OpenBeken, then use TuyaMCU mapping to talk to the Puya over UART. J-Link access to the Puya failed in the thread even with NRST held low, so the working route was replacing only the CBU firmware. [#21164436]

What is TuyaMCU Analyzer, and how does it help capture dpIDs and UART traffic on Avatto dimmers?

"TuyaMCU Analyzer" is a UART analysis tool that captures Tuya MCU packets, identifies dpIDs, and correlates app actions with serial traffic in real time. In this thread it was the winning method for recording what changed when the official Tuya app toggled power, brightness, countdown, switch type, and memory settings. With the CBU riser removed and two USB-TTL adapters connected, the author could compare factory behavior against OpenBeken autoexec commands and build a correct mapping for dpIDs 1, 2, 6, and 14. [#21164436]

Which dpIDs are used by the Avatto DMS16-W1 1-channel dimmer for power, brightness, min/max brightness, countdown, switch type, and power-on state?

The 1-channel Avatto DMS16-W1 uses dpID 1 for power, 2 for brightness, 3 for minimum brightness, 5 for maximum brightness, 6 for countdown, 47 for switch type, and 14 for power-on state. The thread also lists dpID 4 as led_type_1 and dpID 13 as work_mode. Specific ranges are given: brightness and min/max are 10–1000, countdown is 0–86400 s, and power-on state supports off, on, and memory. [#21164436]

How should I write an OpenBeken autoexec.bat for the Avatto DMS16-W1 using startDriver TuyaMCU, tuyaMcu_setBaudRate 115200, and linkTuyaMCUOutputToChannel?

Use a minimal TuyaMCU mapping first, then add extras. Start with startDriver TuyaMCU, tuyaMcu_setBaudRate 115200, and tuyaMcu_defWiFiState 4. Map dpID 1 as bool to channel 1, dpID 2 as val to channel 2, dpID 6 as a text/countdown field, and dpID 14 as enum for power-on behavior. Set channel 2 as Dimmer and apply a hardware range such as 90 600 or 200 1000. The thread’s working scripts also add httpButtons, SetFlag 43 1, and event handlers when the physical switch is rewired to a GPIO. [#21708368]

Why does OpenBeken show a 0-100 dimmer slider in the GUI even when tuyaMcu_setDimmerRange is set to 200 1000 or 90 600?

OpenBeken shows the dimmer as a normalized 0–100 GUI value even when the TuyaMCU hardware range is different. The author explicitly observed that tuyaMcu_setDimmerRange 200 1000 still displayed a fixed 0-100 slider, while UART traffic proved the module sent correct raw Tuya values to the MCU. Later scripts kept the same pattern with ranges like 90 600 and comments that this hardware range is mapped to 0, 100 in the GUI. [#21164436]

What is the difference between the Avatto DMS16-W1/W1 and DMS16-Y1 dimmer variants discussed in the thread?

The thread treats DMS16-W1 and DMS16-Y1 as very similar 1-channel dimmers, but the Y1 variant added a visible countdown-to-off behavior in testing. The Y1 owner reported it worked great with a traditional incandescent bulb and listed the same core dpIDs: 1 for power, 2 for brightness, 3 for brightness range, 4 for switch type, 6 for timer, and 14 for power-on state. The reported baud in extracted config was also 115200, matching the W1 workflow. [#21173417]

How can I map the 2-channel Avatto dimmer dpIDs in OpenBeken, including CH2 values like dpID 7, 8, 9, 10, 11, and 12?

Map the 2-channel unit as CH1 on dpID 1–6 and CH2 on dpID 7–12. In the working 2CH autoexec, CH2 used dpID 7 for On/Off, 8 for brightness, 9 for minimum brightness, 10 for switch type, 11 for maximum brightness, and 12 for countdown. dpID 14 stayed global for power-on behavior. The author confirmed this layout by extracting the Tuya model JSON, where switch_led_2, bright_value_2, brightness_min_2, led_type_2, brightness_max_2, and countdown_2 followed the first channel directly. [#21441155]

What is the best way to handle brightness_min and brightness_max dpIDs in OpenBeken when the Tuya app uses a custom dual-ended range control?

The practical solution is to expose brightness_min and brightness_max as separate controls, not to mimic Tuya’s custom dual-ended slider. OpenBeken did not have a built-in channel type for that UI, and the firmware author said it would need to handle two dpIDs at once. The suggested fallback was two independent sliders, one for minimum and one for maximum, or a custom REST page if you want a better UI. That matches the thread’s conclusion: the Tuya range widget is custom, while OBK’s core mapping stays simpler. [#21164833]

Why does dimming flicker or jump on some TuyaMCU dimmers when using addChannel from OpenBeken event handlers?

Dimming can jump because the MCU reports delayed brightness feedback after OBK already sent a newer value. In logs, a hold event raised channel 2 to 91, but the MCU then reported raw value 554, which OBK mapped back to 90; the same pattern repeated at 93→92 and 95→94. Later testing showed these dimmers change brightness smoothly inside the MCU, so feedback can lag scripted commands. On Avatto DMS16-W1, that lag still caused sporadic flicker even after other fixes, while the compared Moyes MS-105 did not show the same issue. [#21707334]

How does Flag 43 '[TuyaMCU] Use queue' affect stability when sending rapid dimmer commands to a TuyaMCU device?

Flag 43 enables a TuyaMCU send queue so OBK does not push two packets at once. The firmware author described it as a stability aid for rapid command bursts, especially during hold-based dimming. It improved the theory of packet timing, but it did not fully cure Avatto flicker in this thread; the user still saw sporadic brightness flashes during addChannel dimming. The flag was also reported as a GUI/template inconsistency at one point, but it could be set with SetFlag 43 1 in autoexec and was shown correctly in the main flags page. [#21706850]

What does the new linkTuyaMCUOutputToChannel flags argument do, and how does flag value 2 ignore dimmer feedback from the MCU?

The new flags argument extends linkTuyaMCUOutputToChannel so 2 means “ignore read” for that mapping. In practice, linkTuyaMCUOutputToChannel 2 val 2 2 lets OBK send brightness to the MCU while discarding the MCU’s delayed dimmer feedback. That mattered because user scripts on rewired buttons expected their own channel values to win. The firmware author changed the older bDPCache argument into a flags field, where 1 keeps DP cache behavior and 2 suppresses incoming readback for that mapped channel. [#21707931]

How can I rewire the external S1 switch from the MCU to a BK7231N/CBU GPIO and use OpenBeken OnClick, OnHold, and OnRelease events for dimming?

Move S1 off the MCU and wire it to a CBU GPIO plus ground, then let OpenBeken handle the logic. 1. Physically isolate the switch terminal from the old MCU trace and connect it to a GPIO such as P28 on Avatto or P6 on Moyes; users noted terminal N was already tied to 3.3 V circuit ground. 2. Set that pin as Btn. 3. Bind OnClick to toggle power, OnHold to addChannel dimming, and OnRelease to reverse direction if needed. This gave short-press, long-press, and custom dimming behaviors the factory MCU logic did not provide. [#21706499]

What is ping-pong dimming mode in OpenBeken addChannel, and how is mode 2 different from mode 3?

Ping-pong mode makes addChannel bounce between the minimum and maximum instead of clamping or wrapping. With mode 2, OBK remembers direction and automatically reverses when the channel reaches limits such as 0 or 100; the author’s self-test showed a sequence like 0, 25, 50, 75, 100, 75, 50. With mode 3, OBK does not change brightness; it only flips the stored ping-pong direction in place. That let users dim on hold and reverse direction on release or another event. [#21711805]

OpenBeken event scripting vs the original MCU-controlled switch logic on Avatto and Moyes dimmers — which approach works better for custom dimming behavior?

OpenBeken event scripting works better when you want custom dimming behavior. The original MCU-controlled external switch on these dimmers mainly handled On/Off, and users could not get brightness control from the stock Avatto switch logic even after trying flip, sync, and button modes. By moving the switch to a BK7231N GPIO, users added short-press toggle, long-press dimming, release-triggered direction changes, and ping-pong dimming. One thread expert summarized the benefit clearly: rewiring to the Wi-Fi module “allows interesting new features the original device is lacking.” [#21708368]

How long does it take these OpenBeken-configured Avatto or Moyes dimmers to go from minimum to maximum brightness, and what happens on power-on: instant full brightness or a smooth ramp-up?

The thread does not give a confirmed low-to-high timing for Avatto or Moyes after the final scripts, and one later user asked whether the MS-105 still took about 5 s. What is clear is that both devices dim smoothly inside the MCU, and the user scripts often turn the light on at a very low level first, for example with SetChannel 2 1, then continue dimming upward on hold. That means power-on in the custom script can be a controlled low-start rather than an instant jump to 100%, but no final benchmark in seconds was posted. [#21773291]

Generated by the language model.