스마트팜 양액 pH·EC 데이터를 HTTP API로 운영에 연결하는 기준

먼저 결론부터 볼게요

스마트팜에서 양액 pH와 EC 데이터를 모으는 목적은 숫자를 많이 쌓는 일이 아니에요. 오늘 공급액의 상태가 재배 판단에 쓸 만한지, 값이 마지막으로 들어온 시각이 언제인지, 센서와 통신 중 어느 구간을 먼저 확인할지를 정하는 일이 핵심이에요. pH는 산도 변화, EC는 용액의 전기전도도 변화를 보여주지만, 단위와 측정 시각이 빠지면 두 값의 흐름을 함께 비교하기 어려워요.

특히 양액은 한 번의 값보다 구역과 시점의 맥락이 중요해요. 같은 온실이라도 공급액과 배액, 재배 구역에 따라 값의 의미가 달라질 수 있고, 센서 보정 직후와 통신 재연결 직후의 값도 따로 표시해야 해요. 현장 표시값, 제어기나 PLC의 원시 필드, API로 보낸 값, 운영 화면의 마지막 수신 시각을 한 흐름으로 적으면 측정 문제와 전달 문제를 나눠 볼 수 있어요.

처음부터 모든 구역을 연결하기보다 한 구역의 pH·EC 필드로 시작하는 편이 좋아요. 정상 범위의 값만 확인하지 말고 보정 전후, 통신 단절, 재연결 뒤 첫 payload까지 같은 기준으로 기록해요. 그러면 담당자는 양액 조정이 필요한 상황인지, 센서·주소·네트워크를 먼저 확인할 상황인지 결정할 수 있어요.

양액 센서와 현장 제어기에서 운영 시스템까지 값을 확인하는 추상 흐름이에요.

센서 값을 운영 질문으로 바꾸는 기준

주소 맵에는 구역 ID, 센서 필드, 원시 주소, 데이터 타입, 단위, 배율, 측정 시각을 함께 적어요. 예를 들어 ZONE_A의 NutrientPH와 NutrientEC가 각각 제어기의 R100과 R102에 대응한다고 가정할 수 있어요. 이 이름과 주소는 설명을 위한 샘플이므로 실제 센서 사양, 제어기 설정, 현장 field address map과 대조해 확정해야 해요. pH가 실수형인지 정수와 배율 조합인지, EC 단위가 무엇인지도 표에 남겨야 해요.

운영 질문도 필드와 함께 정해요. 현재값을 보는 질문에는 측정 시각과 마지막 수신 시각이 필요하고, 하루의 변화를 비교하는 질문에는 구역 ID와 품질 상태가 필요해요. 값이 정상 범위라도 수신 시각이 오래됐다면 같은 문제로 보지 않도록 상태를 나눠요. 이 기준을 정리할 때는 스마트팜 pH 센서 추세 데이터 글의 변화 확인 관점과 제품 매뉴얼 자료실의 설정 항목을 함께 대조하면 좋아요.

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

현장 필드를 확인해 목적지로 전달하는 범위라면 EASY-LINK를 연결 계층으로 검토할 수 있어요. 한 구역의 pH·EC 값을 HTTP API로 보내고 endpoint, 응답, 재시도 결과를 확인하는 일이 중심일 때 적합한 출발점이에요. 반대로 여러 구역의 저장 이력·전달 상태·대시보드를 함께 봐야 하면 EASY LOGGER를 운영 계층으로 더해 화면과 책임 구간을 정리하는 편이 좋아요. EASY-LINK가 저장 이력과 대시보드 운영을 대신한다고 보지 않고, EASY LOGGER가 실제 현장 주소를 임의로 확정한다고 보지도 않아요.

EASY LOGGER의 승인 원본 이미지로 운영 계층을 구분해 보는 예시예요.

두 제품을 함께 검토할 때도 먼저 필요한 범위를 작게 잡아요. 한 대 또는 한 공정의 시험 필드로 연결해 현장값과 payload를 비교한 뒤, 담당자가 확인할 화면과 보존 책임이 늘어날 때 운영 계층을 넓혀요. 제품의 확인된 현장 연결 범위는 EASY 제품 페이지에서 살펴보고, 실제 연결 가능 여부는 센서 모델·주소 맵·필요한 API 항목을 정리해 상담으로 확인해요.

HTTP API를 목적지로 고르는 기준

