1. What This Project Actually Does

This project is best understood as a wired room automation node that continuously monitors environmental conditions while controlling multiple AC-powered devices through relay outputs.

On the sensing side, it aggregates heterogeneous inputs: three DHT22 temperature/humidity sensors for room conditions, two 1-Wire temperature probes for water or pod monitoring, analog leak or water-level sensors, a photoresistor for ambient light, and an analog CO₂ proxy derived from voltage measurements. These values are periodically sampled in a fixed loop cycle and exposed over Ethernet as structured JSON.

On the actuation side, the controller manages six independent relay-switched outlets, each mapped to a digital GPIO pin. Channels can be toggled instantly or activated with a timer-based auto-off mechanism, enabling basic automation patterns such as delayed shutdown of heaters, pumps, or lighting.

Rather than using cloud services or message brokers, the system exposes a minimal REST-like HTTP interface on port 80, making it suitable for local dashboards, industrial HMIs, or supervisory controllers that require predictable, always-available access.

2. Firmware Architecture and Control Logic

2.1 Periodic Loop Design

The firmware follows a deliberately simple architecture built around a 2-second main loop cadence, chosen to respect the minimum sampling interval of DHT22 sensors.

Each loop iteration performs the following sequence:

Read DallasTemperature probes (water/pod temperature)

Read three DHT22 sensors (temperature, humidity, heat index)

Sample photoresistor (light level)

Compute VPD (Vapor Pressure Deficit) using temperature and humidity

Notably, only sensor #0 is used for VPD calculation

Read analog CO₂ voltage and convert it to a ppm-like estimate

Read analog leak/water-level inputs and normalize to percentage

Process HTTP requests and update relay/timer states

This structure prioritizes predictable behavior over throughput, which aligns with room-scale automation rather than high-frequency control.

2.2 Relay Control and Timers

Each of the six relay channels is mapped to a fixed GPIO pin:

Two control modes are supported:

Immediate switching via /switch/{channel}/{position}

Timed activation via /timer/{channel}/{seconds}

Timer-based control is implemented by storing startMillis and intervalMillis for each channel. Auto-off is enforced by comparing elapsed time during each loop iteration. Because enforcement depends on the main loop cadence, the design correctly avoids claiming real-time precision and instead provides best-effort delayed shutdown.

3. Network Behavior and Ethernet Strategy

3.1 Ethernet Initialization with EEPROM Persistence

The network layer uses the Arduino Ethernet library (<Ethernet.h>), with MAC and IP configuration persisted in EEPROM.

If EEPROM is uninitialized, the firmware:

Writes default MAC/IP values

Attempts DHCP using the default MAC

If EEPROM contains valid data:

Reads MAC from bytes 0–5

Reads static IP from bytes 6–9

Initializes Ethernet with fixed addressing

This approach allows field configuration without reflashing firmware, which is a practical requirement for deployed control nodes.

3.2 HTTP JSON Interface

An EthernetServer listens on port 80 and implements minimal request parsing by tokenizing the URL path. Responses are assembled as JSON strings in fixed-size buffers stored in SRAM, with extensive use of PROGMEM to conserve memory on AVR-class MCUs.

Key endpoints include:

/state — full sensor and relay state snapshot

/switch/{channel}/{position} — direct relay control

/timer/{channel}/{seconds} — timed relay activation

/sys — firmware, hardware ID, uptime

/eeprom/{addr}/{value} — low-level configuration

/reset and /reboot — remote lifecycle control

No authentication or authorization is implemented, which is an explicit design tradeoff that must be considered in deployment environments.

4. Relationship to WIZnet Ethernet Hardware (Code-First Interpretation)

The firmware includes <Ethernet.h> and relies on the standard Arduino Ethernet stack. In the Arduino ecosystem, this library is typically backed by WIZnet W5x00-family Ethernet controllers via Ethernet shields or modules.

However, the source code does not explicitly name a specific chip (e.g., W5100 or W5500), and no BOM text is provided. Therefore, it is technically accurate to state:

This project implicitly targets WIZnet-based Ethernet hardware through the Arduino Ethernet library, without binding itself to a specific W5x00 variant.

From an architectural standpoint, this design aligns well with WIZnet’s hardware TCP/IP approach:

TCP/IP processing is offloaded from the MCU

SRAM usage remains low compared to software stacks such as LwIP

Wired Ethernet ensures stable, deterministic connectivity for always-on control nodes

If optimized further, the same firmware model could benefit from:

W5500 for larger internal buffers and multi-socket handling

W6100 to extend the REST interface into IPv6 environments

W55RP20 to consolidate MCU and Ethernet into a single industrial-grade component

These are conceptual optimization paths, not claims about the current implementation.

5. Why This Design Matters in Practice

This project demonstrates a pragmatic approach to room-scale industrial or maker automation:

Wired Ethernet avoids the variability and recovery issues common in Wi-Fi

Simple HTTP+JSON lowers integration barriers

Sensor-to-actuator latency is bounded and predictable

EEPROM-backed configuration supports field deployment

The system remains understandable, debuggable, and maintainable

Rather than chasing complexity, it focuses on reliability and determinism, which are often more valuable in real installations.

FAQ

Q1: Why use Ethernet instead of Wi-Fi for this controller?
A wired Ethernet connection provides stable latency and continuous availability, which is important for relay control and monitoring tasks that should not fail due to RF interference, reconnection delays, or access point issues. This project prioritizes predictable behavior over mobility.

Q2: What role does WIZnet hardware play in this architecture?
Although the code does not specify a chip, the Arduino Ethernet library is commonly backed by WIZnet W5x00 controllers. These devices offload TCP/IP processing in hardware, allowing the MCU to focus on sensor reading and control logic with minimal RAM usage.

