Automatic energy meter reading across many sites

At a glance

Item	Typical answer
Problem	Consumption is known only from monthly bills and occasional manual readings, so waste, demand penalties and broken meters are found weeks late.
What is connected	The main electricity meter of each site, its submeters, gas and water meters with pulse outputs, and an outdoor temperature, read by one licensed gateway per site.
Who uses it	The energy manager, site and facility managers, finance, and the metering contractor.
Typical first scope	Five to ten sites of one type, such as branches or stores, with the main meter and the largest submeters.
Time to first screen	Typically the day the first gateway reads its meter. Budget four to six weeks for a pilot whose daily totals match the utility's figures.

The situation

An organisation with dozens or hundreds of sites, such as a retail chain, a branch network, a telecom operator or a property portfolio, pays an energy bill per site and sees almost nothing between bills. Some sites have multifunction meters with a Modbus port nobody reads; others have only the utility's fiscal meter and a mechanical gas meter in a cupboard.

Heating left in day mode over a holiday weekend shows up on next month's invoice. A site exceeds its contracted capacity in a heat wave and the penalty is found at the quarterly reconciliation. A submeter dies and tenant cost allocation is estimated for half a year. Energy projects are approved on assumptions, and nobody can show afterwards what they saved. Today the gap is filled by photographed meters and spreadsheets. The aim is readings that arrive by themselves, fine enough to see a night baseload or a demand peak, and an alarm when a meter goes quiet.

Goals and measures

• Consumption per site and period = increase of the energy register over the day, week or month. Hermetry computes it from the stored register with the increase aggregation; no field device calculates anything.
• Energy intensity = kWh per period ÷ floor area, with the area stored as a site attribute. Ranking sites of one type by kWh/m² shows where to look first.
• Baseload ratio = average power while the site is closed (for example 01:00 to 04:00) ÷ average power during opening hours. In a store, a ratio above 30 to 40 % usually means lighting, HVAC or refrigeration that never sleeps; agree the reference per site type.
• Peak demand = highest 15-minute average power in the month against the contracted capacity, from the meter's demand register where it has one.
• Weather-normalised heating = gas kWh ÷ heating degree days from the site's outdoor temperature.
• Data completeness = readings received ÷ readings expected; a 15-minute register gives 96 a day, and the count aggregation gives the number received.

Hermetry keeps minute, hourly and daily aggregates (sum, count, minimum, maximum, last) of every key. Charts and the series API ask for avg, min, max, last, sum, count or increase per bucket; increase treats a value that goes down as a counter reset and counts from zero.

Architecture

Each site gets one licensed gateway running Hermetry Edge next to the main distribution board. It reads the main meter and submeters over Modbus RTU on one RS485 line, or Modbus TCP where meters sit on the site network, and publishes over MQTT with TLS on one outbound connection; nothing on site accepts connections from the internet. Pulse outputs of gas and water meters go to the gateway's digital inputs if the gateway model counts pulses; otherwise a battery LoRaWAN pulse counter next to the meter counts them, which is also the cheaper answer for meters in a basement or pit. See Hermetry Edge and the licensed devices.

Component	Role	Notes
Licensed gateway with Edge	Reads meters, publishes telemetry	One per site. Factory identity, claimed by scanning its code.
Main multifunction meter	Energy, power, voltage, current, power factor, demand	On the incomer. The utility's sealed fiscal meter stays as it is.
Submeters	Energy per end use: HVAC, lighting, refrigeration, tenants, EV chargers	Same RS485 line, own Modbus address each.
Gas and water meters	Volume from pulses	Record the pulse weight, for example 0.01 m³ per pulse.
LoRaWAN pulse counters and gateway	Meters far from the board	Hermetry's own LoRaWAN network server; the codec library includes pulse, digital-input and current-transformer sensors.
Licensed 4G router	Uplink independent of the site network	Your own SIM today; eSIM management is in development in Hermetry Connect.
Hermetry	Storage, aggregates, alarms, rules, boards, API	EU, US or Türkiye region, or on your own servers.

Licensed devices sign in with an X.509 certificate from the platform's own authority; third-party devices with an access token or user name and password, and the profile can require TLS and restrict source networks. Report each meter as a child device of the gateway, with its own keys, history and alarms over the gateway's one connection: meters get replaced and reassigned to tenants independently of the gateway.

Point list

One main meter, four to six submeters, gas and water. Register addresses depend on the meter model; take them from the manual with data type and word order. Intervals are starting values.

