Wiznet makers

Overview
This project implements a small end-to-end pipeline for environmental monitoring: sensor acquisition on an ESP32 (BME280), network transport over wired Ethernet using the WIZnet W5500, publish/subscribe decoupling via MQTT (Mosquitto), and storage into a local SQLite database on a Linux server.

Main Content

Sensing: The ESP32 reads temperature, humidity, and pressure from the BME280 in real time.

Network transport (why WIZnet W5500): The WIZnet W5500 provides the wired Ethernet interface for the ESP32, enabling a dedicated local Ethernet segment rather than relying on Wi-Fi. This choice tends to simplify deterministic LAN setups (static IPs, fixed gateway) for continuous telemetry.

Messaging layer: The ESP32 publishes measurements via MQTT to a Mosquitto broker (localhost:1883 in the reference setup).

Server ingest: A C-based MQTT subscriber receives messages and stores them into SQLite.

Data model & retention: Measurements are stored in a table with timestamp (UTC) and numeric fields for temperature/pressure/humidity; maintenance scripts can purge older data (example: delete data older than 3 hours), and can be automated via cron.

System Context

Intended as a local, offline-friendly monitoring pipeline: dedicated Ethernet LAN (example 192.168.69.0/24), local broker, local persistence.

Separation of concerns: the ESP32 is a publisher node, while logging/retention lives on the server side, keeping the embedded firmware focused on acquisition + transport.

Architecture / Design Considerations

Decoupling with MQTT: MQTT isolates producers from consumers (logger, GUI, analytics) so you can add subscribers without rewriting the embedded side.

Static network configuration: The reference configuration uses static IPs for both server and ESP32; correctness of interface/IP/gateway settings is central to reliability.

Failure-cost hot spot: Broker reachability and network configuration are the highest-cost failure points: if the broker is unreachable (wrong gateway/IP, interface mismatch), telemetry may be dropped upstream before persistence.

Retention trade-off: Automated cleanup reduces database growth but introduces an operational decision: retention window vs. trend visibility.

Possible Implications

Adding a GUI/visualizer or additional consumers is structurally easy: subscribe to MQTT topics rather than touching embedded code.

If you remove the W5500 Ethernet path, the system shifts from “wired LAN telemetry” to another transport (e.g., Wi-Fi), changing the operational assumptions about stability and network isolation.

Conclusion
A compact reference design that demonstrates an embedded-to-server telemetry chain: BME280 sensing on ESP32, WIZnet W5500 wired Ethernet, MQTT decoupling, and SQLite persistence with simple maintenance automation.

전체 개요

본 프로젝트는 환경 센서(BME280) 값을 ESP32에서 읽고, WIZnet W5500 기반 유선 Ethernet으로 로컬 네트워크에 붙인 뒤, MQTT(Mosquitto) 로 브로커에 발행하고, 서버 측에서 C 기반 Subscriber가 SQLite에 적재하는 형태의 “작지만 끝까지 연결된” 모니터링 파이프라인입니다.

문제의식과 기술적 맥락 재구성

센서 모니터링은 결국 “데이터가 끊기지 않고”, “나중에 확인 가능하게 남고”, “원인 분석이 가능한 형태로 저장되는가”가 핵심입니다.

이 프로젝트는 그 목표를 (1) 임베디드 단순화(발행만), (2) 서버 측 수집/저장 책임 분리, (3) MQTT로 결합도 낮추기로 풀고 있습니다.

기술 흐름 설명

ESP32가 BME280에서 온도/습도/기압을 읽습니다.

ESP32는 W5500을 통해 유선 Ethernet으로 네트워크에 연결됩니다. (SPI 배선/리셋 포함)

ESP32는 MQTT Publisher로 브로커(Mosquitto)에 측정값을 발행합니다.

서버에서 MQTT Subscriber(C)가 메시지를 구독하여 SQLite DB에 저장합니다.

데이터는 timestamp(UTC)와 측정 필드(temperature/pression/humidite)를 가진 테이블에 누적됩니다.

