logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

WBR2, WBR3, WBRU, W701-VA2-CG pinout, datasheet, flashing for Home Assistant

p.kaczmarek2 20967 166
ADVERTISEMENT
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • #61 21564542
    robshd2
    Level 4  
    Hi, have followed the instructions to flash the WBR3S in my M515EGWT and soldered it back in, but am slightly at a loss on how to proceed further, since the Flash Tool did not offer a backup option that I could feed into the BK7231GUIFlashTool to get the config.

    So on the WebApp,

    ```
    startDriver TuyaMCU
    ```

    makes the red LED flash and this stops when sending

    ```
    tuyaMcu_defWiFiState 4
    ```

    Which I presume is a good sign? But playing around with the channels yielded no results so far, neither opening the blinds nor closing, and there seems to be no ready-made recipe out there to achieve this. If you could give me some pointers how to arrive at a working config, it would be much appreciated!
  • ADVERTISEMENT
  • #62 21564545
    divadiow
    Level 38  
    hello again :)

    if you run tuyaMcu_sendQueryState in the command line in web app what do you get returned?
  • #63 21564552
    robshd2
    Level 4  
    >>21564545

    Thanks for the quick reply! I get the following:

    Debug:CMD:cmd [tuyaMcu_sendQueryState]
    Info:CMD:[WebApp Cmd 'tuyaMcu_sendQueryState' Result] OK
    Info:TuyaMCU:Received: 55 AA 03 07 00 05 01 04 00 01 01 15
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 12
    Info:TuyaMCU:ParseState: id 1 type 4-enum len 1
    Info:TuyaMCU:ParseState: byte 1
    Info:TuyaMCU:Received: 55 AA 03 07 00 05 07 04 00 01 00 1A
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 12
    Info:TuyaMCU:ParseState: id 7 type 4-enum len 1
    Info:TuyaMCU:ParseState: byte 0
    Debug:TuyaMCU:ApplyMapping: id 7 (val 0) not mapped
    Info:TuyaMCU:Received: 55 AA 03 07 00 08 02 02 00 04 00 00 00 00 19
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
    Info:TuyaMCU:ParseState: id 2 type 2-val len 4
    Info:TuyaMCU:ParseState: int32 0
    Debug:TuyaMCU:ApplyMapping: id 2 (val 0) not mapped
    Info:TuyaMCU:Received: 55 AA 03 07 00 05 05 01 00 01 00 15
    Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 12
    Info:TuyaMCU:ParseState: id 5 type 1-bool len 1
    Info:TuyaMCU:ParseState: byte 0
  • #64 21564567
    divadiow
    Level 38  
    ok.
    I'm wondering if we can get your product ID somehow. Did you manage to capture the factory fw boot log?
  • #65 21564575
    robshd2
    Level 4  
    >>21564567

    I have this output: {"p":"t6ief6k56sapz1ey","v":"1.0.0","m":2}

    Which only gives me this thread if I look for the ID: https://github.com/make-all/tuya-local/issues/924

    Might or might not help.

    Testing some more, channel 2 moves between 0 and 100 if I press the buttons on device, with the curtain. Will need to figure out how to map this to the channels etc. next.

    Edit:

    Alright, this gives me minimal control already, no idea what the other values might be for, but continuing to explore:

    startDriver TuyaMCU
    tuyaMcu_setBaudRate 9600
    tuyaMcu_defWiFiState 4
    setChannelType 2 dimmer
    linkTuyaMCUOutputToChannel 2 2 2
  • #66 21564603
    p.kaczmarek2
    Moderator Smart Home  
    Welcome to forum. I see you have a very interesting device, we'll try to help you with getting it to work. I can see you are already receiving dpIDs, so it should be only the matter of figuring out what they mean.
    The usual approach is here: https://www.elektroda.com/rtvforum/topic4021129.html
    but we do it BEFORE flashing.

    Now that you've flashed it, can you provide us information on what kind of features Tuya app had for this device?

    I've checked the link you provided. @divadiow do those ids match dpIDs of TuyaMCU?

    Here is text formatted by ChatGPT:
    Code: JSON
    Log in, to see the code


    Would that mean that dpID 1 is:
    Code: text Expand Select all Copy to clipboard
    
              "description": "[Required] Used to control motor: open, pause, close. The enum values for this data point (DP) cannot be modified, added, or removed.",


    I think I can add required channel types to firmware for you, we just need to check if that dpIDs are matching.
    Helpful post? Buy me a coffee.
  • #67 21564609
    divadiow
    Level 38  
    Query device details

    Code: JSON
    Log in, to see the code


    query things data model

    Code: JSON
    Log in, to see the code


    Code: JSON
    Log in, to see the code


    Added after 45 [seconds]:

    lol. beat me to it

    Added after 12 [minutes]:

    we seem to match. you handily included translated descriptions :)
  • ADVERTISEMENT
  • #68 21564641
    p.kaczmarek2
    Moderator Smart Home  
    Do you have Home Assistant to test @divadiow ? I will go through those dpIDs and add required channel types if needed
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #70 21564750
    robshd2
    Level 4  
    Alright, here is what I know so far:

    dpId 1 is certainly Open (0), Stop (or something else, 1), Close (2). Seems to be digital triggers for the buttons.
    dpId 2 is percentage control and reporting for the state, 0 = Fully open, 100 = Fully closed.

    The rest in the docs you shared seems plausible. Having used the device in Tuya for a bit, the functions reflect the options given there. Is there a way to transfer this document to an autoexec.bat? Webapp > Import > Template is not the place for it, is it?

    If not, I am already mostly happy with having dpId 1 and 2. I just can't seem to get them onto Home Assistant through MQTT, is there a trick to that? Flag 19, "Always publish channels used by TuyaMCU", does not seem to do it.

    Once I have the full thing working and a better understanding, I might try my hand at the calibration dpids.

    My current autoexec.bat is still:

    startDriver TuyaMCU
    tuyaMcu_setBaudRate 9600
    tuyaMcu_defWiFiState 4
    setChannelType 1 LowMidHigh
    linkTuyaMCUOutputToChannel 1 4 1
    setChannelType 2 dimmer
    linkTuyaMCUOutputToChannel 2 2 2
  • #71 21564801
    p.kaczmarek2
    Moderator Smart Home  
    I'll do MQTT check on my side in one hour and get back to you, I will edit my post.

    What kind of UI do we need for OpenStopClose? In OBK, and in HA?

    Added after 5 [minutes]:

    For HA discovery, add this to end of autoexec.bat:
    Code: text Expand Select all Copy to clipboard
    
