There is one Tuya cloud device remaining at my home, and it is my thermostat. T9W 2.0 R9BW 2.0 (by EZAIOT , but possibly there are different vendors like SALCAR or others). Sold by the big Chinese market. It can't be controlled by LocalTuya (because of some weird protocol version), only cloud....

OBK supports ESP32, so we can try, and it's indeed a very interesting device you've found. Thank you for sharing. For ESP, you just ground IO0 at reboot time and then use esptool.py, first do read.and make sure it worked, so you have a backup. Maybe there is a chance that read will work without cutting traces, if not, well... you'll have to locate where RX/TX lines to MCU are. I see you also did dpID extraction according to our guide, it's a good start.

If the soic8 is indeed a flash chip, then is probably a RTL8720DN chip. Which is problematic, since there is no support for it yet. But, adding support for it is currently in my plans. Can your device see 5ghz networks from stock app?

There is at least one more Realtek with external flash chip. I saw it when making CH341 video: RTL8710BX + 25VQ16ATIG

>>21442803 I don't believe i've ever seen AmebaZ in QFP48 format. I also tried to google AmebaZ2 family chips, but seen only QFP40/QFP32. I doubt Ameba1 are still used, so that leaves AmebaD.

>>21442902 Usually flash is about 4mb in DN devices, but in some devices it can be 8mb (like WBRG1, not DN, but same chip family). 2 interfaces are AP and STA, so no relation to bands. Yes, try to re-pair. And try to take log from the moment it powers to at least when in tries to connect/starts ap mode. Additionally, you can try to enter flash mode, if it is indeed DN. Before powering it up, connect log tx to gnd, disconnect it after powered. If it starts spamming to uart (same symbol at 921600 baud, not sure if i remember it correct), then it is DN chip. To dump via uart, download unpack it and run Code: text Expand Select all Copy to clipboardpython3 rtltool.py -p COMx -b1500000 rf 0 0x400000 ff1.bin And to be sure Code: text Expand Select all Copy to clipboardpython3 rtltool.py -p COMx -b1500000 rf 0 0x800000 ff2.bin I don't recommend to share backup yet, because you would still need to run original firmware, at least until openbeken is ported.

ah! cool. yeh. got me curious and I started to hunt around

seems to be. cut the 8mb file in half and the two halves are identical Added after 29 [minutes]:>>21444049 maybe not. the BW16E/RTL8720DN dev board firmware comes full of RTL8721D references too

While OBK supports ESP32, i haven't managed to make UART work properly. But, this device is some realtek according to log. Which chip exactly is unknown to me, the log is incomplete. And flashing would probably be problematic, i don't see any strapping pin on board. Is this a flash chip between 2 mcus? Doesn't look like it, but if you have ch341a and soic clip, you can try to take a backup

I can't see the marking on the IC clearly, can you take a better photo?

I have a few eeprom/flash programmers. I just need to know what kind of flash it could possibly be, then I can try to read it.I will take some pictures later with a better camera, but both soic8 chip and the 48pin chip have their markings erased and replaced with numbers 12345678. The Chinese have tried to hide what these chips are. Also there is a chip on the right (possibly RF receiver), which also has the markings erased.But yeah, I'll take a better picture, then post it here.From the log I suppose there might be 2 WLAN interfaces by the first lines. The Tuya app? How can I check? By trying to re-pair the device to a 5ghz AP?Anyways thanks for your interactions, this is indeed quite a specific device. After some googling I found out that some of these thermostats indeed come with the Tuya WBR3D Realtek RTL8720DN chip, which is indeed dual band.

You mean the SOIC8 flash or the integrated flash in the chip? When entering flash mode which flash is read? Or maybe both are used? Sorry, I haven't learned about these chips much yet. It would even be easier for me to read the SOIC flash by clip or by desoldering. I also wonder what purpose there is for the Realtek MCU. I hope RF transmitting and RF pairing is done within the other MCU and Realtek chip only does the data receiving from the MCU and does the WiFi part. In the other case, it might be difficult to reprogram pairing stuff etc... That sounds pretty problematic for me And I took some better pictures. Maybe it will be easier to determine the chips.

