스마트팜 온실 구역별 온습도 값을 시각과 함께 기록하는 구성 가이드

온실 구역마다 값이 다른 이유

같은 온실 안이라도 남쪽 처마 밑과 북쪽 통로, 스크린 위와 작물 캐노피 근처의 온도는 같지 않습니다. 농촌진흥청 재배 지침도 온실 내 수평·수직 온도편차를 줄이는 일을 환경 관리의 기본으로 설명하고, 습도는 상대습도보다 스크린 위아래의 절대습도차를 보고 조절하라고 안내합니다. 온실 한가운데 걸린 계측기 한 대의 값만으로는 실제로 작물이 놓인 조건을 설명하기 어렵다는 뜻입니다.

문제는 이 편차가 눈에 보이지 않는다는 점입니다. 난방기를 몇 시에 껐는지, 천창을 어느 정도 열었을 때 북쪽 구역 습도가 어떻게 움직였는지는 그 시간의 값이 남아 있어야 되짚을 수 있습니다. 기록이 없으면 작물 상태가 나빠진 뒤에 원인을 추정하는 일밖에 남지 않습니다.

구역별 기록이 바꾸는 운영 판단

온실을 구역으로 나눠 값을 따로 남기면 판단의 성격이 달라집니다. 난방 설정온도를 올릴지 말지를 감이 아니라 구역별 최저온도 분포로 정합니다. 결로가 반복되는 구역을 특정해 스크린 운영이나 순환팬 위치를 바꿉니다. 같은 작기의 수확 편차를 구역 환경 이력과 겹쳐 보고 다음 작기의 배치를 정합니다.

세 가지 모두 지금 몇 도인가가 아니라 지난 며칠 동안 어떻게 움직였는가를 요구합니다. 현장 계측기 화면은 현재값을 보여 주지만 지나간 값은 대부분 남지 않습니다. 그래서 필요한 것은 새로운 센서가 아니라, 이미 달려 있는 온도센서와 습도센서의 값을 구역 이름과 시각과 함께 계속 쌓아 두는 계층입니다.

구역마다 조건이 다르므로 지점별로 기록을 나눠 남깁니다

온실 구역 환경을 잇는 데이터 흐름 구성

구성은 세 계층으로 나눕니다. 구역에서 값을 재는 수집 계층, 값을 실어 나르는 연결 계층, 값을 쌓고 보여 주는 운영 계층입니다. 한 온실 안에서도 계측기 종류가 제각각이라 하나의 프로토콜만 고집하면 결국 어느 구역은 빠집니다.

수집 계층에는 구역마다 산업용 IoT 게이트웨이인 EASY LOGGER를 한 대씩 둡니다. Modbus RTU로 물린 온도센서와 습도센서는 CONNECTION PROTOCOL에서 Modbus RTU를 고른 뒤 COM 포트, Baudrate, Unit ID를 넣어 등록하고, 수집 조건에서 TRIGGER TYPE을 Timer로, DATA TYPE을 FLOAT로 두고 수집요청주기를 ms 단위로 지정합니다. PLC NAME은 MQTT 토픽과 API 엔드포인트, OPC-UA 노드 경로에 그대로 들어가므로 GH_ZONE_A처럼 구역을 알아볼 수 있는 이름으로 정합니다.

연결 계층은 EASY-LINK가 맡습니다. EASY-LINK는 다른 프로토콜과 방향이 반대여서, 값을 요청받는 대신 장치가 MQTT로 값을 발행하고 상위 장비가 그 값을 받는 연결 역할을 합니다. 배선을 새로 끌기 어려운 동이나 떨어진 구역에는 이 방식이 편합니다. 수집 조건에는 시작 번지와 디바이스 수 대신 ROOT KEY와 ADDRESSES를 넣고, STALE AFTER (MS)를 지정하면 그 시간 동안 수신이 없을 때 값을 null로 저장하고 결함으로 표시합니다.

운영 계층에는 서버 역할의 EASY LOGGER를 둡니다. 구역별 수집 설정이 하나씩 쌓이면 저장 설정 목록에서 STATUS가 RUNNING인지 한눈에 보이고, EASY LOGGER 대시보드에서 저장 이력과 전달 상태를 함께 확인합니다.

EASY LOGGER MQTT 예제

