Wiznet makers

요약

SlimmeLezer Pro는 네덜란드 스마트 계량기의 P1 포트에 연결해 실시간 에너지 데이터를 Home Assistant로 보내는 ESPHome 기반 리더입니다. ESP32-C3로 세대를 교체하면서 WIZnet W5500을 SPI로 붙여 유선 이더넷을 확보했습니다. 내장 이더넷 MAC이 없는 최신 RISC-V MCU에 유선을 되돌려주는 방법을 보여준다는 점에서 주목할 만합니다.

개요

네덜란드·벨기에의 스마트 계량기는 P1 포트로 소비 데이터를 주기적으로 내보냅니다. 이를 읽어 홈오토메이션 플랫폼에 넣어주는 장치가 P1 리더이며, SlimmeLezer는 그중 가장 널리 쓰이는 오픈 펌웨어 계열입니다.

문제는 설치 위치입니다. 계량기는 금속·콘크리트로 둘러싸인 배전반 안에 있고, Wi-Fi에 가장 불리한 환경입니다. 제작자 Marcel Zuidwijk는 유선 모델(WT32-ETH01 + LAN8720 RMII)도 내놓았지만 구형 ESP32 기반이라 핀 소모와 크기 부담이 컸습니다. SlimmeLezer Pro는 이 분기를 합쳐 26.25 × 61.75mm 보드에 Wi-Fi와 이더넷, P1 OUT까지 담았습니다.

제품 페이지: https://www.zuidwijk.com/product/slimmelezer-pro/

도입 배경 / 왜 필요한가

저장소 도입 사례 — 확인됨

• 케이스·RJ12 케이블을 동봉해 판매되는 상용 제품입니다(€34.95, VAT 별도)
• 저장소 zuidwijk/dsmr는 Star 223 / Fork 77을 기록하며, DSMR 컴포넌트는 ESPHome 2021.8.0부터 본체에 정식 편입되었습니다
• 다만 기업·기관 도입 레퍼런스는 확인 불가입니다

저장소: https://github.com/zuidwijk/dsmr

산업적·규제적 필요성 — 확인됨

• 네덜란드 **Energiewet(에너지법)**이 2026년 1월 1일 시행되어 아날로그 계량기의 디지털·스마트 계량기 교체를 의무화했습니다. 감독 기관은 RDI입니다
• P1 규격은 Netbeheer Nederland의 DSMR P1 Companion Standard가 정의하며, 현행 v5.0.2, 차세대 v6.0.0 X1은 2025년 12월 17일 발행되었습니다
• EU Directive 2019/944가 소비자의 근실시간 소비 데이터 접근권을 요구합니다

즉 P1 리더의 대상 모수 자체가 규제로 확대되는 국면입니다. 두 결론은 그대로 병기합니다.

RDI 근거: https://www.rdi.nl/onderwerpen/consumenten/wettelijke-plicht-slimme-of-digitale-meter

산업 트렌드 통찰

• Espressif: ESP32-S31(2026년 4월 공개, 7월 27일 양산) — Gigabit Ethernet MAC 내장, industrial automation 타깃 명시
• Raspberry Pi: FY2025 매출 $323.5M(+25%), 반도체 출하 840만 개로 보드 물량 첫 추월, "두 개의 프랜차이즈" 전략 공식화
• Arduino: 2025년 10월 7일 Qualcomm이 인수

주목할 점은 순서입니다. 본 제품 공개는 2026년 6월 9일로 ESP32-S31 양산보다 앞섰고, 같은 기간 WIZnet Makers에도 P1/DSMR × W5500 프로젝트가 석 달에 다섯 건 등장했습니다. 유선화 요구는 제조사 로드맵보다 커뮤니티에서 먼저 움직였습니다.

Espressif 근거: https://www.espressif.com/en/news/ESP32_S31_Mass_Production Raspberry Pi 근거: https://www.theregister.com/2026/03/31/raspberry_pi_fy_2025/

아키텍처