scheduleHADiscovery 5

    This will do discovery 5 seconds after mqtt connect. Of course, this can be also done manually, but maybe it's easier with command.

    When doing big changes, you may need to remove manually device from HA first.

    Some of channel types may not be discoverable yet, but I can add what's missing

    Added after 1 [hours] 42 [minutes]:

    I'm working on it

    Dropdown menu with three levels: Low, Mid, and High in the Controls section of the user interface.

    Added after 17 [minutes]:

    I will add release soon.
    Sample:
    Code: text Expand Select all Copy to clipboard
    
setChannelType 2 LowMidHigh
scheduleHADiscovery 1

    Result:
    Control panel with dropdown menu for selecting power level; options are Low, Mid, High.
    Code: text Expand Select all Copy to clipboard
    
setChannelType 2 LowMidHigh
setChannelLabel 3 Lalala
setChannelType 3 OpenStopClose
scheduleHADiscovery 1

    Screenshot of a user interface showing a dropdown menu with Open, Stop, and Close options in the Controls section.

    Control panel WinTest_00000000 with speed selection (Low, Mid, High), mode options (Open, Stop, Close), Toggle 0 button, and device electrical data.
    Helpful post? Buy me a coffee.
  • #72 21565307
    robshd2
    Level 4  
    >>21564801

    Thanks for the help! This works through the UI and through the HTTP endpoint now, but no matter how often I reset, reboot or remove the device from HA, it comes up without Controls or Sensors:

    Diagnostics panel for RTL87X0C device showing firmware, connection, and Wi-Fi status.

    Any idea why this might be the case?
  • #73 21565310
    p.kaczmarek2
    Moderator Smart Home  
    So you have this radio buttons on OBK UI, but not in HA?

    Wait... do you REALLY have those new types on UI?

    I added them today, and your build is from 26 may. Hmm. Maybe you need to update?

    Just to be sure, is OpenStopClose channel type really working for you? Do you have it on OBK UI?

    @divadiow , do you have physical device with the same platform as @robshd2 ? Can you check do you get OpenStopClose in HA?

    ENABLE_ADVANCED_CHANNELTYPES_DISCOVERY seems to be enabled on RTL...

    I can also see you're SSID may be a Rick and Morty reference.
    Helpful post? Buy me a coffee.
  • #74 21565324
    robshd2
    Level 4  
    >>21565310

    I still run it with LowMidHigh for now, as the others seemed to error. I had hoped for either the buttons of Channel 2 to show up. Let me update and report back, if it makes a difference for discovery.

    Re: SSID: You would be correct ;)

    EDIT:

    Holy holy, it looks like the update did the trick! Thank you very much, my detachment from the Tuya Cloud seems to be complete!

    To get an understanding of the internals: The channels are exposed based on their type, which is why things like the dimmer on channel 2 would not be visible?

    Current config:

    startDriver TuyaMCU
    tuyaMcu_setBaudRate 9600
    tuyaMcu_defWiFiState 4
    setChannelType 1 OpenStopClose
    setChannelLabel 1 Commands
    linkTuyaMCUOutputToChannel 1 4 1
    setChannelType 2 dimmer
    setChannelLabel 2 ClosingState
    linkTuyaMCUOutputToChannel 2 2 2
    scheduleHADiscovery 5
  • ADVERTISEMENT
  • #75 21565330
    divadiow
    Level 38  
    Screenshot of a panel with two dropdown lists set to Low and Open.

    Code: Text
    Log in, to see the code


    Control panel of RTL87X0C device by Realtek with diagnostics and logbook on the MQTT platform.
  • #76 21565333
    robshd2
    Level 4  
    Control panel with Close command and a button to add to dashboard.

    And a screenshot of the working toggle. Updated the message above with an edit. Thanks again!
  • #77 21565336
    p.kaczmarek2
    Moderator Smart Home  
    Dimmer channel type is special, because it's used to create light entity. I think I will just create a separate channel type with HASS discovery for you tomorrow.

    So, what kind of channel type do we need? Does it have to be read and write, or read only?
    Code: text Expand Select all Copy to clipboard
    

            {
              "abilityId": 2,
              "accessMode": "rw",
              "code": "percent_control",
              "description": "If the curtain motor can monitor its current position (e.g., 50% open), this DP allows precise position control. If selected, percentage display must be enabled. The value range for this DP cannot be modified, added, or removed.",
              "extensions": {
                "iconName": "icon-dp_power"
              },
              "name": "Percentage Control",
              "typeSpec": {
                "max": 100,
                "min": 0,
                "scale": 0,
                "step": 1,
                "type": "value",
                "typeDefaultValue": 0,
                "unit": "%"
              }
            },

    It seems it's rw, so both read and write. Ok, so do you have any suggestions which HA entity should we use for that?

    Alternatively, once we get this fully working, we can check HA for dedicated shutter entity, maybe it would be even more useful.

    Added after 1 [hours] 4 [minutes]:

    maybe something like that:

    A control panel with a battery icon showing 0 and a slider set to 74.

    Added after 5 [minutes]:


    History chart of the device WT00000000 5 with a current value of 31%.
    Helpful post? Buy me a coffee.
  • #78 21599261
    ghorvat87
    Level 1  
    Hi guys, I had some luck with flashing WBR3 thanks to very detailed guide by @p.kaczmarek2 .

    Got this Tuya IR blaster that is now running Open RTL87X0C 1.18.130, however, I notice that the firmware build for RTL87X0C does not have the IR driver? Is this in the pipeline to be developed? I will he happy to publish the template for this device as soon as I get it working.

    Thanks!

    WBR2, WBR3, WBRU, W701-VA2-CG pinout, datasheet, flashing for Home Assistant WBR2, WBR3, WBRU, W701-VA2-CG pinout, datasheet, flashing for Home Assistant
  • #79 21599380
    p.kaczmarek2
    Moderator Smart Home  
    It just need 50us (if I remember correctly) timer ported and then both IR libraries we have can work, more or less
    Helpful post? Buy me a coffee.
  • #80 21599998
    vinibali
    Level 8  
    >>21393106
    hi!
    it seems, this SP1 with RTL8710C has two different layouts.
    I double checked the pinouts for the BL097, but I couldn't make it work.
    Code: text Expand Select all Copy to clipboard
    
