스마트팜 수위 데이터 HTTP API와 Firebase 대시보드로 운영하기
안녕하세요. 스마트팜에서 수위센서 값을 모으는 일은 숫자를 한 번 저장하는 것으로 끝나지 않아요. 현재 수위가 얼마인지, 마지막으로 언제 들어왔는지, HTTP API 전달이 성공했는지, 지난 이력과 비교할 수 있는지가 함께 보여야 운영 판단이 빨라져요.
이번 글에서는 수위센서와 PLC의 필드 주소를 먼저 맞춘 뒤 HTTP API로 전달하고, Firebase와 EASY LOGGER 대시보드에서 흐름을 확인하는 기준을 정리해요. EASY-LINK는 현장 연결과 게이트웨이 역할이 필요할 때 유용하고, EASY LOGGER는 수집 이력과 전송 상태, 대시보드 운영까지 이어서 보고 싶을 때 잘 맞아요. 두 제품은 역할이 겹친다기보다 현장 연결과 데이터 운영을 나눠 맡는 구성으로 이해하면 쉬워요. 관련 제품 범위는 HT Automation 홈페이지의 EASY 제품 안내에서, 전체 글 흐름은 블로그 목록의 연동 사례에서 함께 살펴볼 수 있어요.
EASY-LINK는 현장 장치와 상위 전송 경로를 연결하는 제품이에요.
수위 데이터에서 먼저 맞춰야 할 기준
수위센서의 측정 필드는 현장 주소 맵에서 먼저 확정해야 해요. 예를 들어 LEVEL_01이라는 필드를 PLC의 D0100에 매핑하는 방식은 설명용 예시이며, 실제 주소와 데이터 타입은 현장 필드 주소 맵과 대조해야 해요. 수위 단위가 mm인지 퍼센트인지, 스케일과 정상 범위가 무엇인지도 함께 기록해야 HTTP API의 JSON 키와 대시보드 카드가 같은 의미를 유지할 수 있어요.
EASY-LINK만으로 충분한 경우는 한 현장의 장치 데이터를 MQTT, HTTP API, MySQL, Firebase 중 하나로 곧바로 보내면 되는 경우예요. 여러 수집 조건의 이력과 마지막 수신 시각, 전달 상태를 한 화면에서 운영하려면 EASY LOGGER가 더 적합해요. EASY LOGGER는 수집·저장·외부 연동·대시보드 표시를 한 운영 흐름으로 묶는 역할을 해요.
HTTP API와 전달 대상 프로토콜 비교
HTTP API는 외부 서버나 웹 서비스로 확정된 JSON을 전달하기 좋아요. Firebase는 웹 대시보드에서 현재값과 이력을 빠르게 조회할 대상이 될 수 있고, MySQL은 외부 시스템이 정한 스키마로 장기 분석을 이어갈 때 적합해요. MQTT는 브로커 기반의 실시간 발행·구독이 강점이라 여러 소비자가 같은 값을 받아야 할 때 유리해요.
따라서 수위 화면을 바로 갱신해야 하면 MQTT를 비교 대상으로 보고, 외부 API 계약에 맞춰 보내야 하면 HTTP API를 우선 검토해요. Firebase는 대시보드 조회, MySQL은 외부 스키마 기반 분석이라는 차이가 있어요. EASY LOGGER에서는 현재 수집값과 전송 결과를 먼저 확인한 뒤 목적지별로 범위를 넓히는 편이 운영하기 좋아요.
관련 설정 흐름은 EASY LOGGER HTTP API 설정 가이드에서 확인할 수 있고, 주소와 데이터 타입을 다시 대조할 때는 제품 매뉴얼 라이브러리를 참고하면 좋아요.
EASY LOGGER는 수집 이력과 전달 상태를 운영 화면으로 이어주는 제품이에요.
EASY LOGGER HTTP API 연동 예제
수위센서의 LEVEL_01 필드를 PLC 주소 D0100에 매핑한다는 설정은 예시이며, 실제 적용 전 현장 필드 주소 맵과 reconciled 해야 해요. 아래 Topic과 payload는 HTTP API 설정에서 확인하는 검증된 형식을 기준으로 작성한 예시예요. 먼저 API Runtime Status에서 외부 서버 연결이 활성화되었는지 확인하고, Automatic Endpoint Preview에서 생성된 주소를 확인해요.
POST ENDPOINT: http://LOGGER_HOST:8000/api/write/PLC/CONFIG
GET LATEST: http://LOGGER_HOST:8000/api/write/PLC/CONFIG
이 엔드포인트는 예시 이름을 현장 주소 맵과 대조한 뒤 사용해야 해요. API Payload Log에서는 Timestamp, Endpoint, Json을 확인하고, Dashboard에서는 수위 현재값과 마지막 수신 시각, 전달 상태를 같은 기준으로 비교해요.
수위 필드와 PLC 주소의 대응을 다시 확인한 다음, 외부 API가 받는 JSON은 다음처럼 구성할 수 있어요. D100과 D102는 검증된 API payload 필드 형식의 예시이고, 실제 수위 주소와 키는 현장 필드 주소 맵에 맞춰 reconciled 해야 해요.
{
"D100": 1,
"D102": 23.77,
"write_callback_url": "http://LOGGER_HOST:8000/api/write/PLC/CONFIG"
}
Dashboard에서는 D0100에 매핑한 LEVEL_01의 현재값, 마지막 수신 시각, HTTP API 전달 상태를 한 카드에서 확인하고, Firebase에 저장한 외부 이력과 기간별 추세를 이어서 비교해요. 값이 갱신되지 않으면 Dashboard의 마지막 수신 시각만 보지 말고 API Runtime Status와 API Payload Log를 함께 확인해야 해요.
EASY LOGGER 대시보드 예제
대시보드 구성은 네 가지 증거를 기준으로 잡으면 좋아요. 현재값은 지금 수위를 보여주고, 마지막 수신 시각은 데이터가 멈춘 시점을 구분해요. 전달 상태는 HTTP API와 Firebase 경로가 정상인지 알려주고, 이력은 관수 전후의 변화를 비교하게 해요. 이 화면은 규정 준수나 품질 판정을 대신하는 화면이 아니라 운영자가 데이터 흐름을 확인하는 화면이에요.
LEVEL_01을 PLC D0100에 연결한 예시는 설명용이며 실제 주소·스케일·정상 범위는 현장 필드 주소 맵과 reconciled 해야 해요. EASY LOGGER의 Dashboard 카드에는 매핑된 필드 이름과 단위를 표시하고, HTTP API의 마지막 전송 결과는 API Runtime Status와 Payload Log에서 교차 확인해요. 위젯 필드 근거는 field=LEVEL_01, plc_address=D0100, unit=mm, source=HTTP API, delivery_target=Firebase로 확인해요. current value 근거는 Dashboard 위젯의 LEVEL_01 현재값이며, 같은 위젯의 last receive time과 함께 읽어야 해요.
{
"field": "LEVEL_01",
"plc_address": "D0100",
"unit": "mm",
"source": "HTTP API",
"delivery_target": "Firebase"
}
위 예시가 반영되면 Dashboard에는 LEVEL_01 현재값, last receive time, delivery state, history가 연결되어 보여야 해요. 값만 있고 마지막 수신 시각이 오래되었다면 센서 값의 문제가 아니라 수집 또는 전달 지연일 수 있어요. 반대로 수신 시각은 갱신되는데 history가 비어 있다면 Firebase의 외부 스키마와 쓰기 결과를 확인해야 해요.
운영 전 점검 순서
- 테스트 주소만 사용하고 실제 운영 주소와 분리해요.
- 최소 권한만 부여하고 API와 Firebase의 쓰기 범위를 제한해요.
- 허용 주소 범위를 제한하고 수위 필드 외 주소는 전송하지 않아요.
- PLC 인터록을 확인한 뒤 수집을 시작해요.
- 수동 복구 절차와 마지막 정상 수신 시각을 준비해요.
EASY-LINK는 센서나 PLC에서 게이트웨이까지의 연결이 필요한 현장에 충분하고, EASY LOGGER는 여러 수집 조건의 상태와 이력을 운영해야 할 때 도움이 돼요. 처음부터 모든 목적지를 열기보다 HTTP API와 Firebase 한 경로로 현재값·수신시각·전달상태·이력을 확인한 뒤 MQTT나 MySQL을 추가하는 방식이 안정적이에요.
마지막으로 실제 주소 맵, 단위, 스케일, 외부 Firebase 스키마를 승인한 뒤 Dashboard 카드와 API Payload Log의 키가 일치하는지 확인해요. 현장 연결 가능 여부는 현재 센서 모델, PLC 주소 맵, HTTP API Endpoint만 먼저 확인해도 부담 없이 좁혀볼 수 있어요. 이 과정을 지키면 수위 데이터가 들어왔다는 사실과 지금 운영에 쓸 수 있다는 판단을 분리해서 볼 수 있어요.