12 legs per side? QFN48? RTL8720DN is 48...

>>21443701 Saw your post on tuya-local GitHub. I participated there with a different nickname. I'll try to dump the firmware using @insmod instructions. Assuming it is a RTL8720DN, which it now most likely is.

Yes, it does do that. Now I'm trying to get the python script to work.

assuming DN you may have to add more delay like here

>>21443868 Thanks! 1000 delay wasn't enough, after setting 5000, it worked. Here are the dumps. I'll take a look, but probably won't get much out of them.

getting this looping on RTL8720DN Code: TextLog in, to see the code could it be RTL8721D?

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.

Report a violation of the law

Reply | New topic

Helpful post

#1 21441997 16 Feb 2025 16:22

groove6j groove6j

Level 9
Topic author

Helpful post
Post #1
21441997 16 Feb 2025 16:22

There is one Tuya cloud device remaining at my home, and it is my thermostat. T9W 2.0 R9BW 2.0 (by EZAIOT, but possibly there are different "vendors" like SALCAR or others). Sold by the big Chinese market. It can't be controlled by LocalTuya (because of some weird protocol version), only cloud.
My target is to make it locally controllable by flashing OpenBeken on it. I don't yet know what the chip is inside, but it seems to be at the room thermostat part. Also seems to be a TuyaMCU device (I extracted tons of dpIDs from iot.tuya.com portal, also there is a non-WiFi model which could be missing the WiFi chip entirely).

It consists of 2 parts -
* RF receiver part which is powered by mains power. RT-RC9PLUS 1.1_PCB v1.0 200100164
* room thermostat with LCD screen, setting knob and WiFi, powers either by 2x AA 1.5v batteries or USB-C (or both)

RF receivers board in the picture below. There seems to be RF receiving part, relays, status LEDs, contacts COM, OPEN, CLOSE and power input. Pairing switch and some 20pin chip which has no initials on it. Doesn't seem to be any smart device, only RF receiver.

More will follow!

Added after 1 [hours] 2 [minutes]:

The thermostat board looks like this:

On the other side is the LCD screen and not much else. The main WiFi chip looks to be the 48pin chip to the left. Is it some ESP32 variant? ESP-WROOM-03 perhaps? The board config looks similar to that. I also read the progress you are doing with OpenESP! Great work!
Then there is BAT32G127GH 232101T, which looks to be some kind of LCD controller/MCU. Then there is some unmarked 8pin chip.
Also 48pin LGA chip and 8pin SOIC chips have their labels removed and 123456789 can be seen printed on them.
Any thoughts?
Also there are 2 serial ports, one marked "LOG" and another to the right of it. And some pins (VDD,SWDIO,SWCLK,GND,NRST) right on the bottom of the battery place.

Got this from the serial port called LOG:
Code: text Expand Select all Copy to clipboard
[MEM DBG] heap init-------size:256000 addr:0x1003a740--------- #interface 0 is initialized interface 1 is initialized 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":0,"t":0}y 18:12:15 INFO tuya_module_demo.c:1307: pid = eaacu1av8nz9qdva, ver = 2.0.11, wifi_set_mode = 0 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 INFO tuya_endpoint.c:234: endpoint_mgr.region:EU 18:12:15 INFO tuya_endpoint.c:235: endpoint_mgr.regist_key:36F7 18:12:15 INFO tuya_endpoint.c:210: Host region:EU 02:00:00 INFO lpmgr.c:148: min_dtim = 0 02:00:00 INFO netmgr_api.c:433: netmgr_start

Using the other serial port - nothing yet, only some garbage data. I haven't tried reading it as ESP32 yet, I need to understand how to do that , and how to free up the TX/RX pins, and which to short to ground for bootmode of the chip. I have less experience with ESP

