logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol

williamgibsonwg 8166 58

TL;DR LABEL_AI_GENERATED

  • This teardown covers C01W/C02W/C03W/C04W WiFi+BT LED controllers built around a CBU BK7231N module and a CMS32L051 microcontroller.
  • The CBU module is sandwiched between two boards, while the CMS32L051 handles Bluetooth and drives buffered RGBCW PWM outputs through a 74HC245.
  • Desoldering the CMS32L051 exposed RX/TX on pins 5/6 and allowed flashing the CBU with a 3.3V FTDI TTL-232R-3V3 cable.
  • The modified C02W now works with OpenBeken after jumpering CMS32L051 pins 10 and 16 to CBU pins 8 and 9 and mapping extra channels.
  • Desoldering and splitting the controller from the base board was difficult, and flashing was impossible with the CMS32L051 installed.
AI summary based on the discussion. May contain errors.
ADVERTISEMENT
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
Listen:
  • Here I will present the short teardown and OpenBK7231 programming procedure for a family of LED controllers.
    They are based on CBU module, BK7231N

    C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol

    Unfortunately the CBU module is sandwiched between two boards, making access difficult.
    Here is the generic controller board, both sides:
    C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol

    The generic controller has PWM outputs RGBCW to the mode-specific base board.

    The PWM outputs are not attached to the CBU module!
    The CBU module is connected via UART to a CMS32L051 microcontroller, which is also attached to the bluetooth radio and provides the PWM outputs buffered by a 74HC245.

    I did not know how to get OpenBeken to connect to this CMS32L051 over uart, so the plan was to remove it and jumper to the CBU PWM pins:

    To flash the CBU I desoldered the CMS32L051 which gave access to RX/TX on pins 5/6 (there is a series 1k resistor on both lines)
    Connect:
    CBU:16 RX or CMS32L051:6 - FTDI TTL-232R-3V3 Orange
    CBU:15 TX or CMS32L051:5 - FTDI TTL-232R-3V3 Yellow
    Flashing with the windows tool and a 3v3 FTDI cable was smooth.
    Note: I had disconnected 1k resistors and connected directly on CBU pins.
    I know with CMS32L051 installed, flashing is not possible.
    I assume flashing will work through 1k resistors if CMS32L051 is removed, but this was not tested.


    The RCBCW PWM lines are available on CMS32L051 pins 13/14/15/16/10

    I have a C02W so I jumpered:
    CMS32L051:10 to CBU:8 or P8, and configured this as Channel 5
    CMS32L051:16 to CBU:9 or P7, and configured this as Channel 4

    Doing this without desoldering the controller from the base board would be quite challenging but not impossible. I did split the boards apart as part of my investigation, but it was difficult to remove enough solder even with a desoldering gun.

    For some reason OpenBeken would not set the outputs (i.e. Channel 0 = 0.00, Channel 1 = 0.00, Channel 2 = 0.00, Channel 4 = 0.00, Channel 5 = 0.00) if I only configured channels 4 and 5.
    So I also configured P6 as channel 1 and P9 as channel 2 which makes this a RGBCW device, and now channels 4/5 work, with channels 1/2 not connected to anything and channel 3 not configured.

    I now have a C02W working with OpenBeken.

    There is very likely a better technique, but this was my first OpenBeken device. Any advice would be welcome - I want several such modules but I'm not sure it's worth the hassle.

    Cool? Ranking DIY
    eufyMake E1 - łatwa personalizacja za pomocą druku UV [sponsorowany]
    About Author
    williamgibsonwg
    Level 3  
    Offline 
    williamgibsonwg wrote 6 posts with rating 2. Been with us since 2023 year.
  • ADVERTISEMENT

  • TuyaMCU packet capture workflow for LED control

    #2 20514694
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14765
    Help: 659
    Rate: 12899
    Hello, there are several ways to improve the workflow here.
    1. you can do a 2MB flash backup of this device and use it then to flash next pieces without soldering wires
    2. removing MCU and using PWMs for LED control is good, but you can also just use TuyaMCU driver. For that purpose, you might need first just solder ground ,RX1 and TX1 wires and capture packets with RealtTerm in text hex format. When capturing packets, do separate captures for activities on Tuya APP , like:
    - setting 100% warm
    - setting 100% cool
    - setting red color
    - setting brightness 25%, 50%, 60%, etc
    Then we can use our TuyaMCU analyzer to figure out which dpIDs are used to control colours, etc by the device. And then just use TuyaMCU protocol to control the MCU via OBK UART....

    Here is an example of captured data:
    Code: text Expand Select all Copy to clipboard
    
55AA032B00002D55AA0307000801020004000000BBD355AA03070008020200040000001F3855AA03000001010455AA032400002655AA031C00001E55AA032B00002D

    And now pasted into the analyzer:
    C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol
    Helpful post? Buy me a coffee.

  • Speculates OpenBeken stayed in rgb mode instead of cw

    #3 20514771
    williamgibsonwg
    Level 3  
    Posts: 6
    Rate: 2
    Thanks for the suggestions!
    I did take a backup of the original firmware if it is of use to anyone, let me know.

    I'm not sure what you mean about 'flash without flashing'.

    That's great there is a MCU decoder. Is that available for users or do I post the serial messages in a future teardown?

    Also do you have any suggestions why a cool/warm only LED device was not setting outputs? It looks like the OpenBeken RGBCW controller has a 'rgb' mode and a 'cw' mode and it's as if it was not switching into 'cw', so everything stayed off. That's pure speculation though.

  • Cloudcutter flashing and PWM channel mapping in OpenBeken

    #4 20514826
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14765
    Help: 659
    Rate: 12899
    Sorry, it seems that part of my message was lost during edit. I meant that doing 2MB backup allows you to flash without soldering wires, remotely, via the cloudcutter program. That way you can upload OpenBeken without soldering wires.

    I will be releasing analyzer tool, but for now please post hex data. Maybe I will just attach a build here so you can play with it.

    OpenBeken should work correctly in all common cases, including:
    - single PWM (set channel 0 or 1)
    - two PWMS (set channel 0 and 1, it should just work), as CW
    - three PWMs ( set channel 0, 1, 2 ) - as RGB
    - five PWMs (set channel 0, 1, 2, 3, 4) - RGBCW
    The order of set channels matters. You can start indexing with 0 or with 1, but order matters, and order is: RGBCW. The CW case can also handle special case, if you have two PWMs, the device will know it was meant to be use CW.

    Here is a screenshot from Windows Simulator with CW strip in OBK:
    C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol
    C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol
    C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol
    Helpful post? Buy me a coffee.

  • UART capture from a single-channel Tuya dimmer controller

    #5 20550433
    williamgibsonwg
    Level 3  
    Posts: 6
    Rate: 2
    Hi,

    I got another device and recorded the UART as requested.
    9600 baud 8N1 on pin 5

    Unfortunately the device isn't recognized as Cool/Warm, it appears as just a single channel "Smart Wi-Fi Dimmer" in both "Tuya Smart" and "Smart Life" apps, so I just get brightness and on/off. Both cool and warm are operated equally. I hope you can guess which is which - I would guess the protocol is consistent with RGBCW ordering since that's the pin layout on the main board.
    Let me know what else I can provide!


    Code: text Expand Select all Copy to clipboard
    