핵심은 네트워크 경로가 부팅 시 하나로 결정된다는 점입니다. Wi-Fi와 이더넷은 동시에 사용할 수 없으며, 제품 페이지는 이를 ESPHome의 제약으로 설명합니다.

기술 배경

DSMR과 P1 포트

**DSMR(Dutch Smart Meter Requirements)**은 네덜란드 계량기 요구사항 규격이며, P1은 소비자가 자기 데이터를 읽어가도록 열어둔 단방향 출력 포트입니다.

계량기는 OBIS 코드로 구성된 텍스트 블록(telegram)을 DSMR 5는 1초, DSMR 4 이하는 10초 간격으로 밀어냅니다. 전송은 115200bps 8N1이되 신호가 반전되어 있고 끝에 CRC 체크섬이 붙습니다(DSMR 2.x는 예외).

규격이 이 제품의 설정에 그대로 드러납니다. UART 수신이 **rx_pin: 20, inverted: true**인 이유가 신호 반전이고, DSMR 5는 P1 기생전원만으로 동작하지만 DSMR 4 이하는 USB-C 급전이 필요한 이유가 세대별 급전 차이입니다. DSMR 5가 정한 P1 공급 한도는 250mA입니다.

DSMR 규격: https://www.netbeheernederland.nl/sites/default/files/2024-02/dsmr_5.0.2_p1_companion_standard.pdf

ESPHome과 Home Assistant Native API

ESPHome은 YAML 선언만으로 펌웨어를 생성하고 OTA 배포까지 자동화하는 프레임워크입니다.

핵심은 Native API입니다. 장치는 Home Assistant와 TCP 6053 상시 세션을 유지하고 값이 바뀔 때마다 push로 밀어 올립니다. 폴링이 아닌 상시 연결이므로 빠른 대신, 세션이 끊기면 그 장치를 트리거로 쓰는 자동화가 함께 멈춥니다. 1초마다 갱신되는 전력 데이터로 부하를 제어한다면 링크 품질이 곧 제어 품질입니다.

ESPHome 이더넷 문서: https://esphome.io/components/ethernet/

기술 특징

• 세대 통합: 별개 제품이던 Wi-Fi 모델과 유선 모델을 하나의 보드에 담았습니다
• 표준 경로 채택: W5500은 ESPHome 이더넷 컴포넌트가 공식 지원하므로 YAML 몇 줄로 유선이 활성화됩니다
• 확장성: P1 OUT pass-through로 계량기 물리 포트가 하나뿐이라는 제약을 풀었습니다(5V 공급은 USB 급전 시에만)
• 유지보수: 국가·세대별 YAML 분기와 OTA로 현장 방문 없이 갱신됩니다

W5500이 들어가는 자리 — EMAC 없는 MCU에 유선을 되돌려주다

유선 이더넷은 WIZnet W5500이 담당합니다. 제품 페이지의 ESPHome 설정에 **type: W5500**과 핀 배치가 공개되어 있습니다.

먼저 짚어야 할 것 — 이 구성에서 하드웨어 TCP/IP는 쓰이지 않습니다

W5500은 8개 하드웨어 소켓을 갖춘 하드와이어드 TCP/IP 코어로 알려진 칩이지만, 이 프로젝트는 그 기능을 쓰지 않습니다. ESPHome의 이더넷 컴포넌트는 ESP-IDF의 esp_eth SPI 드라이버를 호출하고, 이 드라이버는 W5500을 MAC과 PHY로만 사용합니다. Espressif의 공식 드라이버 문서는 W5500이 완전한 하드와이어드 TCP/IP 스택을 갖고 있으나 **"ESP 드라이버에서는 사용하지 않는다"**고 명시합니다. TCP/IP는 ESP32-C3 위의 lwIP가 처리합니다.

Espressif 드라이버 문서: https://github.com/espressif/esp-eth-drivers/blob/master/w5500/README.md

그렇다면 W5500은 무엇을 하는가

