Wiznet makers

요약

베트남 Long An 성의 Vam Co 강 유역은 매년 건기마다 해수 염분이 수십 킬로미터 내륙까지 침투하는 피해를 반복한다. 이 저장소는 그 최전선에서 운용되는 무인 현장 관측 스테이션 펌웨어로, ESP32 + W5500 + 4G 모듈의 하이브리드 구조를 통해 6종의 수질·기상 센서 데이터와 Hikvision IP 카메라 스냅샷을 한 사이클로 수집해 원격 서버에 전달한다. 공개 보도는 확인되지 않으나, 코드 구조와 변경 이력으로 미루어 실제 현장 배포를 목적으로 개발된 실전 프로젝트임이 분명하다.

개요: 논밭을 삼키는 소금물

Long An 성은 메콩강 삼각주 북단, 호찌민시와 맞닿은 저지대 농업 지역이다. 이 지역을 관통하는 Vam Co Dong·Vam Co Tay 두 강줄기는 건기마다 남중국해에서 밀려오는 소금물의 통로가 된다. 2020년 건기, 베트남 기상수자원연구소의 관측에 따르면 염도 4‰의 해수가 80~110km 내륙까지 침투했고, Long An 성 전역에서 수만 명이 식수 부족을 겪었으며 농경지와 양식장이 광범위하게 피해를 입었다.

이 프로젝트의 저장소명 **"CanhbaongapLongAn"**은 베트남어로 "Long An 침수 경보"를 뜻한다. 개발 시점이 2020년 2월 — 역대 최악의 염분 침투 재해가 본격화된 바로 그 시기 — 와 겹친다는 점은 우연이 아니다. 시스템이 측정하는 파라미터 역시 이 위기와 직결된다: 염분, pH, 수온, 수위 네 가지는 염분 침투 탐지와 수질 안전성 판단에 필수적이고, 풍향·풍속은 해수 역류 예측에 활용된다.

참고: Long An 성 염분 침투 재해 선포 보도 → https://vnexpress.net/long-an-cong-bo-xam-nhap-man-khan-cap-4735647.html

아키텍처: 세 채널이 분리된 이유

이 시스템은 목적이 다른 세 가지 통신 경로를 병렬로 운용한다.

동작 시퀀스는 단순하다. 딥슬립에서 깨어나면 RS485로 센서 데이터를 수집하고, W5500을 통해 Hikvision 카메라에 FTP로 접속해 현장 스냅샷을 취득한 뒤, 4G 모듈로 수집된 데이터와 이미지를 서버에 전송하고 다시 딥슬립에 진입한다. 실시간 영상 스트리밍이 아닌 FTP 기반 정지 이미지 취득이 핵심이다. 딥슬립 구조는 지속적인 연결을 불가능하게 하고, 야외 태양광·배터리 환경에서 RTSP 스트리밍은 전력 예산을 초과한다.

기술 배경

Modbus RTU: 센서 6종을 하나의 선로로

Modbus RTU는 1979년 Modicon이 정의한 산업용 직렬 통신 프로토콜로, RS485 물리 계층 위에서 마스터-슬레이브 구조로 동작한다. 마스터(ESP32)가 슬레이브 주소를 지정해 순차적으로 폴링하면, 각 센서는 자신의 레지스터 값을 응답하는 방식이다. 선로 하나에 최대 247개 슬레이브를 연결할 수 있어 다중 센서 배선을 대폭 단순화한다.

이 프로젝트에서 Modbus RTU는 이종 센서 6종 — 염분, pH, 수온, 수위, 풍향, 풍속 — 을 단일 RS485 버스로 묶는 역할을 한다. 각 센서가 별도 UART를 점유하지 않아 ESP32의 핀 자원을 절약하고, 센서 추가 시 주소만 변경하면 된다는 유지보수 이점도 크다.

참고: → https://iwaponline.com/jh/article/23/2/324/79285/Design-of-an-automatic-hydro-meteorological

