Skip to content
allanninal.dev/build
Collaborate

Part 1 of 7 · Utility meter reader series ~6 min read

A utility meter reader on AWS for a few dollars a month

The electricity bill jumps forty per cent in March and somebody spends a fortnight looking for what changed. Nothing changed in March. The previous four bills were estimates and this one was a real reading, so March is carrying the difference for four months of under-estimation. This post walks through a small system that would have said so in a sentence.

A row of semi trucks parked next to each other
Photo by Tom Jackson on Unsplash

Key takeaways

  • Estimated readings must be marked and never compared against actual ones.
  • Overnight baseload is the most useful single number and the cheapest to reduce.
  • Gas consumption has to be weather-normalised before any comparison means anything.
  • A saving is not real until it has been verified against the meter.
  • Designed on AWS for about $2 a month.

The whole system on one page

Before any code, here is the shape of what we are designing.

System: meter readings collected, normalised and turned into findingsThree boxes across the top sit outside the AWS account. On the left, Meters and bills, providing half-hourly data or monthly estimates. In the middle, The weather, providing degree days. On the right, Whoever pays it, who wants findings rather than a dashboard. Each connects by an arrow to the AWS account container below. Readings flow down into the account. Temperature feeds in. A few specific things go back out. Inside the AWS account are three components in a row. On the left, the Collector, marking each value as a reading or an estimate. In the middle, the Normaliser, adjusting for weather and for days in the period. On the right, Findings, covering baseload, drift and whether a change worked. A note at the bottom says both adjustments in the middle box are required before any comparison is honest.AWS ACCOUNTMeters and billshalf-hourly, ormonthly estimatesThe weatherdegree daysWhoever pays itwants findings,not a dashboardCollectorreading, orestimate -- markedNormaliserweather, anddays in the periodFindingsbaseload, drift,did it work?readingstemperaturea few specificthingsBoth adjustments in the middle box are required before any comparison is honest.
Fig 1. Three things outside the account, three pieces inside it. The middle box is unglamorous and is what separates a real comparison from an apparent one.
  • Compute
  • Database
  • Management
  • Analytics
  • People

Two adjustments, or nothing works

The first is estimates. A bill labelled as an estimate is a guess by the supplier based on history, and the moment a real reading arrives the difference lands in one period. Comparing periods without knowing which were estimated produces spikes and troughs that correspond to nothing that happened in the building.

The second is time and weather. February has fewer days than January, and last January may have been three degrees colder than this one. Comparing raw totals across periods measures the calendar and the weather considerably more than it measures the building.

What runs (the inside)

  • The collector. Takes readings from whatever source exists and records whether each is actual or estimated. Part 2.
  • The normaliser. Adjusts for days in the period and, for gas, for how cold it was. Part 4.
  • The findings. Baseload, drift, and whether a change actually saved anything. Parts 3 and 5.

One finding, end to end

One baseload finding from detection to verified savingA horizontal row of five boxes joined by arrows. Half-hourly data for electricity. Three o'clock average: eighteen kilowatts, every night. Should be about four kilowatts, for fridges and servers. Traced: a compressor on a twenty-four hour timer. Verified: baseload now five kilowatts. A note says fourteen kilowatts, every hour of every night, for about four years.ONE FINDING, END TO ENDHalf-hourly dataelectricity03:00 average18 kW, every nightShould be ~4 kWfridges and serversTracedcompressor, 24h timerVerifiedbaseload now 5 kWFourteen kilowatts, every hour of every night, for about four years.
Fig 2. The same system as one line. The last box is the one most energy projects skip, and without it nobody knows whether the fix worked.
  • Compute
  • Machine learning
  • Management
  • Analytics

In plain words

Half-hourly electricity data shows the site drawing eighteen kilowatts at three in the morning, every night, including weekends and the Christmas shutdown. Somebody who knows the building says it should be about four: refrigeration, a couple of servers, emergency lighting.

Fourteen kilowatts of unexplained overnight draw is roughly a hundred and twenty thousand kilowatt-hours a year, which is a substantial bill. Tracing it takes an afternoon with a clamp meter and finds an air compressor whose timer was set to twenty-four hours during a maintenance visit in 2022 and never set back.

The timer is changed, and the crucial step is the last one: two weeks later the overnight baseload is measured again and is five kilowatts. The saving is verified against the meter rather than calculated from a specification, which is the difference between a real saving and one that exists in a spreadsheet.

Design rules that shaped every decision

  • Mark every value as actual or estimated, and never compare across the two.
  • Normalise for days in the period, always, and for weather where it applies.
  • Baseload is measured over a window of nights, not from one night.
  • A saving is unverified until the meter shows it.
  • Never act on the building automatically. Produce findings.
  • Say which meter and which period every number came from.

Why this shape

Energy management at small scale suffers from a specific problem: the data is available and nobody has time to look at it, so the analysis happens once, in a burst, when a bill is alarming. That is exactly the wrong moment, because the alarming bill is usually a billing artefact and the real waste is a steady drip nobody has ever noticed.

So the design does the small number of things that reliably find money — baseload, weather-normalised comparison, verification — on a schedule, and stays quiet the rest of the time. There is no dashboard, because a dashboard is a thing nobody opens.

The next four posts walk through each piece: how a reading becomes a usable number, what the overnight baseload tells you, why gas needs the weather, and how a finding becomes a verified saving. One diagram per post, a cost breakdown, and an engineering reference at the end.

All posts