Wiznet makers

요약

Schneider와 Elmeasure, 제조사가 다른 두 전력량계를 하나의 ESP32+W5500 게이트웨이로 통합하고, FastAPI 백엔드가 이를 SQLite에 적재해 3교대(A/B/C) 시프트별 전력 소비량을 자동 집계하는 시스템입니다. RS485 Modbus RTU로 수집한 데이터를 W5500의 하드웨어 이더넷으로 안정적으로 전송한다는 점에서, 산업 현장의 실전형 통합 사례로 주목할 만합니다.

개요

공장이나 플랜트 현장에는 설치 시기와 공급사가 제각각인 전력량계가 여러 대 혼재하는 경우가 흔합니다. 문제는 이들 미터가 저마다 다른 레지스터맵과 **바이트 오더(byte order)**를 쓴다는 점입니다. 하나의 대시보드로 통합하려면 미터별 차이를 흡수하는 파싱 로직이 필수입니다.

이 프로젝트는 그 문제를 정면으로 다룹니다. ESP32가 RS485로 Schneider·Elmeasure 두 미터를 순차 폴링하고, 정상/스왑 두 가지 float 디코딩 방식을 구분 적용해 값을 정규화합니다. 그 결과를 W5500을 통해 UDP로 서버에 밀어넣고, 서버는 3교대 근무 환경에 맞춰 시프트별 소비량을 자동 계산합니다. WiFi가 불안정하기 쉬운 공장 환경에서 유선 이더넷을 선택한 것도 실무적인 판단입니다.

아키텍처

기술 배경

하드웨어 TCP/IP 오프로딩 (W5500)

W5500은 TCP/IP 프로토콜 스택 전체를 실리콘에 내장한 하드웨어 이더넷 컨트롤러입니다. MCU가 소프트웨어로 네트워크 스택을 처리하지 않아도 SPI 한 줄로 인터넷 연결이 가능해, 저사양 MCU에서도 안정적인 통신이 보장됩니다. 이 프로젝트에서는 ESP32의 WiFi 대신 W5500이 UDP 전송을 전담해, 공장 내 전자기 노이즈나 WiFi 혼잡 문제에서 자유로운 통신 경로를 확보합니다.

Modbus RTU / RS485

Modbus RTU는 RS485 물리 계층 위에서 동작하는 산업 표준 마스터-슬레이브 통신 프로토콜입니다. 마스터(ESP32)가 슬레이브 ID와 레지스터 주소를 지정해 요청하면, 슬레이브(전력량계)가 응답하는 방식입니다. 이 프로젝트는 SCH_ID=2, ELM_ID=1로 두 슬레이브를 구분하고, 각 미터의 레지스터 배열을 개별 정의해 폴링합니다.

Server-Sent Events (SSE)

SSE는 서버가 HTTP 연결을 유지한 채 클라이언트로 데이터를 지속적으로 단방향 스트리밍하는 표준 기술입니다. WebSocket보다 구현이 단순하고 재연결 로직이 브라우저에 내장돼 있어, 폴링 없이 실시간 대시보드를 구현할 때 적합합니다. 이 프로젝트의 /api/v1/stream 엔드포인트가 이 방식으로 대시보드에 실시간 값을 공급합니다.

기술 특징

직접 센싱이 아닌 게이트웨이 역할: 이 시스템은 전압·전류를 직접 계측하는 회로(CT, 션트 등)를 갖고 있지 않습니다. Schneider·Elmeasure 미터가 이미 자체 계측 회로와 정확도 인증(산업용 계량 스펙)을 갖춘 상태이므로, ESP32+W5500은 그 값을 Modbus RTU로 읽어 네트워크로 중계하는 역할에만 집중합니다. 실제 산업 현장에서는 계량 정확도·인증이 요구되는 계측 자체는 검증된 전용 미터가 담당하고, 게이트웨이는 통신·집계·시각화에 전념하는 것이 일반적인 역할 분담입니다.

