블로그›2026. 8. 18.

스마트팜 온실 습도 데이터를 MQTT에서 HTTP API로 잇는 인터페이스 설계

먼저 결론부터 볼게요

온실 습도 데이터를 운영에 쓰려면 센서 숫자를 받는 데서 끝내지 말고, 어느 구역의 어떤 필드가 어떤 시각에 전달됐는지 이어서 확인해야 해요. 농림축산식품부는 스마트팜 현장에서 온실 환경과 농작업 데이터를 수집·분석하는 사례를 소개했고, 농촌진흥청도 재배 환경·생육 데이터를 모아 의사결정을 지원하는 방향을 설명했어요. 그래서 습도 한 값도 구역 ID, 단위, 측정 시각, 수집 시각과 함께 설계하는 편이 좋아요.

이번 글은 온실 습도센서 한 대를 MQTT로 읽고 HTTP API를 운영 서버에 전달하는 흐름을 중심으로 살펴봐요. MQTT는 현장 값의 발행과 상태 분배에 잘 맞고, HTTP API는 운영 서버가 정한 endpoint와 요청·응답 계약을 맞추기 좋아요. MySQL은 외부 이력 저장과 기간 비교에, Firebase는 여러 화면에서 현재 상태를 공유하는 용도에 비교할 수 있어요. 네 가지 경로를 같은 역할로 섞기보다 측정·전달·저장·화면의 책임을 나누는 게 핵심이에요.

온실 습도 필드를 먼저 맞춰요

온실 구역 GH-A, 습도 필드 HUMIDITY_RH, 예시 PLC 주소 D0300을 사용한다고 가정해 볼게요. 이 이름과 주소는 샘플이며 실제 센서 사양, PLC 프로그램, 현장 field address map과 대조해 확정해야 해요. 값이 정수인지 소수인지, 상대습도 단위가 %RH인지, 배율과 수집 주기가 무엇인지도 함께 적어요. 측정 시각과 서버 수신 시각을 분리하면 센서 변화와 네트워크 지연을 구분하기 쉬워요.

EASY-LINK는 온실 센서·PLC에서 정해진 목적지까지 값을 연결하고 전달하는 역할로 봐요. 한 구역의 습도값을 MQTT로 보내고 연결 상태만 확인한다면 EASY-LINK만으로 시작할 수 있어요. 여러 구역의 저장 이력, 전달 상태와 Dashboard 운영이 필요하면 EASY LOGGER를 더해 역할을 나누는 편이 좋아요. EASY LOGGER는 수집 이력·전달 상태·대시보드 운영을 맡고, 현장 제어 로직이나 PLC 인터록을 대신하는 제품으로 설명하지 않아요. 제품 역할은 EASY 제품 안내에서 비교하고, 주소와 설정 항목은 제품 매뉴얼 자료실에서 버전별로 대조해 보세요.

MQTT와 HTTP API를 목적별로 나눠요

MQTT는 GH-A/HUMIDITY_RH/READ처럼 Topic을 정해 구독자에게 현재값과 상태를 전달하는 방식으로 설계할 수 있어요. HTTP API는 https://ops.example.kr/api/v1/greenhouse/humidity처럼 운영 서버가 관리하는 endpoint와 JSON 필드를 맞추는 흐름이에요. ops.example.kr과 경로는 예시이며 실제 서버 계약과 보안 정책으로 확정해야 해요. MySQL을 선택하면 farmops.greenhouse_humidity_history 같은 외부 스키마·테이블에 측정 시각, 구역 ID, 습도값, 수신 상태를 저장하는 식으로 정의해요. 이 이름은 EASY LOGGER 내부 스키마가 아니라 외부 운영 DB의 예시예요. Firebase는 현재 상태를 여러 화면에 공유할 때 비교하고, 장기 이력의 기준은 외부 DB 보존 정책으로 따로 정해요.

MQTT와 HTTP API를 비교할 때는 속도보다 책임 경계를 먼저 봐요. MQTT는 발행·구독 권한과 Topic 규칙을 확인해야 하고, HTTP API는 endpoint, 인증 방식, 재시도와 중복 요청 처리를 확인해야 해요. MySQL은 컬럼·인덱스·보존 기간을 정해야 하며 Firebase는 현재 상태의 갱신 기준과 이력 필요 여부를 구분해야 해요. MES·CIM 같은 상위 시스템은 확인된 MQTT, HTTP API 또는 DB 인터페이스 범위에서 필드 계약을 협의해요. 확인되지 않은 전용 커넥터를 전제로 하지 않아요.

온실 센서와 PLC의 습도 필드를 MQTT·HTTP API·MySQL·Firebase 목적에 맞게 나누는 흐름이에요.

EASY LOGGER storage history and delivery status shown in the operations view.

EASY LOGGER HTTP API 예제