{
  "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": {
    "2": "WifiLED;0",
    "3": "LED_n;0",
    "4": "Btn;0",
    "11": "Rel;0"
  },
  "command": "",
  "image": "https://obrazki.elektroda.pl/YOUR_IMAGE.jpg",
  "wiki": "https://www.elektroda.com/rtvforum/topic_YOUR_TOPIC.html"
}
  • #81 21609784
    vinibali
    Level 8  
    >>21599998
    This was maybe not obvious, but I wanted to point out as the pinout for the LEDs, button and relay are different.
  • #83 21610405
    colgate1one
    Level 2  
    Hello from Germany,

    sorry that my first Post is directly a search for help.

    STORY (long):
    ---
    I bought 4 Wifi Smart Plugs (Power Meter) from Amazon.
    They are called Avatar AWP16L - sadly I started TASMOTA compatibility research only after they were here.
    I found a Blog (I am not sure yet if Posting Links to other Websites is allowed - will read the guidelines for this), lets say its the second hit on google for "awp16l tasmota" from 2021.
    It seemed that this will work, since the board look really similar.
    After some hours I found that the Pinout does not match and I have a different chip - WBR2.
    Discovering that they seem not be compatible with TASMOTA, I found this Thread, which is by the way awesome!
    For a first time UART Flash user it was not sometimes not obvious what to do, but manageable (booting into flash mode had me for some time).
    ---

    Questions starts here:
    Now I have two of the four Plugs flashed with OpenBK7231T_App (OpenRTL87X0Cxxxxx.bin).
    On TASMOTA how To´s now would be the Part where I copy a Template to the config?
    Like this one here? https://templates.blakadder.com/AWP16L.html ({"NAME":"AWP16L","GPIO":[0,0,320,0,0,2720,0,0,2624,32,2656,224,0,0],"FLAG":0,"BASE":45})
    If I understand correctly, this will set the Pinout from the ESP to the mainboard on the plug?
    But on OpenBK Website I was not able to find a template for my plug.
    Did I miss something? Is there maybe a config that I can use?
    I understand, that if not I may need to learn to Pinout myself - is there any good guideline?
    Would be nice to get a headstart, so I can finally finish this project =)

    Sorry for the long post and have fun ready about my stupidity.

    See ya.
  • #84 21610410
    p.kaczmarek2
    Moderator Smart Home  
    We don't currently have automatic remap of ESP TYWE2S to WBR2 pins, and it most likely wouldn't help, because manufacturer may change pin roles in a meantime. I think the simplest way now for you would be to just use GPIO doctor to find LED, Relay and button. Then we can think about power metering, as it's also supported by this plug?
    https://www.elektroda.com/rtvforum/topic3976371.html
    Helpful post? Buy me a coffee.
  • #85 21610546
    colgate1one
    Level 2  
    [postid:5713d156a2][/postid:5713d156a2]
    Thank you very much!
    I think I got the PINs:
    Code: JSON
    Log in, to see the code

    I am able to Toggle the Realy and the LED in the Menu now.
    The power measurement is still missing.
    I tryed the Powere Meeter Too, but it says "Unknown command"
    Hopefully it is as comfortable as finding out the PINs, to activate the Measument funktion =)


    Goof Evening.



    //EDIT:
    OK, now I know that I had to start the driver for Power Metering.
    startDriver BL0942 9600
    And I tryed guessing the 3 Sensors:
    "pins": {
    "12": "dInput;51",
    "13": "LED_n;50",
    "15": "BL0937CF;0",
    "17": "Rel;46",
    "18": "BL0937SEL;0",
    "19": "BL0937CF1;0"
    },
    Now I was able to read the Volt and Amps and also calibrate them.
    But Power ist still not showing and I cannot calibrate - "Last status: ERROR: Command found but returned error (undefined)"
    What am I missing? I thought that maybe one of the PINs ist not corret, but if I remove one, then I get only zeros.
    (I was not able to find out how the BL937 CF CF1 and SEL corelate to one another. Is it like, one is for A one for V and one for W?
    Normaly I would say, that the W would just be calculated?)
  • #87 21699635
    divadiow
    Level 38  
    to dump what might remain of the Tuya config or have you more devices not yet flashed to OpenBeken?
  • #88 21699772
    LeMaxime
    Level 7  
    >>21699635 i have two more WB4 Bulbs with stock(Tuya firmware) and want to flash it but selecting GPIO in GPIO Doctor is quite tedious
  • #89 21701460
    p.kaczmarek2
    Moderator Smart Home  
    I've found another WBR3 device - Tuya Smart Kettle model SMART06B. I didn't try TuyaMCU on WBR3 itself yet, because it's has poor flashing pins access, but it works good on CB3S:
    Code: text Expand Select all Copy to clipboard
    