ON 10%
55 AA 00 06 00 05 14 01 00 01 01 21                                     

OFF
55 AA 00 06 00 05 14 01 00 01 00 20                                     

Change to 100% by swiping                                                                       
55 AA 00 06 00 19 1C 03 00 15 31 30 30 30 30 30 30 30 30 30 30 30 30 30 
30 38 66 30 33 65 38 C1 55 AA 00 06 00 19 1C 03 00 15 31 30 30 30 30 30 
30 30 30 30 30 30 30 30 33 36 37 30 33 65 38 93 55 AA 00 06 00 19 1C 03 
00 15 31 30 30 30 30 30 30 30 30 30 30 30 30 30 33 37 62 30 33 65 38 BF 
55 AA 00 06 00 08 16 02 00 04 00 00 03 75 A1 55 AA 00 06 00 05 14 01 00 
01 01 21 55 AA 00 06 00 19 1C 03 00 15 31 30 30 30 30 30 30 30 30 30 30 
30 30 30 33 65 38 30 33 65 38 C3 55 AA 00 06 00 08 16 02 00 04 00 00 03 
E8 14 55 AA 00 06 00 05 14 01 00 01 01 21                               
55 AA 00 00 00 00 FF                                                    


OFF
55 AA 00 06 00 05 14 01 00 01 00 20  

ON 100%                                   
55 AA 00 06 00 05 14 01 00 01 01 21 

Occasional random message
55 AA 00 00 00 00 FF 

"Good Night"
55 AA 00 06 00 05 14 01 00 01 01 21 55 AA 00 06 00 05 15 04 00 01 02 26 
55 AA 00 06 00 20 19 03 00 1C 30 30 30 65 30 64 30 30 30 30 30 30 30 30 
30 30 30 30 30 30 30 30 63 38 30 30 30 30 41                            

"Reading"                                                                        
55 AA 00 06 00 05 14 01 00 01 01 21 55 AA 00 06 00 05 15 04 00 01 02 26 
55 AA 00 06 00 20 19 03 00 1C 30 31 30 65 30 64 30 30 30 30 30 30 30 30 
30 30 30 30 30 30 30 33 65 38 30 31 66 34 82                            

"Working"                                                                        
55 AA 00 00 00 00 FF 55 AA 00 06 00 05 14 01 00 01 01 21 55 AA 00 06 00 
05 15 04 00 01 02 26 55 AA 00 06 00 20 19 03 00 1C 30 32 30 65 30 64 30 
30 30 30 30 30 30 30 30 30 30 30 30 30 30 33 65 38 30 33 65 38 88

Brightness 1%
55 AA 00 06 00 19 1C 03 00 15 31 30 30 30 30 30 30 30 30 30 30 30 30 30 
30 30 61 30 33 65 38 B4 55 AA 00 06 00 19 1C 03 00 15 31 30 30 30 30 30 
30 30 30 30 30 30 30 30 30 30 61 30 33 65 38 B4 55 AA 00 00 00 00 FF 55

Brightness 75%
55 AA 00 06 00 19 1C 03 00 15 31 30 30 
30 30 30 30 30 30 30 30 30 30 30 32 65 31 30 33 65 38 BB 55 AA 00 06 00 
19 1C 03 00 15 31 30 30 30 30 30 30 30 30 30 30 30 30 30 32 65 37 30 33 
65 38 C1 55 AA 00 06 00 19 1C 03 00 15 31 30 30 30 30 30 30 30 30 30 30 
30 30 30 32 65 61 30 33 65 38 EB 55 AA 00 06 00 08 16 02 00 04 00 00 02 
EA 15 

  • TuyaMCU packets include unexplained string dpIDs

    #6 20550441
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14765
    Help: 659
    Rate: 12899
    Here is the tool used:
    https://www.elektroda.com/rtvforum/topic3970199.html#20528459
    Here is interpretation:
    C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol
    The packet above is only turn on, no brightness change.

    C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol

    dpID20 = power?

    C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol
    dpID 22 = dimmer?
    What are those strange extra values?


    "Good night":
    C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol
    What may be this?
    fnId=25 Str V=30 30 30 65 30 64 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 63 38 30 30 30 30
    A string? What if we decode as ASCII...
    Code: text Expand Select all Copy to clipboard
    
30 30 30 65 30 64 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 63 38 30 30 30 30
00 0e 0d 00 00 00 00 00 00 00 00 c8 00 00

    C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol


    "Working"
    C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol


    C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol

    C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol

    I am not sure yet what are those strings. It seems that device is sending also some string ASCII data, maybe ASCII colour codes? I wonder why...
    Code: text Expand Select all Copy to clipboard
    
55 AA	00	06		00 19	1C030015313030303030303030303030303032656130336538	EB	
HEADER	VER=00	Unk		LEN	fnId=28 Str V=31 30 30 30 30 30 30 30 30 30 30 30 30 30 32 65 61 30 33 65 38	CHK


    So there is a dpID for power, for dimmer, and at least two strange dpIDs with string data.

    We need to figure what are those strings. Tell me again, you have only CW version which is seen by app as single color? Or do you have access to RGB / RGBCW version as well?
    Helpful post? Buy me a coffee.

  • Startup UART dump and failed write to raw channel 33

    #7 20550565
    williamgibsonwg
    Level 3  
    Posts: 6
    Rate: 2
    Thanks for your help. I've been at it for a few hours, not figured out yet.

    I have only one kind, cool/warm. The app detects it as monochromatic. I can't seem to manually add a C/W version either, it always autodetects.

    Since there are resistors on UART lines I can actually write serial commands with RealTerm and have them accepted.
    Frustratingly the crc isn't a RealTerm standard so I have to manually calculate it (I found out your app doesn't verify checksums, but it is really helpful, thanks for releasing it!)

    Read startup sequence on RX/TX (below). This lists variables:
    20 (bool) power 0/1
    21 (enum) Manual=0 Scene=2
    22 (int) Brightness 0=1000
    26 (int) ?? V=0
    34 (bool) ?? V=0
    33 (RAW) ?? V=00 01 00 00 03 E8 03 E8 03 E8 03 E8

    Note the string used by the app is NOT here.
    I've tried to create a Write 33 message by changing status message to command; not working:
    Code: text Expand Select all Copy to clipboard
    
Status 55 AA	03	07		00 10	21 00 00 0C 0001000003E803E803E803E8 		F3	
Write 0x55 0xAA 0x00 0x06 0x00 0x10 0x21 0x00 0x00 0x0C 0x00 0x01 0x00 0x00 0x03 0xE8 0x03 0xE8 0x03 0xE8 0x03 0xE8 0xEE


    On Startup:
    Code: text Expand Select all Copy to clipboard
    
55 AA 00 00 00 00 FF 55 AA 00 01 00 00 00 55 AA 00 02 00 00 01 55 
AA 00 08 00 00 07 55 AA 00 03 00 01 03 06 55 AA 00 03 00 01 04 07 55 AA 
00 00 00 00 FF
55 AA	00	00		00 00		FF	
HEADER	VER=00	Heartbeat		LEN		CHK	