Attachments:

ezaiot_dpids.ods (21.26 KB) You must be logged in to download this attachment.

ADVERTISEMENT
Helpful post

#2 21442788 17 Feb 2025 00:12

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Helpful post? (+1)

Helpful post
Post #2
21442788 17 Feb 2025 00:12

OBK supports ESP32, so we can try, and it's indeed a very interesting device you've found. Thank you for sharing.

For ESP, you just ground IO0 at reboot time and then use esptool.py, first do read.and make sure it worked, so you have a backup.

Maybe there is a chance that read will work without cutting traces, if not, well... you'll have to locate where RX/TX lines to MCU are.

I see you also did dpID extraction according to our guide, it's a good start.
https://www.elektroda.com/rtvforum/topic4021129.html

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#3 21442797 17 Feb 2025 00:26

insmod insmod

Level 31

Helpful post? (0)

Post #3
21442797 17 Feb 2025 00:26

While OBK supports ESP32, i haven't managed to make UART work properly.
But, this device is some realtek according to log. Which chip exactly is unknown to me, the log is incomplete.
And flashing would probably be problematic, i don't see any strapping pin on board. Is this a flash chip between 2 mcus? Doesn't look like it, but if you have ch341a and soic clip, you can try to take a backup
#4 21442798 17 Feb 2025 00:29

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Helpful post? (0)

Post #4
21442798 17 Feb 2025 00:29

I can't see the marking on the IC clearly, can you take a better photo?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
Helpful post

#5 21442801 17 Feb 2025 00:36

insmod insmod

Level 31

Helpful post? (+1)

Helpful post
Post #5
21442801 17 Feb 2025 00:36

If the soic8 is indeed a flash chip, then is probably a RTL8720DN chip. Which is problematic, since there is no support for it yet. But, adding support for it is currently in my plans.
Can your device see 5ghz networks from stock app?
ADVERTISEMENT
Helpful post

#6 21442803 17 Feb 2025 00:51

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Helpful post? (+1)

Helpful post
Post #6
21442803 17 Feb 2025 00:51

There is at least one more Realtek with external flash chip. I saw it when making CH341 video:
https://www.youtube.com/watch?v=z9uLPo9QAY8&t=81s

RTL8710BX + 25VQ16ATIG

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
Helpful post

#7 21442813 17 Feb 2025 01:25

insmod insmod

Level 31

Helpful post? (+1)

Helpful post
Post #7
21442813 17 Feb 2025 01:25

>>21442803 I don't believe i've ever seen AmebaZ in QFP48 format. I also tried to google AmebaZ2 family chips, but seen only QFP40/QFP32. I doubt Ameba1 are still used, so that leaves AmebaD.
#8 21442902 17 Feb 2025 08:13

groove6j groove6j

Level 9

Topic author Helpful post? (0)

Post #8
21442902 17 Feb 2025 08:13

insmod wrote:
but if you have ch341a and soic clip, you can try to take a backup

I have a few eeprom/flash programmers. I just need to know what kind of flash it could possibly be, then I can try to read it.
p.kaczmarek2 wrote:
I can't see the marking on the IC clearly, can you take a better photo?

I will take some pictures later with a better camera, but both soic8 chip and the 48pin chip have their markings erased and replaced with numbers 12345678. The Chinese have tried to hide what these chips are. Also there is a chip on the right (possibly RF receiver), which also has the markings erased.
But yeah, I'll take a better picture, then post it here.

insmod wrote:
Can your device see 5ghz networks from stock app?

From the log I suppose there might be 2 WLAN interfaces by the first lines. The Tuya app? How can I check? By trying to re-pair the device to a 5ghz AP?

Anyways thanks for your interactions, this is indeed quite a specific device. After some googling I found out that some of these thermostats indeed come with the Tuya WBR3D Realtek RTL8720DN chip, which is indeed dual band.
Helpful post

#9 21442947 17 Feb 2025 08:52

insmod insmod