다만 이 지점에서 짚어볼 부분이 있습니다. 3초 주기로 미터 두 대를 폴링해 짧은 JSON을 UDP로 전송하는 정도의 워크로드는 MCU에 큰 부담을 주지 않습니다. 즉 "MCU의 TCP/IP 연산 부담을 하드웨어로 덜어준다"는 W5500의 전통적인 오프로딩 장점은 이 프로젝트에서 크게 부각되지 않습니다. 소프트웨어 네트워크 스택(WiFi)을 썼더라도 이 정도 트래픽에서 MCU가 병목이 될 가능성은 낮기 때문입니다.

그렇다고 W5500의 선택 가치가 사라지는 것은 아니며, 부각되는 이유 자체가 다르다고 보는 것이 정확합니다.

• 유선 연결 안정성: 오프로딩 여부와 무관하게, 공장 환경에서 WiFi 대신 유선 이더넷을 쓴다는 것 자체가 핵심 가치입니다. 전자기 노이즈·금속 차폐·거리 문제에서 자유로워지는 것은 MCU 부하와는 별개의 이점입니다.
• 핀 효율성: MAC/PHY 내장형 이더넷을 쓰려면 GPIO를 9개 안팎 소비해야 하지만, W5500은 SPI 4~5핀만으로 연결됩니다. 소형 게이트웨이 보드에서는 이 절약이 실질적입니다.
• 결정론적 타이밍: WiFi는 재연결·재시도 과정에서 전송 타이밍이 흔들릴 수 있지만, W5500은 하드웨어 스택이라 지연이 예측 가능합니다. 시프트 집계처럼 주기적 전송이 중요한 구조에서는 이 편이 유리합니다.

WIZnet 적용 구조

이 프로젝트는 W5500을 실제로 사용합니다. ESP32의 SPI 버스(MISO 12 / MOSI 13 / SCK 14 / CS 15)에 연결되고, 별도 리셋 핀(GPIO 25)으로 전원 인가 시 초기화 안정성을 확보합니다. 정적 IP(192.168.0.177)로 구성되어 UDP 클라이언트로서 서버(포트 6503)에 계측 데이터를 전송하는 통신 게이트웨이 역할을 전담합니다. WiFi 스택을 전혀 사용하지 않고 네트워크를 W5500에 완전히 위임한 구조입니다.

WIZnet Makers 유사 사례 (링크 위치 수정)

ESP32 JSY Energy Meter Gateway with W5500 Support: ESP32+W5500 하드웨어에 UDP·REST를 함께 지원하는 에너지 미터 게이트웨이로, 본 프로젝트와 하드웨어·통신 방식이 거의 동일합니다. 차이는 JSY 단일 계열 미터에 집중한다는 점이며, 본 프로젝트는 이기종 멀티미터 통합과 시프트 집계까지 다룹니다. 

→ 프로젝트 링크: https://maker.wiznet.io/Benjamin/projects/esp32-jsy-energy-meter-gateway-with-w5500-support/

IoT Based Smart Energy Meter Using Modbus Protocol as Electricity Saving Effort: W5500과 Modbus 프로토콜로 원격 전력 모니터링을 구현한 사례로, 프로토콜·칩 구성이 동일합니다. 단일 미터의 절감 효과 검증에 초점을 둔 반면, 본 프로젝트는 멀티 미터·교대조 운영이라는 산업 현장 맥락에 더 특화되어 있습니다. 

→ 프로젝트 링크: https://maker.wiznet.io/matthew/projects/iot-based-smart-energy-meter-using-modbus-protocol-as-electricity-saving-effort/

Arduino pulse counting with multiple Energy Meters and logging to Emoncms: 복수의 에너지 미터를 하나의 게이트웨이로 통합한다는 목적이 동일합니다. 펄스 카운팅이라는 오래된 방식을 쓰는 반면, 본 프로젝트는 Modbus RTU 레지스터 읽기와 FastAPI/SSE 기반의 더 현대적인 스택을 사용합니다. 