W5500 하드웨어 TCP/IP: FTP 스냅샷을 안정적으로 처리하는 방법

W5500은 TCP/IP 프로토콜 스택 전체를 하드웨어 실리콘으로 구현한 이더넷 컨트롤러다. 소프트웨어 스택(lwIP)이 MCU의 CPU 사이클과 SRAM을 소비하는 것과 달리, W5500은 8개의 독립 하드웨어 소켓을 내장하여 네트워크 처리를 MCU와 완전히 분리한다.

이 시스템에서 W5500이 담당하는 FTP 세션은 두 단계 TCP 연결 — 제어 채널과 데이터 채널 — 을 동시에 유지해야 한다. 소프트웨어 스택 기반이라면 메모리 경합이나 타이밍 이슈가 발생할 수 있는 구간이지만, W5500의 하드웨어 소켓은 두 채널을 독립적으로 관리하므로 안정성이 보장된다. Readme.txt에 기록된 socket → closesocket (ftp, kbvison_cam) 수정 이력은 실제 현장 디버깅 과정에서 이 FTP 소켓 관리가 핵심 과제였음을 보여준다.

ESP32 딥슬립과 W5500 재초기화

ESP32의 딥슬립은 소비 전류를 수십 µA 수준으로 낮추어 태양광·배터리 기반 야외 스테이션의 장기 운용을 가능하게 한다. 그러나 딥슬립에서 복귀할 때마다 SPI 페리페럴이 초기화되므로, W5500 역시 매 사이클마다 재초기화가 필요하다. 하드웨어 CS(Chip Select) 제어 수정이 Readme.txt에 별도로 기록된 이유가 여기에 있다. 유사한 ESP32 + W5500 프로젝트들에서도 케이블 미연결 시 Ethernet.begin 호출에 최대 60초 지연이 발생하는 것으로 보고되어 있어, 재초기화 타임아웃 설계가 실전 운용의 핵심 변수다.

기술 특징: 내장 WiFi를 두고 W5500을 선택한 설계 판단

ESP32는 WiFi와 블루투스를 내장하고 있다. 그럼에도 이 프로젝트는 카메라 통신에 W5500 유선 Ethernet을 별도로 배정했다. 이 선택에는 세 가지 실질적 근거가 있다.

• RF 채널 충돌 회피: ESP32의 내장 WiFi와 4G 모듈이 2.4GHz 대역에서 동시에 동작하면 간섭이 발생할 수 있다. W5500 유선 Ethernet은 RF를 사용하지 않으므로 4G 모듈과 무간섭으로 공존한다
• FTP 세션 안정성: Hikvision IP 카메라의 FTP 서버는 연결 지속성에 민감하다. WiFi 기반 연결은 실외 환경에서 신호 변동에 따라 세션이 끊길 수 있는 반면, 유선 Ethernet은 물리 계층부터 안정적이다
• 소프트웨어 복잡도 절감: ESP32 WiFi 드라이버와 lwIP 스택을 FTP 클라이언트에 연동하는 것보다, W5500의 하드웨어 소켓 API로 FTP를 직접 구현하는 편이 코드 복잡도와 디버깅 부담이 낮다

WIZnet 적용: 로컬 Ethernet 전용 컨트롤러

이 프로젝트에서 W5500은 인터넷 연결 모듈이 아니다. 인터넷은 4G 모듈이 담당한다. W5500의 역할은 ESP32와 Hikvision IP 카메라 사이의 로컬 Ethernet 세그먼트를 전용으로 관리하는 것이다. SPI 인터페이스로 ESP32와 연결되고, RJ45 포트로 카메라와 직결된다.

실제 사용 구조 요약:

이처럼 W5500을 WAN 연결이 아닌 로컬 장치 통신 전용으로 사용하는 구조는 WIZnet 생태계에서 보기 드문 활용 사례다. 하드웨어 TCP/IP 오프로딩이 "인터넷"이 아닌 "현장 내 안정적 유선 통신"을 위해 선택된 점이 이 프로젝트의 기술적 특이점이다.