Level 31
Helpful post? (+1)

Helpful post
Post #9
21442947 17 Feb 2025 08:52

>>21442902 Usually flash is about 4mb in DN devices, but in some devices it can be 8mb (like WBRG1, not DN, but same chip family).
2 interfaces are AP and STA, so no relation to bands. Yes, try to re-pair.
And try to take log from the moment it powers to at least when in tries to connect/starts ap mode.
Additionally, you can try to enter flash mode, if it is indeed DN.
Before powering it up, connect log tx to gnd, disconnect it after powered. If it starts spamming to uart (same symbol at 921600 baud, not sure if i remember it correct), then it is DN chip.
To dump via uart, download https://github.com/pvvx/pvvx.github.io/blob/master/RSH-GW018_DM/bin/wbrg1.zip, unpack it and run
Code: text Expand Select all Copy to clipboard
python3 rtltool.py -p COMx -b1500000 rf 0 0x400000 ff1.bin

And to be sure
Code: text Expand Select all Copy to clipboard
python3 rtltool.py -p COMx -b1500000 rf 0 0x800000 ff2.bin

I don't recommend to share backup yet, because you would still need to run original firmware, at least until openbeken is ported.
#10 21443456 17 Feb 2025 14:38

groove6j groove6j

Level 9

Topic author Helpful post? (0)

Post #10
21443456 17 Feb 2025 14:38

insmod wrote:
Usually flash is about 4mb in DN devices, but in some devices it can be 8mb

You mean the SOIC8 flash or the integrated flash in the chip? When entering flash mode which flash is read? Or maybe both are used? Sorry, I haven't learned about these chips much yet. It would even be easier for me to read the SOIC flash by clip or by desoldering.

I also wonder what purpose there is for the Realtek MCU. I hope RF transmitting and RF pairing is done within the other MCU and Realtek chip only does the data receiving from the MCU and does the WiFi part.
In the other case, it might be difficult to reprogram pairing stuff etc... That sounds pretty problematic for me

And I took some better pictures. Maybe it will be easier to determine the chips.
ADVERTISEMENT
#11 21443701 17 Feb 2025 17:16

divadiow divadiow

Level 38

Helpful post? (0)

Post #11
21443701 17 Feb 2025 17:16

12 legs per side? QFN48? RTL8720DN is 48...
#12 21443805 17 Feb 2025 18:33

groove6j groove6j

Level 9

Topic author Helpful post? (0)

Post #12
21443805 17 Feb 2025 18:33

>>21443701
Saw your post on tuya-local GitHub. I participated there with a different nickname. I'll try to dump the firmware using @insmod instructions. Assuming it is a RTL8720DN, which it now most likely is.
Helpful post

#13 21443811 17 Feb 2025 18:35

divadiow divadiow

Level 38

Helpful post? (+1)

Helpful post
Post #13
21443811 17 Feb 2025 18:35

ah! cool. yeh. got me curious and I started to hunt around
#14 21443867 17 Feb 2025 19:06

groove6j groove6j

Level 9

Topic author Helpful post? (0)

Post #14
21443867 17 Feb 2025 19:06

insmod wrote:
If it starts spamming to uart (same symbol at 921600 baud, not sure if I remember it correct), then it is DN chip.

Yes, it does do that. Now I'm trying to get the python script to work.
#15 21443868 17 Feb 2025 19:08

divadiow divadiow

Level 38

Helpful post? (0)

Post #15
21443868 17 Feb 2025 19:08

assuming DN you may have to add more delay like here https://www.elektroda.com/rtvforum/topic4093142-180.html#21437842
#16 21443892 17 Feb 2025 19:26

groove6j groove6j

Level 9
Topic author Helpful post? (+1)

Post #16
21443892 17 Feb 2025 19:26

>>21443868
Thanks! 1000 delay wasn't enough, after setting 5000, it worked.
Here are the dumps. I'll take a look, but probably won't get much out of them.

Attachments:

