스마트팜 환경·제어 데이터를 HTTP API로 운영 시스템에 잇는 기준

환경값과 제어 상태를 함께 이어요

스마트팜에서 온도와 습도, 이산화탄소 같은 환경값은 잘 모이는데 환기팬이나 관수 장치가 언제 움직였는지는 다른 화면에 남는 경우가 있어요. 그러면 환경이 달라진 이유를 보려 할 때 센서 기록과 제어 기록의 시각을 일일이 맞춰야 해요. 운영 시스템으로 데이터를 보낼 때는 값의 개수보다 같은 온실 구역과 같은 시각을 하나의 흐름으로 묶는 일이 먼저예요.

농촌진흥청의 스마트팜 추진 자료도 기상·온실 환경정보와 천창, 환기팬, 관수 같은 장치제어를 함께 제시해요. 농림축산식품부의 스마트팜 데이터 마트 역시 환경·생육·제어 데이터를 통합해 JSON 형식 API로 제공하고 있어요. 이 구조를 현장에 적용할 때의 핵심 질문은 “데이터를 보낼 수 있나요?”보다 “받는 운영 시스템이 같은 의미로 해석할 수 있나요?”에 가까워요.

결론부터 보면 환경센서의 현재값, LS PLC의 제어 상태, 측정 시각과 데이터 유효 여부를 먼저 정리한 뒤 HTTP API 계약을 맞추는 편이 좋아요. 제어 명령은 기존 PLC와 승인된 인터락에 남겨 두고, 상위 시스템 연계는 조회와 업무 판단에 필요한 데이터를 전달하는 경계로 시작해야 해요.

먼저 데이터 계약을 정해요

센서 데이터 수집 항목에는 온실 ID, 구역 ID, 측정 항목, 값, 단위, 측정 시각이 필요해요. 여기에 수집 시각, 서버 도착 시각, 데이터 유효 여부를 나누어 두면 통신이 늦은 것인지 실제 환경이 달라진 것인지 구분하기 쉬워져요. 환기팬과 관수 같은 제어 상태에는 운전·정지 값만 두기보다 상태가 바뀐 시각과 제어 주체를 함께 남기는 편이 좋아요.

환경값과 제어 상태의 주기가 다르다는 점도 중요해요. 센서는 일정 주기로 읽더라도 장치 상태는 변경 이벤트가 중심일 수 있어요. 두 데이터를 억지로 같은 행에 덮어쓰지 말고 공통 온실 ID와 시각 범위로 연결해야 환경 변화 전후를 비교할 수 있어요.

먼저 합의할 항목	HTTP API에 담을 값	운영에서 확인할 질문
대상을 구분하는 키	온실·구역·장치·센서 ID	다른 구역 값이 섞이지 않았나요?
시간을 구분하는 기준	측정·수집·도착 시각	늦게 온 값을 현재값처럼 보지 않나요?
값의 의미	항목명·단위·배율·유효 여부	같은 이름을 양쪽이 다르게 해석하지 않나요?
중복 처리 기준	이벤트 ID 또는 장치·시각 조합	재전송이 새 기록으로 쌓이지 않나요?
제어 경계	조회 데이터와 승인된 명령 경로 분리	상위 화면이 인터락을 우회하지 않나요?

이 표는 작물별 적정 환경값이나 제어 기준을 정하는 표가 아니에요. 농가의 재배 기준, 제어기 설정과 안전 절차는 그대로 두고, 데이터 연동 과정에서 의미가 바뀌지 않는지 확인하는 기준이에요.

현장에서 HTTP API까지 나눠요

주 흐름은 Modbus RTU 환경센서, 현장 제어반, EASY-LINK, HTTP API, 운영 시스템 순서로 나눌 수 있어요. LS PLC에 모인 환기·관수 상태는 확인된 LS XGT 경로로 읽고, 별도 환경센서는 Modbus RTU로 수집하는 구성이 가능해요. 이때 PLC 연동 주소, 센서 레지스터, 배율과 단위는 각 장비 문서와 현장 표시값으로 먼저 대조해야 해요.

EASY-LINK는 LS XGT와 Modbus RTU 데이터를 수집해 목적지에 연결하는 산업용 IoT 게이트웨이 역할을 맡아요. HTTP API를 주 전달 경로로 두면 정해진 운영 서버가 요청을 받고 응답 코드와 본문으로 수신 결과를 돌려주는 구조를 만들 수 있어요. EASY-LINK가 센서 정확도나 PLC 제어 로직, 수신 서버의 업무 규칙까지 대신하는 것은 아니에요.

Modbus RTU 환경값과 LS PLC 상태를 현장 연결 계층에서 정리해 HTTP API와 대안 경로로 보내는 흐름이에요.

