Reading Legacy Utility Meters With a Camera: ESP32-CAM OCR

Reading Legacy Utility Meters With a Camera: ESP32-CAM OCR

The meter stays exactly where it is. A small camera points at the dial, reads the digits itself, and sends one number to the server. That's the tenant metering retrofit I built for a large commercial building, and each camera point cost a fraction of what swapping a single meter would.

Automated meter reading usually starts with a proposal to replace the meters — and in most existing buildings, that proposal dies fast. The meters are certified billing instruments nobody is allowed to touch, or they belong to the utility. Or the plumbing work across a few hundred tenants costs more than the problem it solves.

Why retrofit beats replacement

Analog DN15 water meters clustered in utility shafts are the standard setup in malls and office towers. One meter per tenant, read once a month by a technician with a flashlight and a clipboard. Replacing them with pulse-output or smart meters means cutting pipe, recalibrating, and coordinating with the utility. It also means shutting off water riser by riser, multiplied by every tenant in the building.

A camera retrofit touches none of that. The meter stays sealed and remains the legal billing instrument. A small camera module mounts over the dial, photographs it on a schedule, reads the digits on-device, and publishes a single number upstream.

If a device dies, the technician reads that meter the old way until it's swapped. The failure mode is "back to manual," not "no billing this month."

The hardware is deliberately boring

An ESP32-CAM-class board with an OV2640 sensor, an LED behind a diffuser, and a 3D-printed bracket — that's the whole list. Recognition runs on-device with the open-source AI-on-the-edge-device firmware: a small CNN reads both the digit rollers and the analog pointer dials. That gets you resolution down to liters instead of whole cubic meters. Only the resulting number ever leaves the device, over WiFi and MQTT.

Two details decide whether the device works at all. The stock lens must be refocused for close range — about 10 cm from the dial. The power supply must be a solid 5 V on short cabling.

An underfed ESP32-CAM brownouts into a reboot loop the moment the camera and WiFi radio wake together. It looks exactly like a firmware bug until you measure the rail.

Mounting and lighting are 80% of accuracy

The OCR model is actually the most reliable part of this pipeline. What determines accuracy is optics:

• Fixed geometry. The bracket must hold the camera axis centered and perpendicular to the dial at a repeatable distance. Every millimeter of drift shifts the regions of interest the model reads.
• Controlled light. Meter glass throws glare straight back at an on-axis LED. Mounting the light slightly off-axis behind a diffuser turns an unreadable hotspot into an even, repeatable image.
• Environment. Shafts collect condensation and dust. The enclosure has to keep the optical path clean — fogging shows up as slow accuracy decay, not a clean failure.

Get these right and recognition is essentially a solved problem. Get them wrong and no model rescues the deployment.

Confidence thresholds and the human fallback

A billing pipeline can't ingest raw OCR output. Think of a security guard checking ID at the door. If the photo is blurry or the data looks off, he doesn't wave you through, he calls a supervisor. Every meter reading passes through the same gate:

Plausibility checks are cheap and powerful. A water meter is a monotonic counter, so a reading lower than yesterday's is wrong by definition. A jump beyond the physically possible flow rate is wrong too.

Anything below the confidence threshold or outside plausibility lands in a review queue with the photo attached. A human confirms or corrects the value in seconds. That queue is what makes the system trustworthy: billing never sees an unverified guess, and the review rate itself becomes your accuracy metric per meter.

Power and connectivity

Where the shaft has mains power nearby, wire the device — it deletes an entire category of maintenance visits. Where it doesn't, batteries work fine; billing doesn't need real-time data. A few captures a day with deep sleep in between yields months of battery life.

Size the capture schedule to the billing cycle, not to what the hardware can do. WiFi plus MQTT covers the transport; commercial buildings either have coverage near the shafts or can add one access point per riser cheaply.

The economics

A camera point costs a fraction of a meter swap once you count plumbing labor, downtime, and utility coordination. Because the certified meter remains the billing instrument, there's no recertification question to answer.

Keep a monthly audit sample where a technician manually reads a rotating subset of meters against the system's numbers. It's cheap insurance, and it produces the accuracy figures that make a finance team comfortable signing off.

The number the camera produces is only half the product — it still has to become a tenant invoice. That pipeline, from raw readings to billed cubic meters, is covered in IoT utility metering and billing. The backend patterns underneath it are in the complete guide to IoT backends.