Receive IAMMETER Energy Data on Your Own Server

Receive IAMMETER Energy Data on Your Own Server

IAMMETER Wi-Fi energy meters can send measurement data directly to a server, MQTT broker or data platform controlled by the customer. This lets developers and system integrators build their own EMS, BMS, IoT service, database or monitoring dashboard without using IAMMETER-Cloud as the data destination.

This guide approaches the integration from the receiving-server side:

• bring up a test receiver;
• capture the first meter payload;
• identify the meter and measurement channels;
• normalize and store the data;
• estimate ingestion volume;
• prepare the receiver for production deployment.

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

For meter-side firmware capabilities and address formats, use the IAMMETER Local API and Open Interface Guide. For architecture selection, see Develop Your Own Energy Monitoring System.

1. Select a Receiver Architecture

The meter can push its measurements using several transports. The receiving system should select one primary ingestion path.

Transport	Receiver component	Good starting point for
HTTP / HTTPS	Web endpoint	REST backends and the simplest first integration
MQTT / MQTTS	MQTT broker and subscriber	Existing IoT platforms and message pipelines
TCP / TLS	Socket listener	Dedicated collectors and custom protocol services

HTTP is normally the easiest way to inspect the first payload because the official test receiver can be started with a small Node.js example. MQTT is a strong choice when a broker is already part of the system. TCP/TLS provides a lower-level socket integration but requires more receiver-side engineering.

The secure transports and custom-port formats are maintained in the current firmware guide, rather than repeated here.

2. Quick Start: Receive the First Payload over HTTP

IAMMETER provides an official Node.js HTTP receiver example for integration testing.

2.1 Start the Test Receiver

Download the example from:

• IAMMETER HTTP Server Example on GitHub

Run:

node Server.js

The example listens on port 8000. When a request arrives, it:

• collects the HTTP request body;
• prints the request URL;
• prints the uploaded body;
• returns HTTP status 200 with a small success JSON response.

The example is deliberately minimal. It does not provide authentication, persistence, validation, rate limiting or production security.

2.2 Make the Receiver Reachable

Before configuring the meter, confirm that:

• the server is listening on the expected interface and port;
• the firewall allows the connection;
• the meter can resolve the domain name when a domain is used;
• any NAT, reverse proxy or VPN path is working;
• the final URL reaches the intended application route.

For a LAN test, the meter and receiver can use the same local network without Internet access. For a remote receiver, the site must have a route to the server.

2.3 Point the Meter to the Receiver

In the current meter WebUI, select the HTTP run mode and enter a destination such as:

{server-address}:8000/upload

HTTPS endpoints can use the default port or a custom port. Current address rules, including https://host:port, are documented in the HTTP/HTTPS firmware section.

After saving the setting, check the receiver console for the request path and uploaded JSON. Keep this first raw payload as a test fixture for later parser and database tests.

3. Understand the Incoming IAMMETER Payload

IAMMETER uses a consistent core measurement JSON structure across the supported push transports. The transport changes how the payload arrives, but the measurement model remains consistent.

A payload normally includes device-level fields such as:

• SN — meter serial number used to identify the device;
• version — meter firmware version;
• method — message method or payload type;
• Data or Datas — measurement arrays.

Data is used for a single measurement channel. Datas contains multiple measurement arrays for a multi-channel or three-phase meter.

Example single-channel structure:

{
  "method": "uploadsn",
  "mac": "B0F8932A295C",
  "version": "i.75.98.71y",
  "server": "em",
  "SN": "12345678",
  "Data": [228.91, 1.61, 225, 15066.47, 0]
}

Do not hard-code one array count for every meter. The number of channels and available fields depends on the meter model and enabled measurement features.

Use the authoritative definition when implementing the parser:

• IAMMETER Energy Meter JSON Data Definition

3.1 Model-specific Processing

Keep model-specific processing separate from the transport receiver.

For example, WEM3046T and WEM3046TE measure the 5 A secondary output of an external current transformer. Their values must be converted with the applicable CT ratio to obtain the primary-side measurement. This is a meter and CT characteristic, not an HTTP, MQTT or TCP difference.

A practical ingestion pipeline therefore separates:

1. transport decoding;
2. JSON validation;
3. meter and channel identification;
4. model-specific scaling or normalization;
5. storage and business calculations.

4. Design the Ingestion Data Model

Store enough information to reproduce and diagnose the original reading.

A useful minimum model includes:

Field	Purpose
Meter SN	Maps the payload to a registered device
Channel or phase index	Distinguishes single, split-phase and three-phase data
Server receive time	Provides a consistent ingestion timestamp
Voltage	Electrical measurement
Current	Electrical measurement
Active power	Real-time import/export or load calculation input
Import kWh	Cumulative imported energy
Export kWh	Cumulative exported energy
Firmware version	Supports troubleshooting and parser compatibility
Raw payload	Allows replay, auditing and parser correction

Additional fields such as frequency, power factor and reactive measurements should be stored when the selected model and configuration provide them.

4.1 Keep Raw and Normalized Data Separate

For production systems, consider keeping:

• an immutable or short-retention raw-ingestion record;
• normalized channel-level readings used by the application;
• aggregated hourly, daily and monthly values.

This makes it easier to correct parsing or CT-ratio logic without losing the original payload.

4.2 Use Server Receive Time Carefully

Record the time at which the server accepted the payload. If the business system also uses a device or source timestamp, store both values separately rather than replacing one with the other.

Network delay, reconnects and queued processing can make ingestion time different from measurement time. Define the timestamp used by charts, billing and alarms before production deployment.

5. Implement the Other Receiver Types

5.1 MQTT or MQTTS Receiver