ff1_8mb.bin (8 MB) You must be logged in to download this attachment.

ff1_4mb.bin (4 MB) You must be logged in to download this attachment.
#17 21444049 17 Feb 2025 20:46

divadiow divadiow

Level 38

Helpful post? (0)

Post #17
21444049 17 Feb 2025 20:46

getting this looping on RTL8720DN
Code: Text
Log in, to see the code

could it be RTL8721D?
#18 21444067 17 Feb 2025 20:53

groove6j groove6j

Level 9

Topic author Helpful post? (0)

Post #18
21444067 17 Feb 2025 20:53

>>21444049
Yes, a lot of references of RTL8721D.

This device communicates over 433MHz RF (Bidirectional FSK). I found some references to that in the dump. Wondering if this chip supports RF comms natively or relies on the other MCU.

The flash size was 4MB, right?
Helpful post

#19 21444230 17 Feb 2025 22:30

divadiow divadiow

Level 38

Helpful post? (+1)

Helpful post
Post #19
21444230 17 Feb 2025 22:30

seems to be. cut the 8mb file in half and the two halves are identical

Added after 29 [minutes]:

>>21444049

maybe not. the BW16E/RTL8720DN dev board firmware comes full of RTL8721D references too
#20 21552341 18 May 2025 00:32

groove6j groove6j

Level 9

Topic author Helpful post? (0)

Post #20
21552341 18 May 2025 00:32

Since it is currently not possible to flash this device, I'm moving to a very simple thermostat system using one esphome relay device connected to my stove and one thermostatic device in the living room. If anyone is interested, feel free to contact me.
#21 21552351 18 May 2025 01:06

insmod insmod

Level 31

Helpful post? (0)

Post #21
21552351 18 May 2025 01:06

>>21552341
Why not possible? I added support for RTL8720D about 3 months ago.
I tested it on WBRG1 8mb, BW16 4mb and BW16 2mb, and all of them are working ok.
GPIO and uart is fully working.
ADVERTISEMENT
#22 21552775 18 May 2025 14:50

groove6j groove6j

Level 9

Topic author Helpful post? (0)

Post #22
21552775 18 May 2025 14:50

>>21552351
Sorry, I haven't followed the updates on RTL devices for a while. Great work you have done!

About this device - we didn't really understand which variant of Realtek chip that was, because the chip's name was scraped off, only the firmware which I read was available. If I understand which variant that is, I can flash it.
#23 21552848 18 May 2025 16:38

insmod insmod

Level 31

Helpful post? (+2)

Post #23
21552848 18 May 2025 16:38

>>21552775
It can only be AmebaD chip, since you managed to take a backup with a tool i posted earlier.
It wouldn't work for anything else, i even tried to use it with AmebaDplus and failed.
OpenRTL8720D supports all AmebaD chips, that is RTL8721CSM, RTL8720DN, RTL8720DF, RTL8721DM, RTL8722DM, RTL8711TTF. Not RTL87xxDA though (AmebaDplus).
If you flash it - it will work.
#24 21553039 18 May 2025 19:36

groove6j groove6j

Level 9

Topic author Helpful post? (+1)

Post #24
21553039 18 May 2025 19:36

>>21552848
Trying right away!

[size=9:d42295ab2ab]Added after 25 [minutes]:[/size:d42295ab2ab]

>>21552848
One more question. Should I flash with some other GUI tool I saw in the posts, or is it possible with the same python script I read firmware with?
#25 21553080 18 May 2025 19:43

insmod insmod

Level 31

Helpful post? (+1)

Post #25
21553080 18 May 2025 19:43

>>21553039
It's possible to flash it via script, just use wf instead of rf
#26 21553227 18 May 2025 22:11

groove6j groove6j

Level 9

Topic author Helpful post? (+1)

Post #26
21553227 18 May 2025 22:11

>>21553080
Yes it works. I had to use the Windows tool, python script failed with wrong checksums after write.

