Wiznet makers

📌 Overview

When WIZnet Maker introduced The Willow in June 2023, the main story was an open, self-hosted voice assistant built around an ESP32-S3 voice terminal and Willow Inference Server (WIS). The newer willow-esp-srmodels repository shows a less visible but important next step. It turns already-trained Espressif WakeNet wake-word models into individually downloadable, source-traceable model packages.

The repository is not a training pipeline and it does not contain Willow's W5500 driver. Its job is narrower: clone ESP-SR, select a WakeNet v9 model for each wake word, build a flash-partition image named srmodels.bin, and publish that image with its license and source record. The W5500 path remains in the main Willow firmware, where it gives compatible ESP32-S3 hardware a wired route to the local voice services.

Generated editorial illustration: a packaged wake-word model runs locally on the voice terminal; short SPI traces reach the Ethernet controller, and one cable connects its RJ45 jack to the LAN.

Direct answer: Willow has evolved from demonstrating a self-hosted voice stack to maintaining more explicit model and network lifecycles. The WakeNet model is real trained AI that runs on the ESP32-S3; the W5500 carries network traffic after wake-up and does not perform the AI inference.

That distinction is the key to reading the project correctly. The interesting 2026 change is not evidence that the Hey, Willow neural network suddenly became more accurate. It is the arrival of an automated, source-traceable distribution layer around the model, alongside renewed maintenance and hardware testing of the W5500 firmware path.

What Changed Since the 2023 Willow Post?

The earlier Maker article was published on June 9, 2023. Willow's original W5500 pull request #157 had been merged only one day earlier, so wired Ethernet was present but still a very new edge of the project. The public story at that time naturally centered on the overall assistant and its self-hosted inference server.

The next phase came from a concrete product need: a wake phrase that belonged to Willow. The Willow team requested alternatives in ESP-SR issue #88, and Espressif added wn9_heywillow_tts on December 28, 2023. Follow-up requests for model version information and human-friendly wake-word names were implemented upstream in January 2024. Those are model-management features, not flashy interface changes, but they are exactly what a future model-update workflow needs.

In February 2026, HeyWillow created the dedicated packaging repository. In July 2026, Willow's main firmware received a cluster of W5500 fixes for current ESP-IDF APIs, event-loop handling, unique MAC addressing, hostnames, and time synchronization. Pull request #460 records a maintainer test with an ESP32-S3-BOX-3 and MIKROE ETH WIZ Click.

Those W5500 changes are current mainline evidence. They landed after the 0.4.3 stable release, so they should not be read as proof that the same fixes or W5500 defaults are present in the 0.4.3 release build.

Source-mapped timeline: the model lifecycle and W5500 maintenance became much more concrete after the original Willow introduction.

What actually advanced: The strongest evidence is lifecycle engineering: automated, traceable packaging, provenance, model metadata, and maintained Ethernet integration. It is not a published claim of a newly retrained or more accurate Hey, Willow model.

Is Hey, Willow a Real Trained AI Model?

Yes. Espressif describes WakeNet as a neural-network wake-word engine for low-power microcontrollers. Its WakeNet documentation describes WakeNet9 as a dilated-convolution model, and the ESP-SR model list maps Hey,Willow to wn9_heywillow_tts. The _tts suffix means the model was trained with text-to-speech-generated voice samples.

The packaging workflow does not synthesize audio, train a network, or fine-tune weights. It takes the completed upstream model files and places them in the binary layout expected by ESP-SR. Direct inspection of the July 27 release shows wn9_index and wn9_data payloads matching the corresponding upstream ESP-SR files byte for byte. In other words, srmodels.bin contains model metadata, an index, and learned model data. It is not a rules file or a disguised cloud API configuration.

Espressif reported one false activation per eight hours and an 88% RAR (Right Alarm Rate) for its Hey, Willow candidate on the specific test sets discussed in issue #88. Those figures are upstream model-level test results with a TTS-versus-human-speech caveat. They are not a benchmark of the complete Willow device, room acoustics, microphone array, W5500 connection, or current firmware.

The model's public parameter count, full training-data composition, device-wide latency, and new 2026 accuracy measurements are not disclosed. The safe conclusion is strong but limited: this is a genuine trained local wake-word model, while the 2026 repository improves how that model is packaged and traced.