WIZnet Makers 유사 사례

동일한 ESP-IDF + W5500 조합의 선행 사례는 maker.wiznet.io에서 발견되지 않았다 (Priority 1 미충족). 하드웨어 구조와 기능 유사성을 기준으로 아래 세 프로젝트가 유사 사례로 선정된다.

TEMPO: IoT Edge Device — ESP32 Wroom + W5500(SPI) + SIM800L 셀룰러 모듈 + DHT22 센서를 결합한 IoT 엣지 디바이스. 이 프로젝트와 동일한 "ESP32 + W5500 + 셀룰러 + 환경 센서 → 원격 서버" 하드웨어 패턴을 공유한다. 차이는 SIM800L(2G) vs 4G 모듈, 단일 온습도 센서 vs RS485 다중 센서 구성이다

→ TEMPO: https://maker.wiznet.io/scott/resellers/tempo-your-next-level-iot-edge-device/

ESP32-CAM + W5500 HSPI — ESP32 + W5500 조합으로 카메라 데이터를 유선 Ethernet 경유 전송하는 구조를 다룬다. 이 프로젝트의 "ESP32 + W5500으로 카메라와 통신" 패턴을 가장 직접적으로 보여주는 사례다. 차이는 내장 카메라 모듈(ESP32-CAM) vs Hikvision 외부 IP 카메라(FTP 방식)다

→ ESP32-CAM + W5500: https://maker.wiznet.io/lawrence/projects/esp32-cam-using-hspi-interface-and-w5500-module/

Water Level Monitor (ESP32/W5500 + Deep Sleep) — W5500 + ESP32 + 야외 수위 센서 + 딥슬립 조합으로 장기 저전력 운용을 구현한다. 수질 모니터링이라는 기능적 맥락과 딥슬립 설계 방식이 이 프로젝트와 일치한다. 차이는 단일 초음파 수위 센서 vs RS485 6종 복합 센서다

세 사례 모두 **"WiFi 없이 W5500으로 안정적 유선 통신을 확보한다"**는 동일한 설계 판단을 공유한다. 이는 실외·산업 환경에서 W5500이 선택받는 일관된 이유다.

→ Water Level Monitor: https://maker.wiznet.io/2022/02/03/water-level-monitor-arduino-esp8266-esp32-sigfox/

비즈니스 가치

메콩강 삼각주는 세계 3대 삼각주로 베트남 쌀 생산의 절반, 쌀 수출의 90%를 담당한다. 기후 변화와 상류 댐 건설로 인해 염분 침투 피해는 매년 심화되고 있으며, 베트남은 이미 기후 재난 피해 세계 6위국으로 분류된다. 이 맥락에서 이 시스템이 제공하는 가치는 다음과 같다.

• 농업 피해 조기 예방: 염분 농도와 수위 실시간 모니터링으로 농민·지자체가 수문 개폐, 취수 중단 등 선제 조치를 취할 수 있는 시간을 확보
• 정부 재난 대응 인프라: 기존 지상 관측 인력을 대체하는 무인 자동 수집 스테이션으로, 복수 지점 동시 모니터링 시 비용 효율이 급격히 개선됨
• 수산 양식 관리: pH·수온·염분 복합 모니터링으로 양식 환경 이상을 조기 감지, 어류 폐사 방지
• 기상·수문 데이터 누적: 풍향·풍속·수위 장기 데이터는 홍수 예측 모델 고도화의 입력값으로 활용 가능

WIZnet 관점에서 이 프로젝트는 동남아시아 농업·수자원 관리 시장에서 W5500의 활용 가능성을 보여주는 사례다. 저전력·저비용·현장 직결 구조는 인프라가 제한된 원격지 배포에 적합하며, 유사 시스템의 대규모 네트워크화로 확장될 경우 WIZnet 칩 수요가 동반 성장할 수 있다.

