LOKOTEPEV1 GatewayV1R1: W5500 기반 LoRa TPMS Gateway with MQTT Ethernet Uplink

요약

LOKOTEPEV1 GatewayV1R1은 LoRa 기반 TPMS Gateway Firmware 프로젝트입니다.
TPMS는 Tire Pressure Monitoring System의 약자로, 타이어 압력, 온도, 배터리 상태 등을 모니터링하는 시스템입니다.

이 프로젝트에서 Gateway는 LoRa Node로부터 타이어 압력, 온도, 배터리 전압 데이터를 수신하고, WIZnet W5500 Ethernet을 통해 Cloud MQTT Broker로 데이터를 전송합니다.

이 사례가 중요한 이유는 W5500이 단순한 Ethernet 추가 모듈로 사용된 것이 아니라, 현장형 IoT Gateway의 안정적인 Cloud Uplink 경로로 사용되었다는 점입니다.
Wi-Fi는 설정, OTA Update, NTP 동기화에만 사용되고, 실제 TPMS 데이터 전송은 W5500 기반 Ethernet을 통해 이루어집니다.

Original Source: https://github.com/irhamre/LOKOTEPEV1/tree/main/GatewayV1R1

원본에서 확인되는 주요 사실

• 프로젝트는 LOKOTEPEV1 저장소의 GatewayV1R1 Firmware입니다.
• Gateway Firmware는 W5500 Edition으로 구성되어 있습니다.
• 주요 하드웨어는 ESP32-C3 Mini, LoRa SX1276, WIZnet W5500, DS3231 RTC, LittleFS로 구성됩니다.
• W5500은 MQTT Cloud Uplink를 위한 Ethernet Controller로 사용됩니다.
• Wi-Fi는 TPMS 데이터 전송이 아니라 설정, OTA Update, NTP 동기화에 사용됩니다.

이 프로젝트가 중요한 이유

차량, 물류, 광산, 농업 장비, 산업용 운송 장비에서는 타이어 상태 모니터링이 중요합니다.
타이어 압력이나 온도 이상은 안전 문제, 장비 고장, 운행 중단, 유지보수 비용 증가로 이어질 수 있습니다.

TPMS Node가 차량 또는 장비 근처에서 데이터를 무선으로 보내는 것은 효율적입니다.
그러나 Gateway가 데이터를 수집한 이후 Cloud나 Monitoring Server로 전송하는 구간은 더 안정적인 통신이 필요합니다.

LOKOTEPEV1 GatewayV1R1은 이 구조를 다음과 같이 구성합니다.

LoRa: 현장 TPMS Node 데이터 수집
W5500 Ethernet: Cloud MQTT Broker로 안정적인 데이터 전송

즉, 이 프로젝트는 무선 센서 수집과 유선 Cloud Uplink를 결합한 Hybrid IoT Gateway 구조를 보여줍니다.

하드웨어 구성

이 Gateway는 LoRa SX1276과 W5500이 같은 SPI Bus를 공유하고, 각각 별도의 Chip Select Line을 사용하는 구조입니다.
이 방식은 제한된 MCU Pin을 효율적으로 사용하면서도 LoRa 무선 수신과 Ethernet 유선 업링크를 하나의 Gateway 안에 구현할 수 있게 합니다.

네트워크 구조

이 프로젝트는 Ethernet과 Wi-Fi의 역할을 명확하게 분리합니다.

W5500 Ethernet

W5500은 MQTT 데이터 전송을 위한 주요 Cloud Uplink 경로입니다.
Gateway는 Ethernet을 통해 Cloud MQTT Broker에 TPMS 데이터를 전송하며, DHCP 또는 Link 연결이 실패할 경우 자동으로 재시도하는 구조를 가집니다.

Wi-Fi

Wi-Fi는 TPMS 데이터 전송에 사용되지 않습니다.
대신 설정 Portal, OTA Firmware Update, NTP 시간 동기화와 같은 보조 기능에 사용됩니다.

이 구조는 중요한 데이터를 Wi-Fi에 의존하지 않고, 안정적인 유선 Ethernet으로 전송한다는 점에서 현장형 IoT Gateway에 적합합니다.

