How to copy the contents of the module? Because I don't see the option to read write memory to a file in Ameba.
Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
{
"vendor": "Tuya",
"bDetailed": "0",
"name": "Full Device Name Here",
"model": "enter short model name here",
"chip": "RTL87X0C",
"board": "TODO",
"flags": "1024",
"keywords": [
"TODO",
"TODO",
"TODO"
],
"pins": {
"3": "Rel;1",
"4": "BL0937SEL;0",
"11": "WifiLED_n;0",
"13": "Btn;1",
"14": "LED_n;1",
"17": "BL0937CF;0",
"18": "BL0937CF1;0"
},
"command": "",
"image": "https://obrazki.elektroda.pl/YOUR_IMAGE.jpg",
"wiki": "https://www.elektroda.com/rtvforum/topic_YOUR_TOPIC.html"
}
startDriver BL0937
startDriver NTP
ntp_timeZoneOfs 01:00
PowerSave 0
VCPPublishIntervals 60 60
p.kaczmarek2 wrote:AmebaZ2 PG Tool 1.2.47
$ pip install ltchiptool
$ python -m ltchiptool flash write --device /dev/ttyUSB0 "/home/dolf/OpenRTL87X0C_1.18.21.bin"
I: Detected file type: Realtek AmebaZ2 Flash Image
I: Connecting to 'Realtek AmebaZ2' on /dev/ttyUSB0 @ 115200
I: |-- Success! Chip info: RTL8720CF
I: Writing '/home/dolf/OpenRTL87X0C_1.18.21.bin'
I: |-- Start offset: 0x0 (auto-detected)
I: |-- Write length: 719.1 KiB (auto-detected)
I: |-- Skipped data: 0 B (auto-detected)
[################################################################] 100% I: Transmission successful (ACK received).
I: Transmission successful (ACK received).
I: |-- Finished in 79.313 s
pin symbol type function Tuya Basic Smart Switch usage
4 A18 I/O GPIOA_18, hardware PWM, IC Pin39 LED_n 1
6 A17 I/O GPIOA_17, hardware PWM, IC Pin38 Btn 1
9 A12 I/O GPIOA_12, hardware PWM, IC Pin26 Rel 1
{
"vendor": "Tuya",
"bDetailed": "0",
"name": "Tuya Smart Switch Basic WiFi 10A",
"model": "",
"chip": "RTL87X0C",
"board": "JKY101-F-SR-V3.1",
"flags": "1024",
"keywords": [
"TODO",
"TODO",
"TODO"
],
"pins": {
"12": "Rel;1",
"17": "Btn;1",
"18": "LED_n;1"
},
"command": "",
"image": "https://obrazki.elektroda.pl/1732280500_1718455167.jpg",
"wiki": "https://www.elektroda.com/rtvforum/topic3979433.html"
}
WBR3 is a low-power embedded Wi-Fi+Bluetooth module that Tuya has developed. It consists of a highly integrated RF chip (W701-VA2-CG), with an embedded Wi-Fi network protocol stack and varied library functions.
WBRU is a low-power-consumption embedded Wi-Fi+Bluetooth module that Tuya has developed. Embedded with the Wi-Fi network protocol stack and rich library functions, it consists of a highly integrated RF chip (W701-VA2-CG).
{
"vendor": "Tuya",
"bDetailed": "0",
"name": "Full Device Name Here",
"model": "enter short model name here",
"chip": "RTL87X0C",
"board": "TODO",
"flags": "1024",
"keywords": [
"TODO",
"TODO",
"TODO"
],
"pins": {
"12": "Rel;1",
"17": "Btn;1",
"18": "LED_n;1",
"19": "LED;1"
},
"command": "",
"image": "https://obrazki.elektroda.pl/YOUR_IMAGE.jpg",
"wiki": "https://www.elektroda.com/rtvforum/topic_YOUR_TOPIC.html"
}
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]