Availability is a separate question. Willow 0.4.3's default model bundle contains Alexa, Hi ESP, and Hi Lexin, not Hey, Willow. A downloadable Hey, Willow artifact therefore does not mean the current stable default firmware already includes or selects it.

What Is Inside a Release?

The repository's GitHub Actions workflow runs every Monday at 06:00 UTC and can also be started manually. It clones the latest ESP-SR master, groups wn9_* models by wake word, selects one variant, invokes Espressif's pack_model.py, and creates a release tagged with the date and upstream short commit.

The latest release observed for this article was v20260727-2f8c4b0, published July 27, 2026. It contains 56 per-wake-word archives. The heywillow.tar.gz archive is about 230 KB and expands to:

• srmodels.bin, a 291,040-byte ESP-SR model-partition image containing wn9_heywillow_tts
• LICENSE, the ESPRESSIF MIT License shipped with the upstream model
• SOURCE.txt, identifying the model name, ESP-SR commit, and source path

Source-mapped release evidence, observed July 31, 2026: the tag identifies the upstream ESP-SR revision and each wake word is published separately.

This packaging is useful because a future device-management service could fetch one model artifact without rebuilding the complete firmware. It also creates an audit trail back to Espressif's model tree.

However, a new weekly release does not necessarily mean new neural-network weights. The workflow publishes on schedule even when the relevant upstream model payload has not changed. The inspected wn9_index and learned wn9_data match the December 2023 model byte for byte, while _MODEL_INFO_ metadata changed later to support model version and friendly-name management. Release date, package hash, model metadata, and model-training date therefore answer different questions.

From ESP-SR Files to a Flashable Model Partition

The automation can be read as a small model supply chain:

1. Clone the current ESP-SR source and record its commit.
2. Discover WakeNet9 model directories.
3. Choose one variant per wake-word name.
4. Pack the model with Espressif's partition-image tool.
5. Bundle the image with license and provenance text.
6. Publish a dated GitHub release.

Generated technical diagram from the repository workflow: an upstream WakeNet model becomes a versioned archive with srmodels.bin, license, and source metadata.

There are two implementation details worth noticing. First, the workflow comment says the preferred synthetic variants are _tts3, then _tts2, then _tts, while the code currently ranks _tts2 before _tts3. This does not affect Hey, Willow, because only the _tts variant exists for that name. Second, the collector looks for wn9_*, so other model-family prefixes are outside this release set.

The wrapper repository itself has no top-level license file. The archives copy the upstream ESPRESSIF MIT License, which includes an Espressif-products use condition; it should not be summarized as an unrestricted generic MIT license.

Where Does Each AI Component Run?

The Willow ecosystem separates jobs that are often blurred together in a voice-assistant diagram.

Generated runtime illustration: wake-word inference remains on the device; speech recognition, synthesis, and automation routing are separate LAN services.

The resulting request path is more specific than a generic “device to server” arrow. The microphone feeds local WakeNet inference. After activation, Willow posts audio to WIS and receives a JSON recognition result. Willow then sends that JSON to WAS, which routes the command to the configured endpoint. When speech synthesis is requested, the device uses its configured WIS TTS endpoint. Wi-Fi or the selected W5500 interface carries these LAN exchanges; the inference and automation roles remain outside W5500.

AI boundary: “Cloud-free” means the services can be self-hosted; it does not mean there is no network communication. Local WakeNet avoids an external API for wake detection, while audio and commands still travel across the LAN to the configured Willow services.

⚙️ Where Does W5500 Fit?

W5500 is not inside the model-package repository. Its evidence is in Willow's main firmware, especially main/net/ethernet.c and the related Kconfig options. The code configures W5500 over SPI and attaches it to ESP-IDF's Ethernet network interface.

The current default pin configuration is explicit:

The SPI clock is configured for 36 MHz, and the firmware uses esp_eth_mac_new_w5500(), esp_eth_phy_new_w5500(), and esp_eth_new_netif_glue() to connect the driver to esp-netif. DHCP, hostname derivation, SNTP, and timezone setup are then handled in the normal network lifecycle.

Source-based code evidence from Willow main: W5500 is a selectable SPI Ethernet interface connected to ESP-IDF's host network stack.

