Reference · built on requestOperator by FibricEnergy & demand

Submeter Drift

Submeter totals checked against the main meter, with stuck, gapped, or stepped readings raised as an investigation ticket.

Request accessPricing ↗

About

A submeter that stops counting looks like a tenant who stopped using power. This operator polls each submeter over Modbus TCP or receives its LoRaWAN uplinks through your network server, sums the children under each parent in the meter tree you declare, and compares the sum with the main meter for the same intervals. It also watches the reading itself: a total that has not moved, intervals missing while siblings reported, or a value that jumps or resets between two reads.

For each fault it proposes an investigation ticket in your service desk or CMMS, with the readings attached. A person approves the ticket, and a dismissed fault is remembered so the same window is not raised twice.

This is a reference listing. It documents what Fibric would read from Submeter Drift and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Register reads from each submeter over Modbus TCP on the polling schedule you set: kWh totals, kW, voltage, and current
  • Uplinks from LoRaWAN metering devices via your network server, with battery level, signal quality, and last-seen time per device
  • The main meter's interval totals, from your own meter or the utility's IntervalBlock data
  • Meter points and trend logs on the building management platform, where submeters are already mapped there
  • The meter tree you declare: which children sum to which parent, and the tolerance you accept between them
  • Open tickets and work orders that name a meter, so a fault already known is not raised again

Proposed actions

  • Target capability: propose an investigation ticket in Jira Service Management, ServiceNow, or MaintainX for a meter whose total has not changed across your stuck window
  • Target capability: propose a ticket for a gap: intervals missing from one meter while its siblings reported
  • Target capability: propose a ticket for a step: a total that jumps or resets between two reads, with both values attached
  • Target capability: propose a reconciliation note when children sum to more than their parent, naming the meters and the margin
  • Target capability: propose a device check when a LoRaWAN meter's battery level or signal quality falls before its readings stop

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Tenant submeters against the landlord meter

    Floor submeters polled over Modbus TCP are summed against the landlord's main meter each day. A floor whose total has not moved during business hours is proposed as a Jira Service Management request with the reads attached.

    With Modbus TCP, Jira Service Management

  • LoRaWAN water and gas meters

    Uplinks from battery meters are checked for gaps and falling battery level. A meter gone quiet while its gateway still hears its neighbours is proposed as a MaintainX work order for a site visit.

    With LoRaWAN Network, MaintainX

  • Meters already mapped in the BMS

    Where submeters are points on the building platform, their trend logs are compared with the main meter and a stepped total is proposed as a ServiceNow incident through the Table API.

    With BACnet / IP, ServiceNow

Requirements

  • Submeters reachable over Modbus TCP with a register map, or LoRaWAN meters on a network server with a decoded payload
  • A main meter, or the utility's interval data, for the same periods
  • The meter tree, the parent-to-children tolerance, and the schedules on which an idle meter is expected
  • A ticketing connector: Jira Service Management, ServiceNow, or MaintainX, with the project, table, or team the tickets go to
Authentication
It keeps no credentials of its own. Meters are read through the Modbus TCP, LoRaWAN, and platform connectors you attach; tickets are created through the service desk or CMMS account you assign.

Limits

  • It flags readings. It does not repair meters or edit stored data; a corrected value is entered by a person after the ticket.
  • A stuck reading and a genuinely idle load look alike until the load is due to run. Idle schedules must be declared.
  • Losses between a main meter and its submeters are normal. Below the tolerance you set, nothing is raised.
  • A gap on a LoRaWAN meter may be radio coverage rather than the meter. The proposal says which is more likely from the gateway metadata.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Submeter Drift ↗

Questions and answers

What does the person on the queue approve?
One ticket per meter fault: the fault type, the readings that show it, the parent-to-children sum, and the last time the meter looked healthy. Approve to create it, merge it with an existing ticket, or dismiss it as expected.
What is kept for each fault it raised?
A receipt per fault: the meter, the fault type, the reads compared, the tolerance, the ticket id created, who approved, and when. Dismissed faults are remembered with their window so they are not raised again.
Does it create tickets on its own?
No. A ticket is created only after approval, once. A fault that persists updates the open proposal rather than opening a second ticket.
Ask about Submeter Drift

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy