jeon/HECO2
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
7e2f14538f13313be48ecbe08499f3333bd65402
HECO2/TestProgram/WebDashBoard/HTTP_vs_MQTT_검토.md
T
jeon a502322188 chore: HERV 통합 저장소 재초기화 커밋 
손상된 .git 히스토리(missing tree)로 재초기화 후 작업트리 전체 커밋.
.claude/ 만 제외(로컬 에이전트 설정). 구 저장소 백업(.git_corrupt_backup/) 포함.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-16 09:32:17 +09:00

4.6 KiB
Raw Blame History

통신 방식 검토 : 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 View Git Blame Copy Permalink