참고: → 베트남 최초 IoT 수질 모니터링 시스템 (TheSmartLocal, 2020): https://thesmartlocal.com/vietnam/iot-water-monitoring/

→ 메콩 삼각주 염분 침투 위기 분석 (East Asia Forum, 2025): https://eastasiaforum.org/2025/11/22/salinity-intrusion-threatens-vietnams-rice-bowl/

한계 및 개선 방향

이 프로젝트는 실전 배포를 목표로 개발된 만큼 실용적인 구조를 갖추고 있으나, 몇 가지 구조적 한계가 존재한다.

현재 한계:

• 단일 4G 경로 의존: 셀룰러 불통 시 수집 데이터가 유실된다. 재전송 큐나 로컬 버퍼 캐싱 메커니즘이 코드에 존재하는지 확인 불가
• W5500 재초기화 지연: 딥슬립 복귀 후 Ethernet 케이블 상태에 따라 초기화에 수십 초가 소요될 수 있으며, 이 구간의 전력 소비와 타임아웃 처리가 운용 안정성을 결정
• 평문 FTP 보안: 로컬 Ethernet 세그먼트이지만 물리적 접근 위협이 있는 야외 환경에서 평문 FTP는 스니핑 위험을 안고 있음
• Modbus 버스 오류 내성 미확인: 다중 센서 중 한 개가 응답 불량일 때 전체 수집 사이클에 미치는 영향이 소스코드 직접 확인 없이는 불명확

개선 방향:

• 4G 전송 실패 시 스냅샷·센서 데이터를 로컬 플래시(NVS)에 임시 저장 후 다음 사이클에 재전송하는 버퍼 로직 추가
• FTP를 **FTPS(FTP over TLS)**로 전환하거나, HTTP POST + TLS로 이미지 전송 방식 변경
• W5500 WOL(Wake on LAN) 기능을 딥슬립 복귀 트리거와 연동해 재초기화 지연 최소화
• Modbus RTU 폴링 루프에 슬레이브별 타임아웃·재시도 로직을 추가해 단일 센서 장애가 전체 사이클을 블로킹하지 않도록 구성

FAQ

Q. ESP32에 WiFi가 내장되어 있는데 왜 W5500을 추가했나요? 카메라 FTP 통신과 4G 서버 전송이 동시에 동작할 때 ESP32 내장 WiFi와 4G 모듈의 RF 간섭을 피하기 위해서입니다. 또한 Hikvision IP 카메라의 FTP 세션은 연결 안정성이 중요한데, 실외 환경에서 유선 Ethernet이 WiFi보다 세션 유지에 유리합니다.

Q. W5500이 전송하는 것은 실시간 영상인가요? 아닙니다. FTP 프로토콜로 정지 이미지(스냅샷)를 주기적으로 취득하는 구조입니다. 딥슬립을 병행하는 저전력 설계에서 RTSP 실시간 스트리밍은 구조적으로 불가능합니다.

Q. 센서를 추가하거나 교체하려면 어떻게 해야 하나요? RS485 Modbus RTU 버스를 사용하므로, 동일 프로토콜을 지원하는 센서를 버스에 추가하고 Modbus 슬레이브 주소를 지정하면 됩니다. 최대 247개 슬레이브를 하나의 RS485 선로에 연결할 수 있어 확장 자유도가 높습니다.

Q. 야외 설치 시 전원은 어떻게 구성하나요? 딥슬립 구현으로 평균 전류 소비가 크게 낮아집니다. 태양광 패널 + 리튬 배터리 조합이 일반적이며, 딥슬립 주기와 패널 용량을 배전력 예산에 맞게 설계해야 합니다. 전원 구성 스펙은 소스코드에서 확인되지 않습니다.

Q. 서버 측 수신 구조는 어떻게 되어 있나요? 소스코드에서 확인 불가입니다. 4G 모듈로 HTTP POST 또는 TCP 소켓을 통해 데이터를 전송하는 것으로 추정되나, 서버 수신 API·데이터 포맷·시각화 대시보드 구성은 공개되지 않았습니다.