There is an important WIZnet-specific nuance. Willow's ESP-IDF driver opens W5500 in MACRAW mode and passes Ethernet frames to the host esp-netif/lwIP stack. This implementation therefore does not use W5500's hardwired TCP/UDP socket API as an application-level TCP/IP offload path. The public value here is a maintained, wired Ethernet interface for the voice terminal, not an AI accelerator or a claim that the Willow application runs directly on W5500 hardware sockets.

Ethernet and Wi-Fi are compile-time alternatives in the current firmware, not a demonstrated simultaneous hybrid link. The normal CI builds also leave the W5500 option disabled. The strongest hardware statement is the narrower one documented in PR #460: a maintainer tested the updated path on ESP32-S3-BOX-3 with MIKROE ETH WIZ Click.

Is Model OTA Already a Stable Feature?

Not yet. A feature/srmodel_ota branch demonstrates downloading a model-partition image and writing it to the model partition, but the branch is not merged into the current Willow mainline. It is also behind mainline development.

The release archive itself is not the byte stream the firmware expects. A client must extract srmodels.bin from heywillow.tar.gz before writing the partition. The feature code checks the HTTP result and completed transfer, but the examined path does not show a model signature, hash verification, atomic partition switch, or rollback.

Willow's Rust migration plan explicitly leaves speech-model OTA protocol support, atomic activation, rollback, and migration to ESP-SR 2.x as follow-up work. That makes the present status easy to state:

Current boundary: The model-package release infrastructure is active. General, atomic, rollback-capable model OTA in stable Willow is still an integration target, not a finished user feature.

This boundary also explains why the repository matters now. Reliable model distribution can be built and audited before every layer of device activation is complete.

Why This Evolution Matters

The most convincing progress is architectural clarity:

• The WakeNet model has an upstream identity and can be inspected independently of firmware.
• Each release records the ESP-SR revision and model source.
• A future update service can select one wake word instead of shipping an entire model bundle.
• The ESP32-S3 remains responsible for immediate local wake detection.
• W5500 remains responsible for the wired LAN path to self-hosted application and inference services.
• Server-side STT and TTS can evolve without pretending that those large models run on the microcontroller.

This is a more maintainable story than simply saying “Willow uses AI.” It identifies which trained model runs where, what the network controller actually carries, and which pieces are stable versus still being integrated.

The project also exposes useful open-source rough edges. The packaging repository's README currently links to a non-existent HeyWillow/esp-srmodels/releases path instead of its own Releases page, the wrapper has no repository-level license, and scheduled releases can outnumber actual model changes. None of those erase the engineering value, but they are relevant when building production tooling around the artifacts.

Related WIZnet Maker Reading Path

Start with The Willow for the 2023 platform and self-hosted-inference baseline. Then compare Satellite1 PoE SHOE, which combines ESP32-S3, W5500, ESPHome, and local wake-word handling for a Home Assistant voice satellite. MultiSensor-V2 shows a more product-shaped ceiling sensor that uses W5500 PoE for Home Assistant voice and environmental sensing.

Together, the three examples show different layers of the same design space: Willow emphasizes an open voice-software ecosystem and model lifecycle, Satellite1 emphasizes an ESPHome voice-satellite platform, and MultiSensor-V2 emphasizes integrated PoE room hardware.

Source-Backed Summary

willow-esp-srmodels is a compact repository with a substantial systems role. It packages genuine trained ESP-SR WakeNet9 models, including Hey, Willow, into individually downloadable model-partition images with source and license records. The package automation is active and its releases are inspectable.

The associated W5500 support lives in Willow firmware, not in this repository. It is a selectable ESP32-S3 SPI Ethernet interface that received concrete maintenance and a documented hardware test in July 2026. Local wake-word inference and wired networking are complementary but separate responsibilities.

The major improvement since the 2023 Maker post is therefore model and network lifecycle maturity. The model itself is not proven to have been retrained in 2026, and stable atomic model OTA is not finished. That evidence-bounded reading is also the most interesting one: Willow is moving from a promising voice-assistant demonstration toward components that can be versioned, distributed, tested, and eventually updated independently.

❓ FAQ

Does willow-esp-srmodels train the Hey, Willow model? No. Espressif trained the WakeNet9 model upstream. The HeyWillow workflow packages the completed model into srmodels.bin and publishes it with provenance.

Is srmodels.bin actual AI model data? Yes. It contains model metadata, an index, and the trained WakeNet payload used by ESP-SR for local inference on the ESP32-S3.