But when I disconnect my UART adapter, then it boots the stock firmware. When I connect UART, then it boots OpenRTL8720D. I can tell, because the display lights all the pixels when OpenRTL8720D is booted.
#27 21553231 18 May 2025 22:16

insmod insmod

Level 31

Helpful post? (0)

Post #27
21553231 18 May 2025 22:16

>>21553227
That's strange, i haven't heard of such behaviour before.
Just to make sure, perform OTA once to make sure both firmware slots are flashed with OBK.
But perhaps you're wrong? This device is very likely comes with TuyaMCU, and it usually controls display.
#28 21553239 18 May 2025 22:20

groove6j groove6j

Level 9
Topic author Helpful post? (0)

Post #28
21553239 18 May 2025 22:20

>>21553231
Both slots are definitely not flashed. Ok, I'll try performing OTA.

Yup - every time when the GND, TX and RX pins are connected to my FTDI adapter, it boots OpenRTL8720D, screen shows all pixels (like a screen test) and web-ui etc works.

When it is disconnected, then temp. display works and there is no sign of OpenRTL8720D - no hotspot, no wifi connection.

A guess now - the screen needs to be initialized somehow, maybe setting some DPids to some value? When the stock FW initializes, there are the same screen test, but after a second it initializes fully.

update:
OTA:

Code: text Expand Select all Copy to clipboard
Info:CMD:[WebApp Cmd 'loglevel 3' Result] OK Info:OTA:Current firmware index is 1 Error:OTA:Get OTA header failed Error:OTA:OTA failed

BTW when booting without serial adapter, it shows 02 in screen corner (it is usual behaviour), probably means that the FW2 is booted. How can I flash the other slot? I think that it boots FW1 when TX or RX is high at boot.
#29 21553285 18 May 2025 23:16

insmod insmod

Level 31

Helpful post? (0)

Post #29
21553285 18 May 2025 23:16

That's not how it's supposed to work.
Btw, what image are you using for ota? I just now used that one and it worked fine: https://github.com/openshwprojects/OpenBK7231...wnload/1.18.102/OpenRTL8720D_1.18.102_ota.img
Perhaps try to add 'startdriver tuyamcu' to either autoexec.bat or startup command

Added after 3 [minutes]:

And just to be sure, are you powering the board via VDD pin? If so, remove it and leave just GND and TX.
#30 21553289 18 May 2025 23:28

groove6j groove6j

Level 9

Topic author Helpful post? (0)

Post #30
21553289 18 May 2025 23:28

insmod wrote:
Btw, what image are you using for ota? I just now used that one and it worked fine: https://github.com/openshwprojects/OpenBK7231...wnload/1.18.102/OpenRTL8720D_1.18.102_ota.img

I used the same file. I also tried OpenRTL8720D_1.18.101_ota.img . I tried both uploading it to webapp and pasting the link into the OTA page. Nothing - it doesn't do it at all.

insmod wrote:
Perhaps try to add 'startdriver tuyamcu' to either autoexec.bat or startup command

Already did that, nothing changed.

Added after 4 [minutes]:

insmod wrote:
And just to be sure, are you powering the board via VDD pin? If so, remove it and leave just GND and TX.

Yeah, via VDD. Ok, I'll try right away.

Added after 6 [minutes]:

insmod wrote:
If so, remove it and leave just GND and TX.

Okay. It boots the stock firmware. If I connect RX too, the same.
I can boot FW1 when I connect GND, RX, TX and VCC. (which is OpenRTL8720D)

Update:
OTA worked from Chrome, from Firefox it somehow didn't work. Now when booted it shows that it's FW2 in OpenRTL8720 homepage. But still the old firmware boots when I remove VCC.
Create an account, log in here. You will receive points by participating in discussions.
Join this discussion.

Install Elektroda application

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.

Home page
/
Forum
/
Smart Home
/
Smart Home IoT
/
Flashing OpenBeken on EZAIoT Wifi RF Thermostat for Local Control

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.