Energy Metering Hardware — Meter Types & Selection | EC.DATA

Energy Metering Hardware

A complete guide to energy metering hardware used in commercial and industrial buildings.

Meter Types

• Current Transformers (CTs) — split-core and solid-core for non-invasive measurement
• Rogowski Coils — flexible AC current sensors for large conductors and tight spaces
• Revenue-Grade Meters — ANSI C12 and IEC 62053 certified for billing accuracy
• IoT-Enabled Sub-Meters — wireless meters with built-in connectivity (Wi-Fi, LoRaWAN, cellular)
• Panel-Level Monitors — branch circuit monitoring for granular load disaggregation

Selection Criteria

• Accuracy class: 0.2S for revenue, 0.5 for monitoring, 1.0 for indicative
• CT ratio matching to expected load range
• Communication protocol: Modbus RTU, BACnet, pulse output
• Environmental rating: indoor/outdoor, temperature range
• Certifications: UL, CE, MID, ANSI

Hardware in practice

Class-1 revenue meters, class-0.5 sub-meters, and class-2 monitoring meters each have a different role. EC.Solution Design Studio picks meter class against the analytical use case so partners do not over-spec or under-spec.

How EC.DATA operationalises Hardware

Meter telemetry is the raw material everything else in EC.DATA depends on. EC.Node pulls Hardware from the meter on a 1–15 minute cadence, normalises into the EC.DATA tag schema, and republishes through MQTT to EC.EMS. CT-ratio mismatches and phase-rotation errors are detected during the 24-hour shakedown.

Hardware procurement is driven from EC.Solution Design Studio's panel-survey output so the partner orders the correct meter class, CT ratio, and gateway in one BOM.

Common pitfalls when working with Hardware

Hardware mistakes are made on install day and discovered months later — usually by an unhappy customer.

• Ordering the wrong CT ratio guarantees a return trip; EC.Solution Design Studio's BOM check exists to prevent this.
• Voltage taps tied to the wrong feeder produce energy readings that do not match the bill.
• Pulse meters with the wrong K-factor scale the measurements off by an integer multiple — easy to miss if nobody validates against the utility bill.
• Network meters without TLS are an obvious attack surface; EC.Node enforces mTLS by default.

Where Hardware connects across EC.DATA

Hardware touches every layer of the EC.DATA stack: telemetry capture in EC.Node; visualisation and alerting in EC.EMS with EC.Alerts; tariff translation in EC.Bills; savings verification in EC.GAIA; and field-device fleet governance in EC.IoT. Solution work originates in EC.Solution Design Studio; partner and customer training live in EC.Academy.

Frequently asked questions about Hardware

How does EC.DATA expose Hardware to partners?

Hardware is part of EC.Node's standard ingest pipeline; the meter library covers 200+ brands out of the box.

Do I need a separate license to access Hardware?

No. Hardware is part of the core EC.DATA platform; partners get it as part of their standard licence and white-label it under their own brand for their customers.

Where do I learn more about Hardware on EC.DATA?

Start with the EC.Academy track this page belongs to, then explore the related EC.DATA platform modules linked above. The EC.DATA changelog announces new capabilities and the EC.Academy session catalogue tracks every recorded session.

How EC.DATA applies this in production

The concepts in this lesson are not theoretical — they are operationalised every day inside the EC.DATA platform across deployments in 10+ countries on 3 continents. The module most directly tied to this track is EC.Node, working alongside EC.EMS and EC.IoT to translate the underlying physics, protocols, and methodology into a working production system.

Every reading in EC.DATA flows through the same lifecycle: telemetry is captured at the meter or sensor, normalised by the EC.Node edge gateway (which speaks Modbus RTU/TCP, BACnet, OPC-UA, MQTT and pulse counting natively), buffered locally for offline resilience, then delivered to the cloud where EC.EMS stores it as 1-minute resolution time-series. From there, EC.Bills reconciles metered kWh against the utility invoice, EC.Billing allocates consumption to tenants or cost centres, EC.Alerts watches for anomalies, EC.PQ scrutinises waveform quality, and EC.GAIA applies machine learning for forecasting and root-cause analysis.

That integration is what differentiates EC.DATA from the patchwork of disconnected tools most facilities run today. Because every module shares the same data warehouse and the same role-based permission layer, a finding in one module is immediately actionable in another — a tariff change in EC.Bills can adjust demand-alert thresholds in EC.Alerts, a setpoint override in EC.BMS is automatically measured for energy impact in EC.EMS, and an IPMVP baseline is established once and reused across reports forever.

The team behind EC.DATA — described in more depth on the Who We Are page — combines former Fortune 500 energy consultants, field commissioning engineers, and software developers, with a deliberate hiring policy that requires every senior product role to have prior experience on the customer side of an energy programme. The platform is what we wish had existed when we ran those programmes ourselves; the academy is the public-domain version of the training material we built internally to bring new hires up to speed.

If you want to see the platform in action, the free assessment, the savings calculator, and the Solution Design Studio are open without an account; the partner programme is the route in for ESCOs, facility-management firms, commissioning agents, and utilities that want to deliver EC.DATA under their own brand.