55 AA	00	01		00 00		00	
HEADER	VER=00	Product		LEN		CHK	

55 AA	00	02		00 00		01	
HEADER	VER=00	McuConf		LEN		CHK	

0x55 0xAA 0x00 0x08 0x00 0x00 0x07
55 AA	00	08		00 00		07	
HEADER	VER=00	Unk		LEN	INVALID date		CHK	

55 AA	00	03		00 01	03	06	
HEADER	VER=00	WifiState		LEN	03	CHK	

55 AA	00	03		00 01	04	07	
HEADER	VER=00	WifiState		LEN	04	CHK	



Pin 6:
On Startup:
55 AA 03 00 00 01 00 03 55 AA 03 01 00 32 7B 22 70 22 3A 22 6E 77 61 
72 36 77 6F 76 61 71 79 63 78 78 7A 7A 22 2C 22 76 22 3A 22 31 2E 30 2E 
30 22 2C 22 6D 22 3A 32 2C 22 6D 74 22 3A 31 30 7D C1 55 AA 03 02 00 00 
04 55 AA 03 07 00 05 14 01 00 01 01 25 55 AA 03 07 00 05 22 01 00 01 00 
32 55 AA 03 07 00 05 15 04 00 01 02 2A 55 AA 03 07 00 08 16 02 00 04 00 
00 03 C0 F0 55 AA 03 03 00 00 05 55 AA 03 03 00 00 05 55 AA 03 00 00 01 
01 04 55 AA 03 07 00 10 21 00 00 0C 00 01 00 00 03 E8 03 E8 03 E8 03 E8 
F3 55 AA 03 07 00 08 1A 02 00 04 00 00 00 00 31
Decoded:
55 AA	03	00		00 01	00	03	
HEADER	VER=03	Heartbeat		LEN	00	CHK	

55 AA	03	01		00 32	7B2270223A226E77617236776F766171796378787A7A222C2276223A22312E302E30222C226D223A322C226D74223A31307D	C1	
HEADER	VER=03	Product		LEN	{"p":"nwar6wovaqycxxzz","v":"1.0.0","m":2,"mt":10}	CHK	

55 AA	03	02		00 00		04	
HEADER	VER=03	McuConf		LEN		CHK	

55 AA	03	07		00 05	14 01 00 01 01 		25	
HEADER	VER=03	State		LEN	fnId=20 Bool V=1	CHK	

55 AA	03	07		00 05	22 01 00 01 00 		32	
HEADER	VER=03	State		LEN	fnId=34 Bool V=0	CHK	

55 AA	03	07		00 05	15 04 00 01 02 		2A	
HEADER	VER=03	State		LEN	fnId=21 Enum V=2	CHK	

55 AA	03	07		00 08	16 02 00 04 000003C0 		F0	
HEADER	VER=03	State		LEN	fnId=22 Val V=960	CHK	

55 AA	03	03		00 00		05	
HEADER	VER=03	WifiState		LEN		CHK	

55 AA	03	03		00 00		05	
HEADER	VER=03	WifiState		LEN		CHK	

55 AA	03	00		00 01	01	04	
HEADER	VER=03	Heartbeat		LEN	01	CHK	

55 AA	03	07		00 10	21 00 00 0C 0001000003E803E803E803E8 		F3	
HEADER	VER=03	State		LEN	fnId=33 Raw V=00 01 00 00 03 E8 03 E8 03 E8 03 E8	CHK	

55 AA	03	07		00 08	1A 02 00 04 00000000 		31	
HEADER	VER=03	State		LEN	fnId=26 Val V=0	CHK


    Through a lot of slow effort I simplified some cases for the strings:
    Code: text Expand Select all Copy to clipboard
    
0000000000000000000000100000 1%
0000000000000000000000300000 2%
0000000000000000000000500000 3%
0000000000000000000001000000 11%
0000000000000000000002000000 32%
0000000000000000000003000000 62%

0000000000000000000010000000 99.9%
0000000000000000000020000000 32% (weird)
0000000000000000000030000000 99.9% 
0000000000000000000040000000 99.9% 
0000000000000000000050000000 0%

0000000000000000001000000000 1%
0000000000000000003000000000 2%
0000000000000000005000000000 3%
0000000000000000010000000000 11% (same pattern)

0000000000000000100000000000 99.9% (same weird pattern)

A 1 in any other position (0x31 character) results in OFF/0%
In all cases, R=G=B=0 and C=W=%
  • ADVERTISEMENT

  • Tuya scene button triggers preset brightness only

    #8 20559601
    jrhenk
    Level 10  
    Posts: 59
    Help: 1
    Rate: 8
    Hi Everyone,
    I also got this device today, the CW01 version. Flashing with cloudcutter worked flawlessly, however the config seems a bit more demanding.
    - With the Tuya App the device worked as expected, so I'd say the hardware is OK
    - With openbeken and the config from the screenshot above (pwms at 24,26 and the rest as on the screenshot) I can't change anything. Not even switch on/off. Just for fun I also tried 6, 7, 8, 9 for PWM but also nothing yet.
    - Another issue I haven't seen with openbeken before: While I can edit the pins via the Web App, if I click on the Module section in the UI the firmware just crashes on loading the page (often does not get beyond field 7 or so)

    Happy to help troubleshooting if I can, checked the weblog but did not see any obvious yet there.

    Edit: One potentially interesting thing I noticed: Nevertheless the device runs openbeken now, if I click the button it shows the same dimming up/down as if it would still be running the tuya firmware. Maybe my device actually works with a TuyaMCU? Well I guess all tuya devices have one, but I mean we might need to use the TuyaMCU driver instead of configuring PINs directly? Do I actually understand right how this works? lol

    Added after 8 [minutes]:

    >>20550441
    I can at least help with this :)
    Before I flashed it, I played around with it a bit more and the "Good Night" is a Tuya Scene that just sets the device to some pre-configure brightness :)

  • Serial capture confirms dpID20 power and dpID22 dimmer

    #9 20559645
    williamgibsonwg
    Level 3  
    Posts: 6
    Rate: 2
    Hi jrhenk,

    You might have missed the part where I desoldered the TuyaMCU and directly soldered wires to the CBU.
    I don't recommend you follow this procedure though, since it's a pain.

    Thanks to p.kaczmarek2 I captured the serial RX/TX between TuyaMCU and CBU.

    p.kaczmarek2 - the captures I provided above are from a C01W, not a C02W like I thought.
    I think the strange string we discussed is unnecessary. Sending the on/off and brightness commands over serial did perform as expected.
    dpID20 = power
    dpID 22 = dimmer
    How can we make the TuyaMCU module for jrhenk's C01W?

    I will attempt a capture from a C02W when it arrives.

  • Clarifying TuyaMCU dpID mapping for power and dimmer

    #10 20559648
    jrhenk
    Level 10  
    Posts: 59
    Help: 1
    Rate: 8
    Thanks for the quick reply! I saw that but also the follow up that it's not necessary if you load the tuya driver, made me not getting my solder iron out :) I also saw the info about the dpIDs yet I'm not 100% what to do with it.
    I put "startDriver TuyaMCU" in the autoexec.bat and under "Channel Types" in the Web App configured power for 20 and dimmer for 22 but that didn't work and I also only see a slider for "power" on the www ui which seems wrong... it feels like I'm very close :)

  • Proposed TuyaMCU config for C01W power and dimmer IDs

    #11 20559683
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14765
    Help: 659
    Rate: 12899
    Hello, good job, assuming that this is true:
    williamgibsonwg wrote:

    p.kaczmarek2 - the captures I provided above are from a C01W, not a C02W like I thought.
    I think the strange string we discussed is unnecessary. Sending the on/off and brightness commands over serial did perform as expected.
    dpID20 = power
    dpID 22 = dimmer

    You can use approach from this topics:
    Dimmer EDM-01AA-EU 300W for BK7231 and TuyaMCU - configuration
    MoesHouse DIY Smart WiFi Light LED Dimmer Switch Smart Life
    Please read both of the guides above, but basically, here is a proposed config:
    Code: text Expand Select all Copy to clipboard
    