Point	Telemetry key	Unit	Source	Interval	Notes
Active energy import	import_kwh	kWh	Main meter register	15 min	Source of every consumption figure.
Active energy export	export_kwh	kWh	Main meter	15 min	Sites with solar or a generator.
Tariff registers	import_kwh_t1, import_kwh_t2	kWh	Main meter	15 min	If the meter keeps time-of-use registers.
Reactive energy	import_kvarh	kvarh	Main meter	15 min	For reactive energy charges.
Active power	p_kw	kW	Main meter	60 s	Load profile and baseload.
Power factor	pf		Main meter	60 s	Sign convention varies by model.
Demand, current period	demand_kw	kW	Main meter	60 s	15-minute window as the meter computes it.
Maximum demand this month	max_demand_kw	kW	Main meter	15 min	Reset by the meter at its billing date.
Phase voltages	u_l1_v, u_l2_v, u_l3_v	V	Main meter	60 s
Phase currents	i_l1_a, i_l2_a, i_l3_a	A	Main meter	60 s	Shows phase unbalance.
Submeter energy and power	kwh, p_kw	kWh, kW	Each submeter, one child device each	5 min	Same keys on every submeter.
Gas volume	gas_m3	m³	Pulses × pulse weight	15 min	Store the running total.
Water volume	water_m3	m³	Pulses × pulse weight	15 min	Night flow in a closed site means a leak.
Outdoor temperature	outdoor_temp_c	°C	Sensor	15 min	For degree days.
Meter communication	meter_comm_ok	bool	Gateway Modbus status per meter	5 min	Gateway online, meter not answering.
Site supply	mains_ok	bool	Gateway input	on change	Tells a power cut from a broken link.

Declare each key in the profile's Telemetry keys tab with label, unit, decimals and range; gauges take the range as their scale.

Asset model

• Region (free kind) with regional_manager.
• Store (Site) with location, time zone, floor_area_m2, contract_kw, opening_hours, store_format.
• Main board (Area) with incomer_rating_a and ct_ratio.
• End use (free kind: HVAC, Lighting, Refrigeration, Tenant) with tenant_code where relevant.

Place the gateway on the store, the main meter on the main board and each submeter on its end use, and add Feeds relations from the main meter to its submeters. The relations stop nested submeters from being counted twice and define the unmetered share: main increase minus the sum of submeter increases. A jump in that share usually means a stopped submeter or a new load upstream of it.

A site's status is the worst of its devices, so the site table turns red when any meter there is offline or in alarm. The store's time zone decides how its day is drawn; rules written on a region reach every store below it; an access policy on a region limits every board and alarm list to its stores. Write per-site limits such as contract_kw on the site for people and as a server attribute on the main meter for alarm rules.

Device setup

Profiles. One profile for the site gateway, one per meter model (for example Main meter, three-phase and Submeter, DIN rail) and the built-in LoRaWAN profile for pulse counters. Use the Recent message online rule with the reporting interval and a factor of two or three, so one missed reading does not mark a meter offline.

Provisioning. The administrator claims the gateway by scanning its code, picks its profile and places it on the store. Meters appear as child devices the first time the gateway reports them, so name them in the gateway configuration by store and meter, such as S0142-MAIN. For hundreds of sites, import the device list in a batch.

Settings. Remote device settings on licensed gateways show serial parameters, meter addresses and register maps, polling intervals, and pulse weights where the model has them. Build a baseline per store format, test it on one store with a dry run, then apply it with a bulk job that runs in waves (1 %, 10 %, the rest) and pauses itself if fewer than 95 % of answering devices apply it. Read registers every 15 minutes, main meter power every minute, submeters every five. If the gateway model supports a deadband, use it for voltages; otherwise an Only changes block with a dead band in the profile's root flow drops small moves before storage. Never dead-band energy registers: the fixed rhythm is what makes completeness measurable.

Time and buffering. Synchronise gateway clocks so 15-minute values line up across sites; a device without a reliable clock leaves the time stamp out and Hermetry stamps the arrival. Licensed gateways keep readings during a link outage, with a capacity that depends on the model, and send them afterwards with their original time stamps. They are stored into their own periods, so the day's total fills in, and alarm rules evaluate them as a backfill, marked Backfilled, without paging anyone for the past.

Firmware. Signed gateway firmware rolls out from the profile in waves with a soak time and an automatic pause on failure. Gateways on mobile data wait until metered downloads are allowed.

Dashboards