Does W5500 run WakeNet, STT, or TTS? No. The ESP32-S3 runs WakeNet, and configured servers handle heavier STT/TTS. W5500 supplies the wired Ethernet transport.

Can the latest stable Willow install any of the 56 release models over OTA? Not as a general stable feature. Model OTA exists on a feature branch, while atomic activation and rollback remain planned integration work.

Does a July 2026 package mean the Hey, Willow network was retrained in July 2026? No. The release records a packaging run and ESP-SR source revision. The inspected learned data and index match the December 2023 model, while model-management metadata changed later.

한국어 (Korean)

📌 개요

WIZnet Maker가 2023년 6월 The Willow를 소개했을 때 핵심은 ESP32-S3 음성 단말과 Willow Inference Server(WIS)를 중심으로 한 오픈소스 기반의 자체 호스팅형 음성 비서였습니다. 새로 등장한 willow-esp-srmodels는 눈에 잘 띄지 않지만 중요한 다음 단계를 보여줍니다. 이미 학습된 Espressif WakeNet 웨이크워드 모델을 개별 다운로드가 가능하고 출처를 추적할 수 있는 모델 패키지로 만듭니다.

이 저장소는 모델 학습 파이프라인이 아니며 Willow의 W5500 드라이버도 포함하지 않습니다. 역할은 더 좁고 명확합니다. ESP-SR를 가져와 웨이크워드별 WakeNet v9 모델을 선택하고, srmodels.bin이라는 플래시 파티션 이미지를 만든 뒤 라이선스와 출처 기록을 함께 배포합니다. W5500 경로는 Willow 메인 펌웨어에 있으며, 호환되는 ESP32-S3 하드웨어를 로컬 음성 서비스에 유선으로 연결합니다.

생성형 편집 일러스트: 패키징된 웨이크워드 모델은 음성 단말에서 로컬로 실행되고, 짧은 SPI 배선이 이더넷 컨트롤러로 이어지며 RJ45 케이블 하나가 LAN에 연결됩니다.

핵심 답변: Willow는 자체 호스팅형 음성 스택을 보여주는 단계에서 모델과 네트워크의 수명주기를 더 명확하게 관리하는 단계로 발전하고 있습니다. WakeNet은 ESP32-S3에서 실행되는 실제 학습 AI 모델이며, W5500은 웨이크업 이후의 네트워크 트래픽을 운반할 뿐 AI 추론을 수행하지 않습니다.

이 구분이 프로젝트를 정확히 이해하는 열쇠입니다. 2026년의 중요한 변화는 Hey, Willow 신경망의 정확도가 갑자기 좋아졌다는 증거가 아닙니다. 모델을 자동으로 배포하고 출처를 추적하는 계층이 생겼고, W5500 펌웨어 경로도 다시 유지보수되고 하드웨어로 점검됐다는 점입니다.

2023년 Willow 글 이후 무엇이 달라졌나?

기존 Maker 글은 2023년 6월 9일 게시됐습니다. Willow의 최초 W5500 PR #157은 불과 하루 전 병합됐으므로 당시 유선 이더넷 지원은 프로젝트에 막 추가된 기능이었습니다. 기존 글은 전체 음성 비서와 자체 호스팅형 추론 서버를 중심으로 설명했습니다.

다음 단계는 Willow에 어울리는 웨이크 문구가 필요하다는 구체적인 요구에서 출발했습니다. Willow 팀은 ESP-SR 이슈 #88에서 후보를 요청했고, Espressif는 2023년 12월 28일 wn9_heywillow_tts를 추가했습니다. 모델 버전 정보와 사람이 읽을 수 있는 웨이크워드 이름을 요구한 후속 이슈도 2024년 1월 upstream에 반영됐습니다. 화려한 UI 변화는 아니지만, 향후 모델 업데이트에 꼭 필요한 관리 기능입니다.

2026년 2월 HeyWillow는 전용 패키징 저장소를 만들었습니다. 2026년 7월에는 최신 ESP-IDF API, event loop, 고유 MAC 주소, hostname, 시간 동기화와 관련된 W5500 수정이 메인 펌웨어에 연속 반영됐습니다. PR #460에는 유지보수자가 ESP32-S3-BOX-3와 MIKROE ETH WIZ Click으로 시험한 기록도 남아 있습니다.

