---
title: "ESP32 Environmental Monitoring via WIZnet W5500 Ethernet, MQTT, and SQLite Logging"
url: "https://maker.wiznet.io/josephsr/projects/esp32-environmental-monitoring-via-wiznet-w5500-ethernet-mqtt-and-sqlite-logging/"
markdown_url: "https://maker.wiznet.io/josephsr/projects/esp32-environmental-monitoring-via-wiznet-w5500-ethernet-mqtt-and-sqlite-logging/md"
type: "UCC: User Created Content"
author: "Clément Penn"
author_url: "https://github.com/clement-dev-sys/sensor-monitoring-system"
editor: "WIZnet"
editor_url: "https://maker.wiznet.io/"
original_author: "Clément Penn"
original_url: "https://github.com/clement-dev-sys/sensor-monitoring-system"
published: "2026-01-23"
language: "en"
likes: 0
views: 397
comments: 0
source: "WIZnet Makers (https://maker.wiznet.io/)"
---

# ESP32 Environmental Monitoring via WIZnet W5500 Ethernet, MQTT, and SQLite Logging

> An ESP32 + BME280 node publishes environmental telemetry over WIZnet W5500 Ethernet to an MQTT broker

Original author: Clément Penn (source: https://github.com/clement-dev-sys/sensor-monitoring-system)

## Article

**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 ContentSensing:** 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 ConsiderationsDecoupling 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.

---

### 전체 개요

![](https://maker.wiznet.io/upload/ckeditor5/847019692%5F1769434222%2Epng)

*image generated by gpt*

본 프로젝트는 **환경 센서(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 등의 역량을 나열하고 있으며(세부 경력/직무는 별도 검증 정보가 제한적입니다), 본 프로젝트는 그 중 **임베디드 + 네트워크 + 서버 로깅** 조합을 직접 구현한 형태로 보입니다(추론임).

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

---

Source: https://maker.wiznet.io/josephsr/projects/esp32-environmental-monitoring-via-wiznet-w5500-ethernet-mqtt-and-sqlite-logging/