3단계 데이터 리포팅 구조

LOKOTEPEV1 GatewayV1R1의 강점은 단순히 센서 데이터를 MQTT로 보내는 수준에 그치지 않는다는 점입니다.
실제 모니터링 시스템에 필요한 데이터 리포팅 구조를 갖추고 있습니다.

Layer 1: Heartbeat

각 Paired Node는 일정 주기마다 타이어 데이터를 묶어서 전송합니다.
이를 통해 시스템은 Node가 정상적으로 살아 있는지 확인할 수 있습니다.

Layer 2: Immediate Event

타이어 압력, 온도, 배터리 전압이 설정된 임계값 이상으로 변하면 Gateway는 즉시 MQTT로 데이터를 전송합니다.
이 기능은 이상 상태를 빠르게 감지해야 하는 차량, 광산 장비, 산업용 장비 모니터링에 유용합니다.

Layer 3: Offline Changelog

Ethernet 또는 MQTT 연결이 일시적으로 불가능한 경우, Gateway는 변경된 데이터를 LittleFS의 Offline Changelog Buffer에 저장합니다.
연결이 복구되면 저장된 데이터를 Replay Message로 다시 전송합니다.

이 구조는 현장 네트워크가 항상 안정적이지 않다는 현실을 반영합니다.
연결이 끊겼을 때 데이터를 잃지 않고, 복구 후 다시 전송할 수 있다는 점에서 실제 운영 환경에 적합합니다.

RTC 기반 Timestamp의 중요성

이 프로젝트는 DS3231 RTC를 사용하여 절대 시간을 기록합니다.
MQTT Payload에는 Unix Timestamp와 사람이 읽을 수 있는 Datetime 값이 포함될 수 있습니다.

단순히 MCU의 millis() 값만 사용하는 경우, 재부팅이나 장시간 오프라인 상황에서 시간 정보가 불안정해질 수 있습니다.
반면 RTC를 사용하면 네트워크가 끊겨 있거나 Gateway가 재시작된 이후에도 의미 있는 시간 정보를 유지할 수 있습니다.

TPMS 모니터링에서는 압력, 온도, 배터리 이벤트가 언제 발생했는지 추적하는 것이 중요하기 때문에 RTC 기반 Timestamp는 매우 실용적인 설계입니다.

MQTT 데이터 구조

이 프로젝트는 MQTT Topic을 통해 TPMS 데이터를 전송합니다.

예시 Topic 구조는 다음과 같습니다.

tpms/<NODE_ID>
tpms/gateway/<CHIP_ID>/status

Payload에는 Node ID, Pairing 상태, RF 신호 레벨, Publish Mode, Timestamp, 타이어 압력, 온도, 배터리 전압, BLE RSSI 등의 정보가 포함될 수 있습니다.

특히 publish_mode 값을 통해 해당 데이터가 정기 Heartbeat인지, 즉시 Event인지, 또는 Offline Changelog에서 복구된 Replay 데이터인지 구분할 수 있습니다.

이 구조는 Dashboard, Fleet Monitoring Server, Alert System, Database, Custom Backend Platform과 연동하기에 적합합니다.

W5500이 이 프로젝트에 적합한 이유

LOKOTEPEV1 GatewayV1R1의 Gateway는 여러 기능을 동시에 수행합니다.

• LoRa Packet 수신
• TPMS Node Pairing 상태 관리
• MQTT Topic 및 Payload 구성
• Offline Changelog 저장
• RTC 기반 시간 관리
• Wi-Fi 설정 Portal
• OTA Update
• Serial Diagnostics

이처럼 Gateway가 이미 많은 기능을 처리해야 하기 때문에, 안정적인 Ethernet 통신을 W5500에 맡기는 구조는 실용적입니다.

W5500은 Hardwired TCP/IP 기반 Ethernet Controller로, Host MCU가 네트워크 처리에 과도한 리소스를 쓰지 않도록 도와줍니다.
또한 Arduino Ethernet Library 기반 개발 흐름과도 잘 맞아 PlatformIO 환경에서 유지보수하기 쉬운 구조를 제공합니다.