→ 프로젝트 링크: https://maker.wiznet.io/WIZnet/projects/arduino-pulse-counting-with-multiple-energy-meters-and-logging-to-emoncms/

세 사례 모두 "WiFi가 불리한 산업 환경에서 W5500으로 유선 안정성을 확보하고, 에너지 데이터를 표준 프로토콜로 통합한다"는 동일한 채택 이유를 공유합니다.

비교표

이 비교표를 보면 네 프로젝트 모두 "자체 센싱이 아닌 인증된 미터의 값을 네트워크로 옮기는 게이트웨이"라는 공통 설계 철학을 공유하며, 본 프로젝트는 그중에서도 이기종 미터 통합 + 교대조 집계라는 조합으로 차별화됩니다.

비즈니스 가치

• 이기종 미터 통합: 제조사가 다른 계측기가 혼재된 노후 설비에서도 하나의 대시보드로 통합 관리
• 3교대 공장 운영: 시프트별 전력 소비를 자동 집계해 근무조별 에너지 효율 비교 가능
• 원격 전력 감사: 여러 사업장의 전력 데이터를 중앙 서버로 모아 원격 점검
• 소규모 SCADA 대체: 고가의 상용 SCADA 없이도 핵심 계측·이력 기능 구현

한계 및 개선 방향

이 프로젝트는 이기종 미터 통합이라는 실전 문제를 명확히 해결했다는 점에서 의미가 있습니다. 다만 몇 가지 지점은 향후 개선 여지가 있습니다.

• 현재 한계: UDP 단방향 전송으로 서버 응답(ACK)이 없어 패킷 유실 시 데이터 공백이 발생할 수 있습니다. 정적 IP 하드코딩은 디바이스 확장 시 충돌 관리 부담을 늘립니다. SQLite 단일 파일 DB는 다수 디바이스 동시 기록 시 확장성이 제한될 수 있습니다 [추정].
• 개선 방향: 짧은 시퀀스 번호를 페이로드에 포함시켜 서버 측에서 유실을 감지하는 방식을 고려할 수 있습니다. DHCP+mDNS 조합으로 IP 관리를 자동화하고, 디바이스가 늘어날 경우 PostgreSQL 등으로 DB를 전환하면 W5500이 확보한 통신 안정성을 데이터 계층까지 확장할 수 있습니다.

FAQ

Q1. 새로운 제조사의 미터를 추가하려면 어떻게 해야 하나요? 해당 미터의 레지스터맵과 바이트 오더를 확인해 readMeter 함수에 새 슬레이브 ID와 레지스터 배열을 추가하면 됩니다.

Q2. WiFi 대신 W5500을 쓰는 이유는 무엇인가요? 공장 환경은 금속 구조물과 전자기 노이즈로 WiFi 신호가 불안정하기 쉽습니다. W5500은 유선 이더넷으로 이 문제에서 자유로우며, MCU 부하 없이 하드웨어가 TCP/IP를 전담합니다.

Q3. 디바이스를 여러 대로 확장할 때 주의할 점은? 현재 IP가 하드코딩되어 있어 디바이스마다 정적 IP를 수동 배정해야 합니다. 대수가 많아지면 DHCP 전환이나 별도 IP 관리 체계가 필요합니다.

Q4. UDP 대신 다른 프로토콜을 써야 하나요? 데이터 유실 허용 범위가 좁다면 ACK가 있는 TCP나 MQTT(QoS 1 이상)로 전환하는 것이 안전합니다. 다만 전송 주기가 짧고 페이로드가 작다면 UDP의 경량성도 유효한 선택입니다.

Q5. 유지보수는 어떻게 이뤄지나요? 백엔드는 Windows 배치 스크립트(start/stop)로 PID를 추적하며 운영되므로, 서비스 재시작·로그 확인 절차를 표준화해두는 것이 좋습니다.

Summary