startDriver TuyaMCU
setChannelType 1 toggle
setChannelType 2 dimmer
// not needed here?
//tuyaMcu_setBaudRate 115200
tuyaMcu_setDimmerRange 1 1000
// dpID 20 is power
linkTuyaMCUOutputToChannel 20 bool 1
// dpID 22 is dimmer
linkTuyaMCUOutputToChannel 22 val 2

    but I am not sure if it's all that is required.
    Don't we also need to send that strange ASCII RGB string packet?
    Helpful post? Buy me a coffee.

  • Slow boot time on flashed LED controller

    #12 20560137
    jrhenk
    Level 10  
    Posts: 59
    Help: 1
    Rate: 8
    Oh yes, it's completely working now, thanks so much for the config!!! Thanks to it, I also have a better chance now to translate the initial findings into a config syntax since I had now idea how to do that yesterday :)
    BTW: I bought this module for a little test and was not sure how it goes, as I didn't want to use it for a LED strip but for 12v LED Spots. I reckoned that if you dim the 12V itself and not a power supply that provides the 12V the dimming must be nicer, and this is indeed the case! It's the smoothest dimming I saw for 12V spots so far.

    After using the config I can also go to the Module configuration in the WWW UI without the firmware crashing.

    The only thing that could still be improved now is the boot time, for some reason this module needs significantly longer compared to all other openbeken flashed modules I have until it is initialized. As well on power disconnect/connect as on reboot it needs around 60-80 seconds before it's up.
  • #13 20560204
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14765
    Help: 659
    Rate: 12899
    What does the log say during boot? Connect UART to USB converter RX to TX2 pin of your module.
    Helpful post? Buy me a coffee.
  • #14 20560337
    jrhenk
    Level 10  
    Posts: 59
    Help: 1
    Rate: 8
    Is there any way to do this remotely? Already installed it into a ceiling and also a bit afraid I break it after all with my still beginner's soldering skills

    edit: interesting, after configuring mqtt startup is down to 40sec , still a bit long but definitely better already
  • ADVERTISEMENT
  • #15 20560397
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14765
    Help: 659
    Rate: 12899
    open web app log, press reboot, clear log, and wait for the log to update, it will show a great chunk of things that happen at startup
    Helpful post? Buy me a coffee.

  • TuyaMCU state parsing shows dpId 22 and 31 packets

    #16 20560412
    jrhenk
    Level 10  
    Posts: 59
    Help: 1
    Rate: 8
    Ah ok! I thought you'll see even more when connecting cables, here's what it shows:


    Info:MAIN:Module reboot in 1...
    001/2/set
    Info:MQTT:MQTT client in mqtt_incoming_data_cb data is 0 for ch 1
    Info:GEN:No change in channel 1 (still set to 0) - ignoring

    Info:MQTT:MQTT client in mqtt_incoming_data_cb data is 36 for ch 2
    Info:GEN:CHANNEL_Set channel 2 has changed to 36 (flags 0)

    Info:MQTT:Channel has changed! Publishing 36 to channel 2
    Info:MQTT:Publishing val 36 to openbk/12V_dimmer001/2/get retain=0
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic openbk/12V_dimmer001/2/get
    Info:MQTT:Publishing val 12V_dimmer001 to openbk/12V_dimmer001/host retain=0
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 16 02 00 04 00 00 01 68 96
    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: 360
    Info:GEN:CHANNEL_Set channel 2 has changed to 35 (flags 0)

    Info:MQTT:Channel has changed! Publishing 35 to channel 2
    Info:MQTT:Publishing val 35 to openbk/12V_dimmer001/2/get retain=0
    Info:MAIN:Time 27, idle 361150/s, free 72792, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic openbk/12V_dimmer001/2/get
    Info:MQTT:Publishing val Build on Apr 28 2023 08:55:26 version 1.17.60 to openbk/12V_dimmer001/build retain=0
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 03 00 00 05
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 3 (WiFiState) with 7 bytes
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 06 1F 00 00 02 00 00 30
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 13 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 31, dataType 0-DP_TYPE_RAW and 2 data bytes
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 00 20
    Info:TuyaMCU:TuyaMCU_ProcessIncoming: discarding packet bad expected checksum, expected 32 and got checksum 9
    Info:TuyaMCU:Consumed 6 unwanted non-header byte in Tuya MCU buffer
    Info:TuyaMCU:Skipped data (part) 00 00 02 00 00 31
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 06 D2 00 00 02 00 00 E3
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 13 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 210, dataType 0-DP_TYPE_RAW and 2 data bytes
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 05 22 01 00 01 00 32
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 12 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 34, dataType 1-DP_TYPE_BOOL and 1 data bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte:
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 10 21 00 00 0C 00 01 00 00 03 E8 03 E8 03 E8 03 E8 F3
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 23 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 33, dataType 0-DP_TYPE_RAW and 12 data bytes
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 1A 02 00 04 00 00 00 00 31
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 26, dataType 2-DP_TYPE_VALUE and 4 data bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 0
    Info:MAIN:Time 28, idle 177066/s, free 72792, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:MQTT:Publishing val 1c:90:ff:43:a2:0c to openbk/12V_dimmer001/mac retain=0
    Info:MAIN:Time 29, idle 158262/s, free 72536, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:MQTT:Publishing val 2 to openbk/12V_dimmer001/sockets retain=0
    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
    Info:MAIN:Time 30, idle 347209/s, free 72792, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:GEN:dhcp=0 ip=192.168.1.85 gate=192.168.1.1 mask=255.255.255.0 mac=1c:90:ff:43:a2:0c
    Info:GEN:sta: 1, softap: 0, b/g/n
    Info:GEN:sta:rssi=-68,ssid=tripleXV/0,bssid=28:d1:27:4c:4c:13 ,channel=3,cipher_type:MIXED
    Info:MQTT:Publishing val -67 to openbk/12V_dimmer001/rssi retain=0
    Info:MAIN:Time 31, idle 179807/s, free 72792, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:MQTT:Publishing val 31 to openbk/12V_dimmer001/uptime retain=0
    Info:MAIN:Time 32, idle 189078/s, free 72792, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:MQTT:Publishing val 72792 to openbk/12V_dimmer001/freeheap retain=0
    Info:MAIN:Time 33, idle 187251/s, free 72792, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:MQTT:Publishing val 192.168.1.85 to openbk/12V_dimmer001/ip retain=0
    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
    Info:MAIN:Time 34, idle 189541/s, free 72792, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:MQTT:Channel has changed! Publishing 0 to channel 1
    Info:MQTT:Publishing val 0 to openbk/12V_dimmer001/1/get retain=0
    Info:MAIN:Time 35, idle 194308/s, free 72792, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic openbk/12V_dimmer001/1/get
    Info:MQTT:Channel has changed! Publishing 35 to channel 2
    Info:MQTT:Publishing val 35 to openbk/12V_dimmer001/2/get retain=0
    Info:MAIN:Time 36, idle 188306/s, free 72792, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic openbk/12V_dimmer001/2/get
    Info:MAIN:Time 37, idle 183630/s, free 72792, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    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
    Info:MAIN:Time 38, idle 190844/s, free 72792, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:MAIN:Time 39, idle 188607/s, free 72792, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:MAIN:Time 40, idle 190307/s, free 72792, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    Info:GEN:dhcp=0 ip=192.168.1.85 gate=192.168.1.1 mask=255.255.255.0 mac=1c:90:ff:43:a2:0c
    Info:GEN:sta: 1, softap: 0, b/g/n
    Info:GEN:sta:rssi=-68,ssid=tripleXV/0,bssid=28:d1:27:4c:4c:13 ,channel=3,cipher_type:MIXED
    Info:MAIN:Time 41, idle 185223/s, free 72792, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
    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
    Info:MAIN:Time 42, idle 192612/s, free 72792, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38

  • Questions about NTP delay and MQTT discovery support

    #17 20562988
    jrhenk
    Level 10  
    Posts: 59
    Help: 1
    Rate: 8
    alright, with the newest firmware and the wifi quickconnect flag set I won a couple of more seconds, and it's now down to 20 which is pretty much the same that I also get with a couple of other devices, some still seem to be faster though
    two questions if you don't mind:
    - On github I saw this issue report about NTP delay and in the logs it looks like that device is connected after just 5 seconds. With the C01W and a couple of RGBW spots it seems it just does not get under 20 sec... can this still be improved or does the driver just need this time to initialize?
    - Since one of the last firmware updates mqtt discovery is kind of working, but it seems I can still only control brightness if I add the device manually via the yaml file: is there something I can already do about it or is this going to be addressed in one of the next updates? I remember you said somewhere that tuyamcu discovery is still work in progress

    Thanks in advance!

  • NTP initialization takes about 7 seconds

    #18 20563018
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14765
    Help: 659
    Rate: 12899
    jrhenk wrote:

    - On github I saw this issue report about NTP delay and in the logs it looks like that device is connected after just 5 seconds. With the C01W and a couple of RGBW spots it seems it just does not get under 20 sec... can this still be improved or does the driver just need this time to initialize?

    The issue is closed. I can't think how it can be any faster.

    Here's a sample from my WB3S LED strip, I need 7 seconds to get to NTP ready:
    Code: text Expand Select all Copy to clipboard
    
