IAMMETER Wi-Fi 에너지 미터는 측정 데이터를 고객이 제어하는 서버, MQTT 브로커 또는 데이터 플랫폼으로 직접 전송할 수 있습니다. 이를 통해 개발자와 시스템 통합자는 IAMMETER-Cloud를 데이터 대상으로 사용하지 않고 자체 EMS, BMS, IoT 서비스, 데이터베이스 또는 모니터링 대시보드를 구축할 수 있습니다.
이 가이드는 수신 서버 측에서의 통합을 설명합니다:
IAMMETER meter
│
│ HTTP/HTTPS, MQTT/MQTTS or TCP/TLS
▼
Customer ingestion service
│
├── Raw-payload log
├── Time-series or relational database
├── EMS / BMS / ERP
└── Dashboard, report and alarm services
미터 측의 펌웨어 기능 및 주소 형식에 대해서는 IAMMETER Local API 및 Open Interface 가이드를 참조하세요. 아키텍처 선택에 대해서는 자체 에너지 모니터링 시스템 개발을 참조하세요.
미터는 여러 전송 방식을 사용하여 측정값을 전송할 수 있습니다. 수신 시스템은 하나의 기본 수집 경로를 선택해야 합니다.
| 전송 방식 | 수신기 구성 요소 | 시작하기 좋은 대상 |
|---|---|---|
| HTTP / HTTPS | 웹 엔드포인트 | REST 백엔드 및 가장 간단한 첫 번째 통합 |
| MQTT / MQTTS | MQTT 브로커 및 구독자 | 기존 IoT 플랫폼 및 메시지 파이프라인 |
| TCP / TLS | 소켓 리스너 | 전용 수집기 및 사용자 정의 프로토콜 서비스 |
HTTP는 일반적으로 첫 번째 페이로드를 검사하는 가장 쉬운 방법입니다. 공식 테스트 수신기를 작은 Node.js 예제로 시작할 수 있기 때문입니다. MQTT는 브로커가 이미 시스템의 일부인 경우 좋은 선택입니다. TCP/TLS는 더 낮은 수준의 소켓 통합을 제공하지만 더 많은 수신기 측 엔지니어링이 필요합니다.
보안 전송 및 사용자 정의 포트 형식은 최신 펌웨어 가이드에 유지되어 있으며, 여기서 반복하지 않습니다.
IAMMETER는 통합 테스트를 위한 공식 Node.js HTTP 수신기 예제를 제공합니다.
다음에서 예제를 다운로드하세요:
실행:
node Server.js
예제는 포트 8000에서 수신 대기합니다. 요청이 도착하면 다음을 수행합니다:
200 반환.이 예제는 의도적으로 최소한으로 설계되었습니다. 인증, 지속성, 유효성 검사, 속도 제한 또는 프로덕션 보안을 제공하지 않습니다.
미터를 구성하기 전에 다음을 확인하세요:
LAN 테스트의 경우 미터와 수신기가 인터넷 액세스 없이 동일한 로컬 네트워크를 사용할 수 있습니다. 원격 수신기의 경우 사이트에 서버 경로가 있어야 합니다.
현재 미터 WebUI에서 HTTP 실행 모드를 선택하고 다음과 같은 대상을 입력하세요:
{server-address}:8000/upload
HTTPS 엔드포인트는 기본 포트 또는 사용자 정의 포트를 사용할 수 있습니다. https://host:port를 포함한 현재 주소 규칙은 HTTP/HTTPS 펌웨어 섹션에 문서화되어 있습니다.
설정을 저장한 후 수신기 콘솔에서 요청 경로와 업로드된 JSON을 확인하세요. 이 첫 번째 원시 페이로드를 이후 파서 및 데이터베이스 테스트를 위한 테스트 픽스처로 보관하세요.
IAMMETER는 지원되는 모든 푸시 전송 방식에서 일관된 핵심 측정 JSON 구조를 사용합니다. 전송 방식은 페이로드가 도착하는 방식을 변경하지만 측정 모델은 일관되게 유지됩니다.
페이로드에는 일반적으로 다음과 같은 장치 수준 필드가 포함됩니다:
SN — 장치를 식별하는 데 사용되는 미터 일련 번호;version — 미터 펌웨어 버전;method — 메시지 메서드 또는 페이로드 유형;Data 또는 Datas — 측정 배열.Data는 단일 측정 채널에 사용됩니다. Datas는 다중 채널 또는 삼상 미터에 대한 여러 측정 배열을 포함합니다.
단일 채널 구조 예시:
{
"method": "uploadsn",
"mac": "B0F8932A295C",
"version": "i.75.98.71y",
"server": "em",
"SN": "12345678",
"Data": [228.91, 1.61, 225, 15066.47, 0]
}
모든 미터에 대해 하나의 배열 개수를 하드코딩하지 마세요. 채널 수와 사용 가능한 필드는 미터 모델 및 활성화된 측정 기능에 따라 다릅니다.
파서를 구현할 때는 공식 정의를 사용하세요:
모델별 처리를 전송 수신기와 분리하여 유지하세요.
예를 들어, WEM3046T 및 WEM3046TE는 외부 변류기의 5A 2차 출력을 측정합니다. 해당 값을 해당 CT 비율로 변환하여 1차 측정값을 얻어야 합니다. 이는 미터 및 CT 특성이며 HTTP, MQTT 또는 TCP의 차이가 아닙니다.
따라서 실용적인 수집 파이프라인은 다음을 분리합니다:
원래 판독값을 재현하고 진단할 수 있는 충분한 정보를 저장하세요.
유용한 최소 모델에는 다음이 포함됩니다:
| 필드 | 목적 |
|---|---|
| Meter SN | 페이로드를 등록된 장치에 매핑 |
| 채널 또는 위상 인덱스 | 단상, 분할 위상 및 삼상 데이터 구분 |
| 서버 수신 시간 | 일관된 수집 타임스탬프 제공 |
| Voltage | 전기 측정값 |
| Current | 전기 측정값 |
| Active power | 실시간 송전/수전 또는 부하 계산 입력 |
| Import kWh | 누적 수전 에너지 |
| Export kWh | 누적 송전 에너지 |
| Firmware version | 문제 해결 및 파서 호환성 지원 |
| Raw payload | 재생, 감사 및 파서 수정 허용 |
주파수, 역률 및 무효 측정과 같은 추가 필드는 선택한 모델 및 구성에서 제공하는 경우 저장해야 합니다.
프로덕션 시스템의 경우 다음을 분리하여 보관하는 것을 고려하세요:
이렇게 하면 원래 페이로드를 잃지 않고 파싱 또는 CT 비율 로직을 더 쉽게 수정할 수 있습니다.
서버가 페이로드를 수락한 시간을 기록하세요. 비즈니스 시스템에서 장치 또는 소스 타임스탬프도 사용하는 경우, 하나를 다른 것으로 대체하지 말고 두 값을 별도로 저장하세요.
네트워크 지연, 재연결 및 대기열 처리로 인해 수집 시간이 측정 시간과 다를 수 있습니다. 프로덕션 배포 전에 차트, 청구 및 알람에서 사용하는 타임스탬프를 정의하세요.
MQTT 수집을 위해 고객 시스템은 다음을 제공합니다:
IAMMETER는 다음과 같은 장치 토픽으로 실시간 데이터를 게시합니다:
device/{SN}/realtime
브로커 구성, 자격 증명, 토픽 및 MQTTS 고려 사항에 대해서는 전용 가이드를 사용하세요:
Home Assistant MQTT Discovery는 일반 고객 서버 통합에 필요하지 않습니다.
IAMMETER는 최소한의 Node.js TCP 리스너를 제공합니다:
예제는 포트 8000에서 수신 대기하고 수신된 데이터를 출력합니다. 프로덕션 TCP 수신기는 추가로 다음을 제공해야 합니다:
하나의 소켓 data 이벤트가 항상 하나의 완전한 애플리케이션 메시지와 같다고 가정하지 마세요.
공식 TLS 예제는 서버 키와 인증서가 있는 TLS 리스너를 보여줍니다:
프로덕션 사용 전에 데모 인증서와 설정을 조직의 승인된 인증서, 키 관리 및 보안 구성으로 교체하세요. 수신기는 TLS 오류를 페이로드 유효성 검사 오류와 별도로 기록해야 합니다.
TCP 및 TLS에 대한 미터 측 주소 형식은 펌웨어 인터페이스 가이드에 유지되어 있습니다.
현재 펌웨어는 타사 업로드 간격을 최소 2초까지 지원합니다. 짧은 간격은 수신 시스템, 저장소 및 애플리케이션에 추가 해상도가 필요한 경우에만 유용합니다.
미터당 생성되는 대략적인 레코드 수:
| 업로드 간격 | 미터당 일일 레코드 수 | 일일 100개 미터 | 일일 1,000개 미터 |
|---|---|---|---|
| 60초 | 1,440 | 144,000 | 1,440,000 |
| 10초 | 8,640 | 864,000 | 8,640,000 |
| 2초 | 43,200 | 4,320,000 | 43,200,000 |
이 숫자는 업로드 이벤트를 나타내며 반드시 데이터베이스 행을 의미하지는 않습니다. 삼상 페이로드는 여러 채널 레코드로 정규화될 수 있으며, 인덱스, 원시 페이로드 보존 또는 복제된 저장소로 인해 실제 데이터베이스 볼륨이 증가합니다.
용량 계획에는 다음이 포함되어야 합니다:
동일 LAN에서 1초 제어 또는 자동화가 필요한 경우, 원격 업로드 파이프라인 대신 Modbus TCP를 고려하세요.
프로덕션 수신기는 네트워크 및 애플리케이션 오류를 예상해야 합니다.
최소한 다음을 검증하세요:
잘못된 형식의 페이로드는 유효한 장치를 차단하지 않도록 제어된 진단 경로에 보관하세요.
모든 간격이 정확히 하나의 영구 저장 레코드를 생성한다고 가정하지 마세요. 네트워크 중단, 재연결 동작, 서버 재시도 또는 애플리케이션 처리로 인해 수집 이벤트가 누락되거나 중복될 수 있습니다.
비즈니스 시스템이 다음을 어떻게 처리할지 정의하세요:
웹 또는 소켓 프로세스 이상의 것을 모니터링하세요. 유용한 신호는 다음과 같습니다:
인터넷에 노출된 수신기의 경우:
보안 설계를 선택하기 전에 펌웨어 및 개방형 인터페이스 가이드에서 현재 MQTTS, TLS 및 HTTPS 펌웨어 동작을 검토하세요.
이 문서의 원래 버전은 이전 미터 펌웨어 구성에 초점을 맞추었습니다. 이 스크린샷은 기존 설치를 식별하는 사용자만을 위해 보존됩니다. 새 통합의 경우 현재 WebUI 및 최신 펌웨어를 사용하세요.
이전 펌웨어 문서에서는 로컬 /api/uploadinterval 구성 방법도 사용했으며 6초 최소값을 설명했습니다. 현재 펌웨어는 WebUI에서 간격을 노출하고 문서화된 최소값인 2초를 지원합니다.
마지막 업데이트: 2026년 7월 16일