Board	Audience	Widgets and what they show
Portfolio	Energy manager, management	Map of stores by status; bar chart of yesterday's kWh per store using increase; table with month-to-date kWh, kWh/m², peak demand against contract and open alarms, downloadable to Excel; stat with trend against the previous period.
Store	Store and facility managers	Stats for today's kWh, current power and month peak; seven-day line chart of p_kw, where closing time and night baseload are obvious; heatmap of power by hour and day; daily kWh per end use; gauge of demand against contract_kw.
Gas and water	Facility managers	Daily gas against degree days as a scatter chart; night water flow per store.
Meter health	Energy team, contractor	Device table with connection state and last seen; yesterday's reading count per meter against 96; alarm table filtered to offline and communication alarms.

The store board takes a store as an entity parameter, and a click on a table row or map marker opens it for that store, so one board serves the estate. A short compute script on a card can turn hourly power into one baseload ratio; describe such scripts in a text card, because the figures people quote come from them.

SCADA screens

One single-line view per store format is usually enough. Draw it with the single-line symbols of the Power pack (busbar, circuit breaker, power transformer, power analyser, load, capacitor bank) plus the smart meter, EV charger and combined heat and power symbols where a site has them. See the SCADA library.

• Each power analyser shows p_kw and import_kwh; each load shows its submeter's power.
• A rule greys a meter whose meter_comm_ok is false, so stale values never look live, and colours a feeder amber above 80 % of its rated load, read from an attribute.
• Attach the drawing as a view on the gateway profile: every store gets its own view, and Match everything proposes a meter for each unbound symbol. Clear the Problems tab before applying.

Rules and alarms

Alarm rules sit on the meter profiles; per-store limits come from device attributes such as contract_kw and demand_warn_kw.

Alarm	Condition	Delay and hysteresis	Severity	Notified	Escalation
Demand approaching contract	demand_kw >= attribute demand_warn_kw	2 samples; hysteresis 5 kW	Major	Store manager, push and in-app	Rises to Critical in the same rule when demand_kw >= contract_kw, which notifies again
Contracted demand exceeded	demand_kw >= attribute contract_kw	2 samples	Critical	Energy and store manager, SMS and push	Reminder every 15 min until acknowledged
Main meter offline	Inactivity, 45 min		Major	Energy team, e-mail and in-app	Reminder every 4 h
Submeter offline	Inactivity, 60 min		Warning	Energy team, in-app	None
Meter not answering	meter_comm_ok == false	3 samples	Minor	Contractor, e-mail	Reminder every 24 h
Site supply lost	mains_ok == false	30 s	Major	Facility manager, SMS	Reminder every 30 min
Low power factor	pf < 0.90	900 s; hysteresis 0.02	Warning	Energy manager, in-app	None
Night baseload high	Rules card: p_kw above the store's limit, stays so 60 min, only 23:00 to 05:00		Warning	Store manager, push	None
Register went backwards	Flow: negative delta on import_kwh		Minor	Energy team, e-mail	None

An alarm opens when its condition holds through the debounce, is acknowledged by whoever takes it (User role) and resolves by itself when the condition clears; resolving by hand, muting and editing rules need Admin. One alarm stays open per device and type and counts occurrences, so a store that touches its limit every afternoon shows one alarm with a count. Put the load-shedding instructions for store staff in the rule's runbook text.

Profile alarm rules compare values and do not know the clock, so the night baseload alarm is a rule in the store's or region's Rules card. Its 60-minute wait runs on a timer and fires even if no reading arrives meanwhile. A register that goes backwards or freezes is caught in the main meter profile's root flow: a Delta block sends a negative delta to an alarm raise, and a Watchdog block raises one when a key stays silent although the device still reports.

Mute a meter during work on its board: alarms are still recorded, nobody is paged, and the mute ends by itself (at most 90 days). A regional power cut takes many stores offline together; keep offline and supply alarms at Major or below, and above 20 alarm notifications a minute Hermetry gathers the rest into a five-minute digest.

Automation and integrations

• Energy management and invoice checks: pull consumption through the REST API with a read-only API key, for example GET /api/telemetry/series with agg=increase and bucket=1h, and sum hours into each store's local day on the receiving side.
• Tenant recharging: submeters on tenant assets give monthly consumption per tenant; tables download to Excel.
• Push: a flow's HTTP request block sends readings or events to an endpoint you choose, or publishes them to your own MQTT broker.
• Tickets: signed alarm.created and alarm.cleared webhooks open and close tickets in the facility management system.
• Reporting: monthly figures come from tables and Excel downloads; scheduled, e-mailed reports are not built in today.

The design is read-only: load shedding belongs to the building management system or site controller. For a router problem, an engineer opens a licensed router's web panel through router remote access, without a fixed IP or VPN; sessions are time-limited, capped on metered links and audited.