구역 값을 상위로 내보내는 경로는 MQTT 설정 화면에서 잡습니다. MQTT Server와 Port를 넣고, 평문이면 1883, 암호화가 필요하면 TLS를 켜고 8883을 씁니다. 브로커 계정의 User와 Password를 채운 뒤 Publish를 켜고 연결 테스트를 거쳐 설정 저장한 다음 Enable 스위치를 올립니다. 발행 토픽은 PLC NAME과 CONFIG NAME을 그대로 이어 만들어지므로, 아래는 A구역 프로필과 그 프로필에서 만들어지는 READ Topic 구조입니다.

PLC PROFILE
  PLC NAME: GH_ZONE_A
  CONNECTION PROTOCOL: Modbus RTU
  UNIT ID: 3

CONFIG PROFILE
  CONFIG NAME: ZONE_A_ENV
  TRIGGER TYPE: Timer
  DATA TYPE: FLOAT
  수집요청주기: 5000

READ Topic: GH_ZONE_A/ZONE_A_ENV/READ
Payload:
{
  "values": {
    "ZONE_A_TEMP": 24.6,
    "ZONE_A_HUMI": 71.2
  }
}

저장 전에는 Topic Preview에서 만들어질 토픽 문자열이 의도한 대로 나오는지 확인합니다. Enable을 켠 뒤에는 화면 맨 아래 MQTT 상태 표시등과 Runtime Status가 정상인지 보고, Payload Log에서 실제로 나간 values 내용이 등록한 주소키와 맞는지 봅니다. 값이 비어 보이면 저장 설정 목록의 STATUS부터 확인하고, FAULT면 접속 정보와 주소 범위를 다시 봅니다.

구역 이력을 어디에 남길지 정하기

이 구성의 주 전달 대상은 MySQL입니다. DB 설정에서 스위치를 ENABLE로 켜고 DB Name, Host Address, Port 3306, User와 Password를 넣은 뒤 연결 테스트를 거쳐 저장하면 수집 설정 이름으로 만들어진 테이블에 값이 쌓입니다. 자체 저장이면 Host Address는 127.0.0.1입니다. DB 저장과 로컬 CSV 저장은 동시에 켤 수 없으므로 현장 사정에 맞춰 하나만 켭니다.

기간 조회와 보존 기간 관리는 저장 계층이 맡습니다

전달 경로는 성격이 다릅니다. MQTT는 값이 갱신될 때마다 흘려보내는 데 맞아 화면 갱신과 알림에 강하지만, 브로커는 지나간 값을 조회하는 창구가 아닙니다. HTTP API는 상위 시스템이 필요할 때 당겨 가는 방식이라 접근 통제를 세우기 쉬운 대신 짧은 주기에는 불리합니다. MySQL은 기간 조회와 집계에 강하고, DB TABLE DELETE로 보존 기간을 정하면 매일 00:00에 기간이 지난 수집 데이터만 지웁니다. 남은 용량은 DB 조회 화면의 DB SIZE와 DISK FREE에서 봅니다. 구역 환경처럼 몇 달치를 되짚는 이력은 MySQL에 남기고 실시간 화면만 MQTT로 병행하는 조합이 무난합니다.

MES나 CIM 같은 상위 시스템과 이어야 한다면 화면을 새로 만들지 않고 인터페이스만 맞춥니다. MQTT 발행, HTTP API 조회, 데이터베이스 직접 조회 가운데 상대 시스템이 이미 쓰는 방식을 고르면 데이터 연동 범위가 그만큼 좁아집니다.

한 구역부터 단계적으로 넓히는 순서

처음부터 온실 전체를 묶을 필요는 없습니다. 편차가 가장 심한 구역 한 곳에 한 대를 붙여 2주쯤 값을 쌓아 보면 수집 주기, 보존 기간, 실제로 필요한 주소 개수가 실측으로 정해집니다. 그다음 같은 설정을 복사해 구역을 단계적으로 넓히면 배선과 예산을 한 번에 쓰지 않아도 됩니다.

다른 구성 사례는 HT Automation 홈과 기술 블로그 목록에 정리해 두었고, 같은 온실에서 상위 시스템까지 잇는 이야기는 스마트팜 온실 MQTT 상위 연동 구성에서 이어집니다. 지금 쓰시는 계측기 모델과 통신 방식만 알려 주시면 현장 연결 가능 여부를 먼저 확인해 드립니다. 도입 범위는 그 결과를 보고 정하셔도 늦지 않습니다.