How to Build a Thread Border Router with a W5500 Wired Backbone Using Espressif's esp-thread-br SDK

Overview

Thread is a low-power wireless mesh network (802.15.4) for IoT devices, and the device that links this mesh to a home or building's regular IP network (Wi-Fi/Ethernet) is a Thread Border Router (BR). This project is Espressif's open-source Thread Border Router SDK, implementing a BR by layering the OpenThread stack on an ESP32-S3 (main SoC) + ESP32-H2 (802.15.4 RCP) structure.

A BR's performance hinges on the stability of its backbone (upstream network) connection. This SDK supports both Wi-Fi and Ethernet as the backbone, and if you choose the Ethernet backbone, it can be configured with WIZnet W5500 SPI Ethernet. In other words, the SDK is structured to leave the door open for building a Thread BR with a W5500 wired backbone.

(Confirmed facts and scope: the basic example's sdkconfig.defaults contains CONFIG_EXAMPLE_USE_W5500=y, and enabling the Ethernet backbone runs on the W5500. However, the W5500 Ethernet initialization code itself comes not from this repository but from an ESP-IDF common component (protocol_examples_common). The default build backbone is Wi-Fi, and W5500 Ethernet is an optional configuration.)

Key Features

• Can be configured with a W5500 wired backbone: Choosing the Ethernet backbone uses the W5500 as the default SPI Ethernet chip (CONFIG_EXAMPLE_USE_W5500=y). Opting for a wired backbone instead of Wi-Fi frees you from wireless interference and congestion, and the W5500 handles that wired path.
• Avoids Wi-Fi/Thread antenna interference: Handling Wi-Fi and Thread on a single chip simultaneously can cause 2.4 GHz-band interference (the docs don't recommend it either). Moving the backbone to wired Ethernet (W5500) avoids this wireless self-interference, improving BR stability in RF environments.
• The wired axis of bidirectional IPv6 connectivity: A BR's core function is bidirectional IPv6 connectivity between the backbone link and the Thread mesh. With an Ethernet backbone, the W5500 handles the physical layer (MAC/PHY) of this wired link. The point to note: IPv6 processing is done not by the W5500 but by the ESP32's software stack (lwIP). The W5500 carries Ethernet frames as-is in MACRAW mode, while upper layers like IPv4/IPv6 are handled by the ESP32. This lets functions like mDNS service discovery, multicast forwarding, and NAT64 operate reliably over the wire.
• Clear default SPI configuration: For the Ethernet configuration, the SPI pins (SCLK 21 / MOSI 45 / MISO 38 / CS 41 / INT 39 / RST 40) and a 36 MHz clock are provided as defaults — a wiring reference for reproducing an ESP32 + W5500 Ethernet BR.
• A polished BR stack: An SDK with a web GUI (network formation, status, topology), RCP auto-update, credential sharing, TREL, NAT64, and RF coexistence. The W5500 integrates as the wired interface when this stack is configured with an Ethernet backbone.

System Architecture

The W5500's role in the data path: When configured with an Ethernet backbone, the W5500 becomes the backbone gateway linking the Thread mesh to the upstream IP network. Note, though, that the W5500 only plays the MAC/PHY role of carrying Ethernet frames in MACRAW mode; upper-layer processing like IPv4/IPv6 is handled by the ESP32-S3's software stack (lwIP). Traffic the ESP32-S3 processes via OpenThread goes out to the wired IP network through the W5500 Ethernet, and the reverse path applies when a network device reaches the Thread mesh. (The default build uses a Wi-Fi backbone; the wired backbone is an optional configuration.)

Role and Application of the WIZnet Chip

• Chip used: WIZnet W5500 (the default SPI Ethernet chip when the Ethernet backbone is selected)
• Connection: Wired to the ESP32-S3 via SPI (SPI Host 2, SCLK 21 / MOSI 45 / MISO 38 / CS 41 / INT 39 / RST 40, 36 MHz). Integrated via ESP-IDF's esp_eth (SPI Ethernet) driver.
• Its role: When the Ethernet backbone is selected, the wired backbone connection between the Thread mesh and the upstream IP network.
• Why wired Ethernet (W5500) instead of Wi-Fi:
  • Interference avoidance: A BR risks interference because 802.15.4 (2.4 GHz) and Wi-Fi (2.4 GHz) share the band. Moving the backbone to wired avoids this self-interference.
  • Stability: For an always-on BR, wired has fewer dropouts and less latency than wireless, raising the reliability of the whole mesh's external connection.
• What weakens without the W5500 (i.e., without a wired backbone): Depending on Wi-Fi alone for the backbone drops the reliability of the BR's upstream connection through interference and congestion where Thread and Wi-Fi contend for the same 2.4 GHz.

How the W5500 Is Used (note)

• Integration: Uses the W5500 as an SPI Ethernet MAC/PHY through ESP-IDF's esp_eth + lwIP stack.
• Division of labor: The W5500 carries Ethernet frames in MACRAW mode; TCP/IP and IPv6 processing is done by the software stack (lwIP).
• Why not the hardware stack: The W5500's built-in hardware TCP/IP is IPv4-only, so this IPv6-requiring configuration uses the MACRAW + software-stack approach.
• Source of the init code: W5500 Ethernet initialization comes not from this repository but from an ESP-IDF common component.

Relationship to Matter (Accurate Scope)

Thread is one of Matter's transport layers. Accordingly, a Thread Border Router can be an infrastructure element for building a "Matter-over-Thread" environment — because connecting Matter-over-Thread devices to an IP network requires a Thread BR.

But there's a clear distinction to make. This repository itself does not include a Matter stack or implement Matter. (There is no Matter/connectedhomeip implementation in the source.) This SDK is a pure Thread Border Router; using Matter requires a separate Matter controller/stack alongside it. In other words, this BR can be a component of Matter-over-Thread — it is not, by itself, a Matter-supporting product.

Related Existing Contents

Compared here with cases whose content we verified directly on WIZnet Makers.

HomeThread: Embedded Thread Border Router with Ethernet Backhaul (josephsr)

 A Thread border router built from ESP32-S3 + ESP32-H2 radio + W5500 wired backhaul, topped with a web dashboard.

• Similarities: The ESP32-S3 + ESP32-H2 (RCP) + W5500 wired backbone makeup is essentially identical to the Ethernet BR you can build with this SDK. The goal of "backhauling the Thread mesh over wired Ethernet" is the same too.
• Differences: HomeThread is a project where an individual developer intentionally adopted the W5500 and built the dashboard and registration backend themselves. esp-thread-br is an SDK that leaves the door open to configuring such an Ethernet BR, with W5500 initialization relying on an ESP-IDF common component. It's the difference between "direct implementation" and "configurable via SDK."

Wired Thread Border Router: W5500 Ethernet Backhaul for Matter (Benjamin)

An ESPHome-based project that makes the backhaul of a Matter/Thread smart home wired with ESP32-S3 + W5500.

• Similarities: The core idea of "making the Thread BR's backbone W5500 wired rather than Wi-Fi" is the same, as is the "Wi-Fi is unreliable → wired" logic.
• Differences: Benjamin is a concise ESPHome-based individual implementation; esp-thread-br is a full OpenThread-stack SDK. They differ greatly in feature scope and completeness.

In short, the approach of "building a Thread BR's wired backbone with ESP32 + W5500" has several real implementations on Makers. The significance of this SDK is that it's an open-source foundation that leaves such a W5500 wired-backbone BR open for anyone to configure.

Market & Application Value

• Smart-home Thread gateway (B2C): An always-on gateway that reliably connects Thread devices over a wired backbone. (Can also serve as a component of a Matter-over-Thread environment.)
• Commercial/building IoT (B2B): Integrate many Thread sensors/actuators into a building's wired network. A wired backbone underpins the reliability of a large mesh.
• Industrial IoT gateway: Secure the Thread mesh's upstream connection over wired in environments with heavy wireless interference.
• Development/prototyping reference (system integration): An open-source starting point for quickly configuring a W5500 wired-backbone BR. Commercial BR boards like M5Stack's also run on this SDK.
• Why it's advantageous in real installations: A BR runs continuously once installed. A wired backbone (W5500) is free of reboots, interference, and congestion, so post-install maintenance burden is low.

WIZnet Strategic Value

• A wired-backbone option within the vast ESP32 ecosystem: An enormous base of ESP32/ESP-IDF developers builds Thread BRs with this SDK. Since the default SPI chip for the Ethernet backbone is the W5500, it's naturally surfaced to developers building wired BRs on ESP32.
• A touchpoint with the growing Thread/Matter ecosystem: Thread is a core transport layer for Matter. That the W5500 is used when configuring that BR with a wired backbone shows WIZnet's point of use in the expanding Matter-over-Thread environment.
• Demonstrating the value of a wired backbone: It backs the logic that "the more a device is a wireless gateway, the more its backbone benefits from wired" — as an actually configurable option.
• Reference-design potential: With SPI pins and clock provided, this configuration serves as a reference template for designing and prototyping a W5500-based Thread BR.
• Caution (guarding against overstatement): This SDK can support SPI Ethernet chips and internal EMAC other than the W5500. The W5500 is "the default option when the Ethernet backbone is selected," and the project is not designed exclusively for WIZnet. Recognizing this clearly aids accurate evaluation.

FAQ

Q. What is a Thread Border Router? Thread is a low-power wireless mesh network for IoT. A Thread Border Router (BR) connects this mesh to a home or building's regular IP network (Wi-Fi/Ethernet), letting Thread devices communicate with the Internet or other devices.

Q. Can I build a W5500 wired-backbone BR with this SDK? Yes. Configuring the backbone as Ethernet uses the W5500 as the default SPI Ethernet chip. That said, the default build is a Wi-Fi backbone, and W5500 Ethernet is an optional configuration. Also, the W5500 init code comes not from this repository but from an ESP-IDF common component.

Q. Does using this BR mean Matter is supported? This repository itself doesn't implement Matter. But since Thread is one of Matter's transport layers, this Thread BR can be an infrastructure element for a Matter-over-Thread environment. Actually using Matter requires a separate Matter stack/controller alongside it.

Q. Why wired Ethernet instead of Wi-Fi? Thread (802.15.4) and Wi-Fi use the same 2.4 GHz band, risking interference. Moving the backbone to wired (W5500) avoids this self-interference and raises the connection reliability of an always-on BR. Of course, this SDK also supports a Wi-Fi backbone.

Q. Does it use the W5500's hardware TCP/IP? This configuration uses the W5500 as an SPI Ethernet MAC/PHY via ESP-IDF's esp_eth and the lwIP software stack. The W5500 chip itself embeds hardware TCP/IP, but in this SDK configuration the software stack handles TCP/IP.

Q. I heard the W5500 is IPv4-only — doesn't this BR use IPv6? Correct, the W5500's hardware TCP/IP stack is IPv4-only. But this project doesn't use that hardware stack — it uses the W5500 in MACRAW mode (plain Ethernet frame TX/RX). IPv6 processing is handled by the ESP32's software stack (lwIP), so an IPv6 backbone works fine over the W5500. That is, the W5500 carries frames while the ESP32 does the IPv6 computation.

Limitations / Notes

• The W5500 is "the default SPI chip when the Ethernet backbone is selected." This SDK is not designed exclusively for WIZnet, and the default build backbone is Wi-Fi.
• Source of the W5500 init code: This repository uses the Ethernet connection via an example_ethernet_connect() call; the actual W5500 initialization implementation lives in an ESP-IDF common component (protocol_examples_common). In other words, this repository did not implement the W5500 driver itself.
• No Matter included: There is no Matter stack/implementation in this repository. A Thread BR can be a component of Matter-over-Thread, but does not by itself support Matter.
• No hardware TCP/IP (TOE) usage: With the esp_eth + lwIP approach, the W5500 is used as an SPI Ethernet MAC/PHY and TCP/IP is handled by software. It is not a configuration that uses the hardware socket directly.
• Other Ethernet chips possible: ESP-IDF supports SPI Ethernet and internal EMAC other than the W5500. Depending on the hardware, a different chip can be used.
• This article introduces Espressif's open-source SDK; it describes a development SDK/reference, not a specific commercial product.

Source / Reference Links

• GitHub: espressif/esp-thread-br
• WIZnet W5500: https://docs.wiznet.io/Product/Chip/Ethernet/W5500

Related Projects on WIZnet Makers

• HomeThread: Embedded Thread Border Router with Ethernet Backhaul (josephsr)
• Wired Thread Border Router: W5500 Ethernet Backhaul for Matter (Benjamin)