chore: HERV 통합 저장소 재초기화 커밋
손상된 .git 히스토리(missing tree)로 재초기화 후 작업트리 전체 커밋. .claude/ 만 제외(로컬 에이전트 설정). 구 저장소 백업(.git_corrupt_backup/) 포함. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
jeon
@@ -0,0 +1,89 @@
|
||||
# 통신 방식 검토 : HTTP vs MQTT
|
||||
|
||||
- 작성일: 2026-06-03
|
||||
- 대상: HuevenEco DL 각실제어 원격 모니터링·제어 (EW11 ↔ 미니PC 수집서버 ↔ 웹 대시보드)
|
||||
- 관련: `ErvCollector/`, `../TestProgram/PC_ERV_Protocol.md`, `../EW11_RS485 TO WIFI/260603_EW11_클라우드전송_검토.md`
|
||||
|
||||
---
|
||||
|
||||
## 1. 현재 시스템의 통신 계층 (두 가지)
|
||||
|
||||
| # | 구간 | 현재 방식 | 비고 |
|
||||
|---|------|-----------|------|
|
||||
| ① | ERV ↔ EW11 ↔ 수집서버 | **0xAA 바이너리 프레임 over TCP** | 장치 구간 (HTTP 아님) |
|
||||
| ② | 브라우저 ↔ 수집서버 | **HTTP** (`/api/latest` 1초 폴링 + `/api/control` POST) | 대시보드 구간 |
|
||||
|
||||
> "웹 프로토콜이 HTTP" = ②번. 일반적으로 IoT에서 MQTT가 거론되는 구간은 **①번(장치↔서버)** 이다.
|
||||
|
||||
---
|
||||
|
||||
## 2. HTTP vs MQTT 핵심 차이
|
||||
|
||||
| 항목 | HTTP (현재) | MQTT |
|
||||
|---|---|---|
|
||||
| 모델 | 요청-응답 (Pull) | 발행-구독 (Pub/Sub), **브로커** 경유 |
|
||||
| 연결 | 매 요청 단발 | **지속 TCP 1개 유지** |
|
||||
| 방향 | 클라이언트가 물어봐야 받음(폴링) | 변화 시 **즉시 푸시** |
|
||||
| 오버헤드 | 헤더 큼(매 요청 수백 B) | 헤더 2~수 B, **매우 경량** |
|
||||
| 실시간성 | 폴링 주기만큼 지연 | 낮은 지연 |
|
||||
| 다수 장치 | 서버가 일일이 응답 | 브로커가 **N:N 중계**, 확장 용이 |
|
||||
| 신뢰성/오프라인 | 별도 구현 필요 | **QoS 0/1/2, retained, LWT(접속 끊김 자동 통지)** |
|
||||
| 브라우저 | 기본 지원 | **직접 불가 → MQTT over WebSocket 필요** |
|
||||
| 추가 인프라 | 없음(수집서버가 이미 제공) | **브로커(예: Mosquitto) 1개 필요** |
|
||||
|
||||
---
|
||||
|
||||
## 3. 우리 프로젝트에 대입
|
||||
|
||||
### (A) EW11 → 서버 (3개 현장, 인터넷) — MQTT의 본 무대
|
||||
- EW11은 **MQTT 클라이언트 모드 지원** (매뉴얼 검토 완료).
|
||||
- 토픽 설계(예): 각 EW11이 `erv/site01/status` 에 0xAA STATUS **발행**, 서버 구독.
|
||||
제어는 서버가 `erv/site01/control` 에 **발행** → EW11 구독.
|
||||
- 이점:
|
||||
- 변화 즉시 푸시(저지연)
|
||||
- **LWT(Last Will & Testament)** 로 접속 끊김 자동 감지 (현재는 30초 추정 방식)
|
||||
- QoS 로 유실 방지, retained 로 최신값 즉시 수신
|
||||
- 현장 수가 늘어도(10·50곳) 브로커가 확장 처리
|
||||
- **중요**: 0xAA 프레임/파서/빌더(공용 `ErvProtocol`)는 **그대로 유지**. "raw TCP" 대신 "MQTT 페이로드"로 운반만 바뀜.
|
||||
|
||||
### (B) 브라우저 ↔ 서버 — 굳이 MQTT 아니어도 됨
|
||||
- 브라우저는 raw MQTT 불가 → **MQTT-over-WebSocket** 필요(복잡도 증가).
|
||||
- 모니터링 대시보드엔 **현재 1초 HTTP 폴링으로 충분**(트래픽 미미).
|
||||
- 진짜 실시간 푸시가 필요하면 WebSocket(또는 MQTT-WS)로 전환 가능하나 필수는 아님.
|
||||
|
||||
---
|
||||
|
||||
## 4. 트레이드오프 / 주의
|
||||
|
||||
- MQTT는 **브로커(Mosquitto)** 를 미니PC에 추가로 운영해야 함(구성 요소 증가).
|
||||
- **AWS IoT Core 직결은 EW11 클라이언트 인증서 미지원으로 곤란** (`260603_EW11_클라우드전송_검토.md` 참조) → MQTT로 간다면 **자체 Mosquitto(user/pass + 서버 TLS)** 가 현실적.
|
||||
- 현재 raw TCP + HTTP 폴링도 3현장 모니터링·제어엔 충분히 동작 중.
|
||||
- MQTT 이득이 큰 경우: **현장 수 증가 / 끊김 잦은 망 / 신뢰성·표준 IoT 스택 정렬**.
|
||||
|
||||
---
|
||||
|
||||
## 5. 권장
|
||||
|
||||
| 상황 | 권장 |
|
||||
|------|------|
|
||||
| 현장 3곳 고정 + 단순 운영 | **현행 유지** (raw TCP + HTTP 폴링) — 가장 간단 |
|
||||
| 현장 확장 / 끊김 감지·신뢰성·표준화 중요 | **(A) 장치↔서버만 MQTT(Mosquitto) 전환**, 브라우저는 HTTP 유지 |
|
||||
|
||||
---
|
||||
|
||||
## 6. MQTT 전환 시 작업 범위 (참고)
|
||||
|
||||
전환해도 **변경은 전송 계층에 한정**된다.
|
||||
|
||||
- **EW11 설정**: TCP Client → **MQTT** 모드 (브로커 주소, Client ID, user/pass, publish/subscribe 토픽)
|
||||
- **미니PC**: Mosquitto 브로커 설치(+user/pass, TLS)
|
||||
- **수집서버(ErvCollector)**: 현장별 TCP 리스너 → **MQTT 구독자**로 교체
|
||||
- `erv/+/status` 구독 → 기존 `FrameParser`/`StatusDecoder` 그대로 사용
|
||||
- 제어 시 `erv/{site}/control` 에 `CtrlFrame.*` 결과를 **발행**
|
||||
- 온라인/오프라인은 **LWT** + retained 로 처리(SiteHub 의 30초 추정 대체)
|
||||
- **변경 없음**: 공용 프로토콜(`ErvProtocol` — 0xAA 프레임/CRC/STATUS/CTRL), 웹 대시보드(HTTP API 유지), WPF 대시보드, 프로토콜 문서(장치 페이로드 규격 동일)
|
||||
|
||||
---
|
||||
|
||||
> 결론: MQTT는 **장치↔서버 구간(①)** 에 의미가 있고, 0xAA 규격을 유지한 채 전송만 교체하면 된다.
|
||||
> 3현장 검증을 먼저 마치고, 확장 시점에 (A)만 MQTT로 전환하는 단계적 접근을 권장한다.
|
||||
Reference in New Issue
Block a user