운영 단계에서 DB가 무한히 커지지 않도록 3시간 초과 데이터 삭제 스크립트 및 crontab 자동화 예시가 포함됩니다.

신호 / 데이터 / 동작 순서 중심 설명

신호(센서): I2C로 BME280(SCL=GPIO22, SDA=GPIO21)

전송(네트워크): SPI로 W5500(MOSI=23, MISO=19, SCLK=18, CS=5, RST=4)

데이터 형태(저장): 시간 + 3개 실수값(°C, hPa, %)

동작 순서(의미): “측정 → 발행 → 브로커 큐잉/중계 → 수신/적재”로 분리되어, 임베디드 쪽이 저장 책임을 지지 않습니다.

왜 이런 구조가 나왔는지에 대한 해설

MQTT를 가운데 둔 이유: ESP32(생산자)와 DB 적재/GUI/분석(소비자)을 직접 연결하면, 소비자가 늘 때마다 임베디드를 수정해야 합니다. MQTT는 이 결합도를 낮춰 “구독자 추가”로 확장이 가능합니다.

WIZnet W5500을 쓴 이유(역할 + 선택 이유): 이 설계는 로컬 Ethernet 세그먼트를 전제로 하고, 실제 예시도 192.168.69.0/24 고정 구성을 사용합니다. W5500은 ESP32에 유선 Ethernet 경로를 제공하여, Wi-Fi 의존 없이 “고정 네트워크”를 만들려는 방향성과 맞습니다.

위 문단에서 “유선이 더 안정적이라서” 같은 절대 평가는 피하겠습니다. 다만 정적 IP/게이트웨이 기반 운영을 단순화하려는 의도는 구조상 자연스럽게 읽힙니다(추론임).

설계 선택의 배경, 제약 조건, 대안 가능성

제약(운영): 네트워크가 정적 IP를 쓰는 만큼, config.toml과 펌웨어의 IP/gateway/subnet 설정 불일치가 곧 장애가 됩니다. 특히 서버 NIC 이름(예: enp0s25)이 환경마다 달라서 이 부분이 자주 실패 지점이 됩니다.

대안(구조):

데이터 적재를 SQLite 대신 시계열 DB로 바꿀 수도 있지만, 이 프로젝트는 “간단히 로컬에 남긴다”에 최적화되어 보입니다(추론임).

브로커를 로컬이 아니라 별도 장비로 옮기면, 네트워크 장애 시나리오가 훨씬 늘어납니다. 현재는 localhost:1883 기준으로 복잡도를 낮춘 형태입니다.

실패 비용이 큰 판단 지점 (핵심)

가장 큰 실패 비용 구간은 “ESP32 ↔ 브로커 연결 성립”입니다.
IP/gateway/subnet이 맞지 않거나, 서버 측 인터페이스/브로커가 기대대로 떠 있지 않으면, 그 다음 단계(SQLite 적재)는 아무 의미가 없어집니다. 즉, 장애가 나면 “저장이 안 되는 장애”로 바로 귀결됩니다.

그 다음 비용 구간은 데이터 보존 정책(자동 삭제) 입니다. 운영자가 의도한 보존 기간과 실제 purge 기준이 어긋나면, 나중에 “왜 데이터가 없지?”가 됩니다.

보조 수단으로서의 위치 (왜 ‘중심’이 아니라 ‘보조’인가)

이 시스템에서 ESP32 노드는 데이터 생산자로서의 역할에 머무르고, “정합성/보존/조회”의 중심 책임은 서버 쪽으로 넘어갑니다. 즉, 임베디드는 전체 시스템의 ‘두뇌’가 아니라 센서 단말(보조 수단) 로 위치합니다.

특정 구성요소 제거 시 시스템 성격 변화

W5500 제거 시: “유선 고정 네트워크 기반” 전제가 깨지며, Wi-Fi 등 다른 전송 경로로 설계를 재정의해야 합니다. 네트워크 격리/주소 계획/장애 모델이 바뀝니다.