TL;DR

The Vam Co river system in Long An province, Vietnam, suffers recurring saltwater intrusion every dry season. This repository is the firmware for an unmanned field monitoring station deployed at the front line — using an ESP32 + W5500 + 4G hybrid architecture to collect data from six water quality and weather sensors, capture periodic snapshots from a Hikvision IP camera via FTP, and upload everything to a remote server in a single duty cycle. No public press coverage has been found, but the code structure and changelog point clearly to a real-world field deployment.

Overview: When the River Turns Salty

Long An province sits at the northern edge of the Mekong Delta, bordering Ho Chi Minh City. The Vam Co Dong and Vam Co Tay rivers that run through it become conduits for seawater every dry season. In the 2019–2020 dry season — the worst salinity intrusion recorded in the Mekong Delta in recent decades — saltwater at 4‰ salinity pushed 80 to 110 km inland along these rivers. Tens of thousands of residents faced freshwater shortages, and farmland and aquaculture across the province sustained widespread damage.

The repository name "CanhbaongapLongAn" translates directly from Vietnamese as "Long An flood alert." Its development timestamp — February 2020 — coincides exactly with when that crisis peaked. The parameters the system measures are not incidental: salinity, pH, water temperature, and water level are the four metrics most critical for detecting saltwater intrusion and assessing water safety. Wind direction and speed provide additional input for predicting tidal backflow events.

Reference — Long An province declares Level 4 salinity intrusion emergency (VnExpress): → https://vnexpress.net/long-an-cong-bo-xam-nhap-man-khan-cap-4735647.html

Architecture: Why Three Separate Channels

The system runs three communication paths in parallel, each assigned a distinct role.

The duty cycle is straightforward. The ESP32 wakes from deep sleep, collects sensor data over RS485, connects to the Hikvision camera via W5500 Ethernet and retrieves a still image using FTP, then uploads the combined payload through the 4G module and enters deep sleep again. This is periodic FTP-based still image capture — not real-time video streaming. The deep sleep architecture makes continuous RTSP streaming structurally impossible, and the power budget of a solar-and-battery outdoor station rules it out entirely.

Technology Background

Modbus RTU: Six Sensors on a Single Wire

Modbus RTU is an industrial serial communication protocol defined by Modicon in 1979. It operates over the RS485 physical layer in a master-slave architecture. The master — here, the ESP32 — polls each slave by address in sequence. Each sensor responds with its register values. A single RS485 bus supports up to 247 slaves, which dramatically simplifies field wiring for multi-sensor deployments.

In this project, Modbus RTU consolidates six heterogeneous sensors — salinity, pH, water temperature, water level, wind direction, and wind speed — onto a single RS485 bus. No separate UART port is consumed per sensor, which conserves ESP32 GPIO resources. Adding sensors later requires only an address assignment, not a hardware redesign.

Reference: → https://iwaponline.com/jh/article/23/2/324/79285/Design-of-an-automatic-hydro-meteorological

W5500 Hardware TCP/IP: Stable FTP Sessions Without Software Stack Overhead

The W5500 implements the full TCP/IP protocol stack in silicon. Unlike a software stack such as lwIP — which competes with application code for CPU cycles and SRAM — the W5500 provides eight independent hardware sockets that handle network processing entirely separate from the MCU.

FTP requires two simultaneous TCP connections: a control channel and a data channel. A software stack under memory pressure can drop sessions or introduce timing failures at this boundary. The W5500's hardware sockets manage both channels independently, guaranteeing stability. The changelog entry in Readme.txt — socket → closesocket (ftp, kbvison_cam) — confirms that FTP socket management was a central debugging concern during field development.

ESP32 Deep Sleep and W5500 Re-initialization