이 W5500 변경은 현재 mainline의 근거입니다. 0.4.3 안정판 공개 뒤에 병합됐으므로, 같은 수정이나 W5500 기본 설정이 0.4.3 릴리스 빌드에 들어 있다는 증거로 해석하면 안 됩니다.

출처 기반 타임라인: 기존 Willow 소개 이후 모델 수명주기와 W5500 유지보수가 훨씬 구체적인 형태를 갖추기 시작했습니다.

실제로 발전한 부분: 가장 강한 근거는 자동화되고 추적 가능한 패키징, 출처 추적 정보, 모델 메타데이터, 이더넷 통합 유지보수입니다. Hey, Willow 모델이 새로 재학습됐거나 정확도가 높아졌다는 공개 근거는 아닙니다.

Hey, Willow는 실제 학습된 AI 모델인가?

그렇습니다. Espressif는 WakeNet을 저전력 마이크로컨트롤러용 신경망 웨이크워드 엔진으로 설명합니다. WakeNet 문서는 WakeNet9가 dilated convolution 구조를 사용한다고 설명하며, ESP-SR 모델 목록은 Hey,Willow를 wn9_heywillow_tts에 연결합니다. _tts 접미사는 text-to-speech로 생성한 음성 샘플을 이용해 학습한 모델이라는 뜻입니다.

패키징 워크플로는 음성을 합성하거나 신경망을 학습하거나 가중치를 미세 조정하지 않습니다. 이미 완성된 ESP-SR 원본 모델을 ESP-SR가 요구하는 바이너리 형식으로 배치합니다. 7월 27일 릴리스의 wn9_index와 wn9_data는 ESP-SR 원본과 바이트 단위로 일치합니다. 즉 srmodels.bin에는 모델 메타데이터, 인덱스, 학습된 모델 데이터가 들어 있습니다. 규칙 파일이나 클라우드 API 설정을 모델처럼 포장한 것이 아닙니다.

Espressif는 이슈 #88에서 특정 평가 세트로 시험한 Hey, Willow 후보에 대해 8시간당 1회의 오탐과 88%의 RAR(Right Alarm Rate)을 보고했습니다. 이 수치는 TTS와 실제 사람 음성의 차이라는 단서가 붙은 상위 모델 수준의 시험 결과입니다. 전체 Willow 장치, 방의 음향, 마이크 배열, W5500 연결, 현재 펌웨어의 종합 성능 평가로 해석하면 안 됩니다.

공개된 모델 파라미터 수, 전체 학습 데이터 구성, 장치 전체 지연 시간, 2026년 신규 정확도 측정치는 확인되지 않습니다. 따라서 안전한 결론은 명확합니다. 실제 학습된 로컬 웨이크워드 모델은 맞지만, 2026년 저장소의 진전은 모델을 패키징하고 추적하는 방법에 있습니다.

모델의 존재와 안정판 기본 포함 여부도 구분해야 합니다. Willow 0.4.3의 기본 모델 번들에는 Alexa, Hi ESP, Hi Lexin이 들어 있고 Hey, Willow는 포함되지 않습니다. 다운로드 가능한 Hey, Willow 산출물이 있다고 해서 현재 안정판 기본 펌웨어가 이미 이 모델을 포함하거나 선택한다는 뜻은 아닙니다.

릴리스 안에는 무엇이 들어 있나?

저장소의 GitHub Actions 워크플로는 매주 월요일 06:00 UTC에 실행되며 수동으로도 시작할 수 있습니다. 최신 ESP-SR master를 가져오고, 웨이크워드별 wn9_* 모델을 모아 하나의 변형을 선택한 뒤 Espressif의 pack_model.py를 호출합니다. 릴리스 태그에는 날짜와 상위 ESP-SR의 축약 커밋 해시가 들어갑니다.

이 글에서 확인한 최신 릴리스는 2026년 7월 27일의 v20260727-2f8c4b0입니다. 웨이크워드별 압축 파일 56개가 있으며, 약 230 KB인 heywillow.tar.gz를 풀면 다음 세 파일이 나옵니다.

• srmodels.bin: wn9_heywillow_tts를 담은 291,040-byte ESP-SR 모델 파티션 이미지
• LICENSE: upstream 모델과 함께 배포되는 ESPRESSIF MIT License
• SOURCE.txt: 모델 이름, ESP-SR commit, source path 기록

