post it anyway so we can see what state it's in 
Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
geniack wrote:But... How does it know it's a thermostat?
//starting TuyaMCU driver and it's sensor submodule
startDriver TuyaMCU
startDriver tmSensor
// may be needed, depends on device, some devices also use 115200 or other baud rates
tuyaMCU_setBaudRate 9600
//before proceeding make sure we are connected
waitFor WiFiState 4
// dpID 1 is tempererature div 10
linkTuyaMCUOutputToChannel 24 val 1
setChannelType 1 temperature_div10
{"1":"Switch","2":"Set Temperature","3":"Current Temperature","4":"Mode","5":"Working status","8":"Child lock","13":"Sound","16":"Fault alarm","20":"Temperature calibration","21":"Max setting temperature","25":"Sensor selection","26":"Frost protection","31":"RESET","41":"Backlight brightness","42":"Working day setting","43":"Weekly procedure (working day)","101":"常闭型_常开型","105":"Temperature control switch difference","107":"External Sensor temperature limit"}
I thought I had the hardest part behind me. I just soldered back the WBR3 and put the device back together. I will have to wait for tomorrow before I will be able to check how it works inside my walls. I will report back. Thank you for your time and maintaining this project!
DeDaMrAz wrote:{"1":"Switch","2":"Set Temperature","3":"Current Temperature","4":"Mode","5":"Working status","8":"Child lock","13":"Sound","16":"Fault alarm","20":"Temperature calibration","21":"Max setting temperature","25":"Sensor selection","26":"Frost protection","31":"RESET","41":"Backlight brightness","42":"Working day setting","43":"Weekly procedure (working day)","101":"常闭型_常开型","105":"Temperature control switch difference","107":"External Sensor temperature limit"}
The temperature looks reasonable now, so probably no need to calibrate. I think setting the temperature would be my most important concern for now, so if you could help me figure that out, that would be great.
TL;DR: With 3.3 V wiring and 4–6 UART connections, you can flash WBR2/WBR3/WBRU Tuya modules; as one contributor put it, "the connection ... is the same" even when switching to newer tools. This FAQ helps Home Assistant and OpenBeken users identify pinouts, choose the right flasher, and recover MQTT discovery on RTL8720CF-based devices. [#21375223]
Why it matters: These modules appear in thermostats, plugs, breakers, switches, heaters, blinds, and IR devices, so one reliable flashing method unlocks many Tuya products without cloud dependence.
| Tool | Best use | Write support | Read/backup support | Notable thread detail |
|---|---|---|---|---|
| AmebaZ2 PG Tool 1.2.47 | Legacy RTL8720CF flashing | Yes | No practical read option discussed early on | Original step-by-step guide used it first [#21375223] |
| BK7231GUIFlashTool | Preferred newer workflow | Yes | Yes, later RTL87X0C read/write support added | RTL87X0C support expanded through 2025 [#21708748] |
| ltchiptool | Linux/CLI alternative | Yes | Not the main focus here | One user wrote a 719.1 KiB image successfully on Linux [#21398455] |
Najważniejsza wskazówka: On WBR3, the working UART boot path uses the log UART on A15/A16, not the normal user UART on A13/A14. Most failed flashes came from wrong UART choice, unstable adapters, or weak 3.3 V power. [#21375223]
/dev/ttyUSB0 and the tool auto-detected a 719.1 KiB Realtek AmebaZ2 image successfully. [#21398455]scheduleHADiscovery 5 to autoexec.bat so discovery starts about 5 seconds after MQTT connects. The thread shows this works once the right channel types are assigned; missing or old channel types were a real cause of absent entities. One contributor confirmed the fix immediately after updating the firmware and keeping discovery in autoexec. [#21564801]linkTuyaMCUOutputToChannel 2 val 2 and setChannelType 2 dimmer or Temperature. The thread shows this method working on thermostats, blinds, heaters, and a smart kettle. [#21701460]startDriver TuyaMCU still forces safe mode, the usual causes are wrong baud rate, wrong dpID/channel mapping, or a bad command in autoexec. If Home Assistant entities do not appear, update to a build that includes the needed channel types, then run scheduleHADiscovery 5. That exact issue happened with new OpenStopClose support: the entity appeared only after firmware update because the older May build lacked the required discovery behavior. [#21565324]UART_Log_RXD and A16 as UART_Log_TXD, while A13/A14 are UART0_RXD and UART0_TXD for user-side serial communication. The flashing note repeats the distinction: use A15/A16 for debug output and bootloading, and pull A13 plus A0 high to enter bootloader mode. That distinction explains many failed attempts through the wrong UART. [#21375223]autoexec.bat. 3. Add drivers, labels, MQTT, and Home Assistant discovery. The thread explicitly says original behavior is usually restored either by choosing GPIO roles manually or via template import, then extending it with scripts and TuyaMCU channel mappings. [#21420173]