Info:MAIN:Main_Init_Before_Delay
Info:CFG:####### Boot Count 45 #######
Warn:CFG:CFG_InitAndLoad: Correct config has been loaded with 11 changes count.
Error:CMD:no file early.bat err -2
Info:GEN:PIN_SetupPins pins have been set up.
Info:MAIN:Main_Init_Before_Delay done
Info:MAIN:Main_Init_Delay
Info:MAIN:Main_Init_Delay done
Info:MAIN:Main_Init_After_Delay
Info:MAIN:ssid:qqqqqqqqqqqqqqqqqqqqqqqqqqqq
Info:MAIN:Using SSID [qqqqqqqqqqqq]
Info:MAIN:Using Pass [qqqqqqqqqqqqqqqqq]
Info:MQTT:MQTT_RegisterCallback called for bT obkLEDstripWindow/ subT obkLEDstripWindow/+/set
Info:MQTT:MQTT_RegisterCallback called for bT bekens/ subT bekens/+/set
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/obkLEDstripWindow/ subT cmnd/obkLEDstripWindow/+
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/bekens/ subT cmnd/bekens/+
Info:MQTT:MQTT_RegisterCallback called for bT obkLEDstripWindow/ subT obkLEDstripWindow/+/get
Info:CMD:CMD_StartScript: started autoexec.bat at the beginning
Info:MAIN:Main_Init_After_Delay done
Info:NTP:NTP driver initialized with server=217.147.223.78, offset=0
Info:MAIN:Started NTP.
Info:MAIN:Time 1, idle 240138/s, free 84304, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Time 2, idle 215726/s, free 84304, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Time 3, idle 74493/s, free 84368, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Time 4, idle 0/s, free 84368, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTING - 1
Info:MAIN:Time 5, idle 10399/s, free 82808, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTED - 4
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTED - 4
Info:MQTT:mqtt_userName homeassistant
mqtt_pass qqqqqqqqqq
mqtt_clientID obkLEDstripWindow
mqtt_host 192.168.0.113:1883
Info:MAIN:Time 6, idle 244856/s, free 84264, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 3/38 
Info:MAIN:Boot complete time reached (5 seconds)
Info:CFG:####### Set Boot Complete #######
Info:NTP:Seconds since Jan 1 1900 = 3891990453
Info:NTP:Unix time  : 1683001653
Info:NTP:Local Time : 2023/05/02 04:27:33
Info:MAIN:Time 7, idle 214557/s, free 84496, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:CMD:"NTP is ready"


    jrhenk wrote:

    - Since one of the last firmware updates mqtt discovery is kind of working, but it seems I can still only control brightness if I add the device manually via the yaml file: is there something I can already do about it or is this going to be addressed in one of the next updates? I remember you said somewhere that tuyamcu discovery is still work in progress

    The discovery of TuyaMCU combo Toggle+brightness is still missing, but I can maybe try adding it today or tomorrow, would you be able to help with testing?
    Helpful post? Buy me a coffee.

  • Power-cycle needed for Wifi Quick Connect flag to speed boot

    #19 20564058
    jrhenk
    Level 10  
    Posts: 59
    Help: 1
    Rate: 8
    Thanks for the reply and it wasn't so much about the NTP I was just jealous about the quicker bootup time :)
    In the meantime I think I actually found a fix!! For some reason if you start using the Wifi Quick Connect Flag a simple reboot does not change a lot - it saves a couple of seconds but not more. Disconnecting the device from power and reconnecting it however leads to a significant change, now the same two devices that took 20sec to boot are up in 5-7 seconds, very cool! Dunno if this is specifically connected to these devices, but maybe it could make sense to add this as info to the flag 35
    Edit: Also tried it with RGBW spots (they use the SM2135 driver, the other two the tuyamcu one) and it shows the same behavior... so based on this I think it could make sense to add this tip to the flag

    About the brightness setting: Happy to help testing and share how it goes!!
  • #20 20564123
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14765
    Help: 659
    Rate: 12899
    I didn't know about that "full power off and power on" requirement. This is new to me. Maybe it didn't occur with my devices. @DeDaMrAz have you noticed anything like that?

    I will try to add that full discovery tomorrow. I haven't managed to do it today. I was working on TuyaMCU humidity/temperature sensor, a teardown with detailed guide will be posted in few days.
    Helpful post? Buy me a coffee.
  • #21 20564151
    jrhenk
    Level 10  
    Posts: 59
    Help: 1
    Rate: 8
    Great! You are crazy fast with answering questions here and updates anyway, so take your time... should all remain fun especially for you!

  • Full power cycle may be required for discovery

    #22 20564231
    DeDaMrAz
    Level 23  
    Posts: 620
    Help: 34
    Rate: 130
    p.kaczmarek2 wrote:
    I didn't know about that "full power off and power on" requirement. This is new to me. Maybe it didn't occur with my devices. @DeDaMrAz have you noticed anything like that?

    I will try to add that full discovery tomorrow. I haven't managed to do it today. I was working on TuyaMCU humidity/temperature sensor, a teardown with detailed guide will be posted in few days.


    :D I am not the best one to answer as I set up my devices on the bench and often do full power cycle while testing :)

  • Faster startup on C01W pointed to the cause

    #23 20564239
    jrhenk
    Level 10  
    Posts: 59
    Help: 1
    Rate: 8
    Hahaha it's these unconscious steps one tends to forget about that can turn out to be very important. But this was actually the way that led me to it: I have a C01W dimmer not yet installed where I noticed the faster startup after starting to play with it again, and a different dimmer that is already in the ceiling yet I can switch mains on it. After I noticed the quicker startup in the C01W I just thought: Could that be it? and it was, at least in my case :)
  • ADVERTISEMENT

  • Power loss restores C01W light state incorrectly

    #24 20567116
    jrhenk
    Level 10  
    Posts: 59
    Help: 1
    Rate: 8
    >>20564123
    Hi! I tried the latest firmwares but I guess you did not come around to include the brightness for autodiscovery yet, let me know when you do, happy to help with testing!

    About the C01W: I noticed that while the Moes MS 105 safe the channel states correctly (with the code posted in the other thread), this seem not to fully work yet for this device, guess it does not safe the channel 1 correctly..maybe there's a mistake in my code? On power disconnect/reconnect it sets the light on (to the last level when it was on) and only after reconnecting to mqtt it sets it off again. This does not happen on a reboot without disconnecting power. Here's my complete autoexec.bat - I added the part underneath and I think it's should work?

    Code: text Expand Select all Copy to clipboard
    
