Olimex's €4.95 CH390 Board Puts a Wired Ethernet Port on a Pico or an ESP32, but ESPHome Only Drives It on the ESP32
The design files sit on GitHub under an open hardware license with the maker's own examples, and ESPHome's docs hold a catch for anyone whose spare board is a Pico.

Wi-Fi is the part of a sensor project that quits working after the soldering is done. The Olimex UEXT-CH390 is the cable-shaped answer: a small board with an Ethernet controller on it, sold for €4.95 for a single unit, excluding VAT.
The chip is a CH390, which Olimex’s page calls a “SPI to Ethernet 100MB controller.” It talks to a microcontroller over SPI and presents a regular wired port on the other side. The board carries UEXT and pUEXT connectors, so a host with a matching socket plugs straight in. It measures 50 by 21 mm, about the size of a stick of gum if you cut the gum short.
Olimex says the board is “supported natively by Arduino and ESPHome/Homeassistant” and lists it for the Raspberry Pi Pico, the Pico 2 and ESP32 modules with no wired Ethernet, “like ESP32-S3, ESP32-C3, ESP32-C5, ESP32-C6.” The product page links two software examples, a Raspberry Pi PICO SDK one and an ESPHome Home Assistant one. One is for a Pico running its own code, the other for a board reporting to Home Assistant through ESPHome.
Volume pricing is on the page too, €4.70 each for 10 to 49 and €4.46 each for 50 and up. At those numbers a wired network port costs less than a sandwich. A sandwich, to be fair, does not come with schematics.
This one does. The GitHub repository holds a hardware folder, a software folder and documents, and the README says the “Hardware is released under CERN Open Hardware Licence Version 2 - Strongly Reciprocal,” with the software under MIT and the documentation under CC BY-SA 3.0. The README adds that the silkscreen credits to Bernardo Kastrup and Dean Belfield “should remain.” The product page also offers the Rev. A schematic as a PDF and the KiCad source, so a person can redraw it, respin it or just check it.
The catch is in the software support. ESPHome’s own Ethernet docs list the chip as “CH390 (SPI, ESP32 only).” They also note that “The WCH CH390 shares the Davicom DM9051 register map but reports its own vendor and product IDs,” so choosing the DM9051 type in the config fails at start-up, and the docs say to use CH390 instead. The same page marks the CH390 as unsupported on the RP2040, the Pico’s chip, and names W5500 and ENC28J60 among the SPI chips it does drive there.
So the product page advertises Pico, ESP32 and ESPHome together, and ESPHome’s docs hold the ESP32 half of that. A Pico owner reading the Olimex page gets the SDK example. A Pico owner who wanted the ESPHome route may be out of luck, going by those docs. Whether Olimex’s ESPHome example runs on something other than an ESP32 is not something either page spells out.
The ESPHome config for the ESP32 side is short: a type, a clock pin, MOSI and MISO pins, a chip-select pin and an interrupt pin. That is five pins’ worth of decisions and then a cable.
What this points at is a quiet shift in how cheap network gear gets added: a coin-sized controller on a standard connector, plus open schematics, undercutting the idea that wired networking is a premium feature. Small makers will likely keep copying the formula, a cheap SPI chip with one working example per platform, and the soft spot will be the same each time, the gap between what a product page lists and what a software project actually drives.
Some projects just need a leash.