시설재배 온·습도 이력, 온실 구역별 편차를 비교하는 기준

먼저 결론부터 볼게요

온실의 온도와 습도는 대표 센서 한 대의 현재값만으로 판단하기 어려워요. 같은 시각에도 출입구와 안쪽, 작물 높이와 상부 공간의 값이 다를 수 있기 때문이에요. 농촌진흥청 자료도 시설재배에서 온·습도 환경을 함께 살피고, 센서와 주요 장비의 작동 상태를 데이터로 분석하는 운영이 필요하다고 설명해요.

처음부터 모든 구역을 연결하기보다 서로 다른 위치의 온도센서와 습도센서 세 쌍을 같은 주기로 기록해 보세요. 측정 시각, 구역, 높이, 온도, 상대습도와 수신 상태를 한 묶음으로 남기면 단순히 덥고 습하다는 느낌을 넘어 어느 구역에서 편차가 커지는지 볼 수 있어요. 이 글은 특정 작물의 적정값을 정하는 대신, 현장 기준값을 만들기 위한 데이터 구조와 확인 순서를 다뤄요.

한 시각의 여러 구역을 나란히 봐요

비교의 시작은 센서 이름이 아니라 위치 정보예요. 예를 들어 ZONE-A-LOW, ZONE-B-CROP, ZONE-C-HIGH처럼 구역과 높이를 함께 적고, 각 센서의 PLC 주소·단위·배율을 주소 맵에 연결해요. 온도와 습도의 측정 시각이 다르면 같은 순간의 편차처럼 보일 수 있으니 원본 측정 시각과 수집 시각도 분리해 두는 편이 좋아요.

농사로의 시설재배 자료에서는 상부와 하부의 온도·상대습도 차이를 비교하고, 환기·교반 조건에 따른 환경 변화를 확인해요. 여기서 가져올 판단 기준은 특정 수치를 그대로 복사하는 것이 아니에요. 우리 온실에서도 같은 위치와 같은 시간 구간을 기준으로 환기 전후 편차가 줄었는지 데이터 추세 분석을 할 수 있도록 기록 구조를 만드는 것이 핵심이에요.

연결과 운영의 책임을 나눠요

세 구역의 센서 값이 PLC나 Modbus 장치에 모여 있다면 먼저 주소와 데이터 타입이 맞는지 확인해요. 이 구간에서 EASY-LINK는 LS XGT, Mitsubishi MC, Modbus RTU/TCP처럼 공식 확인된 현장 데이터를 읽고 MQTT, HTTP API, MySQL 또는 Firebase로 전달하는 산업용 IoT 게이트웨이 역할을 맡을 수 있어요. 주소 변환과 전달만 필요하다면 EASY-LINK 중심으로 시작할 수 있지만, 여러 구역의 저장 이력과 전달 상태, 대시보드 운영까지 한곳에서 보려면 EASY LOGGER를 함께 검토하는 편이 맞아요.

EASY LOGGER는 센서 값을 대신 보정하거나 작물별 적정 환경을 자동 결정하는 장비가 아니에요. 통합 수집, 저장 이력, 전달 상태와 대시보드 구성을 통해 담당자가 비교할 자료를 남기는 운영 계층이에요. 센서 교정과 설치 위치, 환기 기준은 장비 문서와 재배 기준에 따라 별도로 관리해야 해요.

실제 EASY LOGGER 원본 이미지이며, 여러 구역의 수집 이력과 전달 상태를 관리하는 역할을 확인할 때 참고할 수 있어요.

EASY LOGGER MySQL 예제

아래 ZONE_A_LOW, ZONE_B_CROP, ZONE_C_HIGH와 PLC 주소 D0100부터 D0105는 구조를 설명하기 위한 예시예요. 실제 적용 전에는 각 온도·습도 필드를 현장 주소 맵과 대조하고, 온도와 습도를 한 쌍으로 읽는 데이터 타입과 배율을 확인해야 해요. 외부 MySQL 스키마 greenhouse_ops에 기록한다고 가정하면 다음처럼 구역과 측정 시각을 분리할 수 있어요. 이 테이블은 EASY LOGGER 내부 스키마가 아니라 수신 측에서 관리하는 외부 예시예요.

CREATE TABLE greenhouse_ops.zone_environment_history (
  measured_at DATETIME NOT NULL,
  zone_code VARCHAR(24) NOT NULL,
  temperature_c DECIMAL(5,2),
  humidity_pct DECIMAL(5,2),
  receive_status VARCHAR(16) NOT NULL,
  PRIMARY KEY (measured_at, zone_code)
);

SELECT measured_at, zone_code, temperature_c, humidity_pct, receive_status
FROM greenhouse_ops.zone_environment_history
WHERE measured_at >= CURRENT_DATE
ORDER BY measured_at, zone_code;

DB History Logs에서는 같은 시간 범위의 세 구역 기록이 연속으로 들어왔는지, 특정 구역만 비어 있지는 않은지 확인해요. 보존 기간은 재배 주기와 비교 목적에 맞춰 외부 DB 정책으로 정하고, 검색할 때는 구역과 측정 시각을 함께 사용해요. 기록이 없을 때는 센서 이상, PLC 주소 오류, 수집 중단, DB 전달 실패를 한 원인으로 묶지 말고 Runtime Status와 DB History Logs를 차례로 비교해요.

세 온실 구역의 온도·습도 값이 연결 계층을 지나 이력 DB와 추세 화면으로 이어지는 추상 흐름이에요.

편차와 수신 공백을 따로 판단해요

대시보드에서는 현재값보다 비교축을 먼저 정해요. 같은 시각의 구역별 온도 차이, 상대습도 차이, 마지막 수신 시각과 연속 누락 횟수를 나란히 두면 실제 환경 편차와 통신 공백을 구분하기 쉬워요. 환기장치를 켜기 전후로 같은 길이의 시간 구간을 선택하되, 날씨와 작물 상태가 다른 날의 결과를 단순히 같은 조건으로 단정하지 않아요.

확인표는 네 칸이면 충분해요. 첫째 센서 위치와 높이가 주소 맵과 일치하는지, 둘째 세 구역의 측정 시각이 비교 가능한지, 셋째 PLC 원시값과 변환값의 단위·배율이 맞는지, 넷째 MySQL 기록과 Dashboard의 마지막 수신 시각이 이어지는지를 봐요. 이 기준을 남겨 두면 값이 다른 이유를 환경 변화와 데이터 경로 문제로 나눌 수 있어요.

세 센서에서 작게 시작해요

1단계에서는 대표 구역 세 곳만 연결해 하루 이력을 남겨요. 2단계에서는 환기 전후 시간 구간과 구역별 편차를 비교하고, 3단계에서 필요한 센서와 온실 동을 늘려요. MES나 다른 상위 시스템이 필요하면 MySQL 또는 확인된 MQTT·HTTP API 인터페이스를 통해 연계 범위를 정해요.

EASY-LINK만으로 현장 데이터 전달이 충분한지, EASY LOGGER까지 더해 이력과 상태를 함께 봐야 하는지는 센서 수와 운영 방식에 따라 달라져요. 구매를 서두르기보다 센서 위치, PLC 주소, 저장 목적지를 정리한 뒤 현장 연결 가능 여부를 먼저 확인해 보세요. 관련된 기본 수집 주기는 온실 습도 MQTT 가이드와 함께 비교하면 판단하기 쉬워요.