startDriver TuyaMCU
setChannelType 1 toggle
setChannelType 2 dimmer
// not needed here?
//tuyaMcu_setBaudRate 115200
tuyaMcu_setDimmerRange 1 1000
// dpID 20 is power
linkTuyaMCUOutputToChannel 20 bool 1
// dpID 22 is dimmer
linkTuyaMCUOutputToChannel 22 val 2
///////
// when channel 1 changes, save it to flash channel 201
addEventHandler OnChannelChange 1 setChannel 201 $CH1
// when channel 2 changes, save it to flash channel 202
addEventHandler OnChannelChange 2 setChannel 202 $CH2
addRepeatingEvent 1 1 backlog setChannel 1 $CH201; setChannel 2 $CH202

  • HASS discovery works for toggle and dimmer combo

    #25 20567163
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14765
    Help: 659
    Rate: 12899
    Hello, I haven't the time to test it yet, but the basic Toggle + Dimmer combo for HASS discovery should be working now. I will try out it today, please wait a moment..

    Added after 31 [minutes]:

    EDIT: wait, it seems to work for me! Take a look:
    C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol
    C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol
    With latest codebase, after doing again HASS Discovery:
    C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol
    C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol
    C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol
    So it works for me, currently for Toggle channel + Dimmer channel combo.
    Helpful post? Buy me a coffee.

  • C02W Tuya dpID mappings and scene format

    #26 20567914
    williamgibsonwg
    Level 3  
    Posts: 6
    Rate: 2
    I've finally got working C02W (d'oh)

    I have determined the string coordinates setting all values simultaneously.
    For non-scene control:
    dpID 21 = 0 (non-scene)
    dpID 22 = dimmer (0-1000)
    dpID 23 = Colour (0 = warm, 1000 = cool)
    dpID 28 = string ("10000000000000", 2 bytes dpID 22, 2 bytes dpID 23)
    -e.g. 100000000000003e803e8 for 100% Cool, 100000000000003e80000 for 100% Warm
    Assuming 1 0000 0000 0000 03e8 0000 is "1 R G B DIM COOL" for anyone with C03W/C04W/C05W, but I can't guess what dpIDs these correspond to sorry.

    When using the Tuya apps, it always uses dpID 28 while scrolling values, and then sets 23/22 after the smooth motion stops. I assume setting 23/22 independently will be OK.

    For scene control:
    dpID 21 = 2 (scene)
    dpID 25 = string :
    1 byte scene number (probably unimportant)
    repeating set of:
    2 bytes timing (100=4.5s, 72=3.2s, 52 = 2.3sm 40=0.5s, something like byte[decimal] = 33.8*exp(0.23*seconds))
    1 byte type (0=constant 1=flash 2=breathe)
    6 bytes zero (almost certainly reserved for RGB)
    2 bytes dpID 22, 2 bytes dpID 23
    for every item you want in the sequence.
    Smart Life only has 1 or 2 items in sequence, but format looks like maybe you could add more.

    Details:
    Spoiler:
    Set scene #4 to flash 100%C/100%W, slow (4.5s):
    dpID25 = "04 64640100000000000003e803e8 64640100000000000003e80000"

    Set scene #4 to flash 100%C/100%W, fast:
    dpID25 = "04 28280100000000000003e803e8 28280100000000000003e80000"

    Set scene #4 to breathe 100%C/100%W, fast (0.5s):
    dpID25 = "04 28280200000000000003e803e8 28280200000000000003e80000"

    C02W startup sequence:
    Product {"p":"3szijijz5uwozmjm","v":"1.0.0","m":2,"mt":10}
    dpID 20=1 (power)
    dpID 21=2 (scene)
    dpID 22=1000 (dimmer)
    dpID 23=1000 (colour)
    dpID 26 = 0 (??)
    dpID 33 = RAW: 00 01 00 00 03 E8 03 E8 03 E8 03 E8 (looks like scene info?)
    dpID 34=0 (??)




    Question: Is there a list of TypeString that setChannelType accepts somewhere? I couldn't find it, looked here.
    I'm not sure how to configure dpID 23.

    Does OpenBeken support constructing these strings? I don't think I care for my application but it was fun reverse engineering it a bit.

  • Autodiscovery still exposes only on/off entity

    #27 20569904
    jrhenk
    Level 10  
    Posts: 59
    Help: 1
    Rate: 8
    >>20567163
    Thanks for looking into it again, for some reason here it isn't working yet with the autodiscovery running 1.17.104
    This is the entity I added in the yaml:
    C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol
    ... and this is via the MQTT autodiscovery, just on/off so far
    C01W/C02W/C03W/C04W WiFi&BT LED Controller with TuyaMCU UART protocol

    Edit: just to be sure I deleted the autodiscovered entity again and let it be autodiscovered again, but still just on/off. Also tried with changing the name in case it's some home assistant issue, but same still ... let me know if I should try something else

  • C05W flashed with ESPHome Tuya config

    #28 20774279
    ray0711
    Level 1  
    Posts: 1
    Thanks to your documentation of your efforts I got my C05W up and running

    Steps
    - cloudcutter (by firmware version Main Module: V2.1.6)
    - flashed the esphome kickstart
    - flashed the esphome config below

    With the config below the C05W shows up in home-assistant and allows adressing all channels.
    I plan to use it as 2xCWW controller so i will still need to re-map the color channels to a second CWW dimmer.

    Code: text Expand Select all Copy to clipboard
    
