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 ローカル API とオープン インターフェース ガイドを参照してください。アーキテクチャの選択については、独自のエネルギー監視システムを開発するを参照してください。
メーターは、複数のトランスポートを使用して測定値を送信できます。受信システムは、主要な取り込み経路を 1 つ選択する必要があります。
| トランスポート | レシーバー コンポーネント | 適した用途 |
|---|---|---|
| HTTP / HTTPS | Web エンドポイント | 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]
}
すべてのメーターに対して 1 つの配列数をハードコードしないでください。チャンネル数と利用可能なフィールドは、メーターのモデルと有効になっている測定機能によって異なります。
パーサーを実装する際は、信頼できる定義を使用してください。
モデル固有の処理は、トランスポート レシーバーから分離してください。
たとえば、WEM3046T と WEM3046TE は、外部変流器の 5 A 二次側出力を測定します。これらの値は、該当する CT 比で変換して一次側の測定値を取得する必要があります。これはメーターと CT の特性であり、HTTP、MQTT、TCP の違いではありません。
したがって、実用的な取り込みパイプラインでは、次の処理を分離します。
元の測定値を再現して診断するのに十分な情報を保存してください。
有用な最小限のモデルには、次のものが含まれます。
| Field | Purpose |
|---|---|
| Meter SN | ペイロードを登録済みデバイスに対応付ける |
| Channel or phase index | 単相、分相、三相のデータを区別する |
| Server receive time | 一貫した取り込みタイムスタンプを提供する |
| 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 レシーバーは、さらに以下を提供する必要があります。
1 つのソケット data イベントが常に 1 つの完全なアプリケーション メッセージと等しいとは想定しないでください。
公式の TLS サンプルは、サーバー キーと証明書を使用した TLS リスナーを示しています。
本番使用の前に、デモ用の証明書と設定を、組織が承認した証明書、キー管理、セキュリティ設定に置き換えてください。レシーバーは、TLS の障害をペイロード検証の障害とは別にログに記録する必要があります。
TCP と TLS のメーター側アドレス形式は、ファームウェア インターフェース ガイドで管理されています。
現在のファームウェアは、サードパーティへのアップロード間隔を最短 2 秒 までサポートしています。短い間隔が役立つのは、受信システム、ストレージ、アプリケーションが追加の分解能を必要とする場合だけです。
メーター 1 台あたりに生成されるおおよそのレコード数：
| アップロード間隔 | メーター 1 台あたりの 1 日あたりのレコード数 | 100 台で 1 日あたり | 1,000 台で 1 日あたり |
|---|---|---|---|
| 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 を検討してください。
本番レシーバーは、ネットワークとアプリケーションの障害を想定する必要があります。
少なくとも以下を検証してください。
不正なペイロードは、正常なデバイスをブロックしないように、管理された診断パスに保持してください。
すべての間隔で正確に 1 つの永続レコードが生成されるとは想定しないでください。ネットワークの中断、再接続動作、サーバーの再試行、またはアプリケーション処理によって、取り込みイベントの欠落や重複が発生する可能性があります。
ビジネス システムで以下の方法を定義してください。
Web やソケットのプロセスだけでなく、より広範囲を監視してください。有用なシグナルには、以下が含まれます。
インターネットに公開されるレシーバーの場合：
セキュリティ設計を選択する前に、ファームウェアとオープン インターフェース ガイドで現在の MQTTS、TLS、HTTPS のファームウェア動作を確認してください。
このドキュメントの元のバージョンは、古いメーター ファームウェアの設定に焦点を当てていました。これらのスクリーンショットは、既存の設置環境を特定するユーザーのためにのみ保持されています。新しい統合には、現在の WebUI と最新ファームウェアを使用してください。
以前のファームウェアのドキュメントでは、ローカルの /api/uploadinterval 設定方法も使用され、最短 6 秒と説明されていました。現在のファームウェアでは、間隔は WebUI で公開され、文書化された最短 2 秒 をサポートしています。
最終更新日：2026 年 7 月 16 日
