스마트팜 유량계 HTTP API 연동, 현장값을 운영 데이터로 바꾸는 순서
먼저 결론부터 볼게요
스마트팜에서 유량계 값을 모으는 목적은 숫자를 한 번 확인하는 데서 끝나지 않아요. 관수나 양액 공급이 계획대로 진행됐는지, 같은 시간에 값이 들어왔는지, 외부 시스템이 다시 읽을 수 있는 형태로 남았는지를 함께 확인해야 운영 판단이 빨라져요. 농촌진흥청 자료도 스마트팜을 환경 데이터 수집과 분석, 서비스, 제어가 이어지는 구조로 설명하고 있어요. 그래서 유량계 연동은 센서값을 HTTP API로 보낸다는 문장보다 필드 정의, 주소 맵, 전달 결과를 한 흐름으로 맞추는 일이 먼저예요.
처음에는 유량계 한 대와 PLC 주소 한 구간만 정해요. 현장 표시값, PLC 원시값, 단위, 수집 시각을 같은 표에 적고 HTTP API의 JSON 필드와 대조하면 주소 오류와 전송 오류를 나눠 볼 수 있어요. 아래의 FLOW01, D0100, FLOW_CONFIG는 설명용 예시 이름이며 실제 PLC와 설정명은 현장 필드 주소 맵과 대조해 확정해야 해요.
유량 데이터를 운영 기준으로 먼저 정의해요
유량계의 단위가 L/min인지 누적량인지부터 정해야 해요. 순간 유량과 누적 유량을 같은 flow 키로 보내면 대시보드가 정상처럼 보여도 관수량을 비교할 때 해석이 달라질 수 있어요. 필드 주소 맵에는 필드명, PLC 주소, 데이터 타입, 단위, 배율, 수집 주기, 변경 시각을 함께 남겨요. FLOW01이 D0100에 대응한다는 문장은 예시이고, 적용 전에는 실제 주소 맵과 대조해요.
전달 대상은 목적에 따라 비교해요. MQTT는 브로커 기반으로 여러 소비자에게 실시간 흐름을 나누기 좋고, HTTP API는 외부 서버의 endpoint와 JSON 계약을 맞추기 좋아요. MySQL은 외부 스키마에 유량 이력을 보존하고 기간별로 검색할 때 유리하고, Firebase는 웹 화면에서 현재 상태와 이력을 공유할 때 비교할 수 있어요. 이번 글의 deliveryTarget은 HTTP API이므로 먼저 요청 본문과 응답 상태를 맞춘 뒤 MQTT, MySQL, Firebase를 추가 판단 대상으로 두면 돼요.
MES·CIM 연계는 확인된 HTTP API, MQTT 또는 DB 인터페이스 범위에서 계약을 정해요. 주소 맵과 외부 스키마를 승인한 뒤 같은 필드가 전달되는지 확인해요.
유량 데이터는 관수량과 양액 공급 흐름을 시간순으로 비교하게 해 줘요. 현재값만 보면 공급이 진행 중인지 멈췄는지 알 수 있지만, 마지막 수신 시각과 누적 이력이 함께 있어야 원인을 좁힐 수 있어요. 운영자는 먼저 데이터를 읽고 전달한 경로를 확인한 뒤 필요한 조치를 별도 승인 절차로 판단해요. 이 글은 그 확인 순서를 HTTP API 구현 예제로 정리해요.
EASY-LINK는 유량계·PLC와 목적지 사이의 현장 연결·데이터 전달을 맡는 게이트웨이 역할에 맞고, EASY LOGGER는 수집 주기·저장 이력·전달 상태·대시보드 운영을 묶는 데이터 로거 역할에 맞아요. 한 장치의 값을 HTTP API로 보내고 연결 상태만 확인하면 EASY-LINK만으로 충분할 수 있어요. 여러 설정의 이력과 API 응답을 계속 확인하거나 운영 화면에서 흐름을 관리하려면 EASY LOGGER를 함께 검토하는 편이 좋아요.
EASY-LINK가 현장 유량계와 PLC 데이터를 연결하는 공식 제품 이미지예요.
HTTP API 전달 흐름을 작게 검증해요
유량계 필드 FLOW01과 PLC D0100의 대응은 예시이며 실제 주소는 현장 필드 주소 맵과 대조해야 해요. 아래 post JSON의 endpoint, field, value, unit, timestamp는 HTTP API 요청을 확인하기 위한 예시 형식이에요. Automatic Endpoint Preview에서 승인된 endpoint를 확인하고 Runtime Status에서 연결·응답 상태를 본 다음 API Payload Log에서 같은 시각의 payload를 대조해요.
{
"endpoint": "https://example.invalid/api/flow",
"field": "FLOW01",
"plc_address": "D0100",
"value": 42.5,
"unit": "L/min",
"timestamp": "2026-08-16T09:00:00+09:00"
}
EASY LOGGER HTTP API 예제
유량계 필드 FLOW01을 PLC D0100에 매핑한 설정은 설명용 예시이며 실제 주소와 설정명은 현장 필드 주소 맵과 대조해야 해요. 아래 예제의 post JSON은 외부 endpoint에 전달되는 확인용 payload이고, write_callback_url은 http://LOGGER_HOST:8000/api/write/PLC/CONFIG 형식의 callback endpoint 예시예요. Automatic Endpoint Preview에서 endpoint와 callback 주소를 확인하고 Runtime Status에서 요청·응답 상태를 확인해요. API Payload Log에서는 post JSON과 write callback JSON이 같은 필드·주소 맵을 가리키는지 비교해요.
{
"post_endpoint": "https://example.invalid/api/flow",
"write_callback_url": "http://LOGGER_HOST:8000/api/write/PLC/CONFIG",
"field": "FLOW01",
"plc_address": "D0100",
"config_name": "FLOW_CONFIG",
"value": 42.5,
"unit": "L/min"
}
WRITE CALLBACK을 호출할 때는 테스트 주소만 사용해요.
{
"write_callback_url": "http://LOGGER_HOST:8000/api/write/PLC/CONFIG",
"field": "FLOW01",
"plc_address": "D0100",
"result": "accepted",
"runtime_status": "verified"
}
WRITE CALLBACK을 사용해 외부 서버가 검증한 값을 EASY LOGGER write endpoint로 보냅니다.
- 테스트 주소만 사용합니다.
- 최소 권한만 부여합니다.
- 허용 주소 범위를 제한합니다.
- PLC 인터록을 확인합니다.
- 수동 복구 절차를 준비합니다.
write callback JSON의 field, plc_address, result는 실제 외부 schema와 주소 맵을 대조한 뒤 사용해요. Runtime Status에서 요청이 승인된 시각과 마지막 오류를 확인하고 API Payload Log에서 post JSON과 callback JSON의 주소가 같은지 확인해요. 운영 제어 범위는 별도 승인과 인터록 조건으로 검토해요.
EASY LOGGER가 유량 데이터의 저장 이력과 전달 상태를 운영하는 공식 제품 이미지예요.
운영에 넘기기 전 확인할 순서
첫째, 현장 표시값과 D0100 원시값의 시각을 맞춰요. 둘째, 단위와 배율을 확인해 HTTP API의 value가 순간 유량인지 누적 유량인지 구분해요. 셋째, Automatic Endpoint Preview에서 endpoint와 callback 주소를 확인해요. 넷째, Runtime Status와 API Payload Log에서 같은 시각의 성공 응답과 payload를 함께 확인해요. 다섯째, 외부 서버 기록이 승인된 schema에 저장됐는지 확인해요.
한 장치의 연결과 전달만 필요하면 EASY-LINK 범위를 먼저 검토하고, 여러 유량계의 저장 이력과 전달 상태를 계속 관리하면 EASY LOGGER를 더하는 구성이 알맞아요. 두 제품의 역할을 섞지 않고 현장 연결 계층과 데이터 운영 계층으로 나누면 장애 위치도 좁혀져요.
HTTP API와 MQTT의 차이를 더 비교하려면 유량계 MQTT와 API 선택 기준을 참고하고, Modbus RTU 문제를 주소·설치 관점에서 다시 점검하려면 유량계 Modbus RTU 점검 순서를 이어서 보면 좋아요. 설정 항목과 장비별 확인표는 제품 매뉴얼 라이브러리에서 확인할 수 있어요.
현장 연결 가능 여부가 궁금하면 유량계 모델, PLC 주소 맵, 전달 endpoint를 알려 주세요. 연결 범위를 먼저 확인해요.