1. ESP32-C3의 lwIP가 IP·TCP 헤더까지 붙여 완성된 이더넷 프레임을 만듭니다
2. 그 프레임이 SPI 25MHz로 W5500에 전달됩니다
3. W5500이 MAC 계층 처리(프레임 송수신, 주소 필터링, 캐리어 감지)와 10/100 PHY의 물리 신호 변환을 수행합니다
4. 마그네틱과 RJ45를 거쳐 구리선 위의 전기 신호가 됩니다. 수신은 정확히 역순입니다

비유하자면 회선 종단 장치입니다. MCU가 편지를 쓰고 주소까지 직접 붙입니다. W5500은 그 봉투를 실제 구리선에 실어 보내고, 들어온 봉투를 받아 올리는 일만 합니다. 경계는 TCP가 아니라 L2와 L3 사이에 그어져 있습니다.

만약 이 칩이 없었다면, ESP32-C3에는 유선 선택지 자체가 없습니다. ESPHome 문서는 RMII PHY(LAN8720 등)를 구형 ESP32 전용으로 구분하며, [추정] ESP32-C3에 RMII 이더넷 MAC이 없기 때문입니다. RMII로 가려면 구형 ESP32로 돌아가 신호선 9개와 50MHz 클럭 공급을 감당해야 합니다. W5500은 MAC과 PHY를 한 칩에 담아 SPI 6핀으로 끝냅니다. 26 × 62mm에 P1 OUT까지 들어간 구성이 여기서 나옵니다.

놓치면 안 되는 관찰: 이 프로젝트는 W5500의 대표 기능인 하드웨어 TCP/IP를 쓰지 않으면서도 W5500을 선택했습니다. ESPHome 생태계에서 이 칩의 채택 근거는 오프로딩이 아니라 단일 칩 통합도와 성숙한 드라이버 지원입니다. 반대로 앞서 소개할 RP2040 브리지 사례는 하드웨어 소켓을 직접 쓰는 정반대 구성입니다.

WIZnet Makers 유사 사례

Ethernet P1 Dongel Pro+ (Smartstuff) — 같은 P1/DSMR 리더에 W5500과 ESPHome을 얹은 상용 제품으로 전원 이원화와 P1 out 스플리터까지 겹칩니다. 차이는 ESP32-S3 기반 하이브리드 네트워크에 S0 펄스·RS485 Modbus RTU까지 확장한다는 점입니다. 
→ 프로젝트 링크: https://maker.wiznet.io/matthew/resellers/ethernet-p1-dongel-pro-slimme-meter-lezer/

ESPHome — DSMR P1 → AstraMeter CT002 (Marstek) — ESPHome DSMR 컴포넌트로 telegram을 파싱하고 W5500 유선(PoE)으로 Wi-Fi 의존을 제거했습니다. 차이는 읽은 값을 가정용 배터리의 CT 센서로 에뮬레이션해 Zero Export 제어까지 한다는 점입니다. 
→ 프로젝트 링크: https://maker.wiznet.io/Sunny_/projects/esphome--dsmr-p1--astrameter-ct002-marstek/

RP2040 + W5500 P1 Smart Meter Serial-to-Ethernet Bridge — P1 telegram을 유선으로 내보낸다는 목적과 UART 구성이 동일합니다. 차이는 순수 S2E 브리지로 TCP 2000에 최대 3개 클라이언트를 동시 배포한다는 점이며, P1 CRC 검증 미구현이 한계로 공개되어 있습니다. 
→ 프로젝트 링크: https://maker.wiznet.io/josephsr/projects/rp2040-w5500-p1-smart-meter-serial-to-ethernet-bridge/

MCU가 무엇이든, 소프트웨어가 ESPHome이든 자체 펌웨어든, "P1 데이터를 유선으로 안정적으로 내보낸다"는 요구에 도달하면 네트워크 계층은 매번 W5500으로 수렴합니다.

공통된 설계 철학은 **"계량기 데이터는 로컬에 머물러야 하고, 그 경로는 무선이 아니어야 한다"**입니다. SlimmeLezer Pro의 차별점은 이를 단일코어 MCU와 최소 구성으로, 계량기가 주는 전력만으로 달성하려 했다는 점입니다.

비즈니스 가치

외부 관점 — 고객과 시장

