Solicite informações agora

DIN Rail Energy Meters · Technical Explainer

Energy Meter Memory After a Power Outage: What to Verify

Cyanotype-style illustration of a generic energy meter with a separate ghosted clock motif on cobalt paper.

Published outubro 17, 2026

Quick answer

Verify an energy meter's outage recovery by data type: accumulated energy, configuration settings, any supported clock, logs and communication state. A retained energy total does not prove that every setting or timestamp survives, and a successful first communication response does not prove continuity in the monitoring database. Remote switching state is a related topic; see remote meter disconnection commands, feedback and recovery.

Request the exact configuration's retained-field description, storage behaviour and manufacturer-authorised acceptance procedure. Record the relevant readings before and after the approved event, with their units, register identities and time references. Treat undocumented features as unknown, not automatically passed or failed.

This is a specification and acceptance-record guide. It does not authorise interrupting a production circuit, clearing accumulated readings or opening a sealed meter.

Identify the exact meter and interrupted supply

Begin with the order code, serial number, hardware revision, firmware where available and fitted configuration. A family name alone may include different displays, communication options and reset functions. Use the manual and register map that match the supplied item.

Describe which supply boundary is affected by the acceptance scenario. Meter power, the measured circuit and the gateway's power are separate identities, even where they normally fail together. Establish their actual arrangement instead of assuming every outage removes every source simultaneously.

Also distinguish an unexpected loss of power from a deliberate reset, a firmware update or replacement of the meter. These are different events with different evidence requirements. Do not include destructive operations in an outage-memory check simply because they are accessible through the same menu.

O RITOKS two-pole communicating energy-meter family publicly lists power-off memory and parameter setting. Ask which fields and behaviours this covers in the selected configuration. That feature label does not specify a storage interval, clock backup mechanism or retention period.

Separate the retained information into named fields

Make a field register rather than a single checkbox marked memory works. For each item, identify the actual display page, parameter or communication register and its meaning. Distinguish total energy from a resettable session value, and import/export direction from a combined quantity where those features are supported.

Schneider's PM5500 memory section describes nonvolatile storage of metering data/configuration and a separate memory provision for data logs in that product. This demonstrates why a model's documentation should identify the stored information, not why all meters must use the same architecture. Its memory life figures are not transferred to RITOKS products. Schneider Electric, PM5500 meter memory.

Use the following original register to define the acceptance scope. Include a row only when the exact configuration supports that function; otherwise mark it not applicable or awaiting documentation.

Information group Identity to record Evidence required for the selected configuration
Accumulated energy Register/display name, unit, direction and reset status Retention description and accepted recovery comparison
Configuração Each required setting and its allowed value Saved-setting behaviour after the defined interruption
Clock Time reference, time zone and synchronisation source if supported Backup or restart behaviour and post-recovery time status
Stored logs Log type, interval or event identity where provided Persistence, capacity and recovery/export behaviour
Comunicação Selected protocol, address and associated settings Restart behaviour and first valid interpreted response
Monitoring system Gateway/logger identity and record timestamps Gap, duplicate and reconciliation handling outside the meter

Assign documentation gaps to the supplier or integrator before commissioning. A feature absent from a short catalogue description is not necessarily absent from the product, but it cannot be treated as verified.

Four separated shapes labelled energy total, settings, clock and logs identify distinct retention questions.
Only where supported; no physical memory architecture or shared retention guarantee is asserted.

Distinguish display updates from durable storage

An active display value and the value last committed to durable storage are different questions. Ask the manufacturer how the selected accumulated values are saved and what happens when power disappears. Do not infer the answer from display refresh speed.

Schneider's ComPacT NSX MicroLogic energy-metering section provides an exact trip-unit example with distinct display-update and nonvolatile-storage cadences. It also distinguishes accumulation modes and resettable versus nonresettable quantities. This is a reason to request those details, not evidence that a DIN-rail meter uses the same interval or register structure. Schneider Electric, MicroLogic energy metering.

Storage cadence alone does not establish an actual loss window. Obtain the manufacturer's description of power-failure handling and recovery before claiming that a particular interval of energy will be lost or retained.

The acceptance record should distinguish a documented expectation from an observed result under defined conditions. A reading that remains visible after one event supports that particular observation; it does not independently establish memory endurance, long-term retention or behaviour under every interruption.

Compare the same energy quantity before and after recovery

Record the pre-event reading with its unit, resolution, direction, register identity and independent observation time. Preserve a screenshot or captured response as appropriate. The post-event comparison must use the same quantity and interpretation.

Account for any measurement that legitimately occurred between the observations under the authorised procedure. A changed total is not automatically lost data, and an unchanged total is not automatically proof of correct accumulation. The accepted method should define how those possibilities are distinguished.

Do not compare a local total with a remotely calculated daily consumption value as though they were the same register. Likewise, do not mistake an import-only total for a combined or signed quantity. The exact configuration's documentation governs what is available.