startDriver TuyaMCU

tuyaMcu_defWiFiState 4

setChannelType 1 Toggle

linkTuyaMCUOutputToChannel 1 bool 1


setChannelType 2 Temperature
setChannelLabel 2 "Current Temperature"

linkTuyaMCUOutputToChannel 2 val 2

setChannelType 4 TextField
setChannelLabel 4 "Target Temperature"

linkTuyaMCUOutputToChannel 4 val 4

    I will post full teardown and device details in separate topic.
    Backup: https://github.com/openshwprojects/FlashDumps/commit/f9f283d2cddad48157f4a7911798b242974dbe36
    Helpful post? Buy me a coffee.
  • #90 21701946
    divadiow
    Level 38  
    insmod wrote:
    The most important is AmebaZ2, but its protocol is somewhat different - even requires separate flash tool, while even AmebaZ is supported by latest flash tools.


    I've been playing with GPT and we seemed to have made a Z2 flash read script. I really don't know how good the code is but it's making identical dumps at different bauds and they can be flashed to erased Z2 (with official tool) and they do boot.

    Code: Text
    Log in, to see the code


    Code: Text
    Log in, to see the code


    Code: Text
    Log in, to see the code


    Code: Text
    Log in, to see the code


    Code: Text
    Log in, to see the code


    AmebaZ2 PG Tool interface showing flash programming and device status

    Comparison of two binary files with message confirming they are identical.
    Attachments:
    • ambz2_flashtool_readonly_withtimer.zip (6.36 KB) You must be logged in to download this attachment.
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
Report a violation of the law

