>>20799162
I try this
but no luck. There is still just a switch in HA. :/
I try this
but no luck. There is still just a switch in HA. :/
Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
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.
tuyaMcu_setDimmerRange 0 1000. [#20652300]DP_TYPE_BOOL and dpID 22 as DP_TYPE_VALUE with 4 data bytes and a sample value of 1000. [#20654276]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]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]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]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]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]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]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]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]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]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]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]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]