2026년 7월 31일 확인한 릴리스 근거: 태그는 upstream ESP-SR revision을 표시하고 각 웨이크워드는 별도의 압축 파일로 배포됩니다.

이 구조를 이용하면 향후 장치 관리 서비스가 전체 펌웨어를 다시 빌드하지 않고 필요한 모델 산출물 하나만 내려받을 수 있습니다. Espressif 모델 트리까지 이어지는 출처 추적 경로도 생깁니다.

하지만 새 주간 릴리스가 곧 새로운 신경망 가중치를 뜻하지는 않습니다. 워크플로는 관련 상위 모델이 바뀌지 않아도 정기적으로 릴리스를 만듭니다. 확인한 wn9_index와 학습 데이터 wn9_data는 2023년 12월 모델과 바이트 단위로 같지만, _MODEL_INFO_ 메타데이터는 이후 모델 버전과 표시 이름 관리를 지원하도록 바뀌었습니다. 릴리스 날짜, 패키지 해시, 모델 메타데이터, 모델 학습 날짜는 서로 다른 질문에 답하는 정보입니다.

ESP-SR 파일이 플래시용 모델 파티션이 되는 과정

자동화는 작은 모델 공급망으로 볼 수 있습니다.

1. 현재 ESP-SR 소스를 clone하고 commit을 기록합니다.
2. WakeNet9 모델 디렉터리를 찾습니다.
3. 웨이크워드 이름별로 하나의 변형을 선택합니다.
4. Espressif의 partition-image 도구로 모델을 pack합니다.
5. 이미지에 라이선스와 출처 기록을 묶습니다.
6. 날짜가 붙은 GitHub Release로 배포합니다.

저장소 워크플로를 바탕으로 만든 기술 다이어그램: 상위 ESP-SR의 WakeNet 모델이 srmodels.bin, 라이선스, 출처 메타데이터를 포함한 버전 표시 압축 파일로 바뀝니다.

구현에서 눈여겨볼 세부 사항이 두 가지 있습니다. 첫째, workflow 주석에는 합성 모델 우선순위가 _tts3, _tts2, _tts 순서라고 적혀 있지만 실제 코드는 _tts2를 _tts3보다 먼저 선택합니다. Hey, Willow에는 _tts 변형만 있으므로 이 이름에는 영향이 없습니다. 둘째, 수집기는 wn9_*만 찾기 때문에 다른 model-family prefix는 이 릴리스 집합 밖에 있습니다.

패키징 저장소 자체에는 최상위 라이선스 파일이 없습니다. 압축 파일은 상위 ESP-SR의 ESPRESSIF MIT License를 복사하며, 이 문안에는 Espressif 제품 사용 조건이 포함됩니다. 제한 없는 일반 MIT License라고 축약해서는 안 됩니다.

각 AI 컴포넌트는 어디에서 실행되나?

Willow 생태계는 음성 비서 그림에서 흔히 한 덩어리로 표현되는 역할을 분리합니다.

생성형 실행 구조 일러스트: 웨이크워드 추론은 장치에 남고, 음성 인식·합성·자동화 연결은 LAN의 별도 서비스가 담당합니다.

실제 요청 흐름은 일반적인 “장치에서 서버로” 화살표보다 구체적입니다. 마이크 입력이 로컬 WakeNet 추론으로 들어갑니다. 웨이크업 이후 Willow는 음성을 WIS에 POST하고 JSON 인식 결과를 받습니다. 이어서 Willow가 그 JSON을 WAS로 보내면 WAS가 설정된 명령 endpoint로 전달합니다. 음성 합성이 필요할 때는 장치가 설정된 WIS TTS endpoint를 사용합니다. Wi-Fi 또는 선택한 W5500 인터페이스는 이 LAN 통신을 운반하며, 추론과 자동화 역할은 W5500 밖에 있습니다.

AI 경계: “클라우드 없이 운영 가능”하다는 말은 서비스를 직접 호스팅할 수 있다는 뜻이지 네트워크 통신이 없다는 뜻이 아닙니다. 로컬 WakeNet은 웨이크 감지에 외부 API가 필요 없게 하지만, 음성과 명령은 구성한 Willow 서비스까지 LAN으로 이동합니다.

⚙️ W5500은 어디에 들어가나?