• 규제가 만든 수요의 지속성: 계량기 교체가 진행되는 동안 P1 리더의 대상 모수는 구조적으로 늘어납니다. 유행이 아니라 정책 일정에 묶인 수요입니다
• 무선 취약 지점의 게이트웨이: 배전반·기계실·지하 설비로, 나아가 소형 상업시설 서브미터링으로 같은 구조가 확장됩니다
• 에너지 제어의 입력단: 동적 요금제, 태양광 자가소비, ESS Zero Export 제어가 모두 초 단위 계량 데이터를 전제로 합니다

내부 관점 — WIZnet

• MCU 세대 교체가 만드는 수요: 신형 저전력 RISC-V MCU가 내장 EMAC 없이 출시되는 흐름은 외장 SPI 이더넷 컨트롤러의 자리를 오히려 넓힙니다
• ESPHome이라는 유입 경로: 공식 지원 덕에 개발자가 드라이버를 작성하지 않습니다. 진입장벽이 YAML 몇 줄 수준이라는 점이 채택률로 직결됩니다
• 플랫폼 중립 포지셔닝: Espressif는 Ethernet MAC 내장 SoC로, Raspberry Pi는 반도체 프랜차이즈로, Arduino는 Qualcomm 산하에서 각각 산업 시장을 향합니다. 어느 플랫폼이 이기든 유선 네트워크 계층은 결국 WIZnet 칩으로 수렴합니다.

한계 및 개선 방향

1인 개발자가 파편화된 4개 세대의 계량기와 3개국 변형을 오픈 펌웨어로 흡수해 왔다는 점을 먼저 짚어둡니다.

• 네트워크 폴백 부재: Wi-Fi와 이더넷을 동시에 쓸 수 없어 링크 장애 시 자동 우회가 없습니다. 링크 다운 감지 후 Wi-Fi 폴백이 있으면 좋겠습니다
• 전력 예산의 압박: P1이 주는 250mA 안에서 MCU와 이더넷을 함께 돌려야 합니다. W5500의 데이터시트 기준 소비는 100M 송신 시 132mA, 10M 송신 시 79mA입니다. 송신 피크 기준이라 상시 소비와는 다르지만 마진이 넉넉하지 않으므로 10M 링크 고정 옵션이 선택지가 됩니다
• 선행 모델의 안정성 보고: Home Assistant 커뮤니티에 SlimmeLezer+의 연결이 며칠 간격으로 끊긴다는 보고가 2023년 2월부터 2025년 11월까지 이어졌습니다. 증상은 ESPHome API(6053) 접속 불가였고 Wi-Fi 신호는 양호하게 보고되었습니다. 원인은 확정되지 않았고 Pro에서 재현된다는 근거도 없습니다 
  → 커뮤니티 스레드: https://community.home-assistant.io/t/slimmelezer-losing-connectivity-every-couple-of-days/539123
• 규격 전환·자료 파편화: DSMR 6.0.0 X1 발행에 따른 호환성 재검증이 필요하고, Pro 전용 YAML이 제품 페이지에만 게재되어 있어 저장소 일원화가 기여자 유입에 도움이 됩니다

FAQ

Q. ESP32-C3에서 이더넷을 쓰려면 왜 외장 칩이 필요합니까? 
ESPHome은 RMII PHY 방식을 구형 ESP32 전용으로 명시합니다. [추정] ESP32-C3에 RMII 이더넷 MAC이 없기 때문이며, SPI로 붙는 W5500 같은 컨트롤러가 현실적인 유일한 유선 경로가 됩니다.

Q. Wi-Fi와 이더넷을 동시에 쓸 수 없는 이유는 무엇입니까? 
제품 페이지는 ESPHome의 제약으로 설명하며, ESPHome 문서 역시 다중 네트워크 인터페이스를 구형 ESP32에서만 지원한다고 안내합니다.

Q. P1 기생전원만으로 이더넷 운용이 가능합니까? 
DSMR 5 계량기라면 가능하도록 설계되어 있습니다. DSMR 4 이하에서는 USB-C 급전이 필요하며, 한도가 250mA이므로 여유가 필요하면 USB 급전을 권장합니다.