아래 예시는 GHPLC01의 HUMIDITY_RH 필드가 예시 PLC 주소 D0300에 대응하고, GH-A 구역의 %RH 값을 HTTP API로 전달한다고 가정해요. GHPLC01, HUMIDITY_RH, D0300, endpoint와 JSON 필드는 모두 현장 field address map, PLC 설정, 운영 서버 계약과 대조해 확정할 예시예요. Automatic Endpoint Preview에서 POST endpoint와 필드 이름을 확인하고, Runtime Status에서 연결·전달 상태를 확인한 다음 Payload Log에서 원시 필드와 전송 payload를 맞춰요.

POST ENDPOINT: https://ops.example.kr/api/v1/greenhouse/humidity
CONTENT-TYPE: application/json

POST JSON의 humidity_rh는 예시 주소 D0300에서 읽은 %RH 값이고 measured_at은 센서 측정 시각이에요. Payload Log에서 GH-A, HUMIDITY_RH, D0300과 단위를 확인한 뒤 Runtime Status의 마지막 전송 시각을 비교해요.

{
  "greenhouse_id": "GH-A",
  "field": "HUMIDITY_RH",
  "plc_address": "D0300",
  "humidity_rh": 68.4,
  "unit": "%RH",
  "measured_at": "2026-08-18T06:30:00Z"
}

프로필과 WRITE CALLBACK의 연결도 예시 계약으로 함께 기록해요. GH-A, HUMIDITY_RH, D0300은 현장 field address map과 대조해 확정할 샘플이고, write_callback_url과 callback endpoint는 운영 서버 계약에 맞춰 확인해요. API Payload Log에서는 callback 요청의 프로필·필드·주소와 응답 시각을 Runtime Status와 함께 대조해요.

{
  "profile": {
    "profile_name": "GH-A",
    "greenhouse_id": "GH-A",
    "field": "HUMIDITY_RH",
    "plc_address": "D0300"
  },
  "write_callback_url": "https://ops.example.kr/api/v1/greenhouse/humidity/write-callback",
  "callback_endpoint": "/api/v1/greenhouse/humidity/write-callback",
  "api_payload_log": "API Payload Log"
}

WRITE CALLBACK을 호출할 때는 테스트 주소만 사용해요.

테스트 주소만 사용합니다.
최소 권한만 부여합니다.
허용 주소 범위를 제한합니다.
PLC 인터록을 확인합니다.
수동 복구 절차를 준비합니다.

HTTP API WRITE 안전 경계

WRITE CALLBACK을 호출할 때는 테스트 주소만 사용해요.

테스트 주소만 사용합니다.
최소 권한만 부여합니다.
허용 주소 범위를 제한합니다.
PLC 인터록을 확인합니다.
수동 복구 절차를 준비합니다.

WRITE CALLBACK은 운영 서버가 승인한 흐름에서만 검토하고, 실제 PLC 쓰기 권한과 인터록 조건은 현장 담당자가 별도로 확인해요.

화면에서 끝까지 대조해요

EASY LOGGER의 Runtime Status에서는 연결 여부와 마지막 전달 시각을 확인하고, Payload Log에서는 구역 ID·필드명·단위·값을 확인해요. 외부 MySQL을 쓰는 경우 DB History에서 farmops.greenhouse_humidity_history의 레코드 시각과 measured_at을 맞춰요. Dashboard에서는 현재 습도, 마지막 수신 시각과 전달 상태를 같은 greenhouse_id로 묶어 봐야 해요. 값은 최신인데 수신 시각이 오래됐다면 센서 정상 범위와 통신 신선도를 따로 판단할 수 있어요.

이런 화면 흐름은 스마트팜 환경·제어 데이터 연계 기준과도 비교해 볼 수 있어요. 다만 기존 글이 제어 데이터와 상위 연계를 다뤘다면, 이번 글은 온실 습도 필드 하나의 주소·payload·전달 상태를 HTTP API까지 이어 보는 데 초점을 둬요.

작게 시작해 운영 범위를 넓혀요

처음에는 한 대의 습도센서와 한 구역 GH-A만 선택해 정상값, 경계값, 단절 뒤 재연결을 순서대로 확인해요. 다음 단계에서 두 번째 구역을 추가하고 greenhouse_id가 섞이지 않는지 비교해요. 그 뒤 MQTT와 HTTP API의 전달 시각, 외부 DB 레코드와 Dashboard의 마지막 수신 시각을 함께 맞추면서 범위를 넓혀요. 한국농업기술진흥원 자료가 온도·습도와 통신 데이터를 수집 대상으로 제시하는 것처럼, 현장에서는 값의 종류보다 필드 정의와 시각 기준을 먼저 고정하는 편이 운영에 도움이 돼요.

현장 연결 가능 여부를 확인하려면 센서 모델, PLC field address map, MQTT Topic, HTTP API endpoint, 원하는 외부 DB 컬럼을 준비해 확인·상담·문의해 주세요.

#EASY-LINK #EASY LOGGER #스마트팜 #습도센서 #MQTT #HTTP API #MySQL #Firebase #PLC 연동 #데이터 연동