MQTT 제거 시: ESP32가 서버 DB로 직접 전송해야 하므로, 임베디드 펌웨어가 “저장 대상/프로토콜/재전송 정책”까지 떠안게 되어 복잡도가 급상승합니다(추론임).

정리 스크립트 제거 시: 데이터는 쌓이기만 하고, 운영자가 언젠가 DB 용량/성능 문제를 직접 맞게 됩니다.

내부 관점에서의 시사점

이 프로젝트의 강점은 “화려함”이 아니라, 끝까지 연결되는 최소 기능을 갖춘 점입니다: 센서 → 네트워크 → 메시징 → 저장 → 유지보수 자동화.

다음 확장 포인트는 보통 2가지입니다.

구독자 추가(시각화/알람): MQTT 구조 덕분에 임베디드 수정 없이 확장 가능합니다.

신뢰성(재연결/버퍼링): 현재 README 기준으로는 “연결 실패 시 데이터 유실을 어떻게 다루는지”가 명시되어 있지 않아, 운영 요구가 생기면 보강이 필요해 보입니다(추론임).

FAQ

기존에 ESP32가 Wi-Fi가 있는데, 왜 W5500으로 유선을 붙였을까요?
로컬 Ethernet 고정 구성(정적 IP, 고정 게이트웨이)을 전제로 설계되어 있어, 네트워크 계획을 단순화하려는 의도가 읽힙니다(추론임). 또한 W5500은 ESP32에 “유선 인터페이스”를 명확히 부여하는 구성요소로 시스템 경계를 분명하게 합니다.

이 구조에서 가장 실패 비용이 큰 지점은 어디인가요?
ESP32가 브로커(Mosquitto)에 제대로 붙지 못하는 순간(주소/게이트웨이/브로커 상태)이 가장 치명적입니다. 이 구간이 깨지면 저장(SQLite)까지 데이터가 도달하지 못하므로 “로그가 남지 않는 장애”가 됩니다.

MQTT를 쓰면 무엇이 달라지나요? (기존 접근 대비 차별점)
ESP32가 DB나 특정 서버 프로그램에 직접 맞물리지 않게 됩니다. 그 결과, 로깅/GUI/분석 같은 소비자를 늘릴 때 임베디드를 건드리지 않고 “구독자 추가”로 확장할 수 있습니다.

핵심 데이터 흐름을 한 줄로 요약하면 어떻게 되나요?
“BME280 측정값 → ESP32 발행 → MQTT 브로커 중계 → 서버 Subscriber 수신 → SQLite 적재”입니다. README에 ASCII 아키텍처로도 같은 흐름이 제시되어 있습니다.

왜 ESP32가 저장까지 하지 않고 ‘보조 수단’처럼 동작하나요?
이 설계는 저장/보존/정리 책임을 서버로 넘겨 임베디드를 단순하게 유지합니다. 임베디드는 측정과 전송에 집중하고, 데이터 수명 관리(예: 3시간 초과 삭제)는 서버 자동화로 처리합니다.

구성요소 하나를 빼면 성격이 가장 크게 바뀌는 것은 무엇인가요?
W5500을 제거하면 “유선 LAN 기반” 전제가 무너져 전송 경로 설계를 다시 해야 합니다. MQTT를 제거하면 임베디드가 직접 저장 프로토콜/재전송까지 떠안게 되어 복잡도가 크게 증가합니다(추론임).

저자 정보 (Author Information)

저장소 소유자는 GitHub 사용자 clement-dev-sys로 표시되며, 프로필에 Clément Penn이라는 이름이 함께 노출됩니다.

공개된 범위에서 확인되는 기술 배경은 C/C++, Linux, 임베디드 시스템, Git 등의 역량을 나열하고 있으며(세부 경력/직무는 별도 검증 정보가 제한적입니다), 본 프로젝트는 그 중 임베디드 + 네트워크 + 서버 로깅 조합을 직접 구현한 형태로 보입니다(추론임).

추가적인 소속/기관 정보는 이 링크들만으로는 확인이 제한적입니다.