활용 가능한 시나리오

1. Fleet Tire Monitoring Gateway

여러 차량의 TPMS Node 데이터를 수집하고, Ethernet을 통해 중앙 MQTT Broker로 전송하는 Fleet Monitoring Gateway로 활용할 수 있습니다.

2. Mining Vehicle Monitoring

광산 차량은 거친 환경에서 장시간 운행되기 때문에 타이어 압력과 온도 모니터링이 중요합니다.
LoRa 기반 TPMS Node와 W5500 Ethernet Gateway를 조합하면 장비 상태 데이터를 안정적으로 수집할 수 있습니다.

3. 물류센터 및 산업 현장 차량 모니터링

물류센터, 항만, 공장, 산업단지에서 운행되는 차량의 타이어 상태를 모니터링하는 용도로 사용할 수 있습니다.
Gateway를 유선 네트워크가 있는 지점에 설치하면 Cloud나 내부 서버로 데이터를 안정적으로 전송할 수 있습니다.

4. 농업 및 중장비 모니터링

농기계나 중장비는 장시간 운행되는 경우가 많고, 타이어 상태가 작업 효율과 안전에 영향을 줄 수 있습니다.
이 프로젝트 구조는 농업 장비나 건설 장비의 상태 모니터링에도 응용할 수 있습니다.

5. Private MQTT Monitoring System

MQTT를 사용하기 때문에 자체 Dashboard, Database, Alert System, Maintenance Platform과 쉽게 연동할 수 있습니다.

차별화 포인트

이 프로젝트의 핵심 차별점은 네트워크 구조입니다.

많은 IoT 프로젝트는 Wi-Fi를 Cloud 연결의 기본 경로로 사용합니다.
하지만 LOKOTEPEV1 GatewayV1R1은 Wi-Fi를 설정과 유지보수 기능으로 제한하고, 실제 TPMS 데이터 전송은 W5500 Ethernet을 통해 수행합니다.

즉, 중요한 데이터는 안정적인 유선망으로 전송하고, Wi-Fi는 보조 기능으로 활용하는 구조입니다.
이 점에서 LOKOTEPEV1 GatewayV1R1은 일반적인 ESP32 IoT 예제보다 현장 적용성이 높은 Gateway 사례라고 볼 수 있습니다.

WIZnet Use Case로서의 가치

이 프로젝트는 WIZnet W5500이 Hybrid IoT Gateway의 안정적인 유선 Backbone으로 사용될 수 있음을 보여줍니다.

단순히 ESP32에 Ethernet을 추가하는 예제가 아니라, LoRa 기반 현장 Node와 Cloud MQTT 시스템 사이에서 W5500이 신뢰성 있는 데이터 업링크를 담당합니다.

또한 다음과 같은 기능들이 포함되어 있어 실제 현장형 Gateway 설계에 참고할 가치가 있습니다.

• LoRa 기반 TPMS Node 데이터 수집
• W5500 Ethernet 기반 MQTT Uplink
• RTC 기반 Timestamp
• Offline Changelog Buffer
• 네트워크 복구 후 Replay Message 전송
• Wi-Fi Configuration Portal
• OTA Firmware Update
• Serial Diagnostics 및 상태 확인 기능

이러한 요소는 W5500이 단순한 Ethernet 모듈이 아니라, 산업용·차량용·현장형 IoT Gateway의 핵심 네트워크 인터페이스로 활용될 수 있음을 보여줍니다.

유사 Maker 콘텐츠와 차별점

FAQ

LOKOTEPEV1 GatewayV1R1은 어떤 프로젝트인가요?

LOKOTEPEV1 GatewayV1R1은 LoRa 기반 TPMS Gateway Firmware 프로젝트입니다. TPMS Node에서 타이어 압력, 온도, 배터리 데이터를 수신하고 WIZnet W5500 Ethernet을 통해 MQTT Cloud Broker로 전송합니다.

LoRa는 어떤 역할을 하나요?

LoRa는 TPMS Node에서 전송되는 타이어 압력, 온도, 배터리 데이터를 Gateway가 수신하기 위한 무선 통신 역할을 합니다.