Topic summary

✨ The discussion centers on flashing and integrating Tuya modules based on the RTL8720CF chip (W701-VA2-CG), including WBR1, WBR2, WBR3, WBR2L, WBR3L, and WBRU, for cloud-free operation with Home Assistant (HA) using the AmebaZ2 PG Tool and OpenBK7231T (OBK) firmware. Detailed pinouts, flashing jigs, and boot logs are shared, highlighting the need to access specific pins (A0, A15, A16) often located on the PCB underside, sometimes requiring desoldering. Users report successful flashing on devices like Kasa HS200, Gosund SP1 (BL097), and Tapo P110, with calibration support for BL0937 power monitoring chips. Challenges include reading and backing up firmware, especially system and calibration data, which may be stored in efuse or inaccessible flash areas. The community collaborates on templates for device configuration, MQTT integration, and HA discovery, including channel type mappings (e.g., OpenStopClose, LowMidHigh, dimmer) for TuyaMCU protocols. OTA updates and UART communication are tested, with ongoing development of tools and firmware support for these Realtek-based modules. Additional discussion covers the similarity between WBR3 and WBRU modules for firmware transplantation and the presence of Tuya config partitions. The thread also touches on related devices like thermostats (WT50-WH-3A, WT100-WH-3A, WT200-16A-W, HY609-WE) and the FR8016HA MCU in some modules. Overall, the topic provides a comprehensive guide and collaborative troubleshooting for flashing, configuring, and integrating RTL8720CF-based Tuya modules with open-source firmware and Home Assistant.
Generated by the language model.
Today's popular

FAQ

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]