ESP32 deep sleep reduces current draw to tens of microamps, enabling long-term operation on solar and battery power at remote outdoor sites. However, every wake cycle resets the SPI peripheral — which means the W5500 must be fully re-initialized on every wake-up. The separate changelog entry for spi driver control cs w5500 reflects exactly this challenge. Similar ESP32 + W5500 projects have reported Ethernet.begin call delays of up to 60 seconds when no cable is connected, making re-initialization timeout design a critical factor for reliable field operation.

Technical Highlights: Choosing W5500 Over Built-in WiFi

The ESP32 includes built-in WiFi. Despite this, the project assigns W5500 wired Ethernet exclusively to camera communication. Three practical reasons drive this decision.

• RF channel isolation: ESP32's internal WiFi and the 4G module can interfere when both operate on the 2.4 GHz band simultaneously. W5500 wired Ethernet uses no RF, so it coexists with the 4G module without interference
• FTP session stability: Hikvision IP cameras are sensitive to connection continuity. WiFi in an outdoor environment is subject to signal variation and session drops. Wired Ethernet eliminates this variable at the physical layer
• Reduced software complexity: Bridging the ESP32 WiFi driver and lwIP stack into a working FTP client adds significant integration overhead. Driving FTP directly through the W5500 hardware socket API is simpler to implement and easier to debug

Where WIZnet Fits

The W5500 in this project is not an internet connectivity module — that role belongs to the 4G module. The W5500 manages a dedicated local Ethernet segment between the ESP32 and the Hikvision IP camera. It connects to the ESP32 over SPI and to the camera over a standard RJ45 port.

Using the W5500 as a local device communication controller — rather than a WAN gateway — is an uncommon pattern in the WIZnet ecosystem. The fact that hardware TCP/IP offloading was chosen for reliable local wired communication, not for internet access, is the architectural highlight of this project.

Similar Projects on WIZnet Makers

No prior examples using the identical ESP-IDF + W5500 software stack were found on maker.wiznet.io (Priority 1 unmatched). The following three projects were selected based on hardware structure and functional similarity.

TEMPO: IoT Edge Device — Combines ESP32 Wroom, W5500 (SPI), SIM800L cellular module, and a DHT22 sensor into an IoT edge device. It shares the exact "ESP32 + W5500 + cellular + environmental sensor → remote server" hardware pattern with this project. Differences: SIM800L (2G) vs 4G module; single temperature/humidity sensor vs RS485 multi-sensor array

→ TEMPO: https://maker.wiznet.io/scott/resellers/tempo-your-next-level-iot-edge-device/

ESP32-CAM + W5500 HSPI — Uses ESP32 and W5500 together to transmit camera data over wired Ethernet. This is the closest analog to the "ESP32 + W5500 for camera communication" pattern in this project. Differences: onboard camera module (ESP32-CAM) vs external Hikvision IP camera accessed via FTP

→ ESP32-CAM + W5500: https://maker.wiznet.io/lawrence/projects/esp32-cam-using-hspi-interface-and-w5500-module/

Water Level Monitor (ESP32 / W5500 + Deep Sleep) — Implements outdoor water level monitoring with W5500, ESP32, and deep sleep for long-term low-power operation. The functional context — water monitoring with a duty-cycle power strategy — maps directly to this project. Differences: single ultrasonic water level sensor vs six-sensor RS485 array

→ Water Level Monitor: https://maker.wiznet.io/2022/02/03/water-level-monitor-arduino-esp8266-esp32-sigfox/

All three projects share the same core design decision: choose W5500 wired Ethernet over WiFi for stable, noise-free communication in environments where wireless reliability cannot be assumed. This is the consistent reason WIZnet hardware appears across outdoor and industrial IoT deployments.

Business Value

The Mekong Delta is one of the world's three largest river deltas, producing roughly half of Vietnam's rice output and 90% of its rice exports. Saltwater intrusion is worsening annually due to climate change and upstream dam construction. Vietnam already ranks sixth globally for climate disaster exposure. Against this backdrop, the value this system delivers is concrete.

