AI on the Edge Device: turning an analog water, gas or power meter into a digital one with an ESP32-CAM

What problem the ESP32-CAM meter reader actually solves

Most buildings already have meters. They are mechanical, they are owned by the utility, and they are not going to be swapped out because a tenant wants a graph. The alternative to reading them by hand is either a pulse sensor glued to a rotating disc or a camera pointed at the digits. AI on the Edge Device takes the second route. An ESP32-CAM photographs the counter, extracts the regions of interest that contain the digits, and runs a TensorFlow Lite model over them to produce a number. The README describes the target audience implicitly: people who want their water, power or gas consumption in a home automation system without touching the meter itself. The hardware is deliberately cheap. The README states the device measures 3 x 4.5 x 2 cm³ and costs less than 10 EUR, which is the whole argument for putting intelligence on the camera rather than streaming images to a server. If you have a Home Assistant instance and a meter in a basement, this is aimed at you.

How the image pipeline and TFLite inference work together

The workflow in the README is short but specific. The device captures a photo at set intervals. It then performs inline image processing: feature detection, alignment, ROI extraction. Only after that does the cropped region go through the neural network. That ordering matters, because alignment is what makes the approach survive a camera that shifts by a millimetre when a door slams. The model is not asked to find the meter in a full frame; it is asked to read digits from a rectangle that the firmware has already located and straightened. The inference runtime is TensorFlow Lite, wrapped by what the README calls an easy-to-use wrapper, running on the ESP32 itself. The output is a digitized meter value, and the README lists three ways to get it out: MQTT, InfluxDB 1 and 2, and a REST API. There is also a web interface for administration and control, and an OTA path for updating the firmware over Wi-Fi afterwards. The architecture is therefore a closed loop on the device: capture, align, crop, infer, publish. Nothing about the recognition step requires a cloud service, which is the point of the project name.

Installing AI on the Edge Device: flashing, SD card and first reading

This is not a package you install. The README sends you to the Releases page for the latest version, then describes two flashing stages. The first is the ESP32 itself, over USB. The README says the preferred way is the Web Installer and Console, a browser-based tool that flashes the ESP32 and extracts the log over USB; Espressif's Flash Tool and the command-line ESPtool are listed as alternatives. The second stage is the SD card, which the README says can be set up automatically after the firmware is installed, via the built-in access point. For that to work the card must be FAT formatted, which the README notes is the default on most cards.

Because the repository ships a webinstaller directory and a sd-card directory rather than a package manifest, there is no install command to copy here. The exact steps live in the documentation site linked from the README. What you can verify from the repository layout is that param-docs and sd-card exist as separate trees, which tells you configuration is file-based on the card rather than compiled in. After the device boots and joins Wi-Fi, the web interface is where you draw the regions of interest and trigger a test recognition. Expect the first attempt to be wrong. The alignment step needs a reference image that actually shows the counter, and a camera aimed at an angle will produce crops that drift.

Where the approach breaks: glare, unreadable dials and the wrong meter

The honest limitation is optical. The README mentions integrated camera and illumination, which helps in a dark meter cabinet, but illumination does not fix a scratched plastic cover or a reflection across the digit window. A rolling-dial meter with no numeric display gives the ROI extractor nothing stable to align on, and the project is built around reading digits, not counting pointer positions. Intervals are another constraint: the README says the device captures a photo at set intervals, so a fast-changing value can be missed between captures, and there is no claim of continuous measurement. Then there is the hardware dependency. The README says all you need is an ESP32 board with a supported camera, and points to a Hardware Compatibility page, which means an unsupported camera module is a dead end rather than a configuration problem. Finally, the licence file is named Licence.md and the repository metadata reports NOASSERTION, so the terms are not summarised by a standard identifier. Anyone embedding this in a product needs to read that file rather than assume.

AI on the Edge Device versus a pulse sensor or a cloud camera

The obvious alternative is a magnetic or optical pulse sensor that counts rotations or pulses and multiplies by a known factor. That approach is simpler and cheaper to run, and it does not need a neural network. Its weakness is that it depends on a pulse output or a reflective mark, and it cannot read a number. It also drifts: a missed pulse is a permanent error until someone corrects it. AI on the Edge Device reads the absolute value from the display, so a failed capture costs you one interval rather than the whole total. The other alternative is a general-purpose IP camera streaming to a server that runs recognition in software. That gives you more compute and easier model updates, but it moves the problem to a machine that must stay powered and online, and it sends images of your home out of the device. The ESP32 approach keeps the image local and publishes only the number. The trade is that you cannot upgrade the model without flashing firmware, and the compute budget is fixed by the microcontroller.

Maintenance, releases and what the licence file means for you

The last push to the default branch was on 2026-07-03, and the most recent release listed is v16.1.0 from 2026-01-11, preceded by v16.1.0-RC1 in December 2025 and v16.0.0 in March 2025. That is a project with a release cadence and a changelog file at the repository root, not an abandoned experiment. The upgrade path is the interesting part: the README states that later updates are possible directly over the air using Wi-Fi, so once the initial USB flash is done you are not reopening the enclosure. That matters because the device is likely mounted inside a meter cabinet with the camera aimed at a counter, and dismounting it means re-aiming it. Budget for re-aiming anyway after a major version, since alignment settings are stored on the SD card and a firmware change can alter how ROIs are interpreted. On licensing, the repository carries a Licence.md file and the metadata does not resolve to a recognised SPDX identifier. That is not a reason to avoid the project for personal use, but it is a reason to read the file yourself before shipping anything built on it. This is not legal advice; it is a pointer to the document that matters.

Editorial conclusion

Adopt it if you own a mechanical meter you are not allowed to replace, you can mount a camera in front of the counter, and you are comfortable flashing an ESP32 over USB before anything else works. Do not adopt it if you need a guaranteed reading every interval, if the meter face is unlit and inaccessible, or if you want a plug-and-play sensor with a vendor hotline. Before buying hardware, check the camera compatibility list in the documentation, confirm your meter has a readable numeric display, and verify that the SD card you own is FAT formatted, because the remote setup path depends on it.

Frequently asked questions

Official sources

1. Issues
2. jomjol/AI-on-the-edge-device on GitHub
3. Project website
4. README
5. Releases