A multi-brand BTU meter integration does not require every usable meter to be replaced. In one Dubai high-rise, ConnectME brought five installed BTU meter brands into a central meter data management system, standardized their readings, automated daily acquisition, exposed offline and fault states, and produced one reporting path for billing operations.
This anonymized case study explains the engineering and data work behind that result. It is relevant to building owners, district-cooling teams, facility managers, billing operators, MEP consultants and BMS providers dealing with mixed meter estates.
Project evidence: this article is based on ConnectME's internal scope and closeout record for a completed Dubai high-rise integration. Client and property identifiers are intentionally omitted. The record covers five BTU meter brands, central data management, daily acquisition, standardized reporting, and fault visibility. Results describe this project only and are not a guarantee for another site.
The starting problem: five meters, five data paths
The building had BTU meters from five manufacturers operating through separate software platforms. Each platform represented readings, timestamps, status values and reports differently. The operations team then used spreadsheets to combine the outputs.
That process created four practical risks:
- Inconsistent meter identity: the same apartment, loop or tenant could be described differently across systems.
- Missing or delayed readings: a communication failure was difficult to distinguish from zero consumption.
- Billing corrections: manual consolidation introduced avoidable transcription, unit and period errors.
- Limited operating visibility: offline and fault conditions were found late because there was no common status view.
The project therefore began as a data-governance problem, not a dashboard redesign. The central question was whether every reading could be tied to a known physical meter, unit, time period and service boundary.
1. Build a meter register before mapping protocols
The integration team first established a controlled register for every BTU meter. A useful register records the manufacturer, model, serial number, location, served unit or loop, engineering unit, multiplier, communication address and source platform. It also records uncertainty rather than hiding it.
This register becomes the reference for gateway configuration, point mapping, exception review and billing. Without it, protocol conversion can move values correctly while still assigning them to the wrong account.
2. Normalize five vendor formats into one data model
Each source was mapped into a common MDMS structure. The model separated cumulative energy, volume, flow, supply temperature, return temperature, delta-T, device status and communication quality where those points were available from the installed meter.
Normalization did not mean inventing values that a meter could not provide. It meant giving equivalent fields the same name, unit, timestamp rule and quality treatment. Original source values remained traceable so an operator could investigate a transformation or disputed reading.
3. Treat status data as part of the reading
A billing value without context can be misleading. The central platform therefore monitored offline and fault states alongside consumption. Daily acquisition jobs produced an exception list when a device failed to report, repeated the same value, returned an invalid status or created a gap.
The workflow distinguished three conditions:
- Valid reading: the value arrived for the expected period and passed the agreed checks.
- Questionable reading: the value arrived but required review because of a status, range or continuity rule.
- Missing reading: no usable value arrived, so the billing team needed a documented exception process.
These states made faults visible before the monthly billing deadline instead of during invoice preparation.
4. Validate the full path, not only the gateway
Commissioning compared representative meter displays and source-platform values with the central record. The team checked meter identity, units, multipliers, timestamps, cumulative registers, interval calculations and status handling. It also tested how the system behaved when a meter or communication path went offline.
A successful packet read was not enough. Acceptance required the value presented to operations and billing to represent the intended physical meter and reporting period.
5. Separate raw data, corrections and billing output
The MDMS preserved acquired readings while producing standardized consumption and billing reports. Corrections and exception handling remained visible rather than overwriting the source without an audit trail. Customized reports followed the building team's required billing and consumption format.
By handover, the project record documented a standardized dataset across all five meter brands, automated daily collection, real-time fault visibility and less manual processing. The value came from one controlled workflow rather than from replacing every field device.
What a buyer should specify
- A verified meter and tenant register with ownership for future changes.
- A point map for every brand, including units, multipliers, timestamps and status codes.
- Rules for gaps, repeated values, rollovers, replacements and communication loss.
- Raw-data retention and an audit trail for corrections or estimates.
- Billing cut-off, exception ownership and approval responsibilities.
- Commissioning tests that compare the field meter with the final report.
- Export and API requirements that avoid a new single-vendor data lock-in.
Where ConnectME fits
ConnectME supports meter data management, automatic meter reading, M-Bus, Modbus and BACnet integration, protocol gateways, data validation and utility billing workflows. The practical first step for an existing building is a meter-register and communications audit before deciding which devices, gateways or software need to change.
Limits of this case study
Meter compatibility, available status points, data quality and billing acceptance depend on the installed models, network condition, documentation and project requirements. A successful five-brand integration at one high-rise does not establish compatibility or regulatory acceptance for another property. The design and commissioning plan must be reviewed against the actual site.