Tech OVN

August 2026 · Integration & Connectivity

How to Get Energy Meter Data into Your Software (MQTT & Modbus)

You have chosen an energy meter. Now you need its measurements — voltage, current, kWh, kVAh, power factor, demand — flowing into your own analytics platform, SCADA, historian, or cloud application. This guide covers the two integration paths that Titan supports: MQTT push and Modbus TCP/RTU poll. No proprietary middleware. No REST API. Your data, your broker, your stack.

Two paths, two use cases

Energy meter integration almost always reduces to one of two architectures: you want the meter to push data to your cloud or analytics platform as it happens, or you want your SCADA system or historian to poll the meter on demand. Titan supports both, and you can run them simultaneously.

The right choice depends on where your application lives and how it consumes data:

  • MQTT push — the meter connects to your broker and publishes readings on a schedule. Best for cloud pipelines, analytics platforms, time-series databases, and AI/ML workloads where you want data to arrive without polling.
  • Modbus TCP/RTU poll — your SCADA, PLC, or historian queries the meter when it needs a reading. Best for on-premises industrial systems with existing Modbus infrastructure or where the application controls the polling cycle.

Both paths use open, vendor-neutral standards. There is no proprietary SDK to install, no REST API, and no dependency on Tech OVN's cloud to access your own meter data.

Path 1 — MQTT push to your own broker

MQTT is a lightweight publish-subscribe protocol designed for constrained devices and unreliable networks. Titan acts as an MQTT client: it connects to the broker you specify, publishes measurement payloads at a configurable interval, and reconnects automatically if the connection drops. You configure the broker endpoint, port, credentials, and topic prefix in Titan's settings.

Broker options

Any MQTT broker works — Titan does not depend on a specific vendor. Common choices:

  • AWS IoT Core — managed MQTT with device certificates, IAM-based access, and direct routing to Timestream, S3, Lambda, or Kinesis
  • Azure IoT Hub — MQTT-compatible hub with device twins, message routing, and Stream Analytics integration
  • HiveMQ / Mosquitto / EMQX — self-hosted or managed brokers for teams that want full control over the message bus

Topic structure and payload

Titan publishes to a configurable topic prefix. A representative topic structure — verify the exact format against your device's firmware documentation — follows this pattern:

techovn/<site-id>/<device-id>/telemetry

The JSON payload includes the core electrical parameters for each phase and the totals. A representative payload structure:

{
  "ts": 1756195200,
  "voltage": { "L1": 231.4, "L2": 230.8, "L3": 232.1 },
  "current": { "L1": 18.3, "L2": 17.9, "L3": 18.6 },
  "kW":    { "L1": 3.82, "L2": 3.75, "L3": 3.91, "total": 11.48 },
  "kVA":   { "L1": 4.24, "L2": 4.12, "L3": 4.32, "total": 12.68 },
  "pf":    { "L1": 0.901, "L2": 0.910, "L3": 0.905, "avg": 0.905 },
  "kWh":   1842.61,
  "kVAh":  2036.12,
  "freq":  49.98
}

The above is illustrative of a typical payload structure. Refer to the Titan firmware documentation or contact Tech OVN for the exact topic hierarchy, field names, and data types for your firmware version.

Your pipeline subscribes to the topic prefix with a wildcard — for example techovn/+/+/telemetry — to receive readings from all meters across all sites into a single subscriber. From there, route by site-id and device-id to write into your time-series database or data lake.

Path 2 — Modbus TCP/RTU to SCADA and historians

Modbus is the lingua franca of industrial automation. If your SCADA system, PLC, or historian already speaks Modbus, you can add Titan meters to your existing polling infrastructure without any change to your data acquisition layer — just add the meter as a new Modbus device.

Modbus TCP vs Modbus RTU

Titan supports both variants. Modbus TCP runs over standard Ethernet/WiFi — the same network the meter uses for MQTT — and is the preferred path for modern installations. Modbus RTU runs over RS485, a two-wire bus that supports multi-drop wiring where multiple meters share a single cable run to a Modbus master. RTU is common in panel-level deployments where meters are physically close to a local panel PC or PLC with an RS485 port.

Register map overview

Titan exposes its measurement parameters as Modbus holding registers (function code 03). The register map covers voltage, current, power (active, apparent, reactive), energy accumulators (kWh, kVAh, kVArh), power factor, frequency, demand, and per-phase values. A representative block structure — again, verify the exact register addresses against the Titan Modbus documentation for your firmware version before configuring your SCADA:

Register block (illustrative addresses):
  0x0000 – Voltage L1 (×0.1 V, uint16)
  0x0001 – Voltage L2
  0x0002 – Voltage L3
  0x0003 – Current L1 (×0.01 A, uint16)
  0x0004 – Current L2
  0x0005 – Current L3
  0x000A – Active Power Total (W, int32, 2 registers)
  0x000C – Apparent Power Total (VA, int32, 2 registers)
  0x0010 – Power Factor Average (×0.001, int16)
  0x0020 – Import kWh Total (×0.01, uint32, 2 registers)
  0x0024 – Import kVAh Total (×0.01, uint32, 2 registers)