• Early agricultural damage prevention: Real-time salinity and water level data gives farmers and local authorities enough lead time to close sluice gates, halt irrigation, and protect crops before saltwater reaches critical thresholds
• Cost-effective government monitoring infrastructure: Unmanned automated stations replace manual field sampling. Deploying multiple units across a river basin scales coverage without proportional labor cost
• Aquaculture protection: Combined pH, water temperature, and salinity monitoring detects dangerous water quality shifts early enough to prevent fish and shrimp mortality
• Hydro-meteorological data accumulation: Long-term wind, water level, and salinity records feed flood prediction models, improving forecast accuracy over time

From WIZnet's perspective, this project illustrates a concrete use case in the Southeast Asian agricultural and water resource management market — a segment where low-power, low-cost, field-deployable hardware is in active demand. A network of stations like this, scaled across a river basin, represents meaningful embedded hardware volume.

Reference — Vietnam's first IoT water quality monitoring system (TheSmartLocal, 2020): → https://thesmartlocal.com/vietnam/iot-water-monitoring/

Reference — Salinity intrusion threatening Vietnam's rice bowl (East Asia Forum, 2025): → https://eastasiaforum.org/2025/11/22/salinity-intrusion-threatens-vietnams-rice-bowl/

Limitations and Future Improvements

This project reflects a purpose-built, field-oriented design. Several structural limitations are worth noting.

Current limitations:

• Single 4G uplink dependency: If cellular coverage fails, collected data is lost. Whether a local buffer or retry queue exists in the firmware cannot be confirmed without direct source code review
• W5500 re-initialization latency: Each wake cycle must re-establish the Ethernet connection. Depending on cable state, this can introduce delays of tens of seconds and affect duty cycle reliability
• Plaintext FTP: The local Ethernet segment reduces exposure, but physical access to outdoor field hardware is not guaranteed. Plaintext FTP carries sniffing risk in adversarial environments
• Modbus bus fault tolerance: The behavior when a single sensor fails to respond — whether the system skips it or stalls the entire collection cycle — cannot be determined without source code access

Improvement directions:

• Add local flash buffering (ESP32 NVS) to cache sensor data and snapshots on 4G failure, with retry on the next successful wake cycle
• Migrate from FTP to FTPS (FTP over TLS) or HTTP POST with TLS for encrypted image transfer
• Leverage W5500 Wake-on-LAN (WOL) as a hardware trigger to minimize re-initialization latency on each duty cycle
• Add per-slave timeout and retry logic to the Modbus RTU polling loop, preventing a single unresponsive sensor from blocking the full collection cycle

FAQ

Q. The ESP32 already has built-in WiFi. Why add a W5500? When the 4G module and ESP32 WiFi operate simultaneously on the 2.4 GHz band, RF interference can degrade both connections. W5500 wired Ethernet carries no RF, so it coexists cleanly with the 4G module. Wired Ethernet also maintains FTP session stability in outdoor environments where WiFi signal quality varies.

Q. Does the W5500 stream live video from the camera? No. The system uses FTP to capture periodic still images (snapshots). Real-time RTSP streaming is structurally incompatible with deep sleep operation and exceeds the power budget of a solar-and-battery field station.

Q. How do you add or replace sensors? The RS485 Modbus RTU bus supports up to 247 slaves on a single wire pair. Adding a compatible sensor means assigning it a Modbus slave address and updating the polling logic — no hardware redesign required.

Q. How is the station powered in the field? Deep sleep dramatically reduces average current consumption, making solar panel and lithium battery operation viable. The specific panel capacity and sleep interval are not documented in the public repository. These parameters must be sized to the duty cycle power budget for the target deployment site.

Q. What does the server-side architecture look like? This cannot be confirmed from the available source code. Data is most likely transmitted via HTTP POST or raw TCP over the 4G module. The server-side API, data format, and dashboard configuration are not publicly documented.