---
title: "FieldLink: ESP32-S3 Pump Controller with Local/Remote Interlock and MQTT Telemetry"
url: "https://maker.wiznet.io/josephsr/projects/fieldlink-esp32-s3-pump-controller-with-local-remote-interlock-and-mqtt-telemetry/"
markdown_url: "https://maker.wiznet.io/josephsr/projects/fieldlink-esp32-s3-pump-controller-with-local-remote-interlock-and-mqtt-telemetry/md"
type: "UCC: User Created Content"
author: "Voltageza"
author_url: "https://github.com/Voltageza/fieldlink"
editor: "WIZnet"
editor_url: "https://maker.wiznet.io/"
original_author: "Voltageza"
original_url: "https://github.com/Voltageza/fieldlink"
published: "2026-01-28"
language: "en"
likes: 0
views: 347
comments: 0
source: "WIZnet Makers (https://maker.wiznet.io/)"
---

# FieldLink: ESP32-S3 Pump Controller with Local/Remote Interlock and MQTT Telemetry

> ESP32-S3 pump controller enforcing LOCAL/REMOTE gating and hardwired STOP; Modbus 3-phase current sensing, TLS MQTT telemetry/commands, and dry-run shutdown.

Original author: Voltageza (source: https://github.com/Voltageza/fieldlink)

## Article

**Overview**
FieldLink is a small industrial controller pattern: keep the “must-not-fail” actions local and deterministic (physical STOP, mode interlock), then layer cloud visibility and optional remote control on top. It reports three-phase current (Ia/Ib/Ic) via Modbus RS485, publishes telemetry to MQTT over TLS, and drives a contactor output plus RUN/FAULT indicators.

**Main Content**

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

*Image generated by gpt*

At the edge, the device reads digital inputs for START (NO), STOP (NC), and a mode selector (LOCAL when grounded, REMOTE when open). In LOCAL, remote commands are blocked; in REMOTE, MQTT commands (START/STOP/RESET) are accepted, but the physical STOP remains authoritative in both modes.
For protection, it includes a DRY_RUN fault rule: if the contactor is ON but no current is detected for ~10 seconds, the controller shuts down and requires a RESET to clear the fault.
Cloud interaction is intentionally thin: telemetry is JSON published to a per-device topic, and commands are simple strings. A web dashboard consumes the live data and exposes control buttons plus device status and mode indicators.

**System Context**
This fits sites where pumps must remain operable without the network, but operators still want remote visibility and “only-when-allowed” remote control. The LOCAL/REMOTE interlock turns cloud control into a supervised capability rather than a default authority.

**Architecture / Design Considerations**

- **Hardwired interlock over software policy:** LOCAL mode blocks MQTT commands at the device, reducing the blast radius of cloud-side mistakes or credentials leaks.

- **Fail-safe STOP (NC):** Wiring STOP as normally-closed means broken wiring trends toward “stop,” not “run.” If you cheap out here, you deserve the outage.

- **Sensing path matters:** The DRY_RUN rule depends on reliable current detection (via Modbus RS485). If sensing is noisy or offline, fault logic becomes either trigger-happy or blind.

- **Ethernet note (WIZnet context):** The reference hardware is an ESP32-S3 board with Ethernet capability. If your design uses a WIZnet Ethernet controller such as **W5500** as the wired interface, the same MQTT-telemetry/control split still applies, but you must treat the Ethernet link as part of the safety boundary (remote commands stay subordinate to LOCAL/STOP).

**Possible Implications**

- The design encourages a clean separation: cloud provides **visibility and optional actuation**, while the edge controller enforces **site safety rules**.

- Extending beyond pumps (fans, compressors, conveyors) is straightforward if you preserve the same interlock philosophy and validate sensing-to-actuation latency.

**Conclusion**
FieldLink is less about fancy IoT and more about refusing to let the network be in charge of something that can flood a plant or burn a motor. The key idea is simple: local safety first, cloud second, and faults that shut things down when the real world disagrees with “ON.”

---

### 전체 개요

FieldLink는 **펌프 제어**에서 흔히 문제가 되는 “원격 제어 편의성”과 “현장 안전”의 충돌을, **물리 인터락(LOCAL/REMOTE) + 물리 STOP 우선**으로 정리한 구조입니다. 디바이스는 **3상 전류(Ia/Ib/Ic)** 를 Modbus RS485로 수집하고, MQTT(TLS)로 텔레메트리를 올리며, 간단한 원격 명령(START/STOP/RESET)을 받습니다.

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

현장 펌프는 “돌아가야 할 때는 반드시 돌아가고, 멈춰야 할 때는 반드시 멈춰야” 합니다. 그런데 클라우드나 앱이 끼어들면, 네트워크 장애·계정 유출·오조작 같은 변수들이 **제어권**에 영향을 주기 쉽습니다. FieldLink는 이를 피하려고 **원격은 ‘가능하면 허용’**, 안전은 **‘항상 강제’**로 배치한 형태로 보입니다. (추론임: “원격 우선”을 막기 위해 인터락을 가장 앞단에 둔 의도가 핵심으로 읽힙니다.)

### 기술 흐름 설명

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

*image generated by gpt*

- **디지털 입력 수집**
  - START: NO(순간 버튼)
  - STOP: NC(비상정지 성격, 단선 시 정지 방향)
  - MODE: GND면 LOCAL, 오픈이면 REMOTE

- **모드에 따른 제어권 결정**
  - LOCAL: MQTT 명령 차단, 수동 START/STOP만 의미 있게 동작
  - REMOTE: MQTT START/STOP/RESET 수용, 수동 버튼도 여전히 동작
  - STOP은 양쪽 모드에서 항상 동작(안전 기능)

- **전류 측정(Modbus RS485)**
  - Ia/Ib/Ic를 읽고, 펌프 운전 여부/이상 판단에 사용

- **구동 출력**
  - DO1: 메인 접촉기(Contactor) 구동
  - DO2/DO3: RUN/FAULT 표시

- **클라우드 연계(MQTT + Dashboard)**
  - 텔레메트리 JSON을 publish
  - command 토픽으로 문자열 명령 수신
  - 웹 대시보드는 전류/상태/모드 및 제어 버튼 제공

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

- **원격 제어는 보조 수단**으로 두고, 제어권을 “현장에 두는” 것이 핵심입니다. LOCAL 모드에서 MQTT를 차단하는 정책은, 클라우드가 살아 있어도 **현장이 원격을 거부할 수 있게** 만듭니다.

- STOP(NC)을 양 모드에서 항상 유효하게 둔 것은 “네트워크나 모드 상태와 무관하게 정지는 가능해야 한다”는 현장 안전 관점의 전형적인 선택입니다.

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

- **DRY_RUN 보호 로직**: “접촉기 ON인데 전류가 없다”를 10초 기준으로 fault로 보고 자동 차단합니다. 이 로직은 단순하지만 효과적입니다.

- 다만 전류 측정이 불안정하거나 Modbus가 자주 끊기면, (추론임) **오탐/미탐**이 발생할 수 있어 임계시간/필터링/센서 failover가 운영 안정성의 관건이 됩니다.

- 원격 명령 payload를 단순 문자열로 둔 것은 구현은 쉬워지지만, 운영 레벨에서 “누가/언제/왜”를 추적하기에는 추가 메타데이터가 필요할 수 있습니다. (추론임)

### 생소한 개념에 대한 풀어쓴 설명

- **LOCAL/REMOTE 인터락**: 원격 제어 기능이 있어도, 현장 스위치가 “원격을 허용할지”를 최종 결정하는 구조입니다.

- **STOP(NC)**: Normally Closed라서, 선이 끊어지거나 접점이 떨어져도 “정지 방향”으로 동작하는 쪽에 가깝습니다.

- **DRY_RUN**: 펌프가 공회전하거나 물이 없는 상태로 운전될 때, 부하가 줄어 전류가 기대보다 낮게 나오거나 아예 감지가 안 되는 상황을 이용한 보호 기법입니다.

### 시스템 구성 및 선택지 해석

- 기준 하드웨어는 ESP32-S3 기반 보드(입출력 절연, RS485 포함, Ethernet/PoE 가능)로 제시되어 있습니다.

- 유선 Ethernet을 쓰는 경우, SPI Ethernet 컨트롤러 기반(WIZnet W5500 등)으로도 유사 패턴을 구성할 수 있는데, 이때도 “원격은 보조, 현장 인터락이 우선”이라는 경계는 그대로 유지되어야 합니다. (추론임: 통신 링크가 바뀌어도 안전 경계가 바뀌면 안 됩니다.)

### 내부 관점에서의 시사점

- 이 구조의 **기존 접근 대비 핵심 차이**는 “클라우드가 살아 있어도, 원격 명령이 항상 먹히는 게 아니라 **현장이 허용할 때만** 먹힌다”는 점입니다.

- **실패 비용이 가장 큰 구간**은 DO1(접촉기 구동)과 그에 연동된 fault 판단입니다. 오동작하면 설비 손상/안전사고로 바로 이어질 수 있으니, 입력 배선(STOP/모드), 출력 드라이브, 전류 감지 신뢰도에 품질을 집중해야 합니다.

- **특정 구성요소 제거 시 시스템 성격 변화**도 명확합니다. 예를 들어 MODE 스위치를 제거하면 “원격은 보조”가 아니라 “원격이 기본”으로 기울 수 있고, STOP(NC)를 약화시키면 현장 안전의 최후 방어선이 사라집니다. (추론임)

- 전류 감지(모드버스)가 빠지면 DRY_RUN 보호가 무력화되어, 시스템은 사실상 “원격 릴레이 제어기”에 가까워집니다.

---

### FAQ

**Q1. 기존 IoT 펌프 제어와 비교했을 때 가장 큰 차별점은 무엇인가요?**
A1. 원격 제어를 “기본 권한”으로 두지 않고, LOCAL/REMOTE 스위치로 현장이 최종 허용권을 갖도록 설계되어 있습니다. 즉, 네트워크가 되더라도 현장이 원격을 차단할 수 있어 사고 범위를 줄입니다.

**Q2. 왜 MQTT 명령을 LOCAL 모드에서 아예 막아버리나요?**
A2. 원격 제어는 편의 기능이지만, 오조작이나 계정 문제, 운영 실수의 피해가 큽니다. LOCAL에서 차단하면 “원격이 불필요한 시간”에 제어권을 현장에 고정할 수 있습니다.

**Q3. 이 시스템에서 실패 비용이 가장 큰 판단 지점은 어디인가요?**
A3. 접촉기(DO1)를 실제로 켜고 끄는 구간과, 전류 감지 기반 fault 판단이 결합되는 지점입니다. 여기서 오동작하면 설비 손상 또는 안전 문제로 직결될 수 있어, 배선/입출력/센서 신뢰도 검증이 핵심입니다.

**Q4. 핵심 신호/데이터 흐름을 한 줄로 요약하면 무엇인가요?**
A4. “현장 입력(START/STOP/모드) → 접촉기 출력 → 전류(Modbus)로 상태 검증 → MQTT로 텔레메트리 제공, 원격은 모드에서 허용될 때만 수용” 흐름입니다. 이 순서가 안전 경계를 명확히 해 줍니다.

**Q5. DRY_RUN 보호는 왜 중요한가요?**
A5. 접촉기가 ON인데 전류가 없으면, 펌프가 실제로 일을 못 하거나(공회전) 계통 이상이 생겼을 가능성이 큽니다. FieldLink는 이를 10초 기준으로 fault 처리하고 자동 차단하는 방식으로 손상을 줄이려 합니다.

**Q6. 전류 측정(Modbus RS485)을 제거하면 어떤 일이 생기나요?**
A6. DRY_RUN 같은 “현실 기반 검증”이 사라져서, 시스템은 명령을 그대로 실행하는 단순 제어기로 성격이 바뀝니다. 결과적으로 안전 기능이 약해지고 운영자가 더 많은 책임을 떠안게 됩니다.

---

### 저자 정보 (Author Information)

- 공개된 저장소 기준으로는 GitHub 계정(또는 그룹) 단위로만 식별되며, **소속/기관의 성격이나 공식 이력은 공개된 정보가 제한적임**으로 보입니다.

- 저장소 구성과 문서 수준으로 볼 때, **산업용 제어(펌프/접촉기), RS485(Modbus) 계측, MQTT 기반 원격 모니터링**을 묶어 실제 운용 가능한 형태로 정리한 경험이 있는 개발/엔지니어링 성격이 강하게 드러납니다. (추론임)

---

Source: https://maker.wiznet.io/josephsr/projects/fieldlink-esp32-s3-pump-controller-with-local-remote-interlock-and-mqtt-telemetry/