Wi-Fi는 TPMS 데이터 전송에 사용되나요?

아닙니다. 이 프로젝트에서 Wi-Fi는 설정 Portal, OTA Update, NTP 동기화에 사용됩니다. 실제 TPMS 데이터 전송은 W5500 Ethernet을 통해 이루어집니다.

Ethernet 또는 MQTT 연결이 끊기면 어떻게 되나요?

Gateway는 변경된 데이터를 LittleFS 기반 Offline Changelog Buffer에 저장하고, 연결이 복구되면 저장된 데이터를 Replay Message로 다시 전송합니다.

Keywords

WIZnet W5500, LoRa TPMS Gateway, MQTT Ethernet Uplink, Offline Changelog, Industrial IoT

LOKOTEPEV1 GatewayV1R1: W5500-Based LoRa TPMS Gateway with MQTT Ethernet Uplink

Summary

LOKOTEPEV1 GatewayV1R1 is a firmware project for a LoRa-based TPMS gateway. TPMS stands for Tire Pressure Monitoring System.
The gateway collects tire pressure, temperature, and battery voltage data from LoRa nodes, then publishes the data to a cloud MQTT broker through wired Ethernet using WIZnet W5500.

This project is a strong WIZnet use case because W5500 is not used as a simple Ethernet add-on. It becomes the main cloud uplink path for a field-oriented gateway system. Wi-Fi is used only for configuration, OTA update, and NTP synchronization, while TPMS data publishing is always handled through Ethernet.

Original source: https://github.com/irhamre/LOKOTEPEV1/tree/main/GatewayV1R1

Why This Project Matters

Vehicle monitoring systems need stable communication.
In fleet, logistics, mining, agricultural, and industrial vehicle environments, tire pressure and temperature data can be important for safety, maintenance, and downtime reduction.

Wireless communication is useful near the vehicle because tire sensor nodes can send data without cables. However, once the gateway collects that data, the uplink to the cloud should be as stable as possible.

This is where WIZnet W5500 is used.

The LOKOTEPEV1 GatewayV1R1 project uses LoRa for local TPMS node communication and W5500 Ethernet for MQTT cloud uplink. This creates a practical hybrid network architecture:

LoRa for field sensor collection
Ethernet for reliable cloud publishing

Hardware Architecture

The gateway shares the SPI bus between the LoRa SX1276 and W5500. Each device uses its own chip select line. This is a practical design choice because it reduces pin usage while allowing both wireless sensing and wired Ethernet uplink in the same compact gateway.

Network Architecture

The project clearly separates the role of Ethernet and Wi-Fi.

Ethernet with W5500

W5500 is the main path for MQTT data publishing.
The gateway uses Ethernet for cloud uplink and automatically retries when DHCP or link connection is not available.

Wi-Fi

Wi-Fi is not used for TPMS data publishing.
It is used only for supporting functions such as configuration portal, OTA firmware update, and NTP time synchronization.

This separation makes the system more reliable.
The critical data path uses wired Ethernet, while Wi-Fi remains available only for maintenance and configuration.

Three-Layer Data Reporting Model

One of the strongest parts of this project is that it is not a basic sensor-to-cloud example.
It includes a practical reporting model for real monitoring systems.

Layer 1: Heartbeat

Each paired node periodically sends bundled tire data even when there is no major change.
This lets the system know that the node is still alive.

Layer 2: Immediate Event

When tire pressure, temperature, or battery voltage changes beyond a defined threshold, the gateway immediately publishes the data to MQTT.
This is useful for detecting abnormal conditions faster than waiting for the next regular interval.

Layer 3: Offline Changelog

If Ethernet or MQTT is unavailable, the gateway stores changed values into an offline changelog buffer in LittleFS.
When the connection is restored, the gateway forwards stored entries as replay messages.

This design is important because field networks are not always perfect.
Instead of losing data during outages, the gateway keeps a local history and sends it later.

Timestamp Reliability with RTC

The project uses a DS3231 RTC to provide absolute timestamps.
Each MQTT payload includes Unix timestamp and human-readable datetime values.