This project brings together two power meters from different manufacturers—Schneider and Elmeasure—through a single ESP32 + W5500 gateway, with a FastAPI backend that stores the data in SQLite and automatically aggregates power consumption by three-shift (A/B/C) schedules. Data collected via RS485 Modbus RTU is transmitted reliably through W5500's hardwired Ethernet, making this a practical, real-world integration case worth examining closely.

Overview

Industrial sites and plants often end up with a mix of power meters installed at different times from different vendors. The core problem is that each meter uses its own register map and byte order. Unifying them into a single dashboard requires parsing logic that absorbs these per-meter differences.

This project tackles that problem head-on. The ESP32 sequentially polls two RS485 meters (Schneider and Elmeasure) via Modbus RTU, applying two distinct float-decoding modes—normal and byte-swapped—to normalize the values. The results are pushed to a server over UDP through W5500, and the server automatically calculates shift-based consumption to match a three-shift operating schedule. Choosing wired Ethernet in a factory environment where Wi-Fi is prone to instability is also a sound practical decision.

Architecture

Technology Background

Hardware TCP/IP Offloading (W5500)

The W5500 is a hardwired Ethernet controller with the entire TCP/IP protocol stack embedded in silicon. It enables Internet connectivity over a single SPI line without requiring the MCU to run a software network stack, ensuring stable communication even on lower-spec MCUs. In this project, W5500 handles UDP transmission instead of the ESP32's Wi-Fi, freeing the system from electromagnetic noise and Wi-Fi congestion issues common in factory settings.

Modbus RTU / RS485

Modbus RTU is an industry-standard master-slave communication protocol that runs over the RS485 physical layer. The master (ESP32) sends a request specifying a slave ID and register address, and the slave (power meter) responds accordingly. This project distinguishes the two slaves as SCH_ID=2 and ELM_ID=1, with separate register arrays defined for each meter's polling routine.

Server-Sent Events (SSE)

SSE is a standard technology in which the server keeps an HTTP connection open and continuously streams data one-way to the client. It's simpler to implement than WebSocket and comes with built-in browser reconnection logic, making it well-suited for real-time dashboards without polling. This project's /api/v1/stream endpoint uses SSE to feed live values to the dashboard.

Technical Highlights

Gateway role, not direct sensing: This system has no circuitry (CT, shunt, etc.) for directly measuring voltage or current. Since the Schneider and Elmeasure meters already carry their own metering circuitry and accuracy certification (industrial-grade metering specs), the ESP32+W5500 combination focuses solely on reading those values via Modbus RTU and relaying them over the network. In real industrial deployments, certified, purpose-built meters typically handle the measurement itself where accuracy and certification matter, while the gateway focuses on communication, aggregation, and visualization.

That said, one point is worth examining more closely. Polling two meters every three seconds and sending a short JSON payload over UDP is a light workload that doesn't place much burden on the MCU. In other words, W5500's traditional advantage—offloading TCP/IP processing from the MCU—doesn't stand out much in this project, since even a software network stack (Wi-Fi) would be unlikely to bottleneck the MCU at this traffic volume.

That doesn't mean W5500's value disappears here; rather, the reason it matters shifts:

• Wired connection stability: Regardless of offloading, using wired Ethernet instead of Wi-Fi in a factory environment is the core value on its own. Freedom from electromagnetic noise, metal shielding, and distance issues is a benefit independent of MCU load.
• Pin efficiency: A MAC/PHY-integrated Ethernet solution typically consumes around 9 GPIOs, whereas W5500 connects via just 4-5 SPI pins. This saving is meaningful on a compact gateway board.
• Deterministic timing: Wi-Fi timing can jitter during reconnects and retries, while W5500's hardware stack provides predictable latency—an advantage for structures like shift aggregation where periodic transmission matters.

Where WIZnet Fits

This project actually uses W5500. It's connected to the ESP32's SPI bus (MISO 12 / MOSI 13 / SCK 14 / CS 15), with a dedicated reset pin (GPIO 25) ensuring stable initialization on power-up. Configured with a static IP (192.168.0.177), it functions purely as a communication gateway, acting as a UDP client that sends metering data to the server (port 6503). The design delegates networking entirely to W5500, with no use of the Wi-Fi stack whatsoever.

