masterETH Controller: Centralized Management of dualETH and quadETH Art-Net Nodes via W5500 Ethernet
masterETH Controller: Centralized Management of dualETH and quadETH Art-Net Nodes via W5500 Ethernet
0
Project description


Overview
masterETH Controller는 같은 lighting LAN에 연결된 여러 dualETH와 quadETH를 자동으로 발견하고, 하나의 Web UI에서 관리할 수 있도록 설계된 network management controller입니다. ESP-07(ESP8266EX)과 WIZnet W5500을 사용하며, W5500 Ethernet을 통해 Art-Net 기반 node discovery와 REST API 기반의 상태 확인, 설정 및 firmware 관리 기능을 제공합니다.
masterETH는 DMX 또는 Pixel output을 직접 생성하는 lighting node가 아닙니다. GitHub README에서는 이 장치를 fleet manager / show controller로 설명하고 있으며, hardware.role = "manager"를 사용하고 DMX port가 없는 별도의 management device임을 명시하고 있습니다.
제품 Spec Sheet에서도 masterETH의 핵심 기능으로 LAN에 연결된 expanseElectronics node 자동 발견, 여러 node를 관리하기 위한 하나의 Web UI, REST API 기반 management를 제시하고 있습니다.

Technical Architecture
masterETH는 Art-Net을 device discovery에 사용하고, HTTP/REST를 device management에 사용하는 구조로 구현되어 있습니다.
| Item | Confirmed Details |
|---|---|
| WIZnet Chip | W5500 Hardwired TCP/IP controller |
| MCU | ESP-07 / ESP8266EX, 4 MB |
| MCU ↔ W5500 | SPI, W5500 CS GPIO15 |
| Ethernet | RJ45 10/100, PoE 802.3af |
| Discovery | Art-Net 4, ArtPoll / ArtPollReply, UDP 6454 |
| Management | REST API + Web UI, HTTP 80 |
| Main Code | src/discovery.cpp, src/api.cpp, src/startFunctions.cpp, data/index.html |
Spec Sheet에서는 Art-Net 4와 UDP 6454를 이용한 ArtPoll discovery 및 ArtPollReply parsing, HTTP 80 기반의 REST/Web UI를 명시하고 있습니다.
masterETH의 node discovery 과정은 다음과 같습니다.
Ethernet LAN
│
┌───────────────────┼──────────────────┐
│ │ │
dualETH dualETH quadETH
│ │ │
└────── ArtPollReply / IP + MAC ──────┘
│
▼
W5500 Ethernet
│ SPI
▼
ESP-07 / ESP8266
│
Node Registry
│
GET /api/identify
│
▼
REST API / Web UIsrc/discovery.cpp에서는 UDP port 6454를 열고 ArtPoll packet을 broadcast합니다. README 기준으로 이 poll은 5초마다 수행되며, 수신한 ArtPollReply에서 IP와 MAC을 추출한 뒤 해당 node의 GET /api/identify를 호출합니다.
/api/identify 응답에서 vendor: "expanseElectronics"가 확인된 장치는 compatible node로 분류됩니다. 발견된 장치는 32-entry MAC-keyed registry에서 관리되며, IP address는 DHCP에 따라 변경될 수 있는 값으로 취급됩니다.
따라서 masterETH의 discovery 과정을 간단히 정리하면 다음과 같습니다.
ArtPoll broadcast
↓
ArtPollReply
↓
IP + MAC 추출
↓
GET /api/identify
↓
Vendor / Device 확인
↓
MAC-keyed Node Registry
↓
Web UI / REST Management이러한 구조는 network에서 장치를 찾는 과정과 발견한 장치가 실제 관리 대상인지 확인하는 과정을 분리한다는 점이 특징입니다.
WIZnet Role in This Project
masterETH에서 W5500은 ESP8266 application과 wired lighting LAN 사이의 Ethernet network engine 역할을 담당합니다. ESP-07과 W5500은 SPI로 연결되며, firmware의 Ethernet.init(15) 설정에서 GPIO15가 W5500 chip-select로 사용됩니다.
W5500은 TCP, UDP, IPv4, ARP 등을 hardware에서 처리하는 Hardwired TCP/IP controller이며, 8개의 independent hardware SOCKET과 32 KB의 internal TX/RX memory를 제공합니다.
masterETH firmware에서는 이 W5500 network path를 통해 다음과 같은 통신을 수행합니다.
| Network Function | Protocol / Port |
|---|---|
| Art-Net node discovery | UDP 6454 |
ArtPollReply reception | UDP 6454 |
| Node identity/status/config | HTTP / REST |
| masterETH Web UI | HTTP 80 |
| Fallback DHCP server | UDP 67 |
| DMX Test generator | ArtDmx / UDP 6454 |
또한 masterETH는 ESP8266의 Wi-Fi interface를 Ethernet과 병행해서 사용하지 않습니다. src/main.cpp에서 Wi-Fi radio를 disable하고 W5500 Ethernet을 network interface로 사용하므로, wired Ethernet 중심의 architecture로 구성되어 있습니다.
제품은 RJ45 10/100 Ethernet과 PoE 802.3af를 지원하므로 network와 power를 하나의 Ethernet cable로 공급할 수 있으며, USB-C 5 V 전원도 사용할 수 있습니다. Spec Sheet에 명시된 typical power consumption은 약 0.82 W입니다.
Developer Takeaways
masterETH의 공개 source에서는 여러 Ethernet device를 자동으로 발견하고 관리해야 하는 embedded system에서 참고할 수 있는 몇 가지 설계 방식을 확인할 수 있습니다.
1. Application protocol을 discovery mechanism으로 활용
masterETH는 모든 IP address를 순차적으로 scan하는 대신 Art-Net의 ArtPoll을 broadcast하고 ArtPollReply를 수집합니다. src/discovery.cpp의 sendArtPoll()과 parseArtPollReply()에서 이 과정을 확인할 수 있습니다.
ArtPoll → LAN broadcast
↓
Art-Net Nodes
↓
ArtPollReply → masterETHArt-Net과 같이 자체 discovery mechanism을 제공하는 protocol을 사용하는 embedded system이라면 이러한 방식을 참고할 수 있습니다.
2. Discovery와 identity verification을 분리
Art-Net에 응답했다는 이유만으로 해당 장치를 바로 관리 대상으로 등록하지 않습니다.
ArtPollReply
↓
Candidate Device
↓
GET /api/identify
↓
vendor / device information
↓
Managed DeviceArtPollReply를 통해 candidate device를 발견한 후 /api/identify를 추가로 확인하여 실제 지원 대상인지 판단합니다. 이를 통해 protocol participant 발견과 product identity 확인을 별도의 단계로 처리할 수 있습니다.
3. IP address가 아니라 MAC을 registry key로 사용
DHCP 환경에서는 동일한 장치의 IP address가 변경될 수 있습니다. masterETH는 최대 32개의 node를 MAC-keyed registry로 관리하고, IP address는 변경 가능한 network information으로 취급합니다.
따라서 여러 embedded Ethernet device를 장기간 관리해야 하는 시스템에서 참고할 수 있는 구조입니다.
4. 하나의 API model을 여러 management path에서 재사용
masterETH의 REST route는 include/api.h와 src/api.cpp의 API_ROUTES를 중심으로 구성되어 있습니다. Web UI뿐 아니라 v2.3의 USB serial configuration에서도 동일한 handler를 재사용하도록 설계되어 있습니다.
Web SPA의 source는 data/index.html이며, node의 설정을 변경할 때는 각 node의 /api/* endpoint를 직접 호출합니다. 따라서 masterETH가 모든 write request를 대신 전달하는 proxy 구조는 아닙니다.
Related Maker Content and Application Value
Link : https://maker.wiznet.io/matthew/resellers/dualeth/
WIZnet Maker Site에는 같은 expanseElectronics ecosystem의 dualETH PixelControl Gen5 사례가 이미 공개되어 있습니다. 기존 글에서는 dualETH가 W5500 Ethernet을 통해 Art-Net 또는 sACN을 수신하고 이를 두 개의 addressable-pixel output으로 전달하는 구조를 다루고 있습니다.
두 제품의 역할은 다음과 같이 구분할 수 있습니다.
[Lighting Data Path]
Lighting Console / Media Server
│
Art-Net / sACN
▼
dualETH
W5500 + ESP-07
│
▼
Pixel Output A/B
[Management Path]
Browser
│
▼
masterETH
ESP-07 + W5500
│
Art-Net + REST
│
┌─────┼─────┐
▼ ▼ ▼
dualETH dualETH quadETH기존 dualETH 글에서도 masterETH가 언급되지만, 주된 목적은 dualETH Gen5에서 ESP-07과 W5500을 사용한다는 근거를 확인하는 것입니다. 또한 기존 게시글에서도 masterETH를 별도의 fleet-management device로 구분하고 있습니다.
따라서 두 사례는 서로 중복되기보다는 서로 다른 network layer를 보여주는 사례로 볼 수 있습니다.
dualETH는 Ethernet을 통해 lighting data를 수신하고 실제 Pixel output으로 전달하는 endpoint입니다.
masterETH는 여러 Ethernet lighting node를 발견하고 상태와 설정을 중앙에서 관리하는 manager입니다.
특히 masterETH에서 확인할 수 있는 device discovery → identity verification → registry → centralized management 구조는 lighting system 외에도 동일한 LAN에 여러 embedded Ethernet node를 구성하는 시스템에서 참고할 수 있습니다. 예를 들어 building automation이나 distributed controller의 device management 구조에도 이러한 설계 방식을 응용할 수 있습니다. 다만 이러한 application은 masterETH의 공식 지원 기능이 아니라, 공개된 architecture를 기반으로 한 확장 관점의 예시입니다.
FAQ
Q. masterETH와 dualETH는 무엇이 다른가요?
A. dualETH PixelControl은 Art-Net/sACN data를 수신하여 addressable-pixel output으로 전달하는 lighting node입니다. 반면 masterETH는 DMX output이 없는 별도의 manager로, 여러 dualETH와 quadETH를 발견하고 하나의 Web UI에서 관리할 수 있도록 설계되어 있습니다.
Q. masterETH는 dualETH와 quadETH를 어떻게 찾나요?
A. UDP 6454를 통해 Art-Net ArtPoll을 broadcast하고, 각 node의 ArtPollReply에서 IP와 MAC을 확인합니다. 이후 GET /api/identify를 호출해 device identity를 확인하고 compatible node를 MAC 기반 registry에 등록합니다.
Q. W5500은 masterETH에서 어떤 역할을 하나요?
A. W5500은 ESP-07과 SPI로 연결되어 masterETH의 wired Ethernet 및 Hardwired TCP/IP network path를 담당합니다. 이 network path를 통해 Art-Net UDP discovery와 HTTP/REST 기반 node management가 이루어집니다.
Verified Scope and Sources
| Source | Link | Checked Date | Notes |
|---|---|---|---|
| masterETH GitHub | GitHub | 2026-09-29 | Hardware, firmware, discovery, REST API |
| masterETH Controller | Product Page | 2026-09-29 | 공식 제품 정보 |
| masterETH Spec Sheet Rev 1.0 | Product Page | 2026-09-29 | Art-Net, UDP, HTTP, PoE, network specification |
| dualETH PixelControl Gen5 | Maker Site | 2026-09-29 | 동일 ecosystem의 기존 Maker 콘텐츠 |
| W5500 Documentation | WIZnet | 2026-09-29 | Hardwired TCP/IP, SPI, hardware SOCKET specification |
현재 source의 FIRMWARE_VERSION은 v2.3이지만, README에서는 이를 last release v2.2 이후의 in-progress version으로 설명하고 있습니다. 따라서 현재 공개 자료만을 기준으로 v2.3을 정식 release version이라고 표현하기보다는 개발 중인 source version으로 구분하는 것이 적절합니다.
또한 현재 공개 자료에서는 실제 설치 대수, 판매량, 독립적인 latency 또는 packet-loss benchmark, 장시간 reliability test 결과는 확인되지 않습니다. 따라서 이러한 항목을 masterETH의 성능이나 상용 성과로 단정하기는 어렵습니다.
masterETH의 기술적인 특징은 단순히 W5500을 이용해 Ethernet port를 제공하는 데 그치지 않습니다. W5500 Hardwired TCP/IP network path를 기반으로 Art-Net discovery, device identity verification, MAC-based registry, REST/Web UI management를 하나의 embedded controller에서 연결한 구조를 확인할 수 있습니다. 기존 dualETH 사례가 W5500 기반 lighting endpoint를 보여준다면, masterETH는 여러 Ethernet endpoint를 실제로 운영하고 관리하기 위한 management layer로 확장된 사례라고 볼 수 있습니다.