Roles and access

Who	Role or group	Can
Energy manager	Admin	Profiles, alarm rules, rules, boards, drawings, mutes, API keys.
Regional manager	User, policy on one region	Boards and alarms of the region, acknowledge, switch a store's rules to Manual.
Store manager	User, policy on one store	Store board, acknowledge the store's alarms.
Finance	User + IoT viewer group	Read and download consumption tables.
Metering contractor	User + IoT operator group, policy on meters	Meter health, device tables, acknowledge communication alarms.
IT owner	Owner	Members, single sign-on, sign-in policy.

An energy service company can run each client as its own organisation, isolated by row-level security, with its engineers holding memberships in all of them. The audit log keeps sign-ins, role and policy changes, rule edits, mutes and setting jobs in a verifiable hash chain, exportable as CSV or NDJSON.

Sizing and data

As an order of magnitude, for 120 stores with one main meter, six submeters, gas, water and temperature, counting one message per meter per reading:

• Main meter: 1,440 power messages plus 96 register messages, about 1,540 a day.
• Submeters: 6 × 288 = 1,728 a day. Gas, water and temperature: 3 × 96 = 288 a day.
• About 3,550 messages per store per day; 430,000 a day or roughly 13 million a month for the estate. Telemetry and attribute messages count toward the allowance; alarms, commands and connection events do not.
• Values: about 20,000 per store per day, roughly 900 million a year in total.

Main meter power every five minutes instead of every minute cuts messages per store to about 2,400 a day and stored values by more than half, without changing any energy figure, because those come from the registers. Raw readings are kept for at most 90 days whatever the plan's retention class; multi-year trends read the hourly and daily aggregates, kept for the full class. Storage per value depends on the deployment, so ask us to confirm the estimate. The plan warns at 80 % and 100 % of the monthly allowance and does not stop devices. See how the platform is load-tested.

Rollout plan

Phase	Weeks	Work	Exit criteria
0. Survey	1-3	Meter model, port, CT ratio and pulse weight per store format; measures, contract limits and alarm recipients.	Signed point list and register map per format.
1. Pilot	4-9	Five to ten stores: profiles, baselines, four boards, single-line drawing, alarms, night baseload rule.	Four weeks with completeness above 99 %; daily totals within an agreed tolerance of utility data; every alarm tested.
2. First format	10-16	All stores of that format, region by region; API connection to the energy system.	Monthly figures accepted by finance; nuisance alarms under an agreed level, such as two per store a month.
3. Estate	17-30	Other formats with their own baselines and drawings; LoRaWAN for hard-to-reach meters.	All stores reporting; meter health reviewed weekly.
4. Projects	Ongoing	Before-and-after periods for each energy project.	Every project has a measured result.

Commissioning checklist

1. Gateway claimed, on its profile, placed on its store; every meter appears as a child device with the agreed name and place.
2. import_kwh in Hermetry matches the meter display to the last digit shown, proving data type and word order.
3. CT ratio applied once, in the meter or in the gateway map; i_l1_a agrees with a clamp meter.
4. p_kw positive when importing; export_kwh still on sites without generation.
5. Pulse weight proven by drawing a known volume, for example 100 litres giving +0.1 on water_m3.
6. A reading taken at 10:15 local time appears at 10:15 in the store's time zone.
7. Each alarm forced once where safe (a meter unplugged from RS485, a temporarily lowered demand_warn_kw); notification, acknowledgement and clearing checked.
8. Uplink unplugged for 30 minutes: offline alarm opens; buffered readings fill the chart and the day's total afterwards.
9. After one full day, 96 register readings per meter on the meter health board.

Pitfalls

• Energy integrated from power. It misses what happens between samples and drifts. Read the register.
• Scale and word order. Swapped words or a meter that switches between Wh and MWh give plausible nonsense. Check each model against its display.
• Nested submeters added up. Sum one level of the Feeds hierarchy only.
• Meter swaps. A new meter starting lower is read as a reset; starting higher, its jump looks like consumption. Note both readings and correct that period, or register the new meter as a new device.
• UTC days. A store's day follows its time zone; sum hourly data into local days elsewhere too.
• Broken pulse cables. Zero gas or water looks like a closed site; compare with power before trusting a zero.

What Hermetry does not replace

Hermetry collects, stores and alarms on meter readings; it is not a fiscal metering or billing system. The utility's meter remains the basis of invoices, and tenant invoices stay in the billing system. Load control, demand limiting and protection stay in the building management system, site controllers and switchgear, and must work when the link or the platform is unavailable.