Similar Projects on WIZnet Makers

ESP32 JSY Energy Meter Gateway with W5500 Support: An energy meter gateway using the same ESP32+W5500 hardware, supporting both UDP and REST — nearly identical in hardware and communication method to this project. The difference is its focus on a single JSY meter series, while this project handles mixed-brand multi-meter integration and shift aggregation. 

→ Project link: https://maker.wiznet.io/Benjamin/projects/esp32-jsy-energy-meter-gateway-with-w5500-support/

IoT Based Smart Energy Meter Using Modbus Protocol as Electricity Saving Effort: A remote power monitoring implementation using W5500 and the Modbus protocol, matching this project's chip and protocol choice. It focuses on verifying savings from a single meter, whereas this project is more specialized for the industrial context of multi-meter integration and shift-based operations. 

→ Project link: https://maker.wiznet.io/matthew/projects/iot-based-smart-energy-meter-using-modbus-protocol-as-electricity-saving-effort/

Arduino pulse counting with multiple Energy Meters and logging to Emoncms: Shares the same goal of consolidating multiple energy meters through a single gateway. It uses the older pulse-counting method, while this project uses Modbus RTU register reads with a more modern FastAPI/SSE-based stack. 

→ Project link: https://maker.wiznet.io/WIZnet/projects/arduino-pulse-counting-with-multiple-energy-meters-and-logging-to-emoncms/

All three share the same underlying rationale: using W5500 to gain wired stability in Wi-Fi-hostile industrial environments while consolidating energy data through a standard protocol.

Comparison Table

This comparison shows that all four projects share a common design philosophy: "a gateway that relays values from a certified meter over the network, rather than sensing directly." This project differentiates itself with its combination of mixed-brand meter integration and shift-based aggregation.

Business Value / Use Cases

• Mixed-brand meter integration: Unified dashboard management even for aging facilities with meters from different vendors
• Three-shift factory operations: Automatic per-shift consumption aggregation enables energy-efficiency comparisons across shifts
• Remote power auditing: Central collection of power data from multiple sites for remote inspection
• Small-scale SCADA alternative: Core metering and history functions without the cost of commercial SCADA systems

Limitations and Future Improvements

This project clearly solves a real-world problem—integrating mixed-brand meters. That said, a few points leave room for future improvement.

• Current limitations: UDP's one-way transmission provides no server acknowledgment, so packet loss can create data gaps. Hardcoded static IPs add configuration overhead as devices scale. A single-file SQLite database may face scalability limits under concurrent writes from multiple devices [Inferred].
• Improvement directions: Including a short sequence number in the payload would let the server detect loss. Combining DHCP with mDNS could automate IP management, and migrating to something like PostgreSQL as device count grows would extend the communication stability W5500 provides all the way to the data layer.

FAQ

Q1. How do I add a meter from a new manufacturer? Check that meter's register map and byte order, then add a new slave ID and register array to the readMeter function.

Q2. Why use W5500 instead of Wi-Fi? Factory environments often have unstable Wi-Fi due to metal structures and electromagnetic noise. W5500 avoids this with wired Ethernet, handling TCP/IP entirely in hardware without burdening the MCU.

Q3. What should I watch for when scaling to multiple devices? The IP is currently hardcoded, requiring manual static IP assignment per device. As device count grows, switching to DHCP or adopting a proper IP management scheme becomes necessary.

Q4. Should I use a protocol other than UDP? If data loss tolerance is low, switching to TCP (with ACK) or MQTT (QoS 1+) is safer. But if the transmission interval is short and payloads are small, UDP's lightweight nature remains a valid choice.

Q5. How is this maintained operationally? The backend runs via Windows batch scripts (start/stop) that track PID, so standardizing service restart and log-checking procedures is advisable.