Q3: Is the CO₂ measurement a calibrated sensor reading?
No. The CO₂ value is derived from a simple analog voltage conversion and linear approximation. It should be treated as a relative or proxy indicator, not as a calibrated NDIR CO₂ measurement suitable for regulatory or scientific use.

Q4: How accurate are the timer-based relay controls?
Timer enforcement depends on the main loop execution cycle, which runs approximately every two seconds. This design is appropriate for delayed shutoff and safety timers but is not intended for high-precision real-time control.

Q5: Is this project suitable for industrial deployment?
Architecturally, yes—especially in controlled networks. However, production deployment would require additional considerations such as authentication, electrical certification, enclosure design, and fail-safe behavior.

Tags

#Ethernet #RoomController #RelayControl #IndustrialIoT #Arduino #WIZnet #HTTPJSON

이더넷 기반 환경 모니터링 및 릴레이 제어 룸 컨트롤러는 어떻게 구현되는가?

1. 이 프로젝트의 본질

이 시스템은 유선 이더넷 기반의 룸 자동화 노드로 볼 수 있습니다.
온도, 습도, 수온, 누수, 조도, CO₂ 유사 지표를 지속적으로 수집하면서, 6개의 릴레이 출력으로 히터, 펌프, 조명 등 AC 부하를 제어합니다.

센서 데이터는 2초 주기의 루프에서 수집되며, 모든 상태는 로컬 네트워크를 통해 JSON 형태로 제공됩니다. 클라우드 의존 없이도 HMI, PLC, 상위 제어기와 직접 연동이 가능합니다.

2. 펌웨어 구조와 제어 방식

2.1 주기적 루프 설계

펌웨어는 DHT22 센서 제약을 고려한 2초 주기 메인 루프를 사용합니다.
각 루프마다 다음 작업을 수행합니다:

수온(1-Wire) 측정

실내 온·습도 3채널 측정

조도, 누수, CO₂ 아날로그 값 측정

VPD 계산 (센서 0번 기준)

HTTP 요청 처리 및 릴레이 상태 갱신

이 구조는 고속 처리보다 예측 가능한 동작을 우선합니다.

2.2 릴레이 및 타이머 제어

6개의 릴레이 채널은 GPIO 4~9번에 매핑되어 있으며:

즉시 ON/OFF

지정 시간 후 자동 OFF

두 가지 방식의 제어를 지원합니다.
타이머는 millis() 기반으로 구현되며, 루프 주기에 따라 해상도가 제한됩니다. 따라서 실시간 정밀 제어가 아닌 지연 차단용 제어에 적합합니다.

3. 이더넷 네트워크 설계

3.1 EEPROM 기반 네트워크 설정

MAC/IP 정보는 EEPROM에 저장되어, 현장에서도 펌웨어 재플래시 없이 네트워크 구성이 가능합니다.
초기 상태에서는 기본값으로 DHCP를 시도하고, 이후에는 고정 IP로 동작합니다.

3.2 HTTP JSON 서비스

포트 80에서 최소한의 HTTP 서버를 운영하며:

/state : 전체 센서/릴레이 상태

/switch, /timer : 출력 제어

/sys, /reset : 시스템 정보 및 재부팅

문자열 기반 JSON 생성과 PROGMEM 활용으로 AVR 계열 MCU의 메모리 한계를 고려한 설계가 돋보입니다.

4. WIZnet과의 관계 (할루시네이션 없는 해석)

이 코드는 <Ethernet.h>를 사용하며, Arduino 환경에서 이는 일반적으로 WIZnet W5x00 계열 이더넷 컨트롤러를 의미합니다.
다만, 특정 칩(W5100/W5500 등)은 명시되어 있지 않으므로 단정하지 않습니다.

구조적으로는 다음과 같은 WIZnet 철학과 잘 맞습니다:

하드웨어 TCP/IP로 MCU 부하 최소화

소프트웨어 스택(LwIP) 대비 낮은 RAM 사용

항상 연결된 유선 이더넷 기반 제어 노드

이는 산업용·상시 동작 시스템에 매우 적합한 접근입니다.

5. 기술적으로 의미 있는 이유

이 프로젝트의 가치는 “복잡함”이 아니라 신뢰성에 있습니다.

Wi-Fi 없이도 항상 접근 가능

예측 가능한 지연 시간

간단하지만 유지보수 가능한 구조

현장 설정과 재부팅 지원

실제 환경 자동화나 제어 노드에서 요구되는 조건을 충실히 만족합니다.

FAQ (한국어)

Q1. 왜 Wi-Fi 대신 이더넷을 사용했나요?
유선 이더넷은 무선 간섭, 재연결 문제 없이 안정적인 지연 특성을 제공합니다. 릴레이 제어와 같이 실패하면 안 되는 작업에 더 적합합니다.

Q2. WIZnet 칩은 이 프로젝트에서 어떤 역할을 하나요?
코드에 명시되지는 않지만, Arduino Ethernet 라이브러리는 보통 WIZnet 기반 하드웨어를 사용합니다. 이를 통해 TCP/IP 처리를 MCU 외부에서 수행할 수 있습니다.

Q3. CO₂ 값은 정확한 측정인가요?
아닙니다. 단순한 아날로그 전압 기반 근사치이며, 보정된 NDIR 센서로 간주해서는 안 됩니다.

Q4. 타이머 제어는 얼마나 정확한가요?
메인 루프 주기에 의존하므로 초 단위 정밀 제어는 아닙니다. 안전 차단이나 지연 OFF 용도로 적합합니다.

Q5. 산업 현장에 바로 사용할 수 있나요?
구조적으로는 가능하지만, 실제 양산이나 산업 적용을 위해서는 보안, 인증, 전기 안전 설계가 추가로 필요합니다.