Q. 비슷한 구조를 직접 만들면 난이도는 어느 정도입니까? 
W5500 모듈과 ESP32 계열 보드면 됩니다. ESPHome이 공식 지원하므로 type: W5500과 SPI 핀 지정 등 YAML 몇 줄로 유선이 활성화되고, 난이도의 대부분은 이더넷이 아니라 P1 신호 반전 처리와 레벨 시프팅에 있습니다.

Summary

SlimmeLezer Pro is an ESPHome-based reader that plugs into the P1 port of a Dutch smart meter and streams live energy data to Home Assistant. Moving to the ESP32-C3 for this generation, it attached a WIZnet W5500 over SPI to gain wired Ethernet. It deserves attention because it shows how to give wired networking back to a modern RISC-V MCU that ships without an Ethernet MAC.

Overview

Smart meters in the Netherlands and Belgium push consumption data out through a P1 port at fixed intervals. A P1 reader picks up that data and feeds it into a home automation platform, and SlimmeLezer is the most widely used open-firmware family in that role.

The hard part is where the device lives. Meters sit inside a distribution cabinet enclosed in metal and concrete — about the worst possible environment for Wi-Fi. Creator Marcel Zuidwijk had already shipped a wired model built on the WT32-ETH01 with a LAN8720 RMII PHY, but it relied on the older ESP32 and paid for it in pin count and board size. SlimmeLezer Pro merges those two branches, fitting Wi-Fi, Ethernet, and a P1 OUT onto a 26.25 × 61.75 mm board.

Product page: https://www.zuidwijk.com/product/slimmelezer-pro/

Why This Matters

Repository adoption — confirmed

• This is a commercial product, sold with a case and an RJ12 cable (€34.95, excluding VAT)
• The zuidwijk/dsmr repository records 223 stars and 77 forks, and the DSMR component has been merged into ESPHome upstream since version 2021.8.0
• That said, no enterprise or institutional deployment reference is confirmed

Repository: https://github.com/zuidwijk/dsmr

Industry and regulatory need — confirmed

• The Dutch Energiewet (Energy Act) took effect on January 1, 2026, making it mandatory to replace analog meters with digital or smart meters. The RDI supervises compliance
• Netbeheer Nederland defines the P1 interface through the DSMR P1 Companion Standard. Version 5.0.2 is the current baseline, and the next-generation v6.0.0 X1 document was published on December 17, 2025
• EU Directive 2019/944 requires member states to guarantee consumer access to near real-time consumption data

In short, regulation is expanding the addressable base for P1 readers. Both conclusions stand side by side.

RDI source: https://www.rdi.nl/onderwerpen/consumenten/wettelijke-plicht-slimme-of-digitale-meter

Industry trend insight

• Espressif: the ESP32-S31 was announced in April 2026 and entered mass production on July 27, 2026. It leads with an integrated Gigabit Ethernet MAC and names industrial automation as a target
• Raspberry Pi: FY2025 revenue reached $323.5M (+25%), and semiconductor shipments of 8.4 million units outpaced board volumes for the first time. The company formalized a "two-franchise" strategy
• Arduino: Qualcomm acquired the company on October 7, 2025

The sequence is the interesting part. This product went public on June 9, 2026, ahead of the ESP32-S31 ramp. Over the same window, WIZnet Makers saw five P1/DSMR × W5500 projects in three months. Demand for wired connectivity moved in the community before it moved on vendor roadmaps.

Espressif source: https://www.espressif.com/en/news/ESP32_S31_Mass_Production Raspberry Pi source: https://www.theregister.com/2026/03/31/raspberry_pi_fy_2025/

Architecture

The key point is that the network path is decided once, at boot. Wi-Fi and Ethernet cannot run at the same time, and the product page attributes this to an ESPHome constraint.

Technology Background

DSMR and the P1 Port

DSMR (Dutch Smart Meter Requirements) is the specification Dutch meters must meet, and P1 is the one-way output port left open so consumers can read their own data.