If a value unexpectedly decreases or changes identity, preserve the evidence and examine the selected register, scaling, reset history and device identity before assigning a cause. Avoid clearing the meter or editing the monitoring baseline to make the discrepancy disappear.

Check parameters without silently restoring them

List the settings essential to the installed application. For a communicating configuration, these may include the selected address and communication parameters supported by that model. For another configuration, the relevant list may be different.

Capture the required pre-event values and compare them after recovery before the integrator automatically rewrites settings. Otherwise, automatic commissioning software can conceal whether the meter itself retained them.

Record any intentional intervention separately: who changed the setting, when and why. A successful result after manual restoration is not the same as automatic retention. It may still be an acceptable project recovery strategy, but the specification and acceptance record should describe it accurately.

O RITOKS DDS1108 DIN-rail meter family is a separate noncommunication family with selected display and reset/clear configurations. Do not apply the communicating model's functions to it. Request exact retention information rather than interpreting a reset option as proof that an outage clears cumulative energy.

Treat timekeeping as a separate function

Where a meter supports a clock or timestamped information, ask what happens to time when primary power is absent. Establish whether the time source belongs to the meter, gateway or server. A timestamp on an exported record may not originate inside the meter.

Schneider's ION8600/ION8650 technical note describes a battery maintaining that meter's real-time clock during loss of primary power. This is an exact-model example of a separate timekeeping function. It does not prove that either RITOKS family contains a battery or clock, and its battery-life figures do not apply to them. Schneider Electric, ION8600/ION8650 clock-battery note.

Capture the post-recovery time state before any supported synchronisation corrects it, where the authorised procedure permits that observation. Record synchronisation as a separate event. Correct time after a server update does not prove uninterrupted local timekeeping.

If clock support is undocumented, identify whether the project actually needs it. An external logger's time reference can be part of a system design, but it must not be advertised as an unverified meter feature.

Verify the monitoring chain after communication returns

A communicating meter, gateway and data platform can recover at different times. Record the first valid meter response and the first valid monitoring record separately. A response must contain the intended interpreted data, not merely indicate that a port is active.

Check which settings the actual protocol/configuration uses; do not universalise the family page's protocol options. Compare local and remote values only where they represent the same documented quantity.

Review the monitoring gap and any duplicated or backfilled records. A retained cumulative total can assist an integrator's reconciliation, but it does not by itself recreate missing interval detail. Record whether recovered history came from meter storage, gateway buffering or a platform estimate.

Use this original evidence matrix to keep conclusions limited to what was observed and documented.

Observation What it can support What it does not prove alone
Same identified energy field available after recovery That field's observed continuity under recorded conditions Every register, retention lifetime or memory endurance
Required parameters unchanged before intervention Observed retention of those named settings Retention of unlisted parameters or every configuration
Clock aligned before synchronisation Observed timekeeping within the agreed comparison basis A particular backup technology or battery lifetime
Protocol response resumes Communication recovery with verified interpreted data Historical record completeness in the server
Stored events can be exported Availability of those documented records Recording of unsupported event types or unlimited capacity
Platform fills a gap A documented reconciliation or estimate Original meter measurement at every missing interval
Record-comparison timeline separates before-event identity, recovery observations and meter-versus-logger reconciliation.
An authorised scope and criteria are required; this is not an outage test sequence or completed result.

Prepare an authorised acceptance record

Request a manufacturer-approved procedure appropriate to the exact meter and application, including permitted conditions and acceptance criteria. Qualified personnel should plan any electrical work in an approved bench or installation context. Do not improvise a live supply interruption, remove seals or use remote-disconnect options as an undocumented test method.

The record should identify the instrument, configuration, source documents, supply boundary, initial readings/settings, authorised event conditions, recovery observations and interventions. Include the clock and monitoring references where applicable.

Give each result a status: observed within the agreed criteria, unresolved, not applicable or failed against a named requirement. Do not replace an unresolved storage or clock specification with a generic memory pass.

Retain the original readings and exports with the signed record. If firmware, configuration or the monitoring integration changes later, assess whether the earlier evidence still covers the changed arrangement. The acceptance conclusion belongs to that identified setup, not every meter bearing the same family name.

Perguntas frequentes

Does power-off memory mean every value is retained?

No. Request the named retained fields and their recovery behaviour for the exact configuration. Energy totals, settings, time and logs require separate evidence.

Does a surviving energy total prove that the clock kept running?

No. Stored values and ongoing timekeeping are distinct functions. Identify the actual timestamp source and any supported backup or synchronisation behaviour.

Can I infer data loss from the storage interval alone?

No. The manufacturer's power-failure handling and recovery description are also required. An update or save interval alone is not proof of a particular shutdown loss window.

If the meter reconnects, is the monitoring history complete?

Not automatically. Review missing, duplicated and backfilled records separately. A cumulative reading and an interval-history record answer different questions.

Referências

Voltar ao topo