Exact register addresses, data types, scaling factors, and supported function codes are specified in the Titan Modbus register map. Request the document from Tech OVN before configuring your SCADA or historian.

No gateway required for WiFi and Ethernet meters

A common pain point with older meter designs is the requirement for a separate data concentrator or gateway — a dedicated piece of hardware that sits between the meters and the network, collects readings over RS485, and forwards them upstream. Titan eliminates this layer for WiFi and Ethernet deployments.

Each Titan meter connects directly to your LAN as a first-class network device. For MQTT, it opens a TCP connection to your broker and pushes data. For Modbus TCP, your SCADA opens a connection to the meter's IP address and polls it directly. No gateway firmware to maintain, no gateway hardware to power and mount, no single point of failure that takes down all the meters behind it.

This matters at scale. In a facility with 20 sub-meters, a gateway-based design typically means 4–5 RS485 buses each with their own gateway — five hardware assets that need maintenance and replacement over time. A direct-connect design is 20 meters, one switch, and one broker.

For deployments where RS485 bus wiring is already in place, Titan's RS485 port and Modbus RTU support let you use the existing cable infrastructure. The Titan Audit portable logger also supports Modbus, which means short-term audit meters slot into the same polling loop as permanent installation meters without additional integration work.

Multi-meter and multi-site aggregation

Individual meter integration is straightforward. Aggregating dozens of meters across multiple sites into a coherent data pipeline takes a little more architecture, but the building blocks are the same.

Single-site, multiple meters

On a single site, all Titan meters publish to the same broker (MQTT) or respond to the same Modbus master (TCP/RTU). Differentiate meters in MQTT by device ID in the topic; in Modbus by unit address. Your backend maps device IDs or unit addresses to physical locations — incomer, production floor feeder A, utilities panel — in a configuration table or device registry.

Multi-site into one pipeline

For multiple sites, include the site identifier in the MQTT topic hierarchy. Each site's meters publish under their own site prefix; your central broker aggregates everything. A subscriber at HQ receives readings from all sites, tagged by site and device, and routes them to the appropriate tenant, building, or reporting entity in your database.

For sites with unreliable WAN links, run a local MQTT broker at the site that buffers readings during outages and bridges to the central broker when connectivity resumes. This pattern keeps local data continuity without losing readings to network gaps.

You own the raw data

The guiding principle of Titan's integration design is that the data belongs to you. Titan is the accurate hardware layer — Class 0.5S per IEC 62053-22 — that puts clean electrical measurements into your broker or your SCADA system. What you build on top of it — dashboards, anomaly detection, ESG reports, tenant billing, AI load forecasting — is entirely your stack. You are not locked to Tech OVN's cloud, and you can change your analytics platform or historian without changing the meters. Contact Tech OVN to discuss your integration architecture before you deploy.

Frequently Asked Questions

Common questions about integrating Titan energy meter data with external software via MQTT and Modbus.

No. Titan uses MQTT (push) and Modbus TCP/RTU (poll) as its two integration protocols. There is no REST API. MQTT is the recommended path for cloud and analytics pipelines; Modbus is the recommended path for on-premises SCADA, PLCs, and historians. Both are open, well-documented standards supported by virtually every industrial and cloud platform.
No. Titan connects directly to your network via WiFi or Ethernet and pushes data to your MQTT broker, or responds to Modbus TCP queries, without any intermediate gateway. For Modbus RTU (RS485) deployments you will need either a Modbus TCP-to-RTU gateway or direct RS485 wiring to a host that has an RS485 port — but for WiFi/Ethernet-connected meters, no gateway is required.
Yes. Because Titan pushes standard MQTT, it can connect to any MQTT-compatible broker — AWS IoT Core, Azure IoT Hub, HiveMQ, Mosquitto, or a self-hosted broker. Configure the broker endpoint, port, and credentials in Titan's settings and your pipeline receives the data directly. You own the data in your own cloud account.
Modbus TCP polling speed depends on network latency and how many registers you request per query. Over a LAN, polling 32 registers from a single meter typically completes in under 100 ms. For a large fleet, structure your polling cycles to query each meter at the interval your application needs — most energy-management applications poll at 1–15 minute resolution, which is easily achievable with dozens of meters on one network. For RS485 bus deployments, the slower bus speed (typically 9600–115200 baud) limits throughput more than TCP does.
Each site's Titan meters publish to the same MQTT broker (or respond to the same Modbus TCP host) using a site identifier in the topic or as a tag. Your backend pipeline reads all sites from one broker endpoint and routes data by site/meter identity. Alternatively, each site can push to a local broker that forwards to a central broker — a common pattern for sites with unreliable WAN links, as the local broker buffers data during outages.
Yes. Titan Audit is the portable energy logger designed for short-term audits and sub-metering deployments. It supports the same Modbus interface, making it straightforward to read alongside fixed Titan meters in the same polling loop or SCADA system. This lets you combine permanent monitoring data with audit or temporary sub-metering data in a single pipeline.

Bring accurate meter data into your own software

Titan pushes measurement data to your MQTT broker or responds to your Modbus queries — no gateway, no proprietary cloud. Talk to an engineer about your integration.