What Does ESPHome Support for W6100 and W6300 Ethernet Add on RP2040 and RP2350?
Native ethernet: config for WIZnet W6100 SPI and W6300 PIO QSPI on RP2040/RP2350, merged by Home Assistant developer bdraco and shipped in ESPHome 2026.4.0.

WIZnet - W6300
New ESPHome ethernet type since 2026.4.0, driven over PIO QSPI with fixed pins on the RP2350-based W6300-EVB-Pico2; runs in MACRAW mode under the arduino-pico lwIP stack.

WIZnet - W6100
New ESPHome ethernet type since 2026.4.0, driven over remappable 4-wire SPI on the RP2040-based W6100-EVB-Pico; runs in MACRAW mode under the arduino-pico lwIP stack.
W6100 and W6300 Become Native ESPHome Ethernet Types
J. Nick Koston, known on GitHub as bdraco, is a Home Assistant core developer based in Houston, Texas, with 517 public repositories and 2,087 followers as of 2026-08-28. On 2026-04-07 he opened pull request #15543 against the ESPHome firmware project, and it was merged the next day: the WIZnet W6100 and W6300 became configurable ethernet types on Raspberry Pi RP2040 and RP2350 boards, with no custom component and no external driver work.
The two chips and their documented target boards. Board image: WIZnet documentation. Generated infographic.
The PR describes its own scope in one sentence: "Add support for WIZnet W6100 and W6300 SPI Ethernet chips on RP2040 platforms. These chips are used on boards like the W6300-EVB-Pico2 and W6100-EVB-Pico." The change is small, 98 lines added and 4 removed across 8 files, and it carries its own tests. The matching documentation change, esphome-docs PR #6411, merged within the same minute. Users received the feature in ESPHome 2026.4.0, released on 2026-04-15, whose changelog lists "[ethernet] Add W6100 and W6300 support for RP2040 esphome#15543 by @bdraco (new-feature)".
The merged PR. Its description names both upstream arduino-pico issues, the needsSPI() bug it works around and the GPIO 0 logging quirk it documents. Screenshot: github.com.
Why an ESPHome Entry Matters for an Ethernet Chip
ESPHome is the framework behind a large share of DIY smart home devices: a user writes a short YAML file, ESPHome compiles it into firmware, and the resulting device talks to Home Assistant over the network. The esphome/esphome repository counts 11,611 stars and 5,583 forks as of 2026-08-28. When a chip gets a native ethernet: type there, every builder in that ecosystem can use it without writing a line of C.
Wired ethernet had long been an ESP32 story in ESPHome, with RMII PHYs and SPI chips like the W5500. The Raspberry Pi RP2040 and RP2350 port had a shorter list, and PR #15543 extends it to five entries, defined in esphome/components/ethernet/__init__.py (line 199 on the dev branch, checked 2026-08-28). The official ethernet component documentation now describes the RP2 family lineup as follows:
| Type | Bus | Platforms (per ESPHome docs) | Documented board |
|---|---|---|---|
| W5100 | SPI | RP2040 only | W5100S-EVB-Pico |
| W5500 | SPI | ESP32 and RP2040 | W5500-EVB-Pico |
| W6100 | SPI | RP2040/RP2350 only | W6100-EVB-Pico |
| W6300 | PIO QSPI | RP2040/RP2350 only | W6300-EVB-Pico2 |
| ENC28J60 | SPI, 10 Mbps | ESP32 and RP2040 | none named |
The two new entries are also the two newest chips on the list. The PR states: "The W6100 and W6300 are next-generation WIZnet Ethernet controllers with IPv6 support."
A Chip Type and Six Pin Numbers per Board
Configuration is a chip type plus six pin numbers. The PR's own example for the W6300 targets the W6300-EVB-Pico2, which pairs the chip with an RP2350:
ethernet:
type: W6300
clk_pin: 17
mosi_pin: 18
miso_pin: 19
cs_pin: 16
interrupt_pin: 15
reset_pin: 22
The board mapping deserves precision, because the two examples sit on different MCU generations. The documented W6100 target is the W6100-EVB-Pico, an RP2040 board configured with clk 18, mosi 19, miso 16, cs 17, interrupt 21, and reset 20, while the documented W6300 target is the W6300-EVB-Pico2, an RP2350 board with the ESPHome board id wiznet_6300_evb_pico2. The docs list both chips as "RP2040/RP2350 only" types, so the platform gate is the RP2 family, not one specific MCU.
The official ethernet component documentation, checked 2026-08-28. The note under the example spells out the fixed QSPI pinout and the serial logging caveat. Screenshot: esphome.io.
The pin semantics differ between the chips. The W6100 hangs off a normal 4-wire SPI bus, and its pins are remapped through the Arduino SPI object at setup. The W6300 pins are quad SPI lines driven by PIO state machines, and the documentation warns that the YAML values "must be set to the board's fixed QSPI pinout", so the six pin numbers describe the board rather than choose a wiring.
Pin sets from PR #15543 and the ESPHome documentation. Board images: WIZnet documentation. Generated infographic.
MACRAW Frames Under lwIP: What the Integration Actually Does
PR #15543 adds no chip driver of its own. The description says so directly: "The arduino-pico framework already includes lwIP_w6100 and lwIP_w6300 libraries, so this adds the ESPHome configuration and code generation plumbing to use them." The Python side maps the new types to those libraries in __init__.py (chip entries at lines 138-139, library selection at lines 204-205 on dev, checked 2026-08-28), and the C++ side instantiates the right lwIP device class at setup.
The arduino-pico drivers descend from Nicholas Humfrey's W5100MacRaw code, and the lineage defines the architecture. The driver opens socket 0 of the chip in MACRAW mode, meaning the W6100 or W6300 passes raw Ethernet frames up to the lwIP TCP/IP stack running on the RP2040 or RP2350. The chips therefore serve as MAC plus PHY in this integration, and their on-chip hardwired TCP/IP engine stays idle. The C++ setup path, in the file now named ethernet_component_rp2.cpp, instantiates Wiznet6100lwIP for one chip and Wiznet6300lwIPFixed for the other, then hands both the same lwIP glue.
How a YAML file becomes packets on the wire. Generated technical diagram.
The W6300 QSPI Path and the Wiznet6300NoSPI Workaround
The W6300 part of the PR is where the engineering lives. The upstream arduino-pico Wiznet6300 class reports needsSPI() as true, which makes the generic LwipIntfDev::begin() call SPI.begin() and claim the very GPIOs the PIO QSPI machinery needs. The ESPHome fix is a thin wrapper, still present in esphome/components/ethernet/ethernet_component.h on the dev branch:
// esphome/components/ethernet/ethernet_component.h
class Wiznet6300NoSPI : public Wiznet6300 {
public:
using Wiznet6300::Wiznet6300;
constexpr bool needsSPI() const { return false; }
};
using Wiznet6300lwIPFixed = LwipIntfDev<Wiznet6300NoSPI>;
A second upstream quirk is documented rather than fixed. The arduino-pico QSPI setup routine calls gpio_init() on an irq_pin field that defaults to 0, which resets GPIO 0, the UART TX pin, and silences serial logging after network startup. The official documentation is explicit that this is cosmetic: "Device operation and OTA are unaffected."
Both issues still exist upstream. A check of arduino-pico master on 2026-08-28 shows needsSPI() returning true in libraries/lwIP_w6300/src/utility/w6300.h and the gpio_init(irq_pin) call still in wiznet_pio_qspi.c, so the ESPHome-side workaround continues to earn its place.
The Upstream Chain Behind the YAML Convenience
The convenience of a short ethernet: block rests on work that happened in other repositories first. WIZnet's Mason, committing as GitHub user wiznet-mason from a wiznet.io address, added the W6300-EVB-Pico and W6300-EVB-Pico2 board definitions to arduino-pico in PR #2999, merged on 2025-06-19. The lwIP_w6300 driver library itself credits Stefan Nuernberger as author, building on the MacRaw lineage, and arduino-pico maintainer Earle Philhower documented W55RP20, W6100, and W6300 support in PR #3446, merged on 2026-06-04.
PR #15543 is the final link that connects that chain to smart home builders. A chip vendor's board support, a community driver, and a framework's code generation each did one job, and the result is that a W6300-EVB-Pico2 can join a Home Assistant network with a config file a beginner can read.
Where It Fits and What Remains Open
For builders, the practical value is wired networking on cheap RP2 silicon inside the most popular DIY smart home stack. Ethernet keeps latency and availability steady where Wi-Fi contends with congested spectrum, which is why ESPHome's wired user base grew on the W5500 in the first place; the W6100 and W6300 bring newer, IPv6-capable silicon to the same workflow.
Some limits are worth stating plainly. The MACRAW-plus-lwIP design means the chips' hardwired TCP/IP offload is not exercised here, and ESPHome's own IPv6 story on RP2 remains separate from what the silicon could do. The feature merged on 2026-04-08, so it is an established capability rather than news, and the W6300 serial logging quirk persists until arduino-pico fixes its QSPI pin initialization. No real photos of the setup exist in the PR; the hardware images in this article come from WIZnet documentation.
Related WIZnet Maker Projects
ESPHome 2026.4.0 - April 2026 covers the same release from the release-notes side, centered on W5500 improvements. The post never mentions the W6100 or W6300, which is exactly the gap this article fills: the PR-level detail of the two new chip types.
W6300-EVB-Pico2 added to Zephyr documents the same board entering a different ecosystem, the Zephyr RTOS. Zephyr targets industrial firmware developers where ESPHome targets home automation builders, so the two posts together show the board's reach across audiences.
Espressif Adds Official W6100 Ethernet Driver Support to ESP-IDF is the W6100's parallel milestone on ESP32. The ESP-IDF driver uses the chip differently than the MACRAW path described here, which makes the pair a useful comparison of integration styles.
How Does an ESPHome W5500 PoE Door Lock Use TOTP and MQTT Face Recognition? shows what people actually build on ESPHome's wired ethernet support. Projects like that door lock are the downstream audience for the W6100 and W6300 types added in PR #15543.
FAQ
Q. Which ESPHome release first supports the W6100 and W6300? ESPHome 2026.4.0, released on 2026-04-15. The support was merged in pull request #15543 on 2026-04-08 and appears in the changelog as a new feature by @bdraco.
Q. Do the W6100 and W6300 use their hardwired TCP/IP engine under ESPHome? No. The arduino-pico drivers open the chip in MACRAW mode and run the lwIP TCP/IP stack on the RP2040 or RP2350, so the chips act as MAC and PHY in this integration.
Q. Can I remap the W6300 pins in the YAML config? No. The W6300 is driven over PIO QSPI with a pinout fixed by the board, and the ESPHome documentation states the pin fields must match the board's QSPI wiring. The W6100, by contrast, uses normal remappable SPI pins.
Q. Why does serial logging stop after the W6300 comes up? An upstream arduino-pico routine initializes an unset interrupt pin field that defaults to 0, resetting GPIO 0, the UART TX pin. Per the ESPHome documentation, "Device operation and OTA are unaffected", and the bug was still present upstream on 2026-08-28.
Q. Which boards does ESPHome document for these chips? The W6100-EVB-Pico, an RP2040 board, for the W6100, and the W6300-EVB-Pico2, an RP2350 board, for the W6300. Other RP2-family boards wired to the same chips would use the same chip types with their own pin values.
-
ESPHome PR #15543
The merged pull request adding W6100 and W6300 support, with example YAML and the PIO QSPI workaround notes
-
ESPHome 2026.4.0 changelog
The release that shipped the feature on 2026-04-15
-
ESPHome ethernet component documentation
Official docs listing W6100 (SPI) and W6300 (PIO QSPI) as RP2040/RP2350 types, with board examples
-
arduino-pico lwIP_w6300 driver library
The upstream MACRAW driver ESPHome builds on for the W6300
-
WIZnet W6300-EVB-Pico2 documentation
The RP2350 board used in the PR's W6300 example
-
WIZnet W6100-EVB-Pico documentation
The RP2040 board used in the PR's W6100 example