W5500은 모델 패키지 저장소 안에 있지 않습니다. 근거는 Willow 메인 펌웨어의 main/net/ethernet.c와 관련 Kconfig option에 있습니다. 코드는 W5500을 SPI로 설정하고 ESP-IDF Ethernet network interface에 연결합니다.

현재 기본 pin configuration은 다음과 같습니다.

SPI clock은 36 MHz로 설정되며, 펌웨어는 esp_eth_mac_new_w5500(), esp_eth_phy_new_w5500(), esp_eth_new_netif_glue()를 사용해 드라이버를 esp-netif에 연결합니다. 이후 DHCP, hostname 생성, SNTP, timezone 설정이 일반적인 네트워크 수명주기 안에서 처리됩니다.

Willow main 소스 기반 코드 근거: W5500은 ESP-IDF host network stack에 연결되는 선택형 SPI Ethernet interface입니다.

WIZnet 관점에서 중요한 세부 사항이 있습니다. Willow의 ESP-IDF 드라이버는 W5500을 MACRAW 모드로 열고 이더넷 프레임을 호스트의 esp-netif/lwIP 스택에 전달합니다. 따라서 이 구현은 애플리케이션 수준의 TCP/IP 오프로드 경로로 W5500 하드와이어드 TCP/UDP 소켓 API를 쓰지 않습니다. 공개적으로 확인되는 가치는 음성 단말을 위해 유지보수되는 유선 이더넷 인터페이스이며, AI 가속기나 Willow 애플리케이션이 W5500 하드웨어 소켓 위에서 직접 실행된다는 주장이 아닙니다.

현재 펌웨어에서 Ethernet과 Wi-Fi는 compile-time 대안이며 동시에 작동하는 hybrid link로 입증되지 않았습니다. 일반 CI build도 W5500 option을 끈 상태입니다. 가장 강한 hardware 근거는 PR #460에 기록된 더 좁은 범위입니다. 유지보수자가 ESP32-S3-BOX-3와 MIKROE ETH WIZ Click으로 업데이트된 경로를 시험했습니다.

모델 OTA는 이미 안정 기능인가?

아직 아닙니다. feature/srmodel_ota branch는 model-partition image를 내려받아 model partition에 기록하는 구현을 보여주지만 현재 Willow mainline에 merge되지 않았고 mainline 개발보다 뒤처져 있습니다.

릴리스 압축 파일 자체가 펌웨어가 기대하는 byte stream은 아닙니다. client는 heywillow.tar.gz에서 srmodels.bin을 먼저 추출한 뒤 partition에 기록해야 합니다. feature code는 HTTP 결과와 transfer 완료를 검사하지만, 확인한 경로에서는 model signature, hash verification, atomic partition switch, rollback을 찾을 수 없었습니다.

Willow의 Rust migration plan은 speech-model OTA protocol, atomic activation, rollback, ESP-SR 2.x 전환을 후속 작업으로 명시합니다. 현재 상태는 다음처럼 정리할 수 있습니다.

현재 경계: 모델 패키지 배포 인프라는 작동 중입니다. 하지만 안정판 Willow에서 일반적으로 사용할 수 있는 원자적 전환·롤백 지원 모델 OTA는 아직 완성된 기능이 아니라 통합 목표입니다.

이 경계는 지금 이 저장소가 왜 필요한지도 설명합니다. 모델을 장치에 적용하는 모든 계층이 완성되기 전에도 신뢰할 수 있는 모델 배포 구조를 먼저 만들고 검토할 수 있습니다.

이 발전이 중요한 이유

가장 설득력 있는 진전은 아키텍처가 선명해졌다는 점입니다.

• WakeNet 모델이 upstream identity를 가지며 펌웨어와 별도로 검사할 수 있습니다.
• 각 릴리스가 ESP-SR revision과 model source를 기록합니다.
• 향후 update service가 전체 model bundle 대신 하나의 웨이크워드를 선택할 수 있습니다.
• ESP32-S3는 즉각적인 로컬 웨이크 감지를 계속 담당합니다.
• W5500은 self-hosted application 및 inference service까지의 유선 LAN 경로를 담당합니다.
• server-side STT/TTS가 발전해도 큰 모델이 microcontroller에서 돈다고 오해하지 않게 됩니다.

