logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Flashing OpenBeken on EZAIoT Wifi RF Thermostat for Local Control

groove6j 5664 54
Best answers

How can I flash OpenBeken/OpenRTL8720D onto an EZAIOT T9W/R9BW Wi‑Fi thermostat for local control?

This thermostat can likely be flashed if the scraped Realtek chip is an AmebaD/RTL8720D-family part, because OpenRTL8720D supports those chips and the dump/boot behavior matched that family [#21552848][#21444230] Use the Realtek flashing workflow, not ESP methods: first back up the flash with `rtltool.py ... rf 0 0x400000` (and `0x800000` if needed), then write with `wf`; if the Python writer gives checksum trouble, the Windows AmebaD tool worked for the thread author [#21442947][#21553080][#21553289] After flashing, use the appropriate OBK driver for the actual wiring: `tuyamcu` if it is a normal TuyaMCU device, or `tmSensor` only if the module is battery-powered and the MCU controls Wi‑Fi power [#21556809] The remaining work is probably on the MCU link, not the flash itself: the unlabeled UART appears to go to the MCU under the display, so sniffing stock firmware traffic and probing alternate UART/protocol settings is the suggested next step to map the dpIDs for local control [#21567115][#21554154]
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • #31 21553300
    insmod
    Level 31  
    >>21553289
    It's not FW2, since firmware can't be switched without OTA.
    Something else must be happening.
    What is the log output when connecting power via type-c without VDD?
  • ADVERTISEMENT
  • #32 21553334
    groove6j
    Level 9  
    >>21553300
    When I add VCC then its normal log and OpenRTL is booting. (LCD all bit are lit)
    Code: text Expand Select all Copy to clipboard
    #[MODULE_BOOT-LEVEL_INFO]:IMG1 ENTER ROMSUB:2
[MODULE_BOOT-LEVEL_INFO]:OTA1 USE
[MODULE_BOOT-LEVEL_INFO]:IMG2 DATA[0xc014750:9328:0x83000]
[MODULE_BOOT-LEVEL_INFO]:IMG2 SIGN[RTKWin(8300c)]
[MODULE_BOOT-LEVEL_INFO]:IMG2 ENTRY[0x83000:0xc002835]
[MODULE_BOOT-LEVEL_INFO]:KM0 BOOT_IMG2 BOOT REASON: 0 
Flash ID:20, 42, 16
read_mode:3
calibration_ok:[2:19:11] 
FLASH CALIB[NEW OK]
RRAM: c0080 176B 
[MODULE_BOOT-LEVEL_INFO]:IMG1 ENTER MSP:[1007fffc]
[MODULE_BOOT-LEVEL_INFO]:IMG2 DATA[0xe0990e0:102672:0x10005000]
[MODULE_BOOT-LEVEL_INFO]:IMG2 SIGN[RTKWin(1000500c)]
[MODULE_BOOT-LEVEL_INFO]:IMG2 ENTRY[0x10005000:0xe02b145]
[MODULE_BOOT-LEVEL_INFO]:Start NonSecure @ 0xe02b144 ...
[MODULE_BOOT-LEVEL_INFO]:KM4 BOOT REASON: 0 
#interface 0 is initialized
interface 1 is initialized

#[MODULE_BOOT-LEVEL_INFO]:IMG1 ENTER ROMSUB:2
[MODULE_BOOT-LEVEL_INFO]:OTA1 USE
[MODULE_BOOT-LEVEL_INFO]:IMG2 DATA[0xc014750:9328:0x83000]
[MODULE_BOOT-LEVEL_INFO]:IMG2 SIGN[RTKWin(8300c)]
[MODULE_BOOT-LEVEL_INFO]:IMG2 ENTRY[0x83000:0xc002835]
[MODULE_BOOT-LEVEL_INFO]:KM0 BOOT_IMG2 BOOT REASON: 0 
Flash ID:20, 42, 16
read_mode:3
calibration_ok:[2:19:11] 
FLASH CALIB[NEW OK]
RRAM: c0080 176B 
[MODULE_BOOT-LEVEL_INFO]:IMG1 ENTER MSP:[1007fffc]
[MODULE_BOOT-LEVEL_INFO]:IMG2 DATA[0xe0990e0:102672:0x10005000]
[MODULE_BOOT-LEVEL_INFO]:IMG2 SIGN[RTKWin(1000500c)]
[MODULE_BOOT-LEVEL_INFO]:IMG2 ENTRY[0x10005000:0xe02b145]
[MODULE_BOOT-LEVEL_INFO]:Start NonSecure @ 0xe02b144 ...
[MODULE_BOOT-LEVEL_INFO]:KM4 BOOT REASON: 0 
#interface 0 is initialized
interface 1 is initialized

Initializing WIFI ...Entering initLog()...
Commands registered!
initLog() done!
Info:MAIN:Main_Init_Before_Delay
EasyFlash V4.1.0 is initialize success.
You can get the latest version on https://github.com/armink/EasyFlash .

WIFI initialized

Main_Init_Before_Delay doneheap 0x2c960
Main_Init_DeWarn:CFG:CFG_InitAndLoad: Correct config has been loaded with 7 changes count.
Error:CMD:no file early.bat err -2
Main_Init_Delay done
N_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:Using SSID [room]
Info:MAIN:Using Pass [xxxx]
Info:HTTP:TCP server listening
Info:MQTT:MQTT_RegisterCallback called for bT rtl8720dFF162F63/ subT rtl8720dFF162F63/+/set
Info:MQTT:MQTT_RegisterCallback called for bT obks/ subT obks/+/set
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/rtl8720dFF162F63/ subT cmnd/rtl8720dFF162F63/+
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/obks/ subT cmnd/obks/+
Info:MQTT:MQTT_RegisterCallback called for bT rtl8720dFF162F63/ subT rtl8720dFF162F63/+/get
Info:CMD:CMD_StartScript: started @startup at the beginning
Info:CMD:CMD_StartScript: started autoexec.bat at the beginning
Info:MAIN:Main_Init_After_Delay done
Info:MAIN:Started TuyaMCU.
Info:GEN:Channel 1 type changed to toggle
Info:GEN:Channel 111 type not set because string is not a known type
Info:GEN:Channel 40 type changed to toggle
Info:MAIN:Time 1, idle 0/s, free 163904, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/16 
#[MODULE_BOOT-LEVEL_INFO]:IMG1 ENTER ROMSUB:2
[MODULE_BOOT-LEVEL_INFO]:OTA1 USE
[MODULE_BOOT-LEVEL_INFO]:IMG2 DATA[0xc014750:9328:0x83000]
[MODULE_BOOT-LEVEL_INFO]:IMG2 SIGN[RTKWin(8300c)]
[MODULE_BOOT-LEVEL_INFO]:IMG2 ENTRY[0x83000:0xc002835]
[MODULE_BOOT-LEVEL_INFO]:KM0 BOOT_IMG2 BOOT REASON: 0 
Flash ID:20, 42, 16
read_mode:3
calibration_ok:[2:19:11] 
FLASH CALIB[NEW OK]
RRAM: c0080 176B 
[MODULE_BOOT-LEVEL_INFO]:IMG1 ENTER MSP:[1007fffc]
[MODULE_BOOT-LEVEL_INFO]:IMG2 DATA[0xe0990e0:102672:0x10005000]
[MODULE_BOOT-LEVEL_INFO]:IMG2 SIGN[RTKWin(1000500c)]
[MODULE_BOOT-LEVEL_INFO]:IMG2 ENTRY[0x10005000:0xe02b145]
[MODULE_BOOT-LEVEL_INFO]:Start NonSecure @ 0xe02b144 ...
[MODULE_BOOT-LEVEL_INFO]:KM4 BOOT REASON: 0 
#interface 0 is initialized
interface 1 is initialized

Initializing WIFI ...Entering initLog()...
Commands registered!
initLog() done!
Info:MAIN:Main_Init_Before_Delay
EasyFlash V4.1.0 is initialize success.
You can get the latest version on https://github.com/armink/EasyFlash .

WIFI initialized

Main_Init_Before_Delay doneheap 0x2c960
Main_Init_DeWarn:CFG:CFG_InitAndLoad: Correct config has been loaded with 7 changes count.
Error:CMD:no file early.bat err -2
Main_Init_Delay done
N_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:Using SSID [room]
Info:MAIN:Using Pass [xxx]
Info:HTTP:TCP server listening
Info:MQTT:MQTT_RegisterCallback called for bT rtl8720dFF162F63/ subT rtl8720dFF162F63/+/set
Info:MQTT:MQTT_RegisterCallback called for bT obks/ subT obks/+/set
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/rtl8720dFF162F63/ subT cmnd/rtl8720dFF162F63/+
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/obks/ subT cmnd/obks/+
Info:MQTT:MQTT_RegisterCallback called for bT rtl8720dFF162F63/ subT rtl8720dFF162F63/+/get
Info:CMD:CMD_StartScript: started @startup at the beginning
Info:CMD:CMD_StartScript: started autoexec.bat at the beginning
Info:MAIN:Main_Init_After_Delay done
Info:MAIN:Started TuyaMCU.
Info:GEN:Channel 1 type changed to toggle
Info:GEN:Channel 111 type not set because string is not a known type
Info:GEN:Channel 40 type changed to toggle
Info:MAIN:Time 1, idle 0/s, free 163904, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/16 
Info:MAIN:Time 2, idle 0/s, free 163904, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/16 
Info:MAIN:Time 3, idle 0/s, free 163904, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/16 
Info:MAIN:Time 4, idle 0/s, free 163904, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/16 
Info:MAIN:Time 5, idle 0/s, free 163904, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/16 
Info:MAIN:Registered for wifi changes
Info:MAIN:Connecting to SSID [room]
Info:MAIN:Time 6, idle 0/s, free 160640, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/16 
Info:MAIN:Boot complete time reached (5 seconds)

RTL8721D[Driver]: set ssid [room] 
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTING - 1
Info:MAIN:Time 7, idle 0/s, free 160960, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/16 

RTL8721D[Driver]: rtw_set_wpa_ie[1182]: AuthKeyMgmt = 0x2 
Info:MAIN:Time 8, idle 0/s, free 160800, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/16 

RTL8721D[Driver]: rtw_restruct_sec_ie[4294]: no pmksa cached 

RTL8721D[Driver]: start auth to 6e:3b:6b:51:55:6c

RTL8721D[Driver]: auth alg = 2
Recv Auth with status_code=0

RTL8721D[Driver]: 
OnAuthClient:algthm = 0, seq = 2, status = 0, sae_msg_len = 0

RTL8721D[Driver]: auth success, start assoc

RTL8721D[Driver]: association success(res=15)
wlan1: 1 DL RSVD page success! DLBcnCount:01, poll:00000001

RTL8721D[Driver]: ClientSendEAPOL[1728]: no use cache pmksa 

RTL8721D[Driver]: set pairwise key to hw: alg:4(WEP40-1 WEP104-5 TKIP-2 AES-4)

RTL8721D[Driver]: set group key to hw: alg:4(WEP40-1 WEP104-5 TKIP-2 AES-4) keyid:2
Info:MAIN:Time 9, idle 0/s, free 155104, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/16 



    When I remove VCC, then it logs this (and stops at the end, there is no more output) (LCD is normal, shows temp, and responds to buttons)

    Code: text Expand Select all Copy to clipboard
    [MODULE_BOOT-LEVEL_INFO]:IMG1 ENTER ROMSUB:2
[MODULE_BOOT-LEVEL_INFO]:OTA1 USE
[MODULE_BOOT-LEVEL_INFO]:IMG2 DATA[0xc014750:9328:0x83000]
[MODULE_BOOT-LEVEL_INFO]:IMG2 SIGN[RTKWin(8300c)]
[MODULE_BOOT-LEVEL_INFO]:IMG2 ENTRY[0x83000:0xc002835]
[MODULE_BOOT-LEVEL_INFO]:KM0 BOOT_IMG2 BOOT REASON: 0 
Flash ID:20, 42, 16
read_mode:3
calibration_ok:[2:19:11] 
FLASH CALIB[NEW OK]
RRAM: c0080 176B 
[MODULE_BOOT-LEVEL_INFO]:IMG1 ENTER MSP:[1007fffc]
[MODULE_BOOT-LEVEL_INFO]:IMG2 DATA[0xe0990e0:102672:0x10005000]
[MODULE_BOOT-LEVEL_INFO]:IMG2 SIGN[RTKWin(1000500c)]
[MODULE_BOOT-LEVEL_INFO]:IMG2 ENTRY[0x10005000:0xe02b145]
[MODULE_BOOT-LEVEL_INFO]:Start NonSecure @ 0xe02b144 ...
[MODULE_BOOT-LEVEL_INFO]:KM4 BOOT REASON: 0 
#interface 0 is initialized
interface 1 is initialized

Initializing WIFI ...Entering initLog()...
Commands registered!
initLog() done!
Info:MAIN:Main_Init_Before_Delay
#[MODULE_BOOT-LEVEL_INFO]:IMG1 ENTER ROMSUB:2
[MODULE_BOOT-LEVEL_INFO]:OTA1 USE
[MODULE_BOOT-LEVEL_INFO]:IMG2 DATA[0xc014750:9328:0x83000]
[MODULE_BOOT-LEVEL_INFO]:IMG2 SIGN[RTKWin(8300c)]
[MODULE_BOOT-LEVEL_INFO]:IMG2 ENTRY[0x83000:0xc002835]
[MODULE_BOOT-LEVEL_INFO]:KM0 BOOT_IMG2 BOOT REASON: 0 
Flash ID:20, 42, 16
read_mode:3
calibration_ok:[2:19:11] 
FLASH CALIB[NEW OK]
RRAM: c0080 176B 
[MODULE_BOOT-LEVEL_INFO]:IMG1 ENTER MSP:[1007fffc]
[MODULE_BOOT-LEVEL_INFO]:IMG2 DATA[0xe0990e0:102672:0x10005000]
[MODULE_BOOT-LEVEL_INFO]:IMG2 SIGN[RTKWin(1000500c)]
[MODULE_BOOT-LEVEL_INFO]:IMG2 ENTRY[0x10005000:0xe02b145]
[MODULE_BOOT-LEVEL_INFO]:Start NonSecure @ 0xe02b144 ...
[MODULE_BOOT-LEVEL_INFO]:KM4 BOOT REASON: 0 
#interface 0 is initialized
interface 1 is initialized

Initializing WIFI ...Entering initLog()...
Commands registered!
initLog() done!
Info:MAIN:Main_Init_Before_Delay
#[MODULE_BOOT-LEVEL_INFO]:IMG1 ENTER ROMSUB:2
[MODULE_BOOT-LEVEL_INFO]:OTA1 USE
[MODULE_BOOT-LEVEL_INFO]:IMG2 DATA[0xc014750:9328:0x83000]
[MODULE_BOOT-LEVEL_INFO]:IMG2 SIGN[RTKWin(8300c)]
[MODULE_BOOT-LEVEL_INFO]:IMG2 ENTRY[0x83000:0xc002835]
[MODULE_BOOT-LEVEL_INFO]:KM0 BOOT_IMG2 BOOT REASON: 0 
Flash ID:20, 42, 16
read_mode:3
calibration_ok:[2:19:11] 
FLASH CALIB[NEW OK]
RRAM: c0080 176B 
[MODULE_BOOT-LEVEL_INFO]:IMG1 ENTER MSP:[1007fffc]
[MODULE_BOOT-LEVEL_INFO]:IMG2 DATA[0xe0990e0:102672:0x10005000]
[MODULE_BOOT-LEVEL_INFO]:IMG2 SIGN[RTKWin(1000500c)]
[MODULE_BOOT-LEVEL_INFO]:IMG2 ENTRY[0x10005000:0xe02b145]
[MODULE_BOOT-LEVEL_INFO]:Start NonSecure @ 0xe02b144 ...
[MODULE_BOOT-LEVEL_INFO]:KM4 BOOT REASON: 0 
#interface 0 is initialized
interface 1 is initialized

Initializing WIFI ...Entering initLog()...
Commands registered!
initLog() done!
Info:MAIN:Main_Init_Before_Delay
EasyFlash V4.1.0 is initialize success.
You can get the latest version on https://github.com/armink/EasyFlash .
#[MODULE_BOOT-LEVEL_INFO]:IMG1 ENTER ROMSUB:2
[MODULE_BOOT-LEVEL_INFO]:OTA1 USE
[MODULE_BOOT-LEVEL_INFO]:IMG2 DATA[0xc014750:9328:0x83000]
[MODULE_BOOT-LEVEL_INFO]:IMG2 SIGN[RTKWin(8300c)]
[MODULE_BOOT-LEVEL_INFO]:IMG2 ENTRY[0x83000:0xc002835]
[MODULE_BOOT-LEVEL_INFO]:KM0 BOOT_IMG2 BOOT REASON: 0 
Flash ID:20, 42, 16
read_mode:3
calibration_ok:[2:19:11] 
FLASH CALIB[NEW OK]
RRAM: c0080 176B 
[MODULE_BOOT-LEVEL_INFO]:IMG1 ENTER MSP:[1007fffc]
[MODULE_BOOT-LEVEL_INFO]:IMG2 DATA[0xe0990e0:102672:0x10005000]
[MODULE_BOOT-LEVEL_INFO]:IMG2 SIGN[RTKWin(1000500c)]
[MODULE_BOOT-LEVEL_INFO]:IMG2 ENTRY[0x10005000:0xe02b145]
[MODULE_BOOT-LEVEL_INFO]:Start NonSecure @ 0xe02b144 ...
[MODULE_BOOT-LEVEL_INFO]:KM4 BOOT REASON: 0 
#interface 0 is initialized
interface 1 is initialized

Initializing WIFI ...Entering initLog()...
Commands registered!
initLog() done!
Info:MAIN:Main_Init_Before_Delay
EasyFlash V4.1.0 is initialize success.
You can get the latest version on https://github.com/armink/EasyFlash .
#[MODULE_BOOT-LEVEL_INFO]:IMG1 ENTER ROMSUB:2
[MODULE_BOOT-LEVEL_INFO]:OTA1 USE
[MODULE_BOOT-LEVEL_INFO]:IMG2 DATA[0xc014750:9328:0x83000]
[MODULE_BOOT-LEVEL_INFO]:IMG2 SIGN[RTKWin(8300c)]
[MODULE_BOOT-LEVEL_INFO]:IMG2 ENTRY[0x83000:0xc002835]
[MODULE_BOOT-LEVEL_INFO]:KM0 BOOT_IMG2 BOOT REASON: 0 
Flash ID:20, 42, 16
read_mode:3
calibration_ok:[2:19:11] 
FLASH CALIB[NEW OK]
RRAM: c0080 176B 
[MODULE_BOOT-LEVEL_INFO]:IMG1 ENTER MSP:[1007fffc]
[MODULE_BOOT-LEVEL_INFO]:IMG2 DATA[0xe0990e0:102672:0x10005000]
[MODULE_BOOT-LEVEL_INFO]:IMG2 SIGN[RTKWin(1000500c)]
[MODULE_BOOT-LEVEL_INFO]:IMG2 ENTRY[0x10005000:0xe02b145]
[MODULE_BOOT-LEVEL_INFO]:Start NonSecure @ 0xe02b144 ...
[MODULE_BOOT-LEVEL_INFO]:KM4 BOOT REASON: 0 
#interface 0 is initialized
interface 1 is initialized

Initializing WIFI ...Entering initLog()...
Commands registered!
initLog() done!
  • #33 21553348
    insmod
    Level 31  
    This looks like there is not enough power.
    Try connecting both type-c and vdd.
  • #34 21553349
    groove6j
    Level 9  
    >>21553348
    Yeah, I'll try again in the morning. Gonna get some sleep. Big thanks for the assistance! :)

    It is interesting that when it's stuck at booting, the display works (and I think that RF part works as well). It made me think, that the old firmware is loading, but actually it stuck, just the MCU part is working for some weird reason.
  • #35 21553802
    groove6j
    Level 9  
    >>21553348
    I have to first apply type-c/battery power. MCU boots, RTL fails.
    After that if I apply VCC RTL boots fine and MCU is still working. If I remove VCC, the RTL stalls. But if I remove type-c - both MCU and RTL keep working.

    In short - if I apply VCC afterwards, both MCU and RTL work. Disconnect VCC - RTL stops working. Why could that be?

    Can't get any TuyaMCU communications too. Tried this config:

    Code: text Expand Select all Copy to clipboard
    
startDriver TuyaMCU
tuyaMcu_setBaudRate 115200
tuyaMcu_defWiFiState 4
setChannelType 1 Toggle
setChannelLabel 1 "l1"
linkTuyaMCUOutputToChannel 1 bool 1 
setChannelLabel 2 "l2"
setChannelType 2 Toggle
linkTuyaMCUOutputToChannel 2 bool 2 
setChannelLabel 3 "Temperature"
setChannelType 3 TextField
linkTuyaMCUOutputToChannel 24 val 3


    I also tried 9600, 921600 and 460800 baud. When the MCU boots and screen works, the RF part totally works, there is no MCU<->OpenRTL communication yet. I understand that there are 2 UARTs on the Realtek chip. One is labeled LOG, which I used to flash and read system logs. The other one seems just to go to pin headers through 100Ohm resistors from Realtek chip.

    I couldn't get anything over that other UART port.
  • #36 21554154
    insmod
    Level 31  
    What about startdriver tmSensor?
    Since there are batteries, perhaps tuyamcu is using v0 protocol?
    Another possibility is that it uses alternate uart, you would need to enable that flag to see if it works.
    You can also try to sniff non-log rx/tx for mcu communication.
  • ADVERTISEMENT
  • #37 21554283
    groove6j
    Level 9  
    >>21554154
    Will try. The mystery to me is that the UART lines which go to points below R33 and R34, they don't seem to connect anywhere further. And by the looks there isn't anything under the screen either. Where does the MCU communicate then?

    I couldn't get anything out of that UART too. I tried standard baud rates with minicom, nothing. There is voltage at those pins, but no output. Although I might connect oscilloscope later.
  • #38 21556497
    groove6j
    Level 9  
    What is with the v0 protocol? How is it different?
    Still I haven't managed to get any TuyabMCU communications. tmSensor, also didn't work, as well as alternate UART flag.
    I think that I'll flash the stock firmware and try sniffing then.
  • #39 21556643
    insmod
    Level 31  
    v0 protocol is for TuyaMCU devices on battery power. In OBK it is enabled by tmSensor driver.
  • Helpful post
    #40 21556809
    p.kaczmarek2
    Moderator Smart Home  
    tmSensor (battery powered devices) are the devices where MCU controls the power of the WiFi module. This is done via MOSFET. Is your WiFi module VDD connected directly to 3.3V? Is so, it's not a battery powered device.

    tmSensor relies on the MCU enabling power of the WiFi module. So, the sequence is the following:
    - first MCU enables power of WiFI module
    - then WiFi module sends hello packet via UART to the MCU
    - then MCU replies.. etc etc.
    If you are powering WIFi module externally, for example, from the USB to UART converter, then tmSensor will not work, because MCU expects tmSensor to send packet exactly after it enables power of the WiFi module.
    Helpful post? Buy me a coffee.
  • #41 21557037
    groove6j
    Level 9  
    >>21556809
    I will flash stock firmware. And see what happens. Hope that the file I downloaded with python tool is OK, because when writing I had to use the AmebaD Windows tool for it to write properly, command line python tool failed.
  • ADVERTISEMENT
  • #42 21567115
    groove6j
    Level 9  
    Some more information I have gathered:
    The UART (which is unlabeled on the board) is definitely wired to TuyaMCU, but the MCU itself seems to live under the display of the device (most likely), which requires full desoldering of it. I have come to this conclusion, because I couldn't trace that UART port to the chip next to RTL8720 and nowhere else of the bottom of this device. It is wired somewhere under the board and perhaps within some middle layer of the board, so I couldn't see the connection.

    So yes, the chip next to RTL seems to be some kind of display driver most likely. Anyways what's left to do is flashing the stock firmware and do some sniffing of TuyaMCU traffic on that UART. It should be smooth sailing from that on, because all dpIDs are found and should configure easily. Also the powering issues I have should clear out if the right data packets are sent on RTL8720 boot to power the TuyaMCU.

    I have some other work to do, so I can't get to sniffing the communications right now. But I will definitely catch on to it.
  • #43 21571326
    kasperkasperfish
    Level 1  
    any update on this? I have the same device working for 2 years now via tuya cloud->homeassistant. Would be interested to flash custom firmware on it to completely bypass the tuya cloud. peace
  • #44 21571628
    groove6j
    Level 9  
    >>21571326
    Yeah, that integration is total trash for this device. Works slow and incomplete.

    We need to sniff TuyaMCU traffic on the first UART (the one not labeled LOG) with stock firmware. I couldn't get any data there, but I had already flashed the device.

    You could try flashing the device and tell your findings. Just take the stock backup and use the Windows AmebaD tool, it seems to work better.
  • ADVERTISEMENT
  • #45 21571688
    insmod
    Level 31  
    Preferably sniff before flashing. Perhaps it even uses a different protocol, though i doubt it.
  • #46 21571823
    groove6j
    Level 9  
    I successfully flashed back to stock. The device works again fully. Tried pairing to Tuya and got some interesting output on UART (when entering pairing mode).
    Code: text Expand Select all Copy to clipboard
    
Initializing WIFI ...
WIFI initialized
init_thread(58), Available heap 0x17f8b18:12:15 INFO  tuya_iot_com_api.c:148: rst_reason is 0
OFFSET = 97d
GAIN_DIV = 2ad6
18:12:15 INFO  tuya_module_demo.c:1227: thermostat_radiator:1.0.6
18:12:15 INFO  tuya_module_demo.c:1228: firmware compiled at Jun 17 2023 12:06:23
18:12:15 INFO  simple_flash.c:670: init succ
18:12:15 INFO  mf_test.c:139: have actived over 15 min, not enter mf_init
18:12:15 INFO  tuya_main.c:142: mf_init succ
18:12:15 INFO  tuya_main.c:143: firmware compiled at Jun 17 2023 12:06:23
18:12:15 INFO  tuya_module_demo.c:1056: product_info = {"p":"eaacu1av8nz9qdva","v":"2.0.11","c":1,"t":0}z
18:12:15 INFO  tuya_module_demo.c:1307: pid = eaacu1av8nz9qdva, ver = 2.0.11, wifi_set_mode = 1
18:12:15 INFO  tuya_iot_com_api.c:954: country_code =
18:12:15 INFO  tuya_iot_com_api.c:958: MAC[1c-90-ff-16-2f-63]
wifi_set_lps_smartps:2
[tuya_module_demo.c:1157] sleep_time_ms = 1000
[tuya_module_demo.c:1169] wifi is not set for powersave, don't do everything
[tuya_module_demo.c:1157] sleep_time_ms = 30000
18:12:15 INFO  tuya_iot.c:577: tuya_iot_init
18:12:15 ERROR tuya_endpoint.c:158: local_storage_get region fail:0xffffffff
18:12:15 INFO  tuya_endpoint.c:234: endpoint_mgr.region:
18:12:15 INFO  tuya_endpoint.c:235: endpoint_mgr.regist_key:
18:12:15 INFO  tuya_endpoint.c:200: Environment:pro
18:12:15 INFO  tuya_endpoint.c:210: Host region:AY
18:12:15 WARN  tuya_iot.c:108: activate config not found:-1
02:00:00 INFO  lpmgr.c:148: min_dtim = 0
product_id:total len = 16
65 61 61 63 75 31 61 76 38 6e 7a 39 71 64 76 61
uuid:total len = 16
66 38 64 63 65 63 32 38 38 38 36 64 61 63 39 64
auth_key:total len = 32
75 77 71 42 53 31 54 4d 41 53 37 57 73 42 6d 4a 42 6c 63 63 66 38 6e 63 54 61 4a 4a 66 45 69 5a
device id key ::total len = 16
74 9d f9 ea 60 3b 08 87 33 ec 29 f0 6e b1 c4 97
adv->data:total len = 28
02 01 06 03 02 01 a2 14 16 01 a2 00 65 61 61 63 75 31 61 76 38 6e 7a 39 71 64 76 61
scan_resp->data:total len = 30
03 09 54 59 19 ff d0 07 00 03 00 00 04 00 94 e9 6f 88 2b 9a 83 b8 b5 b7 82 2d 1b ba 4b 7b


    Gonna try sniffing TuyaMCU now.
  • Helpful post
    #47 21571847
    divadiow
    Level 38  
    Code: JSON
    Log in, to see the code
  • #48 21571866
    groove6j
    Level 9  
    >>21571847 I attached full dpid list in the first post.

    Tried multiple baud rates, can't get anything out of that UART, now even with stock firmware flashed. Any ideas?
    I also tried swapping TX and RX lines. Also changing the temp from Tuya app works, but no data.

    With oscilloscope there is no oscillation over that TX and RX lines. However over LOG TX I get oscillation when the log data enters on boot (very normal). After that, nothing on both UARTs.

    Although there is oscillation on SWDIO ( see the 5 pins within the battery label) when I change temperature remotely. But that's some other protocol. On boot there's a reasonable amount of oscillation. And that's probably how the data is exchanged on this device?

    SWDIO and SWCLK are connected through a resistor and a (diode or transistor) to two pins (bottom 5 and 6 from left side). I don't know which is pin1, because the top of the chip is scraped.
  • #49 21571868
    divadiow
    Level 38  
    groove6j wrote:
    I attached full dpid list in the first post

    Ha. My bad. Thought it odd I hadn't posted it already for some reason. Oh well

    Added after 7 [hours] 47 [minutes]:

    groove6j wrote:
    I don't know which is pin1, because the top of the chip is scraped.


    pin1 marker?
    Close-up of a blue PCB with an integrated circuit and a red arrow pointing to one pin.

    also was it ever stated what this is marked as? I recognise the faint logo
    Photo of a circuit board with a large square integrated circuit marked in red.

    Added after 7 [minutes]:

    ah. Maybe Cmsemicon like seen here https://www.elektroda.com/rtvforum/topic4041794.html#20999418
  • #50 21571975
    p.kaczmarek2
    Moderator Smart Home  
    groove6j wrote:

    Tried multiple baud rates, can't get anything out of that UART, now even with stock firmware flashed. Any ideas?

    Wrong pins? Or maybe try more reliable approach:
    Salae 24MHz logic analyzer for 10$ - analysis of an unknown LED display protocol
    Helpful post? Buy me a coffee.
  • #51 21572734
    groove6j
    Level 9  
    divadiow wrote:
    Maybe Cmsemicon

    That is BAT32G127GH 232101T. Maybe there is some other MCU chip behind LCD, but I am now unsure about that. Most likely no chip there.

    p.kaczmarek2 wrote:
    Wrong pins?

    Most likely that UART is not used at all in this variant of the board. TX and RX just stay at 3.3v and there is no voltage from the other side (which probably doesn't go anywhere). It just has these pads there, that's all. I recorded no oscillation at all. There are some other variants of that thermostat that maybe have different board setup where these pads are used.

    p.kaczmarek2 wrote:
    try more reliable approach

    That's right, I'll order one and try to figure out that protocol that goes over that SWDIO line. Which from the name of it should be SWD. Is that even possible with OpenRTL?
  • #53 21573297
    groove6j
    Level 9  
    >>21573287
    This makes sense, I could probably also read that flash, but with that binary blob there is not much that can be accomplished, yes.

    Well none of the both UARTs are connected to BAT32, but SWD is, so Tuya probably has some SWD driver that takes care of the communication.

    Anyway thanks for the help, this becomes much clearer.
  • #54 21847480
    amigos
    Level 16  
    Macro photo of a blue PCB with an integrated circuit and surrounding SMD components.

    Close-up of BAT32G12 IC on a blue PCB with SMD components

    Device PCB labeled LR6/AA with battery spring contacts inside a white housing
    It's been a while since the last post but you may find this useful. I received the T9W in a newer version. It has small modifications. Regarding the software, the previous ones had the possibility to set the hysteresis every 0.5 degrees and this one every 0.1 .
    Close-up of a blue PCB with SMD components and the marking “R6/AA”.
  • #55 21847883
    divadiow
    Level 38  
    >>21847480

    interesting. an XR806 version. Did you capture boot log, dump firmware etc? What are your plans for it?

    Added after 1 [hours] 50 [minutes]:

    @groove6j I've been playing with your backup and it now boots for me on my BW16E/RTL8720DN. I may as well just paste from GPT what needed doing to bypass a validation check to get it to boot:

    Code: Text
    Log in, to see the code


    etc etc, I think it's checking a device/flashID-dependant signature. So it fails and then boot loops on unexpected flash (or it's doing something mac/efuse and failing that). I now get this boot log:

    Code: Text
    Log in, to see the code


    and then as expected it seems to be waiting for the MCU to respond.

    I'm not getting any bytes of note on any baud on the usual UARTs but there is this distinct repeating pattern, in time with the app wakeup polling, on PA26 (UART3_TX apparently):

    Code: Text
    Log in, to see the code


    no idea what protocol that might be. If you're still interested in probing it'd be good to know what the MCU responds with.

    Patched dump attached for anyone else who might want to play.
    Attachments:
    • Tuya_EZAIoT_T9W_invalid_image_handler_KM4_patched.bin (4 MB) You must be logged in to download this attachment.
Reply | New topic
Report a violation of the law

Topic summary

✨ The discussion centers on flashing OpenBeken (OpenRTL8720D) firmware onto the EZAIoT T9W 2.0 R9BW 2.0 WiFi RF thermostat to enable local control, bypassing Tuya cloud dependency. The device consists of two parts: an RF receiver (RT-RC9PLUS 1.1_PCB v1.0) powered by mains and a battery/USB-C powered room thermostat with an LCD and WiFi. The thermostat likely uses a Realtek RTL8720DN or RTL8721D chip (AmebaD family), with an external SOIC8 flash chip (~4MB). The MCU controlling the display and RF pairing is separate, possibly a BAT32G127GH or similar, hidden under the LCD with erased markings, complicating tracing and UART communication. UART lines labeled LOG provide boot logs, but the other UART intended for TuyaMCU communication shows no activity or oscillation, suggesting it may be unused or routed internally under the display. The device uses TuyaMCU protocol, possibly v0 for battery-powered devices, but attempts to sniff or communicate via UART failed. Flashing was achieved using the Windows AmebaD tool rather than Python scripts due to checksum errors. The device boots OpenRTL8720D firmware only when UART adapter is connected, otherwise boots stock firmware. OTA flashing works inconsistently, requiring proper power connections (USB-C, VDD, GND). The display initialization and MCU communication remain unclear, possibly relying on SWD (Serial Wire Debug) lines for data exchange rather than UART. The community suggests sniffing TuyaMCU traffic on UART before flashing and exploring SWD protocol analysis. Due to complexity and lack of full support for RTL8720DN chips, local control via OpenBeken is challenging but feasible with further reverse engineering. Some users have moved to simpler ESPHome-based thermostat solutions. The discussion includes detailed firmware dump and flashing procedures, chip identification challenges, and protocol analysis attempts.
Generated by the language model.
Today's popular

FAQ

TL;DR: This FAQ helps Home Assistant and OpenBeken users move an EZAIoT T9W thermostat to local control. The board has 4 MB flash, and one developer confirmed: "It can only be AmebaD chip" after a successful dump, flash, and boot workflow on the scraped-marking unit. [#21552848]

Why it matters: This thread shows that the thermostat is not a simple ESP-based Tuya device, so identifying the Realtek-family board and power behavior is the key to getting reliable local control.

Option Hardware path What worked Main limit
Stock Tuya cloud Original firmware Full thermostat operation Cloud-only, slow/incomplete integration
LocalTuya Existing HA integration Did not control this model Protocol version mismatch
OpenRTL8720D on AmebaD Realtek-based board Dumping, flashing, web UI, OTA in Chrome MCU protocol still needed
Simple ESPHome replacement Separate relay + room thermostat Immediate local control fallback Replaces original integrated unit

Key insight: The older T9W board is an AmebaD-family Realtek design with external flash, but full local control still depends on understanding how the separate MCU and RF section communicate. Flashing OpenRTL8720D is only half the job. [#21552848]

Quick Facts

  • The thermostat head can run from 2× AA 1.5 V batteries or USB-C, while the RF receiver is a separate mains-powered board with COM, OPEN, CLOSE terminals. [#21441997]
  • The successful dump size was effectively 4 MB: an 8 MB read produced two identical halves, which indicates a mirrored 4 MB image. [#21444230]
  • Flash-mode detection used a high-speed serial pattern at about 921600 baud, and dumping used rtltool.py at 1500000 baud with reads of 0x400000 and 0x800000 bytes. [#21442947]
  • The extracted Tuya schema exposed concrete control points including set temperature 5.0–300.0 °C, current temperature -30.0–100.0 °C, and battery percentage 0–100%. [#21571847]

How can I identify whether the EZAIoT T9W 2.0 / R9BW 2.0 thermostat uses a Realtek RTL8720DN, RTL8721D, or another AmebaD chip when the package markings are scraped off?

You identify it from behavior, package size, and tooling compatibility rather than the erased top mark. The board showed a 48-pin QFN-style WiFi SoC, external SOIC-8 flash, dual-interface boot logs, and successful entry into Realtek flash mode. The decisive clue came later: the same backup tool worked, and the maintainer stated that this means it is an AmebaD-family chip supported by OpenRTL8720D. That support list included RTL8720DN, RTL8721DM, RTL8722DM, RTL8721CSM, RTL8720DF, and RTL8711TTF. [#21552848]

What is TuyaMCU, and how does it affect flashing OpenBeken or OpenRTL8720D on a WiFi thermostat like the EZAIOT T9W?

TuyaMCU is a separate controller that still runs the thermostat logic, display, sensors, or RF side after you flash the WiFi chip. "TuyaMCU" is a companion microcontroller system that exchanges framed control data with the WiFi SoC, often keeping the UI, relay logic, or sensors on its own firmware. On this thermostat, OpenRTL8720D booted and served a web UI, but heating functions still depended on getting the MCU protocol right. That is why flashing succeeded before full local control did. [#21553239]

How do I put a Tuya WBR3D / RTL8720DN-based thermostat into flash mode and dump the original firmware with rtltool.py before trying OpenBeken?

Use the Realtek flash-mode test first, then read a full backup before writing anything. 1. Connect the LOG UART and, before power-up, pull LOG TX to GND; if the chip floods the port with the same symbol at about 921600 baud, flash mode is active. 2. Run python3 rtltool.py -p COMx -b1500000 rf 0 0x400000 ff1.bin. 3. Repeat with 0x800000 to verify size and mirroring, then keep both dumps safe. This workflow was the thread’s confirmed pre-flash method. [#21442947]

Why does the thermostat boot OpenRTL8720D only when VCC from the UART adapter is connected, but fall back to stock behavior or stall when VCC is removed?

The thread points to a power-delivery problem, not a second valid stock boot path. With external VCC connected, the Realtek side completed boot, joined Wi-Fi, and started services. Without that extra supply, the log repeated early boot stages and stopped during initialization, while the display MCU still ran. The maintainer’s direct diagnosis was that there was not enough power on the WiFi side. The user also confirmed a reproducible pattern: apply USB-C first, then VCC, and both MCU and RTL stayed alive until VCC was removed. [#21553348]

Which is more reliable for flashing an AmebaD-based thermostat backup or OpenRTL8720D image: the Python rtltool script or the Windows AmebaD flashing tool?

The Windows AmebaD flashing tool was more reliable in this case. The backup read succeeded with Python, but writing with the script produced wrong checksums after flashing. The same user then switched to the Windows tool and reported a successful write of OpenRTL8720D. Later, the same user also restored stock firmware with the Windows path. If you need a single practical choice from this thread, use Python for reads and the Windows AmebaD tool for writes. [#21553227]

What is the TuyaMCU v0 protocol, and how is it different from the normal TuyaMCU protocol used by mains-powered devices?

TuyaMCU v0 is the battery-device handshake variant, where power timing matters as much as UART timing. "TuyaMCU v0" is a low-power TuyaMCU protocol variant that expects the MCU to switch power to the WiFi module, then begin communication immediately after wake-up. In OpenBeken, it is handled by tmSensor. The maintainer explained that normal mains-powered designs keep the WiFi module powered directly, while v0 devices often gate power through a MOSFET and require a precise startup sequence. [#21556809]

How can I tell whether the unlabeled UART on the EZAIOT thermostat is actually connected to the MCU, or if communication is happening over SWDIO/SWDCLK instead?

Check for actual signal activity, not just exposed pads. The user tried multiple baud rates, swapped TX and RX, and scoped the unlabeled UART, but saw no oscillation and both lines sat at 3.3 V. In contrast, SWDIO showed repeatable activity when the temperature changed remotely, and the SWD pins were physically routed into the nearby controller area. By June 8, the user concluded that the exposed UART pads were unused on this board revision and that the active control path was likely elsewhere, possibly over SWD-related lines. [#21572734]

What does it mean when an RTL8720DN firmware dump shows 'Invalid image, reboot', and how was that validation check bypassed in the patched backup?

It means the dumped firmware booted far enough to run a validation routine, then intentionally reset because the image check failed. In the later analysis, the patched backup replaced code at flash offset 0x0024AD8 with movs r0,#0; bx lr, which turned the failure handler into an immediate return instead of a reboot loop. After that patch, the firmware advanced further, printed normal Tuya startup logs, and then appeared to wait for MCU communication. That shows the image itself was usable, but blocked by a platform-specific validation path. [#21847883]

Why would OTA flashing of OpenRTL8720D fail in Firefox but work in Chrome on the same thermostat device?

The thread only established a browser-specific failure, not a deeper firmware cause. The same OTA image failed in Firefox with Get OTA header failed, then worked when the user retried from Chrome. After Chrome succeeded, the device reported the new OpenRTL environment correctly. That makes the safest practical conclusion simple: if OTA upload fails in Firefox on this device, retry the exact same image in Chrome before changing anything else. The thread did not provide a lower-level explanation beyond that verified workaround. [#21553289]

What is the tmSensor driver in OpenBeken/OpenRTL8720D, and when should it be used for battery-powered Tuya devices?

Use tmSensor only when the MCU actually powers the WiFi module on demand. "tmSensor" is an OpenBeken/OpenRTL driver for battery-style Tuya devices that wake the WiFi SoC through switched power, then expect an immediate UART greeting sequence. The maintainer clarified that it fits devices where the MCU enables WiFi power through a MOSFET. If you are feeding the WiFi chip externally from a USB-UART adapter, tmSensor will not behave correctly because the expected wake-and-hello timing is lost. [#21556809]

How should I map Tuya dpIDs from the EZAIOT thermostat to OpenBeken channels for features like switch, child lock, current temperature, and valve state?

Map the core functions directly from the published schema, then refine after sniffing live traffic. The strongest starting set is: dpID 1 = switch, dpID 40 = child lock, dpID 24 = current temperature, and dpID 36 or 110 = valve state. The schema also exposed dpID 16 for set temperature, dpID 2 for auto/manual mode, and dpID 107 for battery percentage. Use dpID 36 when you need the logical valve enum, and dpID 110 when you want the graph-oriented valve bool. That gives a usable OpenBeken template even before full protocol capture. [#21571847]

If LocalTuya cannot control this thermostat because of its protocol version, what local-control alternatives were explored in the thread?

Three local-control paths were explored: OpenRTL8720D flashing, protocol sniffing of the MCU link, and a full hardware replacement using ESPHome. The original poster started because LocalTuya only worked through cloud control on this model. When OpenRTL support was still incomplete, the fallback was a simple local system with one ESPHome relay at the stove and a separate room thermostat. After Realtek support improved, the thread shifted back to flashing the original board and decoding MCU communications for a native local solution. [#21552341]

What purpose does the Realtek WiFi SoC likely serve in this EZAIOT RF thermostat, and which functions may still depend on the separate MCU or RF section?

The Realtek SoC handles Wi-Fi, Tuya cloud logic, and local web control, while the separate MCU and RF hardware still appear to handle display, thermostat logic, and 433 MHz behavior. The unit is physically split into two parts: a mains-powered RF receiver board and a room thermostat powered by batteries or USB-C. Later testing also showed that OpenRTL could boot and expose networking while the display and RF behavior still depended on other circuitry. That division explains why flashing the WiFi chip alone did not immediately reproduce full thermostat control. [#21441997]

How can a logic analyzer help decode the unknown protocol on the thermostat's SWDIO line when neither of the expected UARTs shows TuyaMCU traffic?

A logic analyzer lets you capture raw transitions on SWDIO and nearby lines, then measure timing and frame patterns that a serial terminal will miss. In this thread, both expected UARTs stayed quiet, but SWDIO showed clear activity when remote temperature changes occurred. The recommendation was to use a cheap Saleae-style 24 MHz analyzer and decode the line as an unknown digital protocol. That is the right next step when pads exist but no UART waveform appears, because it reveals whether the MCU link is SWD-like, custom, or multiplexed. [#21571975]

What changed in the newer XR806-based version of the T9W thermostat, and how might that affect OpenBeken/OpenRTL support compared with the older Realtek-based board?

The newer T9W revision uses an XR806-based board and changed at least one user-facing control step from 0.5 ° to 0.1 ° hysteresis. That matters because the older thread’s confirmed dump, flash, and OpenRTL8720D workflow targeted an AmebaD Realtek design, not XR806 hardware. So the older Realtek procedure does not transfer directly. A new XR806 unit needs fresh boot logs, firmware dumps, and protocol work before anyone can claim equivalent OpenBeken or OpenRTL support. [#21847480]
Generated by the language model.
ADVERTISEMENT