한 온실의 값 몇 개를 이미 있는 API 서버로 보내는 목적이라면 EASY-LINK 중심으로 작게 시작할 수 있어요. 요청에는 데이터 ID를 넣고, 재시도할 응답과 설정을 바로 고칠 응답을 나눠야 해요. HTTP 성공 코드만 보고 업무 시스템의 저장까지 끝났다고 단정하지 말고 수신 측 처리 결과와 최근 도착 시각도 함께 확인하세요.

전달 방식은 목적지로 골라요

HTTP API는 정해진 운영 시스템과 요청·응답을 확인하기 좋지만 모든 상황의 정답은 아니에요. 여러 화면과 분석 서비스가 같은 값을 받아야 하면 MQTT 발행·구독 구조가 자연스러울 수 있어요. 장기 조회와 집계가 먼저라면 MySQL 저장을 검토하고, 모바일이나 클라우드 서비스가 이미 Firebase를 사용한다면 그 경로를 대안으로 비교할 수 있어요.

선택 기준은 유행보다 수신자와 복구 방식이에요. HTTP API에는 인증, 타임아웃, 응답별 재시도와 중복 방지 기준이 필요해요. MQTT에는 브로커 권한, 토픽 이름과 중복 메시지 처리 기준이 필요하고, MySQL에는 스키마와 보존 기간, Firebase에는 읽기·쓰기 권한과 데이터 구조 합의가 필요해요. 두 경로를 병행한다면 원시값의 단위와 시각, 품질 표시는 한 번만 정의해야 해요.

운영 계층과 상위 시스템을 분리해요

온실과 장치가 늘어나면 단순 전달 성공만으로는 운영 상태를 파악하기 어려워져요. EASY LOGGER는 여러 장치의 통합 수집, 저장 이력과 전달 상태 관리, 대시보드 구성 역할을 맡아요. 어떤 구역의 마지막 데이터가 오래됐는지, HTTP API 전달이 어느 시각까지 이어졌는지, 같은 조건의 환경값과 장치 상태를 함께 비교해야 할 때 운영 계층으로 검토할 수 있어요.

한 구역에서 수집·전달 상태를 검증한 뒤 여러 온실과 상위 운영 화면으로 범위를 넓히는 모습이에요.

EASY LOGGER 대시보드는 환경값과 전달 상태를 확인하는 화면이지 작물 상태를 자동 판정하거나 현장 인터락을 대신하는 장치가 아니에요. 제어 권한은 기존 PLC와 승인된 제어기에 두고, 조회용 계정과 설정 변경 계정을 분리하는 편이 안전해요. 자세한 요청·응답 설정은 EASY LOGGER API 설정 가이드에서 이어서 볼 수 있어요.

MES나 농장 운영 시스템 같은 상위 시스템은 HTTP API, MQTT 또는 DB 인터페이스로 연계해요. 제품별 별도 연계 사양이 확인되지 않았다면 표준 인터페이스 범위에서 필드 이름, 시간대, 결측 표현, 중복 키와 접근 권한을 송신·수신 담당자가 합의해야 해요. 기존 스마트팜 활용 관점은 축사 환기·냉방 데이터 글과 기술 블로그 목록에서도 비교할 수 있어요.

한 동부터 단계적으로 검증해요

처음에는 온실 한 동과 환경센서 한 묶음, LS PLC 상태 몇 점만 고르세요. 현장 표시값과 PLC 값, API 요청 본문과 수신 시스템 값을 같은 시각에 대조하고, 통신을 잠시 끊었다가 복구했을 때 누락·중복·지연 데이터가 어떻게 남는지 확인해요. 조회 경로가 안정된 뒤에만 구역과 장치 수를 늘리는 편이 좋아요.

다음 단계에서는 환경값과 환기·관수 상태를 같은 시간축에 놓고 실제 운영자가 필요한 질문에 답할 수 있는지 살펴봐요. 그다음 EASY LOGGER의 저장 이력과 전달 상태, 대시보드가 필요한 범위를 정하고 상위 시스템 인터페이스를 확장해요. 외부 쓰기나 제어는 별도 위험 검토, 최소 권한, 인터락과 수동 복귀 절차를 마련하기 전에는 열지 않는 게 안전해요.

센서 모델, Modbus RTU 주소, LS PLC 수집 항목, 받을 HTTP API 형식과 보존 목적을 정리했다면 HT Automation 홈페이지에서 현재 구성의 현장 연결 가능 여부를 부담 없이 확인해 보세요. EASY-LINK만으로 충분한지, 여러 온실의 저장 이력·전달 상태와 대시보드 운영을 위해 EASY LOGGER까지 필요한지 연결 범위부터 나눠 볼 수 있어요.