logger:
  baud_rate: 0

web_server:
captive_portal:
mdns:
api:
ota:

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  ap:
  use_address: 192.168.2.226

uart:
  rx_pin: RX1
  tx_pin: TX1
  baud_rate: 9600
tuya:

light:
  - platform: "tuya"
    name: "CWW"
    color_temperature_datapoint: 23
    dimmer_datapoint: 22
    color_temperature_max_value: 1000
    switch_datapoint: 20
    min_value_datapoint: 0
    max_value: 1000
    color_temperature_invert: false
    cold_white_color_temperature: 6536 K
    warm_white_color_temperature: 2000 K
    color_datapoint: 24
    color_type: hsv

  • Bluetooth must be disabled to enable AP mode

    #29 21238000
    theosoft
    Level 10  
    Posts: 37
    Help: 1
    Rate: 2
    >>20774279
    I do have a C05W module and i am not able to cloud cut it.
    Is there any information regarding the right profile? It is on SW 2.1.6
    Has anybody a decoded firmware dump to try profile building?

    Thank you

    Edit:

    I found out: Bluetooth has to be disabled on Handy with tuya app.
    To activate the AP, you have to press the button for 10 sec. and then again for 5 sec.
    Then the AP is found and cloud cutting worked ok.
    The profile was:
    2.1.6 - BK7231N / bk7231n_common_user_config_ty --> Tuya Generic --> WT-SPI SPI RGBW LED Controller v2.1.6
  • #30 21238371
    jrhenk
    Level 10  
    Posts: 59
    Help: 1
    Rate: 8
    >>21238000
    Thanks for your additional info! I had a great run with cloudcutter but suddenly and especially with 2.x firmwares it just didn't seem to work anymore and I couldn't pin down why. Started collecting a pile of devices that I planned to flash with soldering. Never thought about having my phone close by could lead to this and will deffo give it another try!
Reply Cool? Ranking DIY | New topic
Notify about new articles
Listen:
Report a violation of the law

Topic summary

LABEL_AI_GENERATED
The discussion focuses on the teardown and OpenBK7231 firmware programming of a family of WiFi and Bluetooth LED controllers (models C01W, C02W, C03W, C04W, C05W) based on the BK7231N CBU module and CMS32L051 MCU. The CBU module is connected via UART to the TuyaMCU protocol, which controls PWM outputs for RGBCW LED channels. Users explored flashing OpenBeken firmware using cloudcutter and direct UART connections after desoldering the CMS32L051 MCU. Key challenges included interpreting TuyaMCU UART packets, configuring PWM channels correctly (order RGBCW), and handling cool/warm LED modes that sometimes defaulted to single-channel detection in Tuya apps. The TuyaMCU driver was used to decode and send commands via UART, with dpIDs 20 (power), 21 (mode), 22 (dimmer), 23 (color temperature), 25 and 28 (scene and string commands) identified. Users shared UART capture data and developed configuration scripts for OpenBeken, including channel type assignments and TuyaMCU command syntax. Firmware boot times were noted as longer (up to 80 seconds) but improved with MQTT and WiFi Quick Connect flags, especially after full power cycles. MQTT autodiscovery for brightness and toggle channels was partially functional, with ongoing improvements. Scene control commands required sending ASCII-encoded strings with timing and effect parameters. Cloudcutter success varied by firmware version; disabling Bluetooth on the phone and specific button press sequences enabled AP mode for cloudcutter on some devices. ESPHome integration was demonstrated for the C05W model with UART and Tuya platform configuration. Limitations in autoexec.bat command length and UART buffer sizes were discussed, with suggestions to manage command queuing and delays. Overall, the community collaboratively developed firmware flashing, UART protocol decoding, and configuration methods to enable OpenBeken control of these Tuya-based LED controllers, improving integration with Home Assistant and custom automation.
AI summary based on the discussion. May contain errors.
Today's popular

FAQ LABEL_AI_GENERATED