The meter pushes a text block of OBIS codes — a telegram — every second on DSMR 5, or every ten seconds on DSMR 4 and below. Transmission runs at 115200 bps 8N1, but the signal is inverted, and a CRC checksum closes each telegram (DSMR 2.x is the exception).

The specification shows up directly in this product's configuration. The UART line reads rx_pin: 20, inverted: true because of that signal inversion. Likewise, DSMR 5 runs on P1 parasitic power alone while DSMR 4 and below need USB-C, because supply rules changed between generations. DSMR 5 caps P1 supply at 250 mA.

DSMR specification: https://www.netbeheernederland.nl/sites/default/files/2024-02/dsmr_5.0.2_p1_companion_standard.pdf

ESPHome and the Home Assistant Native API

ESPHome generates firmware from a YAML declaration and automates delivery through OTA updates.

The Native API is what matters here. The device holds a persistent TCP session on port 6053 with Home Assistant and pushes every value change as it happens. Because it is a live connection rather than polling, it responds fast — but when the session drops, every automation triggered by that device stops with it. If you drive a load from power readings that update once per second, link quality is control quality.

ESPHome Ethernet documentation: https://esphome.io/components/ethernet/

Technical Highlights

• Generational merge: the Wi-Fi model and the wired model used to be separate products. Pro puts both on one board
• Standard path: the ESPHome Ethernet component officially supports the W5500, so a few lines of YAML bring up the wired link
• Expandability: P1 OUT pass-through removes the constraint of a single physical meter port (5 V is supplied only under USB power)
• Maintainability: per-country and per-generation YAML branches plus OTA keep updates remote

Where WIZnet Fits — Giving Ethernet Back to an MCU Without an EMAC

The WIZnet W5500 handles wired Ethernet here. The product page publishes type: W5500 along with the full pin assignment.

ESPHome documentation separates the two approaches: RMII PHYs such as the LAN8720 are listed for the original ESP32 only, while SPI Ethernet controllers like the W5500 are supported on ESP32 variants and RP2040/RP2350. [Inferred] Because the ESP32-C3 has no RMII Ethernet MAC, an external SPI Ethernet controller was effectively the only way to keep wired networking while moving to the C3.

What happens when a request arrives

1. Home Assistant opens a connection to TCP port 6053 on the device
2. The W5500 handles the ARP reply, IP routing, and TCP three-way handshake in hardware. The MCU never touches any of it
3. Once the session is open, retransmission, ordering, checksums, and window management stay inside eight independent hardware sockets
4. Only the finished payload reaches the ESP32-C3. The MCU focuses on telegram parsing, CRC verification, and sensor mapping

Think of it as a dedicated post office standing in front of the meter cabinet. The MCU only writes the letter. Addressing it, choosing the route, and resending anything that bounces all belong to the W5500. A single SPI bus draws a clean line between what the MCU does and what it never has to.

Without this chip, a single-core RISC-V part would run the lwIP software stack while juggling telegram parsing and TCP retransmission timers at the same time. Going the RMII route would mean surrendering a handful of pins and falling back to the older ESP32, and fitting P1 OUT into a 26 × 62 mm board would have been difficult.

Similar Projects on WIZnet Makers

Ethernet P1 Dongel Pro+ (Smartstuff) — a commercial P1/DSMR reader built on the same W5500 and ESPHome pairing, matching even the dual power path and P1 out splitter. It differs by running a hybrid network on an ESP32-S3 and extending to S0 pulse inputs and RS485 Modbus RTU. 
→ Project link: https://maker.wiznet.io/matthew/resellers/ethernet-p1-dongel-pro-slimme-meter-lezer/

ESPHome — DSMR P1 → AstraMeter CT002 (Marstek) — parses telegrams with the same ESPHome DSMR component and removes Wi-Fi dependence through W5500 wired Ethernet over PoE. It differs by emulating a home battery's CT sensor to run Zero Export control on the values it reads. 
→ Project link: https://maker.wiznet.io/Sunny_/projects/esphome--dsmr-p1--astrameter-ct002-marstek/

