How Captia Connect speaks IEC 870-5-102
Connect acts as the controlling station in the metering session, the side that asks. The meter is the secondary station and never speaks unless it is asked. That asymmetry is the first thing to accept, because it explains everything else: Connect does not receive a continuous stream of measurements, it opens a session, requests blocks of records the meter has already closed, and hangs up. The meter keeps measuring and storing whether anyone reads it or not; Connect only collects what the meter has already saved.
In a Spanish industrial site this is what sits behind the phrase "pulling the meter curve". The fiscal meter, the same one that underpins billing for the supply, stores the energy registers and the load curve internally. IEC 870-5-102 is the route by which Connect extracts them without touching the tariff configuration or interfering with the network operator's own reading.
Serial link and TCP link: the same dialogue over two paths
Connect establishes the session over two media, and the application dialogue is identical in both. The first is serial, against the meter's communications port or its associated modem, typically RS-232 or RS-485 at deliberately low speeds: 1200, 2400, 9600 and 19200 baud are all common across the installed base, with even parity and eight data bits as the most frequent combination. This is not a limitation worth fighting: a metering session moves very little data and the slow link is rarely the bottleneck.
The second is TCP, where the meter sits behind a serial to Ethernet converter, an industrial router or a vendor gateway that publishes the serial port onto the network. The field detail that matters here is that there is no port assigned by convention, no equivalent of 502 for Modbus TCP or 4840 for OPC UA: the port is whatever the person who fitted the converter chose, and it belongs in the commissioning record alongside the line speed. Connect treats it as a configuration parameter, never as a default.
In both cases the connection runs outbound from the Connect node to the meter and stays inside the site network. Outwards, the node opens no inbound ports: the link to the platform is established by Tailscale as a secure outbound connection. It is the same principle as every other acquisition route into the platform, and it matters more here than anywhere else, because the metering cabinet is usually the exact place nobody wants to open remote access into.
Addressing: link address and measurement point
Two identifiers are needed for Connect to read the right meter, and they should not be conflated, because that is the most common commissioning error with this protocol. The link address distinguishes the device on the bus or communication channel: it is what lets several meters share one RS-485 line without colliding. The measurement point address identifies the registered metering point, the one that appears on the contract and in the site paperwork. A device can answer on the link and return data for a metering point other than the one you believed you were reading.
Connect treats both addresses as part of the identity of the signal, not as connection parameters that are forgotten once the link is up. That is what allows a curve in the history to be reconciled against an invoice months later without depending on the memory of whoever did the installation.
What Connect asks for in each session
A metering session has a recognisable shape and Connect follows it in the same order: identify the device, check the clock, request the record blocks for the missing period and close. Three blocks matter, and each answers a different business question.
The load curve is the series of energy integrated over consecutive periods, with a timestamp per period. It is the data with a shape, the one that draws the daily consumption profile and underpins any subsequent energy analysis. The totalisers are the cumulative registers of active and reactive energy by quadrant and tariff period, together with the associated maximum demand values. The billing closures are the snapshots the meter consolidates at the end of each billing period and then freezes: they are the reference an invoice is checked against.
Connect always requests an explicit time range, with overlap, rather than "the latest". That design decision is what avoids the classic metering failure mode: a session that fails one night and leaves a gap nobody notices until somebody looks at the chart a month later. By requesting a range that overlaps what has already been downloaded and discarding duplicates on period timestamp, recovery after a failure is automatic and needs no intervention.
Why the cadence is unlike a process protocol
This is the hardest difference to convey and the one that drives the most decisions. A process protocol such as Modbus or OPC UA delivers the instantaneous value of a quantity, and the design question is how often to sample it. In metering there is no instantaneous value to sample: the meter delivers energy already integrated over a closed period. Reading more often buys no extra resolution, because resolution is set by the integration period configured in the meter, not by how frequently it is asked.
The practical consequence is that the typical session is daily and scheduled overnight, to collect the previous day's curve once it is complete. Where the operation wants to see consumption during the working day, Connect raises the session frequency to several times a day, and the ceiling is still the granularity of the curve. If what is genuinely needed is instantaneous power second by second, this is not the route: that comes from a power analyser, and that analyser speaks a different protocol. The distinction is developed in the limits section.
The flip side of a slow cadence is that buffering stops being optional. The Connect node runs acquisition on Docker and persists series to InfluxDB at the edge itself, so a drop in the link to the platform does not lose a download that happens once a day and that, if lost, has to be requested from the meter all over again. How that history is then retained and queried is the subject of the industrial historian guide.
| Parameter | What is decided | Starting criterion |
|---|---|---|
| Medium and link | Serial over RS-232 or RS-485, or TCP through a converter or industrial router | Use the link already present in the metering cabinet, without displacing the operator modem |
| Line parameters | Baud rate, parity and data bits, or the IP address and port of the converter | Recorded at commissioning: there is no de facto port that can safely be assumed |
| Addresses | Link address of the device and address of the metering point | Both are recorded as signal identity, not merely as connection parameters |
| Session scope | Which blocks are requested: load curve, totalisers or billing closures | Curve for analysis, totalisers and closures for reconciliation against invoices |
| Cadence | How often a session opens and how much overlap the requested range carries | A nightly session with an overlapping range, raised to several a day where operations need it |
Which equipment speaks IEC 870-5-102
In a Spanish industrial installation this protocol almost always turns up in the same physical place, the metering cabinet, and in three distinct forms worth separating because the integration work changes.
The first is boundary metering, the billing meters for the supply on sites with meaningful contracted power. This is the canonical case: the device is already installed, already verified and already storing a curve. The work for Connect is reading, and the installation amounts to reaching the communications port without disturbing anything already in place.
The second is secondary or allocation metering, the meters industry fits itself to know what each building, line or general service consumes. There is no regulatory obligation of any kind here, so the device was chosen by the installer, and the usual surprise is finding that the same meter offers both a metering session and a Modbus register map. When that happens the same protocol does not always win, and the decision sits in the coexistence section.
The third is concentrators and remote management units that group several metering points behind a single communication channel. The pattern is the same for Connect, with the difference that one session walks several link addresses and several metering points, and that the access window on the channel is shared with whoever else uses it.
Alongside those devices, in the same cabinet, there are almost always power analysers. They are not fiscal meters and they do not speak this protocol: they deliver voltage, current, power, power factor and harmonics over Modbus, TCP or RTU on RS-485. They are complementary rather than alternative, and in practice most Connect energy installations read both. The service that carries out that end to end data capture is edge ingestion.
From meter register to time series
What Connect downloads is not loose samples, it is timestamped blocks. Each curve period arrives with its start timestamp and its integrated energy, and that structure forces three normalisation decisions that never come up in a process protocol.
The first is the timestamp convention. A curve period is an interval, not an instant, and energy integrated between two hours can be stamped at the start or at the end of the interval. The convention is fixed once, documented and never changed. Change it midway through a history and the consumption charts shift by one period, a shift precisely the size that nobody notices until an invoice has to be justified.
The second is the difference between cumulative and consumption. A totaliser is a count that only grows, so the series useful for operations is its increment between readings, not its absolute value. Connect keeps both: the cumulative figure, because that is what is reconciled against invoices and because an increment without its origin cannot be audited; and the increment, because that is what gets plotted and what models consume. A cumulative register that resets or jumps backwards is itself a diagnostic signal.
The third is clock handling. The meter's own clock stamps the curve, and it is a clock that drifts and that also lives through seasonal time changes, with the duplicated and skipped periods that entails. Connect checks the device clock on every session and records the observed deviation alongside the data instead of silently correcting it. An energy history whose timestamps somebody rewrote to make things line up stops working as evidence.
On top of those three decisions the remaining work is identity, as in any industrial data acquisition system: every series is tied to its metering point, its consumption centre and its unit, with a stable name. That is what makes the curve usable by the energy optimisation module, which works on consumption histories and on the shape of the curve captured by Connect, not on isolated readings.
| What the meter delivers | What Connect does with it | What it is good for later |
|---|---|---|
| Load curve by integration period | One sample per period, stamped with the interval convention that was fixed and documented | It is the consumption profile that energy analysis and optimisation work on |
| Active and reactive energy totalisers | The cumulative value is stored and the increment between readings is derived as its own series | The cumulative figure reconciles against invoices, the increment is what gets plotted |
| Recorded maximum demand values | Kept associated with their tariff period and their timestamp | They support analysis of contracted power and of the excesses that penalise it |
| Billing period closures | Recorded as consolidated, immutable values, kept separate from the curve | They are the reference when an invoice does not match what was measured |
| Meter clock time | Compared against the node clock each session, with the deviation recorded beside the data | Prevents silent rewrites and explains any shift in the curve |
| Link address and metering point | Tied into the identity of the series, with a stable consumption centre and unit | Lets the history be reconciled with the contract months after installation |
When IEC 870-5-102 is not the right route
This is the right protocol for reading what a fiscal meter has stored, and the wrong route for almost everything else. Five scenarios where insisting on it costs time and adds nothing.
Instantaneous power or power quality is needed. The most frequent case and the most misunderstood. If the question is how much power is being drawn right now, whether a motor start is causing a voltage dip, or how much harmonic distortion the installation carries, metering does not answer it: it delivers energy integrated over closed periods. That comes from a power analyser over Modbus, at a cadence of seconds, and having both sources side by side is the norm.
Somebody wants to act on consumption. Connect acquires, it does not issue setpoints, and on a fiscal metering device that boundary is stricter still: the meter is a verified instrument and its configuration belongs to whoever verifies it. Shedding load, stopping a machine or moving a start is work for the plant control system, and the recommendation that triggers it comes from the energy optimisation module, not from the metering channel.
The meter is a submeter and already exposes Modbus. In secondary metering, where no fiscal traceability is required, a meter offering both routes is almost always better read over Modbus: the cadence is free, the register map is direct, and there are no sessions or access windows to manage. Metering is reserved for where it gives what Modbus cannot, namely the consolidated, auditable record.
The data already sits outside, in a network operator or supplier system. When what is needed is the curve a portal, a supplier web service or a periodic file already publishes, standing up a serial session against the meter is duplicated work. The route is the standard integrations over REST API, webhooks or CSV. The trade off should be understood: data from an external portal arrives days late and with whatever aggregation that portal applies, whereas reading the meter directly is available the next day at the granularity the device stores.
There is no physical or network access to the device. This happens more often than expected: the meter is sealed inside a shared cabinet, its communications port is occupied by the network operator's modem, or the channel has an access window that must not be intruded on. That is an installation limit rather than a protocol one, and the honest answer is usually to fit an own metering device downstream rather than force the boundary meter.
And one limit that belongs to the brief rather than the protocol: a load curve on its own explains nothing. A peak at three in the morning is inert data until somebody can say which machine was starting. The value appears when the curve is crossed with the process signals Connect acquires in parallel over other routes, which is why this protocol delivers little when it is deployed as an isolated integration.
Coexistence with the rest of the installation
On a site with energy metering, IEC 870-5-102 is never the only protocol and does not aim to be. The pattern Connect meets again and again is a division of labour: metering gives the consolidated, auditable consumption of the metering point, power analysers give instantaneous power and supply quality over Modbus, and PLCs and machines give, over OPC UA or MQTT, the process state that explains the consumption. Connect acquires over all three routes in parallel and lifts them into the same time series model, so they sit at the same level in the history and nobody needs to know which protocol a value came from in order to use it.
Where metering and an analyser coexist on the same supply, the inevitable question arrives: the two numbers disagree. Nor should they agree. They measure at different points, with different accuracy classes and over different integration periods. The Connect operating rule is simple and heads off the argument: the fiscal meter is the reference for any figure that will be checked against an invoice, and the analyser is the reference for anything to do with shape, dynamics and diagnosis. Both series are kept, and neither is corrected against the other.
Migration, in the sense of replacing this protocol with another, barely exists. A boundary meter is not swapped because somebody would prefer a different protocol: it is swapped when it is due, and until then it speaks what it speaks. What does evolve is the installation around it, as newer secondary metering arrives already speaking Modbus or with its own IP interface. Hence the recommendation not to frame energy metering as a protocol homogenisation project, but as an acquisition layer that accepts what is in the cabinet.
The energy optimisation module then works on that layer, drawing on consumption histories and on the load curves captured by Connect, and the engineering project that deploys it is edge ingestion.