TL;DR: 15 answers and one proven config: “dpID20 = power” and dpID 22 controls brightness. This FAQ helps OpenBeken, ESPHome, and Home Assistant users flash C01W–C05W BK7231N LED controllers and choose TuyaMCU UART instead of risky PWM rewiring. [#20559645]

Why it matters: These controllers hide LED PWM behind a second MCU, so the right UART dpID mapping saves soldering time and avoids dead outputs.

Method Best case Key values Main drawback
Cloudcutter OTA conversion Firmware 2.1.6 profile worked on C05W Profile-dependent
Solder flashing Reliable local flash 3.3 V UART, RX/TX, GND Requires opening device
Remove CMS32L051 Direct PWM control CBU P7/P8 jumpers tested Difficult rework
TuyaMCU driver Keeps stock LED MCU 9600 baud, dpIDs 20/22/23 Needs UART decoding

Key insight: Do not treat the C01W/C02W board as a simple PWM LED strip controller. The CBU talks UART to a CMS32L051, so OpenBeken usually needs TuyaMCU dpID links, not only pin PWM roles.

Quick Facts

  • The controller family uses a CBU module with BK7231N, while the CMS32L051 handles Bluetooth and buffered RGBCW PWM through a 74HC245. [#20514670]
  • The working C01W OpenBeken TuyaMCU mapping is dpID 20 as power and dpID 22 as dimmer, with tuyaMcu_setDimmerRange 1 1000. [#20559683]
  • UART capture on the C01W used 9600 baud, 8N1, on MCU pin 5, and exposed dpIDs 20, 21, 22, 26, 33, and 34. [#20550433]
  • C02W warm/cool control uses dpID 22 for 0–1000 brightness and dpID 23 for 0–1000 color temperature. [#20567914]
  • A 2025 solder-flash report powered the CBU from 5 V at V+, held CMS32L051 reset low, and observed the CBU temperature rising from about 45 °C to 65 °C unloaded. [#21562219]

How do I flash OpenBeken on a C01W/C02W/C03W/C04W/C05W WiFi and Bluetooth LED controller based on the CBU BK7231N module?

Flash OpenBeken either by Cloudcutter or by 3.3 V UART on the CBU BK7231N module.
  1. Try Cloudcutter first if the Tuya firmware profile matches.
  2. For wired flashing, connect GND, RX, and TX to CBU UART.
  3. If the CMS32L051 blocks UART, remove it or hold its reset pin low.
One working wired method used CMS32L051 pins 5 and 6, plus GND, with a 3.3 V FTDI adapter. [#21562219]

What is TuyaMCU UART protocol and how does it control LED dimmers through dpIDs like 20, 22, 23, 25, and 28?

TuyaMCU UART sends framed serial commands where dpIDs represent device functions. "TuyaMCU UART protocol" is a serial control protocol that links the WiFi module to a secondary MCU, using framed packets and datapoint IDs to report or set power, dimming, color, and scene states. In this thread, dpID 20 controls power, dpID 22 brightness, dpID 23 color temperature, dpID 25 scenes, and dpID 28 combined non-scene values. [#20567914]

What is OpenBeken and why would someone install it on a Tuya BK7231N LED controller?

OpenBeken replaces Tuya cloud firmware with local control for BK7231N devices. "OpenBeken" is open firmware for Beken-based smart devices that provides local web, MQTT, scripting, and driver support, including TuyaMCU control for modules where the WiFi chip talks to another microcontroller. Users installed it here to control C01W and C02W LED dimmers locally through Home Assistant and MQTT. [#20560137]

What is Tuya Cloudcutter and which profile works for a C05W firmware 2.1.6 LED controller?

Tuya Cloudcutter performs an OTA conversion without soldering when the profile matches the Tuya firmware. "Tuya Cloudcutter" is an over-the-air flashing workflow that exploits compatible Tuya firmware, allowing BK7231 devices to receive alternate firmware without opening the enclosure or connecting UART wires. For C05W firmware 2.1.6, the reported working profile was “Tuya Generic → WT-SPI SPI RGBW LED Controller v2.1.6”. [#21238000]

Cloudcutter vs solder flashing: which method is better for converting C01W/C02W/C05W LED controllers to OpenBeken or ESPHome?

Cloudcutter is better when the profile works; solder flashing is better when OTA backup or exploit fails. Cloudcutter worked flawlessly for one C05W on firmware 2.1.6. A 2025 C01W case failed OTA backup, then succeeded with wired tools. Solder flashing also allows full firmware dumps with ltchiptool or bk7231tools before replacing Tuya firmware. [#21562219]

How do I configure OpenBeken TuyaMCU for a C01W single-channel dimmer using dpID 20 for power and dpID 22 for brightness?

Configure C01W as a TuyaMCU toggle plus dimmer device. Use this startup pattern: startDriver TuyaMCU, setChannelType 1 toggle, setChannelType 2 dimmer, tuyaMcu_setDimmerRange 1 1000, linkTuyaMCUOutputToChannel 20 bool 1, and linkTuyaMCUOutputToChannel 22 val 2. A user confirmed this made the C01W fully controllable. [#20560137]

Why do the PWM outputs on a C01W or C02W not work directly after flashing OpenBeken unless the TuyaMCU driver is used or the CMS32L051 MCU is removed?

The CBU pins do not drive the LED PWM outputs directly on the original board. The CBU talks by UART to a CMS32L051 microcontroller. That MCU connects to Bluetooth and provides RGBCW PWM through a 74HC245 buffer. Direct OpenBeken PWM works only after removing the MCU and jumpering LED channels to CBU GPIOs. [#20514670]

How can I capture and decode TuyaMCU UART packets from a CBU BK7231N LED controller using RealTerm or the TuyaMCU analyzer?

Capture RX/TX serial traffic as hex while changing one app function at a time. Use 9600 baud, 8N1 for the C01W capture. Record separate actions, such as ON, OFF, 1% brightness, 75% brightness, and scenes. Then paste hex frames into the TuyaMCU analyzer to identify dpIDs and data types. [#20550433]

What do the C02W TuyaMCU dpIDs mean for warm/cool control, brightness, color temperature, and scenes?

C02W uses separate dpIDs for mode, brightness, color temperature, and scenes. For non-scene control, dpID 21 selects non-scene mode 0, dpID 22 sets brightness from 0 to 1000, dpID 23 sets warm-to-cool from 0 to 1000, and dpID 28 sends the combined string. For scene control, dpID 21 becomes 2 and dpID 25 carries the scene string. [#20567914]

How are Tuya scene strings on dpID 25 encoded for C05W or MiBoxer HW5 RGB/CCT controllers, and why are they sent as ASCII hex strings?

Scene payloads on dpID 25 are typed as strings, so binary-looking scene bytes are sent as ASCII hex characters. One example used dpID 25 as 19, string type 03, and length 0036. The decoded scene began with 04 46 46 02 0078 03E8 03E8 0000 0000. The device must enter scene mode before receiving that scene payload. [#21253730]

How can I expose OpenBeken web buttons or scene commands as Home Assistant MQTT entities?

Expose a scene command by binding it to a published toggle channel. Create an alias for the TuyaMCU command, label a channel, publish that channel, and add a change handler. Then set the channel type to Toggle in the web app and rediscover the device in Home Assistant. One example used channel 6 and addChangeHandler Channel6 == 1 TEST. [#21255918]

Why does a C01W OpenBeken device take 40–80 seconds to boot, and how does the WiFi Quick Connect flag plus full power cycling improve startup time?

Slow startup improved after enabling WiFi Quick Connect and fully removing power. One user first saw about 60–80 seconds, then 40 seconds after MQTT configuration. With newer firmware and WiFi Quick Connect, a full power-off and power-on reduced startup to about 5–7 seconds on two devices. A simple reboot did not show the same gain. [#20564058]

What causes BK7231Flasher to fail when reading a C01W backup with “expected 4111” bytes, and what alternatives like ltchiptool or bk7231tools can be used?

The thread shows BK7231Flasher failing during read, while other tools completed identical dumps. The failure log expected 4111 bytes but saw 4095 bytes after detecting TH25Q16HB flash. Later testing reported that ltchiptool and bk7231tools both worked perfectly for the same C01W backup workflow, while BK7231Flasher did not work on Linux. [#21562219]

Where can I find the list of OpenBeken setChannelType TypeString values, and how should dpID 23 color temperature be configured?

The thread does not provide a complete TypeString list, but dpID 23 should map as color temperature for CCT control. For C02W, dpID 23 uses a 0–1000 warm-to-cool range. An ESPHome C05W example configured color_temperature_datapoint: 23, color_temperature_max_value: 1000, dimmer_datapoint: 22, and switch_datapoint: 20. [#20774279]

What safety and wiring precautions should I follow when soldering to CBU RX/TX pins or CMS32L051 pins 5 and 6 on a mains-powered LED controller?

Disconnect mains power and use only isolated low-voltage UART connections while soldering or flashing. Use a 3.3 V UART adapter for RX/TX, connect GND, and avoid driving the CMS32L051 during flashing. One successful method held CMS32L051 pin 3 reset to GND, used pins 5 and 6 for UART, and powered V+ from 5 V USB during bench flashing. [#21562219]
AI summary based on the discussion. May contain errors.
ADVERTISEMENT