Quick Facts

  • WBR3, WBR2, and WBRU in this thread all center on W701-VA2-CG / RTL8720CF, a Wi-Fi + BLE 4.2 Realtek platform typically running at 100 MHz with 256 KB SRAM in the shared comparison table. [#21375443]
  • The proven boot wiring uses 3.3 V, not 5 V logic, and the guide explicitly recommends a solid external 3.3 V LDO because some USB-UART adapters cannot power the module reliably from their 3.3 V pin. [#21375223]
  • WBR3 flashing usually needs access to underside pads: connect A15/A16, pull A0 and A13/RXD high, then reset with EN to GND. WBR2 exposes similar signals more accessibly. [#21375223]
  • Later tool work added practical dump support: one successful RTL87X0C backup read a full 0x200000 = 2 MB flash and verified it with a SHA-256 hash match before extraction attempts. [#21727461]
  • Real-world confirmation spans several devices, including a Kasa HS200, Gosund SP1 plug, and Tapo P110 variants, showing the method is not limited to one Tuya product family. [#21381809]

How do I flash a Tuya WBR3 or WBR2 module based on W701-VA2-CG / RTL8720CF with OpenBeken using AmebaZ2 PG Tool or BK7231GUIFlashTool?

Flash it over the log UART, not the normal serial port. 1. Power the module from a stable 3.3 V supply and wire A16→USB-UART RX, A15→USB-UART TX, plus GND. 2. Pull A0 and A13/RXD high to enter bootloader, then reset by shorting EN to GND. 3. Write an OpenRTL87X0C binary with AmebaZ2 PG Tool or the newer BK7231GUIFlashTool, then remove the boot straps and reboot. The guide states this method works for WBR1, WBR2, WBR3, WBR2L, WBR3L, and WBRU-class RTL8720CF modules. [#21375223]

What is W701-VA2-CG, and how is it related to Realtek RTL8720CF, WBR2, WBR3, and WBRU modules?

W701-VA2-CG is the RF module core used by several Tuya-branded boards, and in this thread it is treated as the same platform as Realtek RTL8720CF. "W701-VA2-CG" is an embedded Wi-Fi + Bluetooth module family that packages the RTL8720CF-class chip into different Tuya footprints, including WBR2, WBR3, and WBRU, while keeping the same flashing concept and similar GPIO families. That is why one firmware family, OpenRTL87X0C, can target multiple module shapes even though the pin headers differ. [#21515587]

Which pins do I need to connect on WBR3, WBR2, and WBRU to enter bootloader mode and flash over UART?

Use the log UART pins plus two boot straps. For WBR3, connect 3.3 V, GND, A16 to USB-UART RX, A15 to USB-UART TX, then pull A0 and RXD/A13 high and reset with EN. For WBR2, the same rule applies, but A15 and A16 are on the back and A13 is labeled RXD. For WBRU, the note is explicit: A15 and A16 are the debug/flashing UART, while A13 and A0 must be pulled high for bootloader mode. [#21375223]

Why does a WBR3 usually need to be desoldered before flashing, and are there any practical alternatives like a jig or NodeMCU adapter hack?

WBR3 usually needs desoldering because its critical flashing pads sit on the underside. Multiple replies confirm you generally must remove it to reach A15 and related pads, although practical alternatives appeared in the thread: a spring-pin jig in development and a NodeMCU carrier hack with wires routed below the module. Those ideas reduce repeat soldering, but the tested method remained full access to the underside pads. One concise reply put it plainly: "yes. WBR3 pads on the underside would need to be accessed." [#21376702]

What is AmebaZ2 PG Tool 1.2.47, and when should I use it instead of BK7231GUIFlashTool or ltchiptool for RTL87X0C devices?

AmebaZ2 PG Tool 1.2.47 is the legacy Realtek flashing utility first used in this guide for RTL8720CF-based Tuya modules. Use it when you only need a known-good write path on Windows and want to follow the original screenshots exactly. Prefer BK7231GUIFlashTool when you need newer RTL87X0C support, backup features, or config extraction workflows. Use ltchiptool when you want a Linux CLI path; one user flashed an OpenRTL87X0C image from /dev/ttyUSB0 and the tool auto-detected a 719.1 KiB Realtek AmebaZ2 image successfully. [#21398455]

How do I set up OpenBeken after flashing a WBR3 or WBR2 so it joins Wi-Fi and appears in Home Assistant via MQTT discovery?

After flashing, boot OpenBeken, join its AP, and configure Wi-Fi at 192.168.4.1. Then set your MQTT broker, save, and either run Home Assistant discovery manually or add 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]

Why does flashing a WBR3 with an FT232 adapter fail with XMODEM timeouts, while a CH340 works better for some users?

The thread’s strongest pattern is adapter quality and UART stability, not the module itself. A user repeatedly hit XMODEM timeouts and short-packet errors with an FT232-based adapter, then switched to a CH340 and obtained a proper RTL flash backup with hash verification. Another contributor noted many FT232 boards are fake, while CH340 and CP210x adapters worked reliably in their experience. Stable 3.3 V power also matters, because a weak adapter supply can look like a protocol failure. [#21809020]

What do the WBR3, WBR2, and WBRU pinouts look like, including the hidden A15/A16 log UART pads used for flashing?

The important difference is where the log UART appears. WBR3 exposes 16 edge pins, including A13/RXD and A14/TXD, but A15 is on the back and A16 is the log TX pin used for internal output. WBR2 has 11 main pins, with A15 and A16 again available on the rear pads. WBRU is more convenient: both log UART pins, L_RX = A15 and L_TX = A16, are on the sides together with TX = A14 and RX = A13. That hidden A15/A16 pair is why photos and board diagrams matter so much. [#21375223]

How can I read or back up flash contents from RTL8720CF / RTL87X0C devices, and what tools currently support dump and restore?

Today, use BK7231GUIFlashTool for practical dump and restore on RTL87X0C. By October 2025, the thread showed full read and write working, including a 2 MB backup, flash ID detection, hash verification, and config extraction attempts. Earlier in the thread, the answer was effectively “not yet” for AmebaZ2 PG Tool, which lacked a straightforward read-to-file path for users. There was also experimental CLI work around AmebaZ2 reads, but the clearest usable path became BK7231GUIFlashTool rather than the older vendor flasher. [#21708748]

What is TuyaMCU, and how do I map Tuya dpIDs to OpenBeken channels for thermostats, heaters, blinds, and kettles?

TuyaMCU is the secondary-MCU protocol layer many smart devices use between the Wi-Fi module and the product logic board. "TuyaMCU" is a serial protocol interface that carries dpIDs such as switch, target temperature, blind position, or kettle temperature, and OpenBeken maps each dpID to a channel type, label, and direction. In practice, start the driver, set the baud rate, then use commands like 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]

How do I troubleshoot a TuyaMCU device on WBR3 when startDriver TuyaMCU causes safe mode or when Home Assistant entities do not show up?

Start by removing the bad autoexec, rebooting cleanly, and launching TuyaMCU manually. If 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]

What is the difference between the log UART on A15/A16 and the user UART on A13/A14 on WBR modules, and which one is used for flashing?

The log UART on A15/A16 is the flashing path; the user UART on A13/A14 is the application serial port. The module tables describe A15 as 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]

AmebaZ2 PG Tool vs BK7231GUIFlashTool vs ltchiptool for Realtek RTL8720CF flashing — which tool is better for writing, reading, and recovery?

BK7231GUIFlashTool is the best all-around choice in this thread’s later state. Use AmebaZ2 PG Tool for basic legacy writing, ltchiptool for Linux command-line writing, and BK7231GUIFlashTool for the broadest write-plus-read-plus-recovery workflow. By late 2025, BK7231GUIFlashTool added RTL87X0C read/write support, flash-ID handling, and config operations, while AmebaZ2 PG Tool remained mostly a vendor writer. ltchiptool proved practical for write-only Linux use, but the thread did not position it as the primary backup or recovery solution. [#21708620]

How can I preserve or reconstruct original device functionality after flashing OpenBeken, including importing templates, using GPIO Doctor, and writing autoexec.bat scripts?

Rebuild the device in layers: pins first, protocol second, automation third. 1. If it is not a TuyaMCU device, use GPIO Doctor or a known template to find relay, button, LEDs, and metering pins. 2. If it is a TuyaMCU device, extract or infer dpIDs and map them in 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]

What should I watch out for when moving firmware or backups between WBR3 and WBRU modules, especially around RF calibration, system data, and per-device settings?

Expect the main firmware to be portable, but treat per-device data cautiously. One reply says WBR3 and WBRU use the same W701-VA2-CG core and should run the same program image, yet the follow-up warning is RF and system data: calibration may be per-device, MAC is in efuse, and a later developer comment says system and calibration areas at 0x1000–0x3000 do not appear readable in normal dumps. So move the application image only when possible, not a blind full-device clone for certification-sensitive work. [#21516179]
Generated by the language model.
ADVERTISEMENT