This is more reliable than using only millis() because the gateway may reboot or stay offline for a long period. The RTC allows the system to maintain meaningful time information even when network access is temporarily unavailable.

For a TPMS monitoring system, accurate time is important because pressure, temperature, and battery events must be analyzed in sequence.

Example MQTT Data Structure

The project publishes data using MQTT topics such as:

tpms/<NODE_ID>
tpms/gateway/<CHIP_ID>/status

A payload can include node ID, pairing status, RF signal level, publish mode, timestamp, and tire data such as pressure, temperature, battery voltage, and BLE RSSI.

The publish_mode field can indicate whether the data is a normal heartbeat, an immediate event, or a replay from the offline changelog.

This makes the system easier to integrate into a dashboard, fleet monitoring server, or maintenance platform.

Why W5500 Is a Good Fit

W5500 is a strong fit for this project because the gateway already performs several tasks:

• Receives LoRa packets from TPMS nodes
• Maintains paired node status
• Handles MQTT topic structure
• Stores offline changelog entries
• Manages RTC time
• Supports Wi-Fi configuration and OTA update

By using W5500 for Ethernet communication, the project can keep the cloud uplink stable while reducing the burden of implementing network behavior only in software.

W5500 also supports a familiar Arduino Ethernet library workflow, which helps make the firmware easier to maintain in PlatformIO-based development.

Application Scenarios

1. Fleet Tire Monitoring Gateway

The gateway can be used to collect TPMS data from vehicles and send it to a central MQTT broker through Ethernet.

2. Mining Vehicle Monitoring

Mining vehicles often operate in harsh environments where stable infrastructure communication is important.
A LoRa-to-Ethernet TPMS gateway can help collect tire data from equipment and forward it to a monitoring system.

3. Industrial Yard or Logistics Site

For vehicles operating in depots, ports, factories, or logistics yards, the gateway can be installed near parking or service areas and connected to a wired network.

4. Agriculture and Heavy Equipment Monitoring

Large agricultural equipment can benefit from tire pressure and temperature monitoring, especially when vehicles operate over long hours and difficult terrain.

5. Private MQTT-Based Monitoring System

Because the project uses MQTT, it can be integrated with dashboards, databases, alert systems, or custom backend platforms.

Differentiation Point

The key value of this project is the network architecture.

Many IoT projects use Wi-Fi as the main cloud connection.
LOKOTEPEV1 GatewayV1R1 takes a different approach. It uses Wi-Fi only for setup and maintenance, while W5500 Ethernet handles the important TPMS data uplink.

This is a more field-oriented architecture for applications where data reliability matters.

Why It Is a Good WIZnet Use Case

This project shows WIZnet W5500 in a practical gateway architecture.

It is not only about adding Ethernet to ESP32.
It demonstrates how W5500 can serve as the reliable wired backbone of a hybrid IoT gateway that connects wireless field nodes to a cloud MQTT system.

The project also includes features that make it more realistic than a basic example:

• LoRa wireless node collection
• W5500 Ethernet MQTT uplink
• RTC-based timestamping
• Offline changelog buffer
• Replay after network recovery
• Configuration portal and OTA support
• Serial diagnostics and status commands

These details make the project valuable for developers who want to build industrial or fleet-oriented IoT gateways.

FAQ

What is LOKOTEPEV1 GatewayV1R1?

LOKOTEPEV1 GatewayV1R1 is a LoRa-based TPMS gateway firmware project that publishes tire monitoring data to a cloud MQTT broker through WIZnet W5500 Ethernet.

What is the role of LoRa in this project?

LoRa is used to receive tire pressure, temperature, and battery data from TPMS nodes.

Is Wi-Fi used for TPMS data publishing?

No. In this project, Wi-Fi is used for configuration, OTA update, and NTP synchronization. TPMS data publishing is handled through Ethernet using W5500.

What happens when Ethernet or MQTT is offline?

The gateway stores changed values in an offline changelog buffer and forwards the stored entries when the connection is restored.

Keywords

WIZnet W5500, LoRa TPMS Gateway, MQTT Ethernet Uplink, Offline Changelog, Industrial IoT