RP2040 + W5500 P1 Smart Meter Serial-to-Ethernet Bridge — shares the same goal and UART setup for pushing P1 telegrams over a wire. It differs as a pure serial-to-Ethernet bridge, distributing to up to three simultaneous clients on TCP 2000, and it publishes missing P1 CRC validation as a known limitation. 
→ Project link: https://maker.wiznet.io/josephsr/projects/rp2040-w5500-p1-smart-meter-serial-to-ethernet-bridge/

Whatever the MCU, and whether the software is ESPHome or custom firmware, the moment a design needs to push P1 data reliably over a wire, the network layer converges on the W5500.

They share one design philosophy: meter data should stay local, and the path it travels should not be wireless. SlimmeLezer Pro stands apart by chasing that goal with a single-core MCU, a minimal configuration, and nothing but the power the meter provides.

Business Value

External view — customers and market

• Regulation makes the demand durable: as meter replacement proceeds, the addressable base for P1 readers grows structurally. This is demand tied to a policy schedule, not a trend
• A gateway for wireless dead zones: distribution cabinets, plant rooms, and basement utilities — and the same structure scales into submetering for small commercial sites
• The input stage for energy control: dynamic tariffs, solar self-consumption, and ESS Zero Export control all assume second-by-second metering data

Internal view — WIZnet

• MCU generational churn creates demand: as low-power RISC-V parts ship without an integrated EMAC, the space for external SPI Ethernet controllers widens rather than shrinks
• ESPHome as an on-ramp: official support means developers never write a driver. A barrier to entry measured in a few lines of YAML translates directly into adoption
• Platform-neutral positioning: Espressif pushes SoCs with an integrated Ethernet MAC, Raspberry Pi builds a semiconductor franchise, and Arduino advances under Qualcomm — each toward the industrial market. Whichever platform wins, the wired network layer still converges on WIZnet silicon.

Limitations and Future Improvements

It is worth noting first that a solo developer absorbed four fragmented meter generations and three national variants into open firmware.

• No network fallback: because Wi-Fi and Ethernet cannot run together, a link failure has no automatic detour. Wi-Fi fallback on link-down detection would help
• Tight power budget: the MCU and Ethernet share the 250 mA the P1 port provides. Datasheet figures for the W5500 are 132 mA when transmitting at 100M and 79 mA at 10M. These are transmit peaks rather than steady-state draw, but the margin is not generous, which makes a fixed 10M link option a reasonable choice
• Stability reports on the earlier model: the Home Assistant community logged reports that SlimmeLezer+ connections dropped every few days, running from February 2023 to November 2025. The symptom was an unreachable ESPHome API on port 6053, while Wi-Fi signal strength was reported as adequate. The cause was never confirmed, and there is no evidence it reproduces on Pro 
  → Community thread: https://community.home-assistant.io/t/slimmelezer-losing-connectivity-every-couple-of-days/539123
• Standard transition and scattered documentation: the release of DSMR 6.0.0 X1 calls for hardware compatibility re-validation, and the Pro-specific YAML lives only on the product page, so consolidating the repository would help attract contributors

FAQ

Q. Why does the ESP32-C3 need an external chip for Ethernet? 
ESPHome documents RMII PHYs as ESP32-only. [Inferred] The ESP32-C3 has no RMII Ethernet MAC, which makes an SPI-attached controller like the W5500 the only practical wired path.

Q. Why can't Wi-Fi and Ethernet run at the same time? 
The product page attributes it to an ESPHome constraint, and ESPHome documentation likewise notes that multiple network interfaces are supported only on the original ESP32.

Q. Can Ethernet really run on P1 parasitic power alone? 
It is designed to work on a DSMR 5 meter. DSMR 4 and below require USB-C power, and since the cap is 250 mA, USB power is the safer choice when you want headroom.

Q. How hard is it to build something similar yourself? 
You need a W5500 module and an ESP32-family board. Because ESPHome supports it officially, type: W5500 plus SPI pin assignments — a few lines of YAML brings the link up. Most of the difficulty sits not in Ethernet but in handling the inverted P1 signal and level shifting.