이는 단순히 “Willow가 AI를 쓴다”고 말하는 것보다 유지보수 가능한 설명입니다. 어떤 학습 모델이 어디에서 실행되는지, network controller가 무엇을 운반하는지, 어느 부분이 안정화됐고 어느 부분이 통합 중인지 구분할 수 있습니다.

프로젝트는 오픈소스 도구의 거친 부분도 보여줍니다. 패키징 저장소 README의 릴리스 링크는 현재 존재하지 않는 HeyWillow/esp-srmodels/releases로 연결되고, 저장소 수준의 라이선스가 없으며, 실제 모델 변경보다 정기 릴리스 수가 많아질 수 있습니다. 이런 점이 기술적 가치를 지우지는 않지만 실제 운영 도구를 만들 때는 고려해야 합니다.

관련 WIZnet Maker 읽기 순서

먼저 The Willow에서 2023년 플랫폼과 self-hosted inference의 기준점을 확인해 보세요. 이어서 ESP32-S3, W5500, ESPHome, 로컬 웨이크워드 처리를 Home Assistant 음성 위성에 결합한 Satellite1 PoE SHOE를 비교할 수 있습니다. MultiSensor-V2는 W5500 PoE를 Home Assistant 음성과 환경 sensing에 활용하는 제품형 천장 센서 사례입니다.

세 프로젝트는 같은 설계 공간의 서로 다른 계층을 보여줍니다. Willow는 개방형 음성 software ecosystem과 model lifecycle, Satellite1은 ESPHome voice-satellite platform, MultiSensor-V2는 통합 PoE room hardware에 초점을 둡니다.

출처 기반 요약

willow-esp-srmodels는 작은 저장소지만 시스템에서 중요한 역할을 합니다. Hey, Willow를 포함한 실제 학습 ESP-SR WakeNet9 모델을 개별 다운로드 가능한 model-partition image로 패키징하고 source와 license record를 함께 제공합니다. 자동화는 활성 상태이며 릴리스도 직접 검사할 수 있습니다.

관련 W5500 지원은 이 저장소가 아니라 Willow firmware에 있습니다. ESP32-S3가 선택할 수 있는 SPI Ethernet interface이며, 2026년 7월 구체적인 유지보수와 hardware test 기록이 추가됐습니다. 로컬 웨이크워드 추론과 유선 networking은 서로 보완하지만 역할은 분리돼 있습니다.

따라서 2023년 Maker 글 이후의 핵심 발전은 모델과 네트워크 수명주기의 성숙입니다. 모델이 2026년에 재학습됐다는 근거는 없고, 안정적인 원자적 모델 OTA도 아직 끝나지 않았습니다. 오히려 이 근거 중심 해석이 더 흥미롭습니다. Willow는 가능성을 보여주는 음성 비서 데모에서 각 컴포넌트를 독립적으로 버전 관리하고 배포·시험·업데이트할 수 있는 시스템으로 발전하고 있습니다.

❓ FAQ

willow-esp-srmodels가 Hey, Willow 모델을 학습하나요? 아닙니다. Espressif가 상위 ESP-SR에서 WakeNet9 모델을 학습했고, HeyWillow 워크플로는 완성된 모델을 srmodels.bin으로 패키징해 출처 정보와 함께 배포합니다.

srmodels.bin은 실제 AI 모델 데이터인가요? 그렇습니다. ESP-SR가 ESP32-S3에서 로컬 추론할 때 쓰는 모델 메타데이터, 인덱스, 학습된 WakeNet 모델 데이터를 포함합니다.

W5500이 WakeNet, STT, TTS를 실행하나요? 아닙니다. ESP32-S3가 WakeNet을 실행하고 구성된 server가 더 무거운 STT/TTS를 담당합니다. W5500은 유선 Ethernet transport를 제공합니다.

최신 안정판 Willow가 릴리스의 56개 모델을 OTA로 설치할 수 있나요? 일반적인 안정 기능으로는 아직 아닙니다. 모델 OTA는 기능 브랜치에 있고 원자적 전환과 롤백은 후속 통합 작업입니다.

2026년 7월 패키지는 Hey, Willow 신경망이 2026년 7월 재학습됐다는 뜻인가요? 아닙니다. 릴리스는 패키징 실행과 ESP-SR 소스 리비전을 기록합니다. 확인한 학습 데이터와 인덱스는 2023년 12월 모델과 같고, 모델 관리용 메타데이터는 이후 바뀌었습니다.