logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Configuration Issues with Tuya S1-B-WT Triac Dimmer after OBK Firmware Flashing

andyc1 6012 35
Best answers

How do I manually configure OpenBeken for a Tuya S1-B-WT triac dimmer after flashing OBK so the switch and dimmer actually control the light?

Your device is a TuyaMCU dimmer, and the working OBK setup needs the correct baud rate plus the real dpIDs from the MCU log, not the guessed 1/2 mapping. Use an autoexec.bat like `startDriver TuyaMCU`, `tuyaMcu_defWiFiState 4`, `tuyaMcu_setBaudRate 115200`, then `setChannelType 1 toggle`, `setChannelType 2 dimmer`, `tuyaMcu_setDimmerRange 0 1000`, and finally `linkTuyaMCUOutputToChannel 20 1 1` and `linkTuyaMCUOutputToChannel 22 2 2` [#20652300][#20654338] The log you posted shows dpID 20 as a boolean on/off state and dpID 22 as a value for brightness, which is why the earlier 1/2 mapping did nothing [#20654116][#20654338] To identify dpIDs on your own device, open the Web App log and use the physical wall switch / dimmer input, since web-page toggles may not generate the same TuyaMCU packets [#20654184][#20654210] After updating the config, fully power-cycle the module; a web-app reboot alone did not reliably initialize all devices, but power off/on fixed the state reporting for the thread starter [#20665740]
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • #1 20649501
    andyc1
    Level 3  
    Posts: 14
    Rate: 2
    Configuration Issues with Tuya S1-B-WT Triac Dimmer after OBK Firmware Flashing Hello,
    I have a Tuya generic S1-B-WT triac dimmer which I have successfully flashed with the latest OBK firmware.
    I can navigate to the device IP address and can launch the web application. There is a cloudcutter profile available but when I paste it into the import section of the app, it doesn't seem to generate any useful script. I've been through the 3-step import process and restarted the device, but nothing happens. Here is the JSON code:
    Code: JSON
    Log in, to see the code


    I'm completely new to this sort of stuff and have no idea how to configure it manually or how to interpret this code.
    Can anyone help?

    Thanks

    Update.

    After reading this post : https://www.elektroda.com/rtvforum/topic3898502.html I thought that maybe my device has a TuyaMCU. So I copied the autoexec.bat script from that post and added it via the file system tab. I now have an on/off switch I can toggle and a dimmer slider on the main page. Unfortunately these do not actually make the device do anything, the light connected to the device doesn’t come on.
    Is there anything else I should do?
    Again, I’m a complete beginner so my understanding is minimal.
  • ADVERTISEMENT
  • #2 20652080
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12632

    Hello, can you extract OBK config that way:
    https://www.youtube.com/watch?v=WunlqIMAdgw
    so I can determine whether it's TuyaMCU and check the baud rate used?

    Still, by judging from the CC profile, it kinda looks like TuyaMCU, but at a higher baud rate than the device you linked, so no wonder it didn't work...
    Helpful post? Buy me a coffee.
  • #3 20652186
    andyc1
    Level 3  
    Posts: 14
    Rate: 2

    I've attached the requested TuyaConfig file for you and I've also taken a couple of photos of the inside of the device so that you can see the components if that might be of any help to you.

    Configuration Issues with Tuya S1-B-WT Triac Dimmer after OBK Firmware Flashing Configuration Issues with Tuya S1-B-WT Triac Dimmer after OBK Firmware Flashing
    Attachments:
    • BK7231T_TuyaConfig_extension_1.bin (72 KB) You must be logged in to download this attachment.
  • #4 20652300
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12632
    The binary you have attached confirms the data from CC profile:
    Code: JSON
    Log in, to see the code

    Please try following autoexec.bat:
    Code: text Expand Select all Copy to clipboard
    
startDriver TuyaMCU
tuyaMcu_defWiFiState 4
tuyaMcu_setBaudRate 115200

    Reboot, then open Web App log, and try pressing the button, changing brightness, etc, etc, and copy the web app log here so we can see which dpIDs are received by OBK.

    EDIT: You could also try to guess dpIDs, maybe they still have dpID 1 for switch and 2 for dimmer, if that's the case, then try:
    Code: text Expand Select all Copy to clipboard
    
startDriver TuyaMCU
tuyaMcu_defWiFiState 4
tuyaMcu_setBaudRate 115200

// not sure about those ids:

setChannelType 1 toggle
setChannelType 2 dimmer
tuyaMcu_setDimmerRange 0 1000
linkTuyaMCUOutputToChannel 1 1 1
linkTuyaMCUOutputToChannel 2 2 2
    Helpful post? Buy me a coffee.
  • #5 20654116
    andyc1
    Level 3  
    Posts: 14
    Rate: 2
    Hello,
    I've copied the autoexec.bat to the device with your suggestion of trying dpId 1 for switch and dpId 2 for dimmer again. The device still doesn't work, however.
    Here is the log after I've toggled the switch and moved the dimmer :

    Info:MAIN:Time 737, idle 266616/s, free 84936, MQTT 1(2), 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 738, idle 256722/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 739, idle 252465/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 740, idle 256624/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 741, idle 261507/s, free 84936, MQTT 1(2), 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 742, idle 261891/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 743, idle 263425/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 744, idle 254676/s, free 84712, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 3/38
    Info:MAIN:Time 745, idle 256978/s, free 84936, MQTT 1(2), 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 746, idle 256964/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 747, idle 249703/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 748, idle 253313/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 749, idle 256125/s, free 84936, MQTT 1(2), 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 750, idle 516447/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 751, idle 252728/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 752, idle 256741/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 753, idle 256820/s, free 76320, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 3/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 754, idle 258886/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 755, idle 248278/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MQTT:Channel has changed! Publishing 0 to channel 1
    Info:MQTT:Publishing val 0 to extension_1/1/get retain=0
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic extension_1/1/get
    Info:MAIN:Time 756, idle 254900/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MQTT:Channel has changed! Publishing 1 to channel 1
    Info:MQTT:Publishing val 1 to extension_1/1/get retain=0
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic extension_1/1/get
    Info:MAIN:Time 757, idle 250274/s, free 84936, MQTT 1(2), 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 758, idle 258054/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MQTT:Channel has changed! Publishing 0 to channel 1
    Info:MQTT:Publishing val 0 to extension_1/1/get retain=0
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic extension_1/1/get
    Info:MAIN:Time 759, idle 247987/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MQTT:Channel has changed! Publishing 1 to channel 1
    Info:MQTT:Publishing val 1 to extension_1/1/get retain=0
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic extension_1/1/get
    Info:MAIN:Time 760, idle 254244/s, free 84728, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 761, idle 249814/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MQTT:Channel has changed! Publishing 9 to channel 2
    Info:MQTT:Publishing val 9 to extension_1/2/get retain=0
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic extension_1/2/get
    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 762, idle 259644/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MQTT:Channel has changed! Publishing 20 to channel 2
    Info:MQTT:Publishing val 20 to extension_1/2/get retain=0
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic extension_1/2/get
    Info:MAIN:Time 763, idle 252325/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 764, idle 254945/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MQTT:Channel has changed! Publishing 58 to channel 2
    Info:MQTT:Publishing val 58 to extension_1/2/get retain=0
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic extension_1/2/get
    Info:MAIN:Time 765, idle 255425/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MQTT:Channel has changed! Publishing 81 to channel 2
    Info:MQTT:Publishing val 81 to extension_1/2/get retain=0
    Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic extension_1/2/get
    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 766, idle 252698/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 767, idle 253144/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 768, idle 254858/s, free 84936, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 769, idle 256429/s, free 84936, MQTT 1(2), 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 770, idle 251833/s, free 84712, MQTT 1(2), bWifi 1, secondsWithNoPing 1, socks 3/38
  • ADVERTISEMENT
  • #6 20654184
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12632

    Did you toggle the dimmer by using a physical switch? There is no toggling in log.

    Toggling the dimmer on the web page will not help.

    You need to attach a physical switch to the device like in the Tuya manual and use it to adjust the dimmer mode. Then copy the log here.
    Helpful post? Buy me a coffee.
  • #7 20654204
    andyc1
    Level 3  
    Posts: 14
    Rate: 2
    Do you mean wire in a standard dimmer switch as in this wiring diagram?
    Configuration Issues with Tuya S1-B-WT Triac Dimmer after OBK Firmware Flashing
    If not, please explain.
    What should I look for in the log to check I've done it correctly?
  • #8 20654210
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12632
    Yes, wire it as on manual.

    Your log currently shows that TuyaMCU works:
    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 (Hearbeat) with 8 bytes

    Text above was copied from your log. But we need to know dpIds.

    So something like:
    Code: text Expand Select all Copy to clipboard
    
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 7, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 07 00 05 01 01 00 01 01 0F 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 7 (State) with 12 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 1, dataType 1-DP_TYPE_BOOL and 1 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte: 
Info:TuyaMCU:TUYAMCU received: 55 AA 00 00 00 01 01 01 

    You need to know which dpID is brightness (0 to 1000 value) and which is toggle (1 or 0).

    See related topic: https://www.elektroda.com/rtvforum/topic3971440.html
    Helpful post? Buy me a coffee.
  • #9 20654276
    andyc1
    Level 3  
    Posts: 14
    Rate: 2
    Info:MAIN:Time 120, idle 255798/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38

    Info:GEN:sta: 1, softap: 0, b/g/n

    Info:MAIN:Time 121, idle 256285/s, free 84936, MQTT 1(4), 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 122, idle 257517/s, free 84720, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 3/38
    Info:MAIN:Time 123, idle 261994/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 124, idle 259182/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 125, idle 258917/s, free 84936, MQTT 1(4), 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 126, idle 259142/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 127, idle 252645/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 128, idle 509759/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 129, idle 275874/s, free 84936, MQTT 1(4), 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 130, idle 260798/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38

    Info:GEN:sta: 1, softap: 0, b/g/n
    Info:MAIN:Time 131, idle 248198/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 132, idle 257561/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 133, idle 260344/s, free 84936, MQTT 1(4), 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 134, idle 277193/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 135, idle 253442/s, free 76328, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 3/38
    Info:MAIN:Time 136, idle 266841/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 137, idle 264837/s, free 84936, MQTT 1(4), 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: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:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 16 02 00 04 00 00 03 E8 18
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 22, dataType 2-DP_TYPE_VALUE and 4 data bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 1000
    Info:MAIN:Time 138, idle 254529/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 139, idle 240308/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 140, idle 268222/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38

    Info:GEN:sta: 1, softap: 0, b/g/n
    Info:MAIN:Time 141, idle 255353/s, free 84936, MQTT 1(4), 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 142, idle 261834/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 143, idle 253031/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 144, idle 260330/s, free 76328, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 3/38
    Info:MAIN:Time 145, idle 259039/s, free 84936, MQTT 1(4), 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 146, idle 257863/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 147, idle 254984/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 148, idle 524373/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 149, idle 264002/s, free 84936, MQTT 1(4), 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 150, idle 256541/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38

    Info:GEN:sta: 1, softap: 0, b/g/n
    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:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 16 02 00 04 00 00 03 E8 18
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 22, dataType 2-DP_TYPE_VALUE and 4 data bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 1000
    Info:MAIN:Time 151, idle 252131/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 152, idle 241174/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 153, idle 258513/s, free 84936, MQTT 1(4), 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 154, idle 259229/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 155, idle 251885/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 156, idle 269107/s, free 84936, MQTT 1(4), bWifi 1, secondsWithNoPing 1, socks 2/38
  • ADVERTISEMENT
  • #10 20654338
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12632

    This means dpID 20 is a boolean toggle on and off, and the dpID 22 is a value - dimmer state.

    Please change the dpIDs in autoexec.bat to reflect your device configuration.

    Reminder:


    Code: text Expand Select all Copy to clipboard
    linkTuyaMCUOutputToChannel dpId varType tgChannel

    Helpful post? Buy me a coffee.
  • #11 20654390
    andyc1
    Level 3  
    Posts: 14
    Rate: 2

    Yes, it works!
    Thank you very much for your help, I've learned a lot today.
    I'm going to try integrating into Home Assistant next, hopefully auto discovery will work okay because I don't know anything about YAML (yet).
  • #12 20654465
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12632

    Thank you, now I would like to add your device to our devices list. Can you give me some more information about where it was bought, how it looks like, maybe some screenshots from the seller page or photos of the box...
    https://openbekeniot.github.io/webapp/devicesList.html
    Helpful post? Buy me a coffee.
  • #14 20664674
    andyc1
    Level 3  
    Posts: 14
    Rate: 2

    Hello again,
    I have now flashed a further 6 modules of the same type and integrated all into Home Assistant. They all seem to work fine except for one issue.
    The modules can be switched on independently from Home Assistant via wall switches that operate via radio frequency.
    When I turn on/off the original module via the wall switch, the module's state correctly shows as "on"/"off" in HA and also in the OBK web app. The dimming level is also correctly shown.
    This does not work with the other 6 modules, i.e. if I switch them on/off via their wall switch, the "on"/"off" state is not reflected correctly within HA or the OBK app.
    If I restart the modules via the OBK web app, then their "on"/"off" state changes within the OBK web app and HA to correctly show their actual state.
    Once I use their wall switches again, however, the correct state is lost and I have to restart the modules again.
    I'm not aware that I have configured these modules any differently from the original one that works correctly.
    What might the problem be?
  • #15 20664687
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12632
    If a state change from physical button (or from RF) does not show in OBK app, this can mean that you haven't configured TuyaMCU correctly.

    Are you able to control those switches from OBK panel? Is the communication broken just in one direction, or is there no communication at all?

    Please try opening Web App Log and then changing physical switch state. Is the TuyaMCU packet for given dpID change received by OpenBeken?
    Helpful post? Buy me a coffee.
  • #16 20664783
    andyc1
    Level 3  
    Posts: 14
    Rate: 2

    I can confirm that I can control ALL switches from the OBK panel both on and off.

    The web log for the switch that works correctly shows that the TuyaMCU packet is received by OBK when the physical switch is used:
    Info: MQTT: Channel has changed! Publishing 1 to channel 1
    Info: MQTT: Channel has changed! Publishing 0 to channel 1

    I tried one of the other switches and the web log does not show this info when the physical switch is activated.
  • #17 20664845
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12632
    How your autoexec.bat looks like on such switch?
    Helpful post? Buy me a coffee.
  • #18 20664898
    andyc1
    Level 3  
    Posts: 14
    Rate: 2

    For the switch that doesn't work correctly:

    startDriver TuyaMCU
    tuyaMcu_defWiFiState 4
    tuyaMcu_setBaudRate 115200

    setChannelType 1 toggle
    setChannelType 2 dimmer
    tuyaMcu_setDimmerRange 0 1000
    linkTuyaMCUOutputToChannel 20 1 1
    linkTuyaMCUOutputToChannel 22 2 2

    It is the same for the switch that does work correctly although strangely the number of characters is different (217 above, 220 below):

    startDriver TuyaMCU
    tuyaMcu_defWiFiState 4
    tuyaMcu_setBaudRate 115200

    setChannelType 1 toggle
    setChannelType 2 dimmer
    tuyaMcu_setDimmerRange 0 1000
    linkTuyaMCUOutputToChannel 20 1 1
    linkTuyaMCUOutputToChannel 22 2 2
  • #19 20665740
    andyc1
    Level 3  
    Posts: 14
    Rate: 2

    I think I may have solved the issue.
    First, I made sure all the devices used the same autoexec.bat as the device that was working.
    Next, I restarted the devices from the web app. This didn't seem to work.
    Finally, I powered off all the devices and then restarted them. This seems to have worked and all switches are now reporting the correct state on the OBK web app and in HA.
  • #20 20665763
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12632
    Hmmm, I wasn't aware of this, but maybe there was some bug in the Tuya MCU itself that caused it to partially skip the initialization of the communication. Still, it's a new thing to me. I always repower my devices after doing config so I didn't know about this problem.

    I am glad to hear you've got it solved.
    Helpful post? Buy me a coffee.
  • #21 20665834
    andyc1
    Level 3  
    Posts: 14
    Rate: 2

    Thanks.
    I have one further thing I thought I should mention regarding the flashing procedure.
    The Wi-Fi module is a wb2s. I had read that when flashing it was necessary to short CEN to ground at the "waiting for...." stage to continue the procedure. This did not work for me and in the end, I just had 3v, TX, RX, and Gnd connected and let the script run. This worked fine, and I was able to successfully flash the OBK firmware.
  • #22 20665907
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12632
    There are two way to reboot device:
    - you can short CEN to ground
    - or you can just disconnect and reconnect the power
    Both should work fine, I prefer the latter.
    Helpful post? Buy me a coffee.
  • Helpful post
    #23 20784769
    atomphil
    Level 10  
    Posts: 31
    Help: 4
    Rate: 17

    p.kaczmarek2 wrote:
    Thank you, now I would like to add your device to our devices list. Can you give me some more information about where it was bought, how it looks like, maybe some screenshots from the seller page or photos of the box...https://openbekeniot.github.io/webapp/devicesList.html


    It is also a device from the Skydance ecosystem: https://www.iskydance.com/index.php?c=product_show&a=index&id=1606

    Perhaps the devices list should be updated.
  • #24 20785588
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12632
    Thank you, that's a very informative find. Futhermore I can see that documentation on the Skydance's site is very detailed, that's nice. Let me post here some screenshots:
    Image of a WiFi-RF dimmer with text on a webpage.
    Image of LED dimmer specifications and features. System wiring diagram with installation and mechanical structure description. Infographic showing features and applications of the Skydance AC TRIAC dimmer with Wi-Fi, RF, and push-button control.
    They even offer a leading edge or trailing edge dimming selection? Nice.
    Helpful post? Buy me a coffee.
  • #25 20799075
    atomphil
    Level 10  
    Posts: 31
    Help: 4
    Rate: 17

    Thanks to the information in this thread, I was able to install OpenBeken on my S1-B(WT) very easily. Everything works wonderfully, except for one thing:

    In the Home Assistant, the dimmer only reports as a switch and not as a dimmer. What do I need to change to be able to dim in the HA?
  • #26 20799107
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12632
    Please post your current configuration, all available information, and I will try to check what's wrong.

    Alternatively, you can always add the device manually - through the configuration.yaml.
    Helpful post? Buy me a coffee.
  • #27 20799131
    atomphil
    Level 10  
    Posts: 31
    Help: 4
    Rate: 17

    Thanks for your fast reply. In the Home Assistant, the dimmer only reports as a switch and not as a dimmer, and the signal strength is displayed as an extra sensor and not on the device.

    Home Assistant interface with Bad_Dimm 1 device

    My autoexec.bat:

    Code: text Expand Select all Copy to clipboard
    startDriver TuyaMCU
startDriver SSDP
tuyaMcu_defWiFiState 4
tuyaMcu_setBaudRate 115200
PowerSave 1
setChannelType 1 toggle
setChannelType 2 dimmer
tuyaMcu_setDimmerRange 0 1000
linkTuyaMCUOutputToChannel 20 1 1
linkTuyaMCUOutputToChannel 22 2 2



    If I write the following in autoexec.bat, I can dim the brightness, and the signal strength is not displayed as an extra sensor (but of course, it shows the full RGBCCT panel, I only need a dimmer slider):

    Code: text Expand Select all Copy to clipboard
    startDriver TuyaMCU
startDriver SSDP
tuyaMcu_defWiFiState 4
tuyaMcu_setBaudRate 115200
PowerSave 1
tuyaMcu_setupLED 24 0


    Lighting control interface with brightness slider set to 33%.

    How can I add the device manually through configuration.yaml?
  • ADVERTISEMENT
  • #28 20799162
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12632
    The first script should work with HASS Discovery as well too, I need to check that.

    You can check this topic for manual dimmer YAML guide:
    https://www.elektroda.com/rtvforum/topic3898502.html
    Helpful post? Buy me a coffee.
  • #29 20814571
    andyc1
    Level 3  
    Posts: 14
    Rate: 2

    Hello,
    I'd like to post an update to my original posts with an issue that cropped up that I have now been able to resolve.

    Whenever Home Assistant was restarted, the state of the devices would change to "unknown" within Home Assistant and I was unable to operate them via HA. I would have to switch them on via the wall switch before their state reported correctly and then dim them for their brightness level to be shown in HA.
    This became quite a problem as it would happen with any power cuts as well as HA updates.

    I eventually solved this within the OBK interface by going to: config/configure general/flags and enabling flag 7 - Always set Retain flag to all published values.

    If anyone has a similar issue, hopefully this will help.
  • #30 20814615
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14615
    Help: 655
    Rate: 12632
    Hello @andyc11 , the following issue with potential fixes was also discussed here:
    OpenBeken Devices Displaying Multiple Switch Toggle Icons upon Home Assistant Restart
    Helpful post? Buy me a coffee.
Reply | New topic
Report a violation of the law

Topic summary

✨ The discussion revolves around configuration issues with the Tuya S1-B-WT triac dimmer after flashing it with OpenBeken (OBK) firmware. The user successfully accessed the device's web application but faced challenges with the cloudcutter profile import, which did not yield a functional script. Various troubleshooting steps were suggested, including verifying the baud rate, using the correct dpIDs for the dimmer and switch, and ensuring proper wiring with a physical switch. After several attempts and adjustments to the autoexec.bat file, the user managed to resolve the issues, enabling the device to function correctly with Home Assistant. Additionally, the conversation touched on flashing procedures and the importance of consistent configurations across multiple devices.
Generated by the language model.
Today's popular

FAQ

TL;DR: At 115200 baud, the fix was "change the dpIDs" and use dpID 20 for on/off plus dpID 22 for brightness. This FAQ is for OpenBeken beginners whose S1-B-WT dimmer flashes successfully but does not control the light until TuyaMCU is mapped manually. [#20654338]

Why it matters: This thread turns a non-working reflashed dimmer into a repeatable OpenBeken setup, including Home Assistant and MQTT edge cases.

Approach Setup effort Local control path Extra hardware/software Reported pros Reported cons
S1-B-WT Wi-Fi + OpenBeken Higher OBK + MQTT/Home Assistant Flashing tool, serial wiring Full local control after mapping dpIDs Manual flashing and TuyaMCU setup needed
WZ Zigbee + Zigbee2MQTT Lower Zigbee2MQTT Zigbee adapter No reflashing, mesh repeaters, lower power use Requires Zigbee coordinator

Key insight: Importing a Cloudcutter profile was not enough here. The dimmer worked only after confirming TuyaMCU at 115200 baud and linking the real state dpIDs from the physical switch log.

Quick Facts

  • The working TuyaMCU serial speed was 115200 baud, confirmed both by the Cloudcutter profile and the extracted config binary. [#20652300]
  • The dimmer’s brightness datapoint used a 0–1000 value range, and OBK was configured with tuyaMcu_setDimmerRange 0 1000. [#20652300]
  • A valid physical-state log showed dpID 20 as DP_TYPE_BOOL and dpID 22 as DP_TYPE_VALUE with 4 data bytes and a sample value of 1000. [#20654276]
  • The working flash procedure on the WB2S module used only 3 V, TX, RX, and GND; shorting CEN to GND was not required for that user. [#20665834]
  • One user reflashed 6 additional modules successfully, but some reported state correctly only after a full power cut and restart, not just a web reboot. [#20665740]

How do I manually configure a Tuya Generic S1-B-WT triac dimmer in OpenBeken after flashing when the Cloudcutter profile import doesn’t create a working script?

Manually configure TuyaMCU and map the real dpIDs instead of relying on profile import. Use this 3-step process: 1. Add a minimal autoexec.bat with startDriver TuyaMCU, tuyaMcu_defWiFiState 4, and tuyaMcu_setBaudRate 115200. 2. Trigger the dimmer from the physical wall switch and read the OBK log. 3. Link the detected dpIDs to channels, which were 20 for toggle and 22 for brightness in this thread. After that change, the S1-B-WT started working correctly. [#20654390]

What is TuyaMCU, and how can I tell whether a Tuya S1-B-WT dimmer uses it after installing OBK firmware?

"TuyaMCU" is a microcontroller-side serial protocol that exchanges state and commands between the Wi-Fi module and the dimmer electronics, using datapoints, baud-rate settings, and periodic heartbeat frames. On this S1-B-WT, the main clue was that the Cloudcutter profile and extracted config both pointed to a serial setup at 115200 baud, and OBK logs showed recurring 55 AA ... heartbeat packets. If you see heartbeat traffic but no GPIO-only behavior, the dimmer is using TuyaMCU rather than a simple direct-pin design. [#20652300]

Why would a Tuya S1-B-WT dimmer show an on/off toggle and brightness slider in the OBK web app but still not switch the connected light on?

Because the web UI can show channels before they are linked to the device’s real TuyaMCU datapoints. In this thread, the user added a script that created a toggle and slider, but the light still stayed off. The cause was not the UI itself; it was missing or wrong dpID mapping. OBK could display controls, yet the dimmer would ignore them until the actual state datapoints were identified from TuyaMCU traffic and linked correctly. [#20649501]

How can I extract the OBK config or TuyaConfig from a flashed device to check whether the baud rate and TuyaMCU settings are correct?

Extract the OBK config file and inspect the serial settings, especially wifi_bdrate. In this case, the extracted binary confirmed wifi_bdrate as 115200, wifi_config_ver as 1.0.0, and crc as 127. That matched the Cloudcutter profile and explained why a lower-baud example script failed. Once those values were confirmed, the next step was to test TuyaMCU communication in the web log and map the correct dpIDs. [#20652300]

Which autoexec.bat commands are needed to get a Tuya S1-B-WT dimmer working with OpenBeken at 115200 baud?

Use TuyaMCU startup, set the dimmer channel types, define the 0–1000 range, and link the real dpIDs. The working script in this thread was: startDriver TuyaMCU tuyaMcu_defWiFiState 4 tuyaMcu_setBaudRate 115200 setChannelType 1 toggle setChannelType 2 dimmer tuyaMcu_setDimmerRange 0 1000 linkTuyaMCUOutputToChannel 20 1 1 linkTuyaMCUOutputToChannel 22 2 2 Those values matched the physical-switch log and fixed the dimmer. [#20664898]

What is a dpID in the TuyaMCU protocol, and how do I identify the correct dpIDs for switch state and brightness from the OBK web log?

"dpID" is a TuyaMCU datapoint identifier that labels one device function, such as relay state or brightness, and each dpID also carries a data type like boolean or numeric value. Identify it by opening the OBK log and looking for processing dpId ... entries after a real hardware action. In this thread, the decisive lines were dpId 20 with DP_TYPE_BOOL and dpId 22 with DP_TYPE_VALUE, which exposed the correct switch and dimmer mappings. [#20654210]

How do I use a physical wall switch to generate TuyaMCU state packets and confirm the correct dpIDs for an S1-B-WT dimmer?

Wire the wall switch as shown in the device manual, then operate the dimmer physically while the OBK web log is open. Do not rely on the web page slider for this test. The successful capture showed command 7 (State) packets, then dpId 20 as a boolean and dpId 22 as a value of 1000. Those packets gave the exact mapping needed for linkTuyaMCUOutputToChannel. Without the physical switch, the user only saw heartbeat traffic. [#20654276]

Why does the OBK log show only TuyaMCU heartbeat packets and no useful state changes when I move the dimmer from the web interface?

Because moving the dimmer in the web interface does not prove the TuyaMCU is sending back hardware state packets. The thread’s expert answer was blunt: "Toggling the dimmer on the web page will not help." You must use a physical wall switch wired as in the manual. Heartbeat frames like 55 AA 03 00 00 01 01 04 only confirm that serial communication exists; they do not reveal which dpIDs carry real switch and brightness state. [#20654184]

What do the log entries showing dpID 20 as a boolean and dpID 22 as a value mean for configuring a Tuya S1-B-WT dimmer?

They mean dpID 20 is the on/off datapoint and dpID 22 is the brightness datapoint. In the log, dpID 20 appeared as DP_TYPE_BOOL, and dpID 22 appeared as DP_TYPE_VALUE with 4 data bytes and a sample value of 1000. So the correct OBK mapping is to link dpID 20 to a toggle channel and dpID 22 to a dimmer channel with a 0–1000 range. That was the configuration that made the device work. [#20654338]

How should I set up Home Assistant discovery so an OpenBeken Tuya dimmer appears as a dimmer entity instead of only a switch?

Use channel-based dimmer mapping, not only tuyaMcu_setupLED 24 0, and keep Home Assistant discovery enabled. The thread showed that a script with setChannelType 1 toggle, setChannelType 2 dimmer, and linkTuyaMCUOutputToChannel 20 1 1 plus 22 2 2 should be the right discovery path. However, one user still saw only a switch in Home Assistant, so the maintainer said the first script should work and needed checking. In short, discovery expects a real dimmer channel, not just relay-only exposure. [#20799162]

What can I put in Home Assistant configuration.yaml to manually add an OpenBeken TuyaMCU dimmer if auto discovery creates the wrong entity type?

Use a manual dimmer definition in configuration.yaml instead of waiting for discovery to classify it correctly. The maintainer explicitly pointed the user to a manual dimmer YAML guide after discovery exposed the S1-B-WT only as a switch. If your script already uses setChannelType 2 dimmer and tuyaMcu_setDimmerRange 0 1000, but Home Assistant still shows only a switch, manual YAML is the fallback path mentioned in the thread. [#20799162]

Why do some reflashed S1-B-WT modules stop reporting on/off state changes from the RF wall switch until they are fully power-cycled?

Because some modules may not complete TuyaMCU initialization properly after configuration changes until a full power reset. In this thread, 6 extra modules worked from the OBK panel but failed to report RF wall-switch state back to OBK and Home Assistant. A web reboot alone did not fix them. After powering all devices off and back on, the modules started reporting on/off state correctly again. The maintainer suspected a Tuya MCU initialization bug or partial startup issue. [#20665763]

How can I fix OpenBeken devices that become 'unknown' in Home Assistant after an HA restart or power cut, especially with MQTT retain settings?

Enable OBK flag 7 so MQTT publishes retained values. The exact fix reported was: go to config > configure general > flags and enable flag 7 - Always set Retain flag to all published values. Before that change, Home Assistant showed the dimmers as unknown after each HA restart or power cut, and users had to toggle the wall switch before state returned. After enabling retain, the user reported the issue was resolved. [#20814571]

What’s the correct way to flash a WB2S-based Tuya dimmer with OpenBeken, and when should I short CEN to ground versus simply power-cycling it?

For this WB2S dimmer, both methods can reboot the module, but simple power-cycling was enough. One user succeeded with only 3 V, TX, RX, and GND connected and did not need to short CEN to ground during flashing. Later, the maintainer clarified there are two valid reboot methods: short CEN to ground or disconnect and reconnect power. He said both should work, and he prefers power-cycling. The same support reply also recommended taking a 2MB flash backup before deeper work. [#20665907]

Skydance S1-B-WT Wi-Fi with OpenBeken vs the Zigbee WZ version with Zigbee2MQTT — which approach is better for local control, reliability, and setup effort?

Choose Zigbee WZ for lower setup effort, and choose Wi-Fi plus OpenBeken if you want a reflashed local MQTT device. The 2026 follow-up argued that the Zigbee version is "much more efficient" because it avoids reflashing, works with Zigbee2MQTT, can repeat signals in a mesh, and uses less energy than Wi-Fi. The Wi-Fi S1-B-WT did achieve solid local control in Home Assistant, but only after flashing, serial setup, dpID mapping, and some troubleshooting. For beginners, Zigbee is the easier path. [#21854335]
Generated by the language model.
ADVERTISEMENT