{"id":3808,"date":"2026-11-04T13:00:00","date_gmt":"2026-11-04T05:00:00","guid":{"rendered":"https:\/\/cnbygele.com\/?p=3808"},"modified":"2026-11-03T19:13:15","modified_gmt":"2026-11-03T11:13:15","slug":"meter-duplicate-energy-records","status":"publish","type":"post","link":"https:\/\/cnbygele.com\/id\/blog\/meter-duplicate-energy-records\/","title":{"rendered":"Duplikasi Catatan Meter Energi: Rekonsiliasi Interval Tanpa Penghitungan Ganda"},"content":{"rendered":"

Duplicate energy meter interval records should be reconciled by measurement identity and interval meaning before any rows are removed. Two identical timestamps can represent an exact replay, a corrected observation, different physical meters, or overlapping collection paths. Preserve the original records, define a complete comparison key, separate identical replays from conflicting values, and retain a decision trail. Never sum duplicated interval energy or delete apparently repeated rows solely because their displayed clock time matches.<\/p>\n

This procedure applies to external collection, database and reporting systems. It does not assume that a particular panel meter stores interval history or performs deduplication internally. Establish what the supplied instrument and collection software actually provide before designing acceptance rules.<\/p>\n

Identify what each record represents<\/h2>\n

Start with the quantity. Interval energy describes energy accumulated over a stated period; cumulative energy is a running counter; instantaneous power describes a rate at a measurement instant. These require different processing. Repeated cumulative counter values may be perfectly valid during a quiet period. Two equal interval values may also be legitimate observations of similar load in consecutive intervals.<\/p>\n

Define the physical meter, measurement point, quantity, direction, unit, interval start, interval end and quality state. Keep collection time separate from measurement time. A gateway may upload yesterday’s measurements today after a connection recovers. The late arrival alone does not make the observations new energy, incorrect data or a duplicate of today’s readings.<\/p>\n

The Department of Energy metering guidance<\/a> discusses metering, data management and the use of energy information. It supplies context for preserving useful measurement evidence, rather than a universal database deletion rule. The duplicate decision below must be documented for the specific reporting system.<\/p>\n

Preserve raw evidence before changing a report<\/h2>\n

Keep the original files or received messages unchanged in an access-controlled location appropriate to the site. Record source system, arrival time, file identity and import batch. Give each stored row its own traceable record identifier even when several rows refer to the same measurement interval. This separates evidence preservation from selection of the record used in reporting.<\/p>\n

Do not edit a production month while diagnosing the issue. Make a staging copy, reproduce the repeated records there, and compare outputs before and after applying the proposed rule. Keep enough information to restore the previous accepted report if the interpretation later changes. A tidy table without the original conflicting evidence can make the next investigation harder.<\/p>\n

NIST’s OT security guidance<\/a> provides the wider basis for controlled changes, integrity and operational records. It does not prescribe a preferred duplicate key for every energy platform. Use its lifecycle principles while retaining the metering meaning defined by your own system.<\/p>\n

\"Duplicate
Reference-based illustration of a disconnected BY194 front beside external duplicate energy meter records review materials. Documents and symbols illustrate a workflow; they do not establish installed product functions.<\/figcaption><\/figure>\n<\/p>\n

Define a comparison key that preserves boundaries<\/h2>\n

A useful logical comparison key might include physical asset identity, measurement point, quantity, flow direction, interval boundaries and configuration version. The actual key depends on the source schema. Timestamp plus meter display name is often inadequate: names can be reused, and a replacement instrument may occupy the same network address as its predecessor.<\/p>\n

For example, a retired meter and its replacement might both report Panel-A<\/code> during a changeover. Deleting one series because the names and timestamps match could erase real evidence. Use the meter asset identity reconciliation workflow<\/a> to establish which physical instrument owns each segment before deciding whether the streams overlap.<\/p>\n

Normalize comparison fields through documented transformations while retaining raw values. Equivalent units and timezone representations can make identical observations look different. Conversely, two records that display the same local time can refer to different UTC instants. RFC 3339<\/a> explains explicit timestamp offsets; it does not determine whether a source labels interval starts or ends.<\/p>\n

Classify repeats before choosing an action<\/h2>\n

Use separate categories for exact replay, conflicting revision, legitimate parallel measurement and partially overlapping intervals. An exact replay has the same defined measurement identity, interval, value, unit and relevant quality metadata. A conflicting revision shares the intended measurement slot but changes one of the fields that matter to acceptance. Treat a source revision marker according to its documented meaning rather than assuming it is trustworthy by its name alone.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n
Observation<\/th>\nPossible meaning<\/th>\nControlled response<\/th>\n<\/tr>\n<\/thead>\n
Same key, value and quality<\/td>\nReplayed import or retransmission<\/td>\nRetain raw rows; select one reporting observation<\/td>\n<\/tr>\n
Same key, different value<\/td>\nCorrection, decoding error or conflict<\/td>\nQuarantine the conflict for a defined resolution<\/td>\n<\/tr>\n
Same clock time, different asset<\/td>\nIndependent measurement<\/td>\nPreserve both unless boundary reconciliation proves overlap<\/td>\n<\/tr>\n
Same asset, different intervals<\/td>\nDifferent aggregation windows<\/td>\nCompare coverage before combining quantities<\/td>\n<\/tr>\n
Same value, consecutive intervals<\/td>\nStable operating demand<\/td>\nKeep both valid observations<\/td>\n<\/tr>\n
Same interval, different quality<\/td>\nRevised evidence state<\/td>\nApply the approved quality precedence rule<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

The table is a review framework, not a rule to overwrite an existing historian automatically. Record which fields are included in equality and which metadata can change without changing the underlying observation.<\/p>\n

Work through a small energy example<\/h2>\n

Suppose a file contains interval energies of 4, 5 and 6 kWh for three consecutive intervals. A connection recovery replays the second interval with the same complete identity, value and quality. Adding all four rows produces 20 kWh, whereas the three selected observations total 15 kWh. In this illustrative example, the replay should not add another 5 kWh to the report.<\/p>\n

Now suppose the repeated second interval contains 5.2 kWh instead. The accepted total could become 15.2 kWh only if the source’s correction process and review evidence justify replacing 5 with 5.2. A larger record identifier or later arrival is not sufficient evidence by itself. Keep both original observations and identify which one was accepted, by whom and under which rule.<\/p>\n

Do not apply that example to cumulative counters by summing repeated readings. A running counter requires differences between suitable successive observations, with separate treatment of resets and rollover. See counter reset audit records<\/a> when a discontinuity follows an authorized change. Deduplication cannot determine an undocumented counter’s physical behavior.<\/p>\n

Make repeated imports produce a stable result<\/h2>\n

An accepted import process should produce the same reporting selection when the exact same batch is received again. This is an acceptance property to verify in staging, not a reason to discard raw data. The second pass may still create an arrival record, but it should not create another unit of reported energy for an already accepted measurement slot.<\/p>\n

Test a complete replay, a partly repeated file and an out-of-order arrival. Also test a corrected interval, a missing quality field and a replacement meter using the old display name. Verify selected observations, exceptions, total energy and coverage after each case. Keep the sample dataset small enough for an engineer to calculate the expected outcome independently.<\/p>\n

Define the scope of replacement explicitly. A correction to one interval should not silently replace an entire day’s file unless the approved source contract says so. If a new import removes previously present intervals, stop and investigate instead of interpreting the absence as deletion. The history of report changes should remain reproducible.<\/p>\n

Investigate collection overlap without altering the meter<\/h2>\n

Check whether two gateways, file jobs or database connectors read the same source and write into the same reporting dataset. Redundant collection is not inherently wrong, but the system needs a documented rule for reconciling the paths. Record source-path identity separately from physical-meter identity so that switching paths does not look like a new measurement point.<\/p>\n

For compatible serial instruments, begin with the documented Modbus commissioning and decoding checks<\/a>. Confirm which client owns acquisition and where records are timestamped. Avoid changing meter settings just because a database contains repeated rows; the repetition may occur entirely after acquisition.<\/p>\n

The BY194 instrument family<\/a> offers relevant product context, but its public family page does not establish an interval database, automatic replay identifier or deduplication feature for every variant. Request the exact model manual, fitted communication option and collection architecture before assigning responsibility to the device.<\/p>\n

\"Duplicate
Reference-based illustration of a disconnected BY194 front beside external duplicate energy meter records review materials. Documents and symbols illustrate a workflow; they do not establish installed product functions.<\/figcaption><\/figure>\n<\/p>\n

Approve an auditable correction<\/h2>\n

Before releasing corrected figures, compare accepted records against raw coverage, explain every discarded reporting contribution and review unresolved conflicts. Preserve both before-and-after totals and a list of affected reporting periods. If an invoicing or allocation process consumes the output, use its approved correction procedure rather than silently replacing previously issued numbers.<\/p>\n

Keep the selection policy version with the report. A future rule change may produce a different result from the same raw records, and that difference should be explainable. Monitor repeated arrivals and conflicts separately: a replay storm and a measurement disagreement require different investigations even if both create duplicate-looking rows.<\/p>\n

Review the process after collector changes or connection recovery incidents. A clean import today does not establish that future software versions preserve identifiers, timestamps or revision markers. Acceptance belongs to the complete information path, from the documented measurement to the final reporting selection.<\/p>\n

Further learning: competing operations<\/h2>\n

Computerphile’s race conditions lesson explains how concurrent operations can interfere with one another. It helps explain why overlapping collectors and imports need controlled ownership and repeatable outcomes. The lesson is conceptual computer science, not a demonstration of an energy historian or instructions for modifying a meter.<\/p>\n