Push Integration (HTTP Push)

IOmeter's Bridge can push meter readings and device status updates directly to a URL you host — no polling, no LAN adjacency, no Partner API account linking. The Bridge acts as an HTTPS client and calls your endpoint whenever a new reading or status change occurs.

How it fits with the other integration paths

• Push can be used in addition to or instead of routing energy consumption data through IOmeter Cloud:
• By default, readings continue to flow through IOmeter Cloud as normal alongside push delivery.
• Optionally, IOmeter Cloud's transport of meter-reading data can be disabled per installation, so energy consumption data reaches only your push endpoint. IOmeter Cloud itself is still required in this mode — device management, onboarding, smart-meter PIN entry, and monitoring keep working as before — it simply stops transporting meter readings.
• It's conceptually the same push model as LAN Integration's UDP Multicast — the device sends data as soon as it's available, with no request/response per message — except the transport is HTTPS POST to a single URL you control, reachable from wherever your endpoint lives (it does not need to be on the customer's LAN).
• Device management (provisioning, pairing, firmware) remains done through the IOmeter App and IOmeter Cloud regardless of whether push is enabled or whether Cloud's reading transport has been disabled.

Where to start

1. Setup & Authentication — endpoint requirements, authentication options, request/response contract
2. Message Payloads — the two message types sent to your endpoint

For the OBIS registers and meter-number formats that appear in these payloads, see the OBIS Codes Reference and Meter Number Decoding.

Setup & Authentication

Endpoint requirements

Your endpoint must accept an HTTPS POST request:

POST {pushUrl}

{pushUrl} is configured per IOmeter device/installation through the IOmeter Cloud, as agreed with Neometer GmbH during onboarding. All message types (reading and status) are sent to this same URL — your endpoint is responsible for telling them apart, which you can do by parsing the "__typename" field (see Message Payloads).

Authentication

The Bridge supports several ways to authenticate its requests to your endpoint:

• HTTP Basic Auth
• Bearer token
• A custom/pre-signed URL (credentials embedded in {pushUrl} itself)

Which method is used, and how credentials are provisioned to the device, is agreed with Neometer GmbH as part of setting up the push integration — there's no self-service configuration step.

Response contract

Return 204 No Content to acknowledge successful receipt:

Status: 204 NO CONTENT

Any other response is treated as delivery failure. As with UDP Multicast, there's no built-in retry/backoff contract documented here — treat missed deliveries the way you would a dropped multicast datagram: readings continuing to arrive is the signal that the endpoint is healthy. Whether IOmeter Cloud also receives every reading as a fallback depends on whether Cloud's reading transport has been disabled for the installation — see How it fits with the other integration paths.

Message Payloads

Push uses the same two message schemas as the Local API's HTTP/SSE and UDP multicast delivery — see Data Models for the full field-by-field reference. This page only covers what's specific to push delivery.

Both are delivered as the JSON body of the POST request described in Setup & Authentication. All timestamps are RFC 3339 (YYYY-MM-DDTHH:MM:SSZ), and OBIS codes are in hexadecimal form — see the OBIS Codes Reference.

Example: iometer.reading.v1

{
   "__typename": "iometer.reading.v1",
   "installationId": "301105a3-00c9-49bf-ae73-c58e244b9d17",
   "externalId": "any string",
   "meter": {
      "number": "1ESY1163206544",
      "reading": {
         "time": "2024-12-05T21:03:01Z",
         "registers": [
            { "obis": "01-00:01.08.00*ff", "value": 874.4651, "unit": "Wh" },
            { "obis": "01-00:10.07.00*ff", "value": 0, "unit": "W" }
         ]
      }
   }
}

Example: iometer.status.v1

{
   "__typename": "iometer.status.v1",
   "installationId": "301105a3-00c9-49bf-ae73-c58e244b9d17",
   "externalId": "any string",
   "meter": { "number": "1ESY1163206544" },
   "device": {
      "id": "0b21d582-54af-4619-b432-ae794d9f6e08",
      "bridge": { "rssi": -20, "version": "build-69" },
      "core": {
         "connectionStatus": "connected",
         "rssi": -14,
         "version": "build-62",
         "powerStatus": "wired",
         "attachmentStatus": "attached",
         "pinStatus": "entered"
      }
   }
}

If a meter number can't be resolved to the standard format, meter.number may contain a raw hex octet string instead — see Meter Number Decoding for why, and how to handle it.