HTTP API는 운영 서버가 정한 endpoint와 요청·응답 계약을 분명히 해야 할 때 검토하기 좋아요. pH·EC 값을 JSON으로 보내면 서버는 구역, 필드, 측정 시각, 품질 상태를 기준으로 저장하거나 후속 화면에 전달할 수 있어요. 이 데이터 연동은 endpoint와 payload의 책임 주체를 먼저 정하는 방식이에요. 다만 성공 응답만 믿지 말고 timeout, 재시도, 중복 요청을 어떻게 기록할지 먼저 정해야 해요.

MQTT는 여러 소비자가 현재 변화를 구독할 때 비교하고, MySQL은 운영팀이 소유한 외부 스키마에서 기간별 이력을 조회할 때 비교해요. Firebase는 웹·모바일 화면의 현재 상태 동기화를 검토할 수 있어요. 이 네 방식은 우열보다 소비 주체와 보존 책임이 달라요. 운영자는 프로토콜 비교 결과를 데이터 보존과 확인 화면의 요구에 맞춰 해석해요. MES·CIM 같은 상위 시스템도 확인된 MQTT·HTTP API·DB 인터페이스 연계 범위에서 협의하고, 확인되지 않은 전용 커넥터를 전제로 하지 않아요.

단계적으로 검증하는 순서

먼저 센서 표시값과 현장 원시 필드를 같은 시각에 기록해요. 다음으로 변환된 pH·EC 값, API payload의 measuredAt, 서버의 receivedAt을 나란히 비교해요. 정상값, 경계값, 센서 단절, 제어기 통신 단절, HTTP 재연결 뒤 첫 요청을 차례로 확인하면 어느 구간의 책임인지 좁히기 쉬워요.

운영 화면에서는 현재값과 마지막 수신 시각을 먼저 보고, Runtime Status에서 연결 상태를 확인한 뒤 Payload Log에서 필드·단위·시각을 대조해요. 저장 기능을 함께 쓰는 구성이라면 DB History에서 같은 zoneId와 field가 시간 순서대로 남는지 확인하고, Dashboard에서는 구역별 추세를 비교하는 데이터 추세 분석을 해요. 원격 모니터링이 필요한 경우에도 마지막 수신 시각과 품질 상태를 함께 확인해요. 화면에서 보이는 값은 운영 판단을 돕는 근거이고, 현장 제어와 보정은 별도 승인 절차로 나눠요.

EASY LOGGER HTTP API 예제

아래 NUTRIENT_CTRL_01, ZONE_A, R100, R102는 설명을 위한 샘플이에요. pH 필드가 R100, EC 필드가 R102에 대응한다고 가정했으므로 실제 사용 전 센서·제어기 설정과 현장 field address map을 대조해야 해요. Automatic Endpoint Preview에서 endpoint와 callback 흐름을 확인하고, Runtime Status에서 연결 상태를 본 뒤 Payload Log에서 전송된 필드와 시각을 확인해요.

{
  "endpoint": "https://OPERATION_SERVER_HOST/api/v1/nutrient/readings",
  "method": "POST",
  "plcName": "NUTRIENT_CTRL_01",
  "configName": "ZONE_A_PH_EC",
  "dataType": "float",
  "values": {"R100": 5.8, "R102": 2.1},
  "measuredAt": "2026-08-25T09:00:00+09:00",
  "zoneId": "ZONE_A"
}

위 payload는 NutrientPH와 NutrientEC를 각각 R100, R102로 읽어 변환했다는 예시예요. Automatic Endpoint Preview에서 POST 주소와 응답 코드를 확인하고, Runtime Status에서 마지막 전송 시각을 본 뒤 API Payload Log의 values가 주소 맵과 맞는지 확인해요.

{
  "write_callback_url": "https://TEST_SERVER_HOST/api/v1/nutrient/callback",
  "status": "accepted",
  "requestId": "sample-request-001"
}

WRITE CALLBACK을 호출할 때는 테스트 주소만 사용해요.

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

위 JSON의 write_callback_url은 callback endpoint의 구체적인 예시예요. API Payload Log에서 callback endpoint, 응답 상태, requestId를 함께 확인하고 Runtime Status의 마지막 처리 시각과 대조해요. 운영 제어와 데이터 확인을 같은 권한으로 묶지 않고, callback 응답과 현장 인터록 결과를 따로 기록해요. 한 구역에서 값·시각·응답을 맞춘 뒤 한 공정으로 단계적 범위를 넓히면 변경 책임도 추적하기 쉬워요. 현장 연결 가능 여부를 확인하고 싶다면 센서 모델, pH·EC 주소 맵, endpoint 계약, 필요한 Runtime Status 항목을 정리해 상담이나 문의로 확인해 보세요.