For MQTT ingestion, the customer system provides:

• a reachable MQTT broker;
• authentication and access-control rules;
• a subscriber or consumer service;
• payload validation and persistence;
• monitoring for broker and consumer health.

IAMMETER publishes real-time data under a device topic such as:

device/{SN}/realtime

Use the dedicated guide for broker configuration, credentials, topics and MQTTS considerations:

• Publish IAMMETER Data to Your MQTT Broker

Home Assistant MQTT Discovery is not required for a general customer-server integration.

5.2 TCP Receiver

IAMMETER provides a minimal Node.js TCP listener:

• IAMMETER TCP Server Example on GitHub

The example listens on port 8000 and prints received data. A production TCP receiver must additionally provide:

• connection lifecycle management;
• payload buffering and validation;
• safe handling of partial or combined socket chunks;
• device identification;
• persistence and error handling;
• monitoring and controlled resource limits.

Do not assume that one socket data event always equals one complete application message.

5.3 TLS Receiver

The official TLS example demonstrates a TLS listener with a server key and certificate:

• IAMMETER TLS Server Example on GitHub

Before production use, replace demonstration certificates and settings with the organization's approved certificate, key-management and security configuration. The receiver should log TLS failures separately from payload-validation failures.

The meter-side address formats for TCP and TLS are maintained in the firmware interface guide.

6. Plan the Upload Interval and Server Capacity

Current firmware supports a third-party upload interval down to 2 seconds. A short interval is useful only when the receiving system, storage and application need the additional resolution.

Approximate records generated per meter:

Upload interval	Records per meter per day	100 meters per day	1,000 meters per day
60 seconds	1,440	144,000	1,440,000
10 seconds	8,640	864,000	8,640,000
2 seconds	43,200	4,320,000	43,200,000

These numbers represent upload events, not necessarily database rows. A three-phase payload may be normalized into several channel records, and indexes, raw-payload retention or replicated storage increase the actual database volume.

Capacity planning should include:

• peak concurrent connections;
• requests or messages per second;
• JSON parsing cost;
• channel-level row multiplication;
• database indexes and retention;
• dashboards and aggregation queries;
• logs, retries and dead-letter storage;
• backup and replication traffic.

For one-second control or automation on the same LAN, consider Modbus TCP instead of using a remote upload pipeline.

7. Handle Reliability and Data Quality

A production receiver should expect network and application failures.

7.1 Validate Every Payload

Validate at least:

• JSON syntax;
• required identity fields;
• expected array structure;
• numeric types and reasonable ranges;
• supported model or channel mapping;
• firmware-dependent field variations.

Keep malformed payloads in a controlled diagnostic path without allowing them to block valid devices.

7.2 Plan for Duplicate and Missing Uploads

Do not assume that every interval produces exactly one permanently stored record. Network interruptions, reconnect behavior, server retries or application processing can produce missing or repeated ingestion events.

Define how the business system will:

• detect duplicate records;
• identify gaps;
• distinguish a silent meter from a failed receiver;
• avoid calculating energy by blindly summing cumulative kWh registers;
• reconcile cumulative energy after an interruption.

7.3 Monitor the Complete Data Path

Monitor more than the web or socket process. Useful signals include:

• last payload time per meter;
• invalid-payload count;
• receiver response time and error rate;
• active TCP/TLS connections;
• MQTT consumer lag;
• database write latency;
• queue depth;
• disk usage and retention jobs.

8. Secure the Receiving System

For an Internet-facing receiver:

• prefer an encrypted transport supported by the deployment;
• restrict exposed ports and network sources where possible;
• apply MQTT authentication and topic authorization;
• protect HTTP endpoints with the surrounding network or application security architecture;
• manage TLS certificates and private keys securely;
• avoid writing credentials or complete sensitive payloads to application logs;
• rate-limit and isolate malformed or abusive traffic;
• keep the operating system, runtime and dependencies updated.

Review the current MQTTS, TLS and HTTPS firmware behavior in the firmware and open-interface guide before selecting a security design.

9. Production Deployment Checklist

Meter and network

• Firmware version recorded and validated
• Meter SN mapped to the correct site and channels
• Destination address and port verified
• DNS, firewall, NAT or VPN path tested
• Required upload interval confirmed

Receiver

• Raw payload captured from every meter model in scope
• Parser tests created from real payload fixtures
• Single and multi-channel payloads handled
• WEM3046T/E CT-ratio processing validated where applicable
• Malformed and unsupported payloads isolated safely
• Receiver returns or maintains the behavior expected by the selected transport

Storage and operations

• Timestamp policy documented
• Duplicate and missing-data policy documented
• Database capacity calculated for the device count and interval
• Logs, metrics and per-meter last-seen alerts enabled
• Retention, backup and recovery tested
• Certificates, credentials and access rules reviewed
• Network interruption and receiver restart tested

10. Related Documentation

• Develop Your Own Energy Monitoring System
• Use IAMMETER Without Internet or IAMMETER-Cloud
• IAMMETER Local APIs and Open Interfaces
• MQTT Energy Meter Integration
• IAMMETER Measurement JSON Definition
• Self-hosted and Open-source Integration Overview

11. Legacy Meter-side Configuration Screenshots

The original version of this document focused on configuring older meter firmware. These screenshots are retained only for users identifying an existing installation. For new integrations, use the current WebUI and latest firmware.

Legacy TCP page

Legacy TLS page

Legacy HTTP/HTTPS page

Earlier firmware documentation also used the local /api/uploadinterval configuration method and described a six-second minimum. Current firmware exposes the interval in the WebUI and supports a documented minimum of 2 seconds.

Last updated: July 16, 2026