logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Identifying TX/RX Pins on EWELINK Zigbee Gateway with ESP32 and EWL-WBT04 Module

yotapaki 4044 24
Best answers

How can I find the UART TX and RX pins on an EWeLink Zigbee gateway with an EWL-WBT04 ESP32 module?

The working UART pins reported for this gateway are GPIO23 as RX and GPIO19 as TX, found by tracing the board rather than relying on boot text [#21487805][#21582540] One user noted that these pins may not be used for logging, so seeing no startup output is normal, and garbled characters usually mean TX/RX are swapped or the wrong pads are connected [#21582540] For one board variant, entering download mode also required GPIO0 to GND and LED9 to GND in addition to RX↔TX, 3.3V↔3.3V, and GND↔GND before powering the programmer [#21621420]
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • #1 21395282
    yotapaki
    Level 2  
    Posts: 4
    Hello,

    I am currently working on an EWELINK Zigbee gateway that uses an ESP32 chip. This device includes a module labeled EWL-WBT04, but I’ve been unable to find any documentation or information about it online.

    So far, I’ve successfully identified the GND and VCC pins. The module has a 2x9 pin layout, with two ground pins and two 3.5V VCC pins.

    I’m now trying to locate the TX and RX pins but have encountered difficulties. I attempted to connect my UART controller to each pin individually to find the TX port. However, on some pins, I only receive garbled data (”?????”), and on others, there’s no output during the device boot sequence, suggesting these might not be the correct pins.

    Do you have any tips or methods to help me correctly identify the TX and RX pins?

    Thank you in advance for your assistance!

    EWL-WBT04 circuit module on a printed circuit board.
    Electronic module on a circuit board with pin markings.

    AI: Could you provide more details on the method or tools you used to test the pins for TX and RX?
    I connected a cable from the RX port of my UART controller to each pin of the module.
    AI: Are there any additional markings or identifiers on the EWL-WBT04 module that might help in identifying the pins?
    Nope
  • ADVERTISEMENT
  • #2 21396463
    miegapele
    Level 16  
    Posts: 173
    Help: 15
    Rate: 29
    There is lots of different esp32 chips. If it's zigbee you probably should NOT try to flash it. Likely you will brick it.
    If REALLY you want to try pinout looks similar to the one on page 13. pins 40 and 41.
  • #3 21396508
    inot
    Level 38  
    Posts: 3505
    Help: 434
    Rate: 785
    You can trace the path of the signals marked in the attachment.
    You can trace (traverse) the path of the signals marked in the attachment.
    Attachments:
    • Identifying TX/RX Pins on EWELINK Zigbee Gateway with ESP32 and EWL-WBT04 Module 2799748500_1737019472.png (3.53 MB) You must be logged in to download this attachment.
  • ADVERTISEMENT
  • #4 21396802
    yotapaki
    Level 2  
    Posts: 4
    Thank you for your response!

    The chip I’m working with is an ESP32 D0WD, which serves as a WiFi module. Additionally, the board includes another module featuring a Zigbee chip (CC2652).

    I’ve managed to locate the TX and RX pins, and I’m trying to enter bootloader mode by grounding GPIO0. Unfortunately, it seems I don’t have direct access to this pin. Do you have any suggestions on how to proceed?

    For reference, here’s some additional information that might help: https://kdrive.bagou450.com/app/share/763082/10c05739-3e48-4751-8a52-ee38994626ed

    Apologies if my questions seem a bit basic—this is my first time working on something this advanced with a board! 😊

    [url=https://obrazki.elektroda.pl/5718286300_1737102141.png]Close-up of a circuit board with marked pins GND, VCC, RX, and TX.[/url>]
  • #5 21396933
    inot
    Level 38  
    Posts: 3505
    Help: 434
    Rate: 785
    Proceed in the same way as before, i.e. find where the GPIO0 signal path leads.
    Attachments:
    • Identifying TX/RX Pins on EWELINK Zigbee Gateway with ESP32 and EWL-WBT04 Module 2799748500_1737019472.png (3.53 MB) You must be logged in to download this attachment.
  • #6 21398440
    yotapaki
    Level 2  
    Posts: 4
    I don’t fully understand how to proceed, as the GPIO pins seem to connect to another layer of the PCB.

    However, I noticed that one pin switches from 3V to 0V when I press the button. Could this be GPIO0? I tried holding the button while powering it up, but instead of entering bootloader mode, it just boots normally.
  • #7 21398888
    inot
    Level 38  
    Posts: 3505
    Help: 434
    Rate: 785
    yotapaki wrote:
    I noticed that one pin switches from 3V to 0V when I press the button. Could this be GPIO0?
    .
    This is most likely the CHIP_PU pin that serves as a reset.

    yotapaki wrote:
    I don't fully understand how to proceed
    .
    I thought you knew what I meant by finding the TX and RX pins as I described.
    To check where the GPIO0 signal path goes, use a multimeter and measure whether there is a connection between it and the other pins (one of the eighteen).
  • #8 21454093
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    >>21395282 I received that gateway today, and managed to flash and connect it to Z2M successfully.
    Close-up of an electronic module with clearly marked RX, TX, and GPIO0 pins.
    For pins, treat it like ZBBridge-P that lack some features (i2c rtc, buzzer).
    There is also a PSRAM chip that i haven't managed to get to work.
    ESP32 backup attached.
    Attachments:
    • zb-gw.zip (960.01 KB) You must be logged in to download this attachment.
  • #9 21454302
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    And now i've managed to enable PSRAM by doing some pin tracing.
    ESPHome sdkconfig_options are
    CONFIG_D0WD_PSRAM_CLK_IO: "5"
    CONFIG_D0WD_PSRAM_CS_IO: "18"

    I haven't seen any config for ZBBridge-P with psram enabled, but since all pins are the same those would probably work for ZBBridge-P too.
  • ADVERTISEMENT
  • #10 21454456
    divadiow
    Level 38  
    Posts: 4850
    Help: 421
    Rate: 854
    didn't know there was a thread for this already. mine arrived today too.
    more pics for library:

    Packaging of Ewelink Zigbee 3.0 Gateway Hub EZ-MG-ZG-806. Close-up of the Zigbee Wireless Gateway packaging with manufacturer's information. Zigbee gateway starter kit contents on a wooden table. Cardboard packaging with a white label displaying the technical specifications of a wireless device. Zigbee wireless gateway placed on a wooden surface. White square sensor on a wooden surface. Device setup instructions on a wooden table. Zigbee Gateway user manual on a wooden surface. Close-up of an electronic circuit board with visible integrated circuit components. Electronic circuit board with visible USB port and components on a PCB. Interior of an electronic device showing PCBs and a USB port. Close-up of a green printed circuit board with an integrated circuit.

    Added after 37 [minutes]:

    log from that TX labelled. 115200 then 921600

    Code: Text
    Log in, to see the code
  • #11 21466695
    setum
    Level 7  
    Posts: 15
    Help: 2
    Rate: 3
    deleted, wrong thread
  • #12 21487393
    setum
    Level 7  
    Posts: 15
    Help: 2
    Rate: 3
    >>21454302
    Your mention of ESPHome got me intrigued. Can we install ESPHome in it? How will it work -- similar to Tasmota ZBBridge or similar to ESPHome bluetooth proxy, but with Zigbee (Zigbee Proxy). Do you have the ESPHome yaml for this device?
  • #13 21487805
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    >>21487393
    I don't know how Tasmota works - i've never used it.
    But it creates a port for zigbee connection, and i use bluetooth proxy of course.
    Connecting to zigbee is simple - just specify tcp://{ip}:8888
    I tested this with Z2M, and now it works with ZHA.
    I migrated from Tuya WRG1+TYZS3 gateway, flashed with OpenBeken to this.

    I swapped led functions, now red - zigbee connection, blue - wifi status led.
    Remove packages and specify your wifi, api and ota settings.
    Code: text Expand Select all Copy to clipboard
    substitutions:
  ip: "192.168.0.9"
  powersave: "LIGHT"

esphome:
  name: esp32-zb-bridge
  friendly_name: esp32_zb-bridge
  platformio_options:
    build_flags: "-DBOARD_HAS_PSRAM"
  on_boot:
    priority: 800
    then:
      - switch.turn_on: zigbee_rst
      - delay: 15ms
      - switch.turn_off: zigbee_rst

external_components:
  - source: github://oxan/esphome-stream-server

esp32:
  board: esp32dev
  framework:
    type: esp-idf
    sdkconfig_options:
      CONFIG_ESP32_REV_MIN_3_1: "y"
      CONFIG_D0WD_PSRAM_CS_IO: "18"
      CONFIG_D0WD_PSRAM_CLK_IO: "5"
      CONFIG_BT_BLE_DYNAMIC_ENV_MEMORY: "y"
      CONFIG_BT_ALLOCATION_FROM_SPIRAM_FIRST: "y"

debug:
  update_interval: 5s

# Enable logging
logger:
  baud_rate: 115200 

uart:
  rx_pin: GPIO23
  tx_pin: GPIO19
  baud_rate: 115200

packages:
  common: !include base/common.yaml
  ota: !include base/ota.yaml
  wifi: !include base/wifi_psk_both.yaml

psram:
  mode: quad
  speed: 80MHz

esp32_ble_tracker:
  scan_parameters:
    interval: 1100ms
    window: 1100ms
    active: false

bluetooth_proxy:
  active: false
  cache_services: false

status_led:
  pin: 
    number: 21
    inverted: false

stream_server:
  port: 8888

binary_sensor:
  - platform: stream_server
    connected:
      name: Connected
      on_press:
        - light.turn_on: red
      on_release:
        - light.turn_off: red

  - platform: gpio
    pin: 
      number: 27
      inverted: True
    name: "update_switch"
    internal: True
    device_class: update
    on_click:
      min_length: 1s
      max_length: 3s
      then:
        - switch.turn_on: reboot
    on_double_click:
      min_length: 50ms
      max_length: 350ms
      then:
        - switch.turn_on: fw_update

sensor:
  - platform: stream_server
    connection_count:
      name: Number of connections
  - platform: debug
    free:
      name: "Heap Free"
    psram:
      name: "Free PSRAM"
  - platform: wifi_signal
    name: WiFi Signal Sensor
    update_interval: 3600s

output:
  - platform: gpio
    pin: GPIO2
    inverted: true
    id: status

light:
  - platform: binary
    name: "Red"
    id: red
    output: status
    internal: True
    restore_mode: ALWAYS_OFF

switch:
  - platform: template
    name: FW Update
    id: fw_update
    turn_on_action:
      - switch.turn_on: zigbee_bsl
      - delay: 1s
      - switch.turn_on: zigbee_rst
      - delay: 1s
      - switch.turn_off: zigbee_rst
      - delay: 2s
      - switch.turn_off: zigbee_bsl
      - delay: 25s
      - switch.turn_off: fw_update

  - platform: gpio
    id: zigbee_rst
    pin: 15
    name: "Zigbee RST"
    inverted: True
    internal: True
    restore_mode: ALWAYS_OFF

  - platform: gpio
    id: zigbee_bsl
    pin: 22
    name: "Zigbee BSL"
    inverted: True
    internal: True
    restore_mode: ALWAYS_OFF
  • #14 21525120
    tepliukyurii
    Level 4  
    Posts: 3
    Rate: 1
    Wgrałem oprogramowanie https://xzg.xyzroe.cc
    Tak że zmieniłem firmware zigbee na coordinator od tasmota.

    Z Home Assistant pracuję jak z Z2M tak i ZHA.
    Dużo dodatkowych funkcji.
  • ADVERTISEMENT
  • #15 21558029
    sevenissimo
    Level 3  
    Posts: 8
    Rate: 1
    >>21487805
    Just wanted to let you know your post and all your work were an immense help! I easily managed to flash ESPHome onto my gateway, so huge thanks for that!

    Unfortunately, Zigbee isn't working yet.
    I'm guessing I need to upload the proper firmware, similar to other CCxxxx-based coordinators.
    I'm just not clear if you did that step, and if so, which firmware version you used.
  • #17 21562627
    sevenissimo
    Level 3  
    Posts: 8
    Rate: 1
    >>21558442
    Thanks! I finally uploaded the Zigbee firmware and got ZHA working with this coordinator.
    The hardware seems like good value for money. It should be listed on blakadder.
  • #18 21582439
    germansunza
    Level 2  
    Posts: 3
    Hello, I hope you can help me. My English is not good. I have received my gateway and connected it as shown in the image, but I can't get any data. It seems that the TX and RX pins are not correct.
  • #19 21582540
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    >>21582439
    They cannot be wrong, i've traced them and flashed successfully via them.
    Perhaps you've accidentally swapped RX and TX? And as far as i remember, they aren't used for logging, so don't expect any output.
  • #20 21583011
    germansunza
    Level 2  
    Posts: 3
    >>21582540 Connect the module's RX to the UART's TX and TX to RX. I tried to flash it with Tasmota and without success. I tried to do it with Esphome using the script you posted and the same result, GPIO to ground to be able to enter programming mode, voltage at 3.3 volts.

    Identifying TX/RX Pins on EWELINK Zigbee Gateway with ESP32 and EWL-WBT04 Module
  • #21 21583025
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    I was using usb to power it, and connecting uart module gnd to any gnd on the whole board (even usb socket body would work). GPIO0 to gnd before powering up.
    Alternatively you could try to read/write firmware via ch341a and a clip.
  • #22 21583302
    germansunza
    Level 2  
    Posts: 3
    >>21583025 In the end it was my USB adapter, I managed to flash it with Tasmota and it's working fine for the moment.
  • #23 21593753
    muriloneo
    Level 1  
    Posts: 1
    Hey, just register here to talk in this thread!
    I was trying to tweak this one to get out of the eWeLink app, as I am more and more diving into the Home Assistant world. I am still very new.
    I have a Home Assistant in a NUC using Portainer and with a CC2531 USB Stick.
    So what I am trying to do is flash it with Tasmota or whatever for the CC2531 or any other way to detect it directly.

    Does this sound a good direction? Should I try flashing it?
    And how did you that managed to flash made this work, as I don't see proper placement for wires... Appreciate the patience!
  • #24 21621420
    LeMaxime
    Level 7  
    Posts: 16
    Rate: 2
    Same device, same module
    But can't launch ESP in download mode
    tried even with external power - same result
    rx-tx, tx-rx, gnd-gnd, gpio0-gnd

    Well, after a few days of thinking and the help of a very smart guy, there are a few things that need to be described.
    My Ewelink Zigbee Gateway is different from the one described above. I attach photos. There is also a photo of the back side of the EWL-WBT04 module

    Package and case photos
    Spoiler:

    White square device with rounded corners on a black surface with white speckles
    Back of a white device case with vent holes on a dark splattered background
    White box labeled “Mini Wireless Gateway” on a dark splattered background
    White box labeled “1 * Mini Wireless Gateway 1 * USB Cable” on its side
    White box with QR code and text Scan the QR code for User Guide
    White box with FCC, CE, RoHS symbols and crossed-out wheeled bin mark
    White box listing supported sensors: water leakage, door/window, temp/humidity, PIR


    Board photos

    Spoiler:
    PCB with EWL-WBT04 module, label SM-031 V1.1, back view
    PCB with EWL-WBT04 module, USB-C connector, surface-mounted components visible


    Backside photo EWL-WBT04

    Spoiler:
    Back side of EWL-WBT04 module with labeled pins on green PCB.

    Front photo EWL-WBT04 with pins describe

    Spoiler:
    Close-up of EWL-WBT04 module with labeled pins and GPIO connections


    In order to switch to download mode on this board, additional actions are required.
    Connect RX-TX, TX-RX, 3.3 - 3.3, GND-GND from EWL-WBT04 to your programmer (there are 2 GND on the board - choose any you like) You also need to additionally connect GPIO0-GND and LED9-GND. - Then connect the programmer to the computer.
    Now flash any firmware you want.
    My config for ESPHome (based on the insmod config with a small edit)

    Code: text Expand Select all Copy to clipboard
    esphome:
  name: esp32-zb-bridge
  friendly_name: esp32_zb-bridge
  platformio_options:
    build_flags: "-DBOARD_HAS_PSRAM"
  on_boot:
    priority: 800
    then:
      - switch.turn_on: zigbee_rst
      - delay: 15ms
      - switch.turn_off: zigbee_rst

external_components:
  - source: github://oxan/esphome-stream-server

esp32:
  board: esp32dev
  framework:
    type: esp-idf
    sdkconfig_options:
      CONFIG_ESP32_REV_MIN_3_1: "y"
      CONFIG_D0WD_PSRAM_CS_IO: "18"
      CONFIG_D0WD_PSRAM_CLK_IO: "5"
      CONFIG_BT_BLE_DYNAMIC_ENV_MEMORY: "y"
      CONFIG_BT_ALLOCATION_FROM_SPIRAM_FIRST: "y"

debug:
  update_interval: 5s

# Enable logging
logger:
  baud_rate: 115200 

uart:
  rx_pin: GPIO23
  tx_pin: GPIO19
  baud_rate: 115200


psram:
  mode: quad
  speed: 80MHz

esp32_ble_tracker:
  scan_parameters:
    interval: 1100ms
    window: 1100ms
    active: false

bluetooth_proxy:
  active: false
  cache_services: false

status_led:
  pin: 
    number: 21
    inverted: false

stream_server:
  port: 8888

binary_sensor:
  - platform: stream_server
    connected:
      name: Connected
      on_press:
        - light.turn_on: red
      on_release:
        - light.turn_off: red

  - platform: gpio
    pin: 
      number: 27
      inverted: True
    name: "update_switch"
    internal: True
    device_class: update
    on_click:
      min_length: 1s
      max_length: 3s
      then:
        - switch.turn_on: reboot
    on_double_click:
      min_length: 50ms
      max_length: 350ms
      then:
        - switch.turn_on: fw_update

sensor:
  - platform: stream_server
    connection_count:
      name: Number of connections
  - platform: debug
    free:
      name: "Heap Free"
    psram:
      name: "Free PSRAM"
  - platform: wifi_signal
    name: WiFi Signal Sensor
    update_interval: 3600s

output:
  - platform: gpio
    pin: GPIO2
    inverted: true
    id: status

light:
  - platform: binary
    name: "Red"
    id: red
    output: status
    internal: True
    restore_mode: ALWAYS_OFF

switch:
  - platform: template
    name: FW Update
    id: fw_update
    turn_on_action:
      - switch.turn_on: zigbee_bsl
      - delay: 1s
      - switch.turn_on: zigbee_rst
      - delay: 1s
      - switch.turn_off: zigbee_rst
      - delay: 2s
      - switch.turn_off: zigbee_bsl
      - delay: 25s
      - switch.turn_off: fw_update
  - platform: restart
    name: "Restart"
    id: reboot
    internal: true

  - platform: gpio
    id: zigbee_rst
    pin: 15
    name: "Zigbee RST"
    inverted: True
    internal: True
    restore_mode: ALWAYS_OFF

  - platform: gpio
    id: zigbee_bsl
    pin: 22
    name: "Zigbee BSL"
    inverted: True
    internal: True
    restore_mode: ALWAYS_OFF
  • #25 21633766
    tepliukyurii
    Level 4  
    Posts: 3
    Rate: 1
    Hello everyone,

    I've been following this thread and noticed many of you are looking for a reliable way to connect the ZG-806z hub and the Sonoff Zigbee Bridge Pro to Home Assistant.

    First, I'd like to extend a special thanks to the users in this community who provided the module pinout for flashing. Your contribution was essential in making this project possible.

    Building on that community effort, I have forked the XZG firmware to add full support for these specific hubs. My custom firmware unlocks their full potential, transforming your hub into a fully-fledged Zigbee coordinator for Home Assistant. It offers a much more functional and seamless integration compared to the stock firmware or other workarounds.

    Crucially, the firmware provides full support for both zigbee2mqtt and ZHA, so you can choose the integration that best fits your setup.

    You can find the firmware, source code, and installation instructions on my GitHub repository:
    https://github.com/Zapadenec1982/XZG

    This solution is designed to be a significant upgrade. Feel free to check it out, and I'd be happy to answer any questions.

    Best regards!
    Attachments:
    • XZG_20250813.full.bin (2.91 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 identifying the TX and RX pins on an EWELINK Zigbee gateway featuring an ESP32 D0WD chip and an EWL-WBT04 module with a CC2652 Zigbee chip. The module has a 2x9 pin layout with known GND and 3.5V VCC pins, but locating UART TX/RX pins proved challenging. Users recommended tracing signal paths with a multimeter and verifying connections, noting that TX/RX pins must be correctly cross-connected (module RX to UART TX and vice versa). Bootloader mode requires grounding GPIO0, but access to this pin is often indirect, sometimes connected through PCB layers or buttons that may instead control reset (CHIP_PU). Successful flashing was achieved using Tasmota firmware specifically for Sonoff Zigbee Bridge Pro CC2652 devices, with guidance to toggle the firmware update switch and use appropriate flashing tools. ESPHome was also flashed successfully, enabling Zigbee integration with Z2M and ZHA, though proper Zigbee firmware upload is necessary for full functionality. The gateway hardware resembles the ZBBridge-P but lacks some features like I2C RTC and buzzer. PSRAM was enabled by pin tracing and configuring specific GPIOs. Users shared images and configuration snippets to assist with pin identification and firmware setup. Common issues included swapped RX/TX lines and USB adapter problems during flashing. The device is considered good value and suitable for Home Assistant integration after proper firmware flashing and configuration.
Generated by the language model.
Today's popular

FAQ

TL;DR: On the 2×9 EWL-WBT04 header, users identified ESP32 UART at 3.3 V, and one expert said, “treat it like ZBBridge-P.” This FAQ helps Home Assistant users find TX/RX, enter download mode, flash ESPHome, and pass the CC2652 to ZHA or Zigbee2MQTT over tcp://IP:8888. [#21454093]

Why it matters: This thread turns a poorly documented eWeLink gateway into a usable Zigbee coordinator workflow with concrete pin, baud, and flashing details.

Option Reported hardware basis Key difference Reported compatibility
eWeLink gateway ESP32 D0WD + CC2652 + EWL-WBT04 Some revisions need extra boot wiring Works with ESPHome, ZHA, Z2M
Sonoff ZBBridge-P Used as pinout reference Lacks exact same extras on this board CC2652 firmware/pin approach seen as similar
Newer eWeLink revision Same module family, different board behavior GPIO0→GND alone may fail; LED9→GND also needed Flashing succeeded after extra wiring

Key insight: TX/RX tracing solved only half the problem. Successful flashing depended on the exact board revision, especially how download mode was forced on the ESP32 and how the CC2652 BSL and reset lines were controlled. [#21621420]

Quick Facts

  • The EWL-WBT04 module was first described as a 2×9 header with two GND pins and two 3.5 V VCC pins, which gave users a starting map for continuity checks and UART probing. [#21395282]
  • A confirmed boot log was captured on the TX-labelled pin at 115200 baud, then switched to 921600 baud after the ROM boot stage, which is a strong clue when verifying a suspected UART TX line. [#21454456]
  • A working ESPHome setup exposed Zigbee over tcp://IP:8888 and mapped the ESP32 UART to GPIO23 RX and GPIO19 TX for Home Assistant integration. [#21487805]
  • PSRAM was reported working only after setting CONFIG_D0WD_PSRAM_CLK_IO="5" and CONFIG_D0WD_PSRAM_CS_IO="18", matching traced pins on this gateway. [#21454302]
  • On at least one newer board revision, ESP32 download mode required GPIO0→GND and LED9→GND in addition to RX↔TX, 3.3 V, and GND, showing that not all gateways boot the same way. [#21621420]

How can I identify the TX and RX pins on an EWELINK Zigbee gateway with an ESP32 D0WD and EWL-WBT04 module?

Identify them by tracing copper first, then confirm with UART behavior. One user succeeded after following signal paths on the board, and a later dump showed a valid ESP32 boot log on the TX-labelled pad. If you see readable boot text at 115200 baud, that pad is TX. Then connect your adapter TX to the remaining traced RX pad. The board in the thread used an ESP32 D0WD for Wi-Fi and a separate CC2652 for Zigbee, so trace only the ESP32-side UART you want to flash. [#21454456]

What is the safest way to trace GPIO0 on the EWL-WBT04 module when the signal disappears into another PCB layer?

Use a multimeter in continuity mode and test GPIO0 against the other 18 module pins. That was the explicit advice when the signal vanished into an inner PCB layer. Do not guess from button behavior alone. Measure continuity point-to-point until you find where the net emerges on an accessible pad or trace. This avoids shorting the wrong line and is safer than forcing random pads low during power-up. [#21398888]

Why do some pins on the EWELINK Zigbee gateway output garbled UART data like "?????" during boot instead of readable logs?

They usually are not the correct UART TX pin or the baud rate is wrong. Early probing in the thread produced garbled characters on some pads and no output on others. A later confirmed boot log showed the line starts at 115200 baud and then moves to 921600 baud. If your terminal stays at one speed, readable ROM text can turn into junk after the handoff. That makes mixed readable and unreadable output normal during boot verification. [#21454456]

What steps are required to put the ESP32 on the EWL-WBT04 module into download or bootloader mode for flashing?

Pull GPIO0 low before power-up and keep power, UART, and ground stable. Use this 3-step method: 1. Connect RX↔TX, TX↔RX, 3.3 V↔3.3 V, and GND↔GND. 2. Tie GPIO0 to GND before applying power. 3. Power the board from USB or the programmer and start flashing. One successful report also used any board ground, even the USB shell, as common ground. If that still fails, your board revision may need extra wiring. [#21583025]

Why does holding the front button during power-up fail to enter bootloader mode on some EWELINK Zigbee gateways?

Because the front button may not be wired to GPIO0. In one test, pressing the button pulled a pin from 3 V to 0 V, but the board still booted normally. Another contributor said that pin was most likely CHIP_PU, which resets the ESP32 instead of selecting download mode. So the button can restart the chip without forcing the ROM loader. That is why normal boot continues even while the button is held. [#21398888]

What is the CHIP_PU pin on an ESP32 board, and how is it different from GPIO0 during flashing?

CHIP_PU is the ESP32 enable/reset pin, and it is different from the boot-strap pin. "CHIP_PU" is a control pin that powers the ESP32 core on and off logically, acting like reset or enable rather than selecting the ROM flashing mode. In the thread, a pin dropping from 3 V to 0 V during button press was identified as CHIP_PU, not GPIO0. GPIO0 selects download mode at power-up; CHIP_PU just restarts the chip. [#21398888]

How do I flash ESPHome onto this EWELINK Zigbee gateway and expose the CC2652 over tcp://IP:8888 for Home Assistant?

Flash ESPHome to the ESP32, then run a stream server on port 8888. A working config in the thread used UART on GPIO23 RX and GPIO19 TX, stream_server on port 8888, and Home Assistant connected to tcp://{ip}:8888. Use this 3-step flow: 1. Flash the ESP32. 2. Load the ESPHome YAML with stream_server and UART enabled. 3. In Z2M or ZHA, point the coordinator connection to tcp://IP:8888. The same setup also enabled Bluetooth proxy on the ESP32 side. [#21487805]

Which UART pins and baud rates were reported for the EWELINK Zigbee gateway boot log, and how do I verify them on my board?

The reported ESPHome UART mapping was GPIO23 for RX and GPIO19 for TX, and the observed boot log appeared at 115200 baud before switching to 921600. Verify them by opening the suspected TX pad in a serial terminal, power-cycling the board, and checking for the ESP32 ROM banner. Then confirm the log contains the ESP-IDF boot text and partition table. A contributor also posted, “log from that TX labelled. 115200 then 921600,” which is the clearest verification pattern in the thread. [#21454456]

What is PSRAM on the ESP32, and why were CONFIG_D0WD_PSRAM_CLK_IO and CONFIG_D0WD_PSRAM_CS_IO needed on this gateway?

PSRAM is external pseudo-static RAM attached to the ESP32 for extra memory. On this gateway, it did not work until traced pins were declared explicitly as clock and chip-select. The working values were CONFIG_D0WD_PSRAM_CLK_IO="5" and CONFIG_D0WD_PSRAM_CS_IO="18". Without those settings, one user said the PSRAM chip had not been made to work. After pin tracing, the same user reported PSRAM working under ESPHome with those exact GPIO assignments. [#21454302]

How does this EWELINK Zigbee gateway compare with the Sonoff ZBBridge-P for pinout, features, and firmware compatibility?

It was treated as very close to a Sonoff ZBBridge-P for pinout and firmware approach. One contributor said to “treat it like ZBBridge-P” but noted missing features such as I2C RTC and buzzer on this eWeLink board. The same post also mentioned a PSRAM chip that needed extra work. Later reports confirmed successful flashing and use with Z2M and ZHA, so practical firmware compatibility looked similar even if the peripherals were not identical. [#21454093]

What firmware should be flashed to the CC2652 Zigbee chip in this gateway so it works with ZHA or Zigbee2MQTT?

Use the Sonoff Zigbee Bridge Pro CC2652 firmware mentioned in the thread, not a generic CC2652 image. A successful setup specifically pointed to the Tasmota Sonoff Zigbee Bridge Pro CC2652 firmware set and warned to flash only those files. The same user paired it with a ZigStar flashing tool and guide, then told others to toggle the FW Update switch first. Later replies confirmed ZHA started working after loading that Zigbee firmware. [#21558442]

How do ZHA and Zigbee2MQTT differ when using this flashed EWELINK Zigbee gateway as a coordinator in Home Assistant?

In this thread, both worked with the flashed gateway, so the main difference was software stack, not hardware support. One user first tested the tcp://IP:8888 bridge with Zigbee2MQTT and later confirmed it also worked with ZHA. Another user reported running the device with both Z2M and ZHA after changing firmware. So the gateway was validated with both Home Assistant integrations once the ESP32 bridge and CC2652 coordinator firmware were in place. [#21487805]

What does BSL mean in the CC2652 flashing process, and how do the zigbee_bsl and zigbee_rst GPIO controls work in ESPHome?

BSL is the bootloader control path used to place the CC2652 into firmware update mode. "BSL" is a bootloader-entry control signal that forces the Zigbee MCU into a firmware-loading state, usually paired with a reset pulse so a host can replace coordinator firmware. In the shared ESPHome config, zigbee_bsl used GPIO22 and zigbee_rst used GPIO15. The FW Update action turned BSL on, pulsed reset, released reset, then later released BSL after a timed sequence. [#21487805]

Why might flashing fail even when RX, TX, GPIO0, 3.3V, and GND seem to be connected correctly on the EWL-WBT04 module?

Flashing can fail because the USB-UART adapter is bad, the lines are swapped, or the board does not output logs on that UART. One user could not flash with correct-looking wiring and later solved it by changing the USB adapter. Another contributor warned not to expect logging on those pins, because they were used for flashing rather than continuous console output. That means “no data” does not prove the pad map is wrong. [#21583302]

What extra wiring is needed on newer EWELINK Zigbee gateway board revisions where GPIO0 to GND alone does not start ESP32 download mode?

On at least one newer revision, you must ground LED9 as well as GPIO0. The successful wiring was RX↔TX, TX↔RX, 3.3 V↔3.3 V, GND↔GND, plus GPIO0→GND and LED9→GND before connecting the programmer to the computer. That user said GPIO0 alone did not launch download mode on their board. This is the clearest revision-specific fix in the thread and explains why older instructions can fail on newer hardware. [#21621420]
Generated by the language model.
ADVERTISEMENT