블로그›2026. 7. 28.

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

환경값과 제어 상태를 같은 시각에 놓아요

스마트팜에서는 온도·습도 값은 잘 모이는데 환기팬이나 관수 장치의 상태가 다른 화면에 남는 경우가 있어요. 그러면 환경이 달라진 이유를 보려 할 때 기록의 시각을 일일이 맞춰야 해요. 운영 시스템으로 보낼 데이터는 값의 개수보다 온실 ID, 측정 시각, 단위와 유효 상태를 같은 계약으로 묶는 일이 먼저예요.

농촌진흥청 자료는 기상·온실 환경정보와 천창, 환기팬, 관수 같은 장치 제어를 함께 제시해요. 농림축산식품부 스마트팜 데이터 마트도 환경·생육·제어 데이터를 JSON API로 제공해요. 현장에서는 이 구조를 참고하되 작물별 기준과 제어 로직은 재배 기준, 제어기 설정과 안전 절차를 따라야 해요.

연결 계층과 운영 계층을 나눠요

Modbus RTU 환경센서와 LS PLC 상태를 한 서버로 보낼 때는 주소, 배율, 단위, 측정·수집·도착 시각을 먼저 합의해요. 이 센서 데이터 수집 기준이 맞아야 양쪽 화면에서 같은 값을 읽을 수 있어요. EASY-LINK는 LS XGT와 Modbus RTU 값을 읽어 HTTP API, MQTT, MySQL, Firebase로 전달하는 연결 계층이에요. 센서 정확도나 PLC 제어 로직, 수신 서버의 업무 규칙을 대신하지 않아요.

한 온실의 값 몇 개를 기존 API로 보내는 목적이라면 EASY-LINK 중심으로 시작할 수 있어요. 장치가 늘고 수집 주기, 저장 이력과 전달 상태를 함께 관리해야 하면 EASY LOGGER는 통합 수집·저장·라우팅·관찰을 맡아요. 즉 EASY-LINK가 현장 값을 가져와 연결 경로를 만들고, EASY LOGGER가 그 값을 보관하고 목적지로 나누며 운영 상태를 보여주는 구조예요.

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

EASY LOGGER HTTP API 예제

HTTP API는 정해진 운영 서버가 요청을 받고 응답으로 수신 결과를 돌려줄 때 알맞아요. EASY LOGGER의 공식 outbound POST JSON은 PLC 주소를 키로 쓰고, 쓰기 경로가 열렸을 때 write_callback_url을 함께 제공해요. 아래 형식과 URL은 공식 예시를 그대로 보여줘요.

{
  "D100": 1,
  "D102": 23.77,
  "write_callback_url": "http://LOGGER_HOST:8000/api/write/PLC/CONFIG"
}

Automatic Endpoint Preview에서 POST 대상과 callback endpoint를 확인해요. Runtime Status에서는 LAST POST, QUEUED WRITES와 LAST ERROR를 보고, HTTP 성공 코드만으로 상위 시스템 저장까지 끝났다고 단정하지 않아요. 수신 측의 최근 도착 시각과 중복 키도 함께 대조해야 해요.

WRITE CALLBACK은 외부 서버가 /api/write/{PLC}/{CONFIG}로 직접 주소·값 JSON을 보내는 구조예요. first-party API Payload Log에서 확인된 예시 endpoint는 /api/write/PLC1/ZR100000_ZR100200이고, body에는 wrapper 없이 주소와 값만 들어가요.

{
  "ZR100198": 21604,
  "ZR100199": 161
}

온실 검증에서는 이 형식을 유지하되 PLC1/ZR100000_ZR100200 설정의 ZR100198·ZR100199를 실제 환기·관수 출력과 분리된 온실 시험용 주소로 현장 주소 문서에 지정한 뒤 사용해요. 값과 주소는 공식 로그의 형식 확인용 예시이며, 실설비 제어값으로 해석하지 않아요. API Payload Log에서 Timestamp, endpoint와 위 JSON이 그대로 남는지 확인해요.

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

