Introduction

This documentation is for developers and integrators building on top of IOmeter, whether that's a home energy management system, a battery/inverter controller, or a backend platform integration.

What is IOmeter?

IOmeter makes German electrical utility meter data — power, energy consumption, and energy production — available to other systems in real time. IOmeter is a hardware + cloud product made up of three parts:

The Core and Bridge together are what most people mean by "an IOmeter installation" — one Core per meter, talking to one Bridge, which is on the customer's home network and registered to their IOmeter account (and, through that account, to IOmeter Cloud).

Use cases

IOmeter data is commonly used to:

• Display live power consumption and energy production to an end user
• Bill or monitor energy usage
• Control home battery storage systems and inverters — the live power reading is precise and fast enough to drive charge/discharge decisions, in particular to prevent feeding battery energy back to the grid

Three ways to get IOmeter data

There are three fundamentally different ways to integrate, and most integrations pick one:

• Cloud integration — talk to the Partner API, a GraphQL backend-to-backend interface. You don't need access to the customer's local network; you link their IOmeter account once (with their consent) and then receive readings from IOmeter Cloud.
• LAN integration — talk directly to the IOmeter Bridge over the customer's local network (HTTP or UDP multicast). No cloud dependency, but your integration needs to run on the same LAN as the device.
• Push integration — the Bridge pushes readings and status updates directly to an HTTPS endpoint you host, no LAN adjacency or polling required. Requires a prior agreement with Neometer GmbH.

Read Choosing an Integration for a detailed comparison, or jump straight to Cloud Integration, LAN Integration, or Push Integration.

Terminology used throughout these docs (Core, Bridge, Installation, Device, OBIS code, ...) is collected in Key Concepts.

Key Concepts

Terminology used consistently across both the Cloud and LAN integration guides.

Choosing an Integration

IOmeter data can be consumed three ways. They are not mutually exclusive, but almost every integration is primarily one.

Guidance

• Choose Cloud if you're building a backend service or SaaS platform that needs data from IOmeter installations you don't have physical/network access to, or if you need historical (backfill) data.
• Choose LAN if your integration runs on-premises (e.g. an inverter or home automation hub on the customer's network) and needs the lowest-latency near realtime power reading, or needs to work with limited internet connectivity.
• Choose Push if you want the meter readings not routed through the IOmeter Cloud. Best for privacy and compliance.
• Combine methods if, for example, your backend uses the Partner API for historical/billing data while an on-site device of yours also reads live power locally for fast control loops, or while Push delivers the same data to your backend without polling.

OBIS Codes Reference

OBIS codes identify individual measurement registers on the utility meter. Not every meter provides every register — a reading only ever contains what the meter actually reported.

IOmeter represents OBIS codes differently depending on which API you're using:

• The Local API, HTTP Push uses the raw hex form the meter reports, e.g. 01-00:01.08.00*ff.
• The Partner API can normalize it to the shorter decimal form, e.g. 1-0:1.8.0

* 1-0:36.7.0 is reported by some older meter models in place of 1-0:16.7.0 for the same measurement (current active power).

Meter Number Decoding

The meter.number field (present across the Local API, Push Integration, and Partner API) is the meter's serial number, normally in DIN 43849 format, e.g. 1ESY1161338362. This page explains where that value comes from and when it can't be produced.

The German digital meter identifier system has gone through many changes during the German smart-meter rollout. In particular, early-installed smart meters may have meter numbers that IOmeter's firmware cannot translate to the value printed on the meter itself.

This is rare, but worth planning for: if you link meter numbers to user accounts, be aware a small fraction may not match the printed serial. The installation_id and device_id provided by IOmeter Cloud are stable regardless of meter-number decoding, and can be used as a fallback key if you need to manually reconcile a meter number to an account.

How IOmeter Core decodes meter numbers

SML

The meter number is normally taken from OBIS code 01-00:00.00.09*ff, or 01-00:60.01.00*ff for older, legacy meters.

The value of this OBIS code is used inconsistently across meter manufacturers, and is even configurable on some meter models. IOmeter attempts to interpret the raw value and translate it into the unified identifier format specified by DIN 43849, e.g.:

1ESY1161338362

If translation isn't possible, meter.number contains the raw octet string in hexadecimal instead, e.g.:

080535342d4ca011

IEC 1107 / DIN EN 62056-21 Mode D

The meter number is taken from one of 01-00:60.01.00*ff, 01-00:00.00.09*ff, or 01-00:00.00.00*ff. Since Mode D uses ASCII, no decoding is performed — the value is copied as-is into reading and status payloads.