HTTP API가 모든 목적지의 정답은 아니에요. 여러 서비스가 같은 값을 받아야 하면 MQTT, 장기 조회가 먼저면 MySQL, 기존 모바일·클라우드 경로가 있으면 Firebase를 비교할 수 있어요. 어떤 경로든 주소·단위·시간대·결측 표현은 하나의 데이터 계약으로 유지해요.

EASY LOGGER OPC UA 예제

SCADA나 OPC UA Client가 노드를 읽어야 한다면 공식 endpoint와 Node ID 형식을 그대로 따라요. 아래는 GREENHOUSE_TEST라는 시험 PLC와 ZR100198 시험 노드로 바꾼 예시예요. 실제 PLC 이름, CONFIG와 노드는 Automatic Node Preview 및 현장 주소 맵과 대조해야 해요.

endpoint: opc.tcp://192.168.0.50:4840/easylogger/server/
node id: ns=2;s=EASY_LOGGER/Devices/GREENHOUSE_TEST/Tags/ZR100198
data type: word
access level: CurrentWrite
test WRITE value: 21604

먼저 읽기 전용으로 온도·습도와 제어기 상태가 같은 시각에 보이는지 확인해요. 쓰기가 필요한 ZR100198만 시험 노드로 지정하고, 그 밖의 노드는 읽기 권한으로 유지해요. Automatic Node Preview에서 Node ID와 datatype을 확인한 뒤 Runtime Status의 RUNNING, LAST WRITE와 LAST ERROR를 함께 봐요.

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

OPC UA WRITE는 대시보드 명령이나 현장 안전 로직을 대신하지 않아요. 기존 PLC 인터락과 수동 운전 절차를 그대로 두고, 시험 결과가 주소·노드 문서와 일치할 때만 다음 범위를 검토해요.

EASY LOGGER 대시보드 예제

Dashboard에는 현재 온도와 습도를 current value 위젯으로, 환기팬·관수 제어기 상태를 별도 상태 위젯으로 놓아요. last receive time은 데이터 최신성을, delivery state는 HTTP API나 MQTT 전달 결과를 보여줘요. 온도·습도와 제어 상태의 전후 변화를 볼 때는 history 그래프를 같은 시간축으로 맞춰요.

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

대시보드는 작물 상태를 자동 판정하거나 현장 인터락을 우회하는 제어 화면이 아니에요. 운영자는 마지막 수신 시각, 전달 오류와 이력 추세를 보고 어디를 점검할지 좁혀요. MES·CIM이나 농장 운영 시스템은 HTTP API, MQTT 또는 DB 인터페이스 범위에서 필드와 권한을 합의해 연계해요.

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

온실 한 동, 센서 한 묶음과 PLC 상태 몇 점부터 시작해요. 현장 표시값, PLC 값, POST JSON과 수신 시스템 값을 같은 시각에 대조하고, 통신 복구 뒤 누락·중복·지연 데이터가 의도대로 남는지 확인해요. 조회 흐름이 안정된 뒤 WRITE CALLBACK과 OPC UA 시험 노드를 각각 분리해 검증해요.

API 설정은 EASY LOGGER API 설정 가이드, 다른 스마트팜 활용은 축사 환기·냉방 데이터 글과 기술 블로그 목록에서 비교할 수 있어요. 센서 모델, Modbus RTU 주소, LS PLC 항목과 수신 API 형식을 정리했다면 HT Automation 홈페이지에서 현재 구성의 현장 연결 가능 여부를 부담 없이 확인해 보세요. 연결만 필요한지, 저장·라우팅·대시보드 운영까지 필요한지 범위부터 나누면 돼요.

#EASY-LINK #EASY LOGGER #스마트팜 #LS PLC #Modbus RTU #HTTP API #MQTT #MySQL #Firebase #PLC 연동 #센서 데이터 수집 #데이터 연동