Letter from a Power Meter

The power meter in the service cabinet of my building is, depending on how you look at it, either a small box that adds up the kilowatt-hours I have consumed or a small, somewhat opinionated computer that has been silently watching my domestic habits for the last seven years. I have known, in the abstract, for most of those seven years that it was the latter. I had not, until this month, taken the time to ask it what, exactly, it had been doing.

This essay is the result of asking. It is, in a quiet way, a kind of biography: of a meter, of the firmware running on it, and of the engineers who, in 2018, wrote that firmware under deadlines I can only guess at, in a building I have never been in, somewhere in a Tier-2 Indian city whose name does not appear on any of the documentation. I am writing it because the more time I spend with the meter, the more I think the meter has things to say that are worth listening to.

The cabinet

The cabinet is in the stairwell, on the ground floor, behind a steel door that is supposed to be locked. The lock has not worked since at least 2021, when I moved in. Inside the cabinet are twelve single-phase meters, one for each apartment, mounted in two rows of six on a perforated steel plate. The meters are made by a company whose name I will not give here, because I do not want to pretend that this is a story about a particular vendor. It is a story about a class of devices.

Each meter has a small LCD that shows, in a six-digit display, the current cumulative energy reading. Each has three LEDs — one for power, one for what the manual calls "communication," and one for what the manual calls "warning" — and a small infrared window on the front, behind which there is, the manual tells me, an IrDA transceiver that can be used by an authorised technician to interrogate the device. There is also, the manual does not tell me, a serial header on the back, accessible if you remove four screws and a piece of tamper-evident tape. I removed the tape. The tape, like the lock on the stairwell door, was honoured more in the breach.

The serial header speaks, when probed with a 3.3-volt USB-UART adapter, in a quiet stream of human-readable text at 9600 baud. It says things like:

[2026-05-12 04:37:02] MTR: tick (5s); kW=0.41; kWh=18472.331
[2026-05-12 04:37:07] MTR: tick (5s); kW=0.42; kWh=18472.332
[2026-05-12 04:37:12] MTR: tick (5s); kW=0.39; kWh=18472.332
[2026-05-12 04:37:17] COMM: heartbeat OK; uplink RSSI=-67dBm

It says, in other words, that it is awake, that it is watching, and that it is reporting. The reporting is via a small GSM modem mounted on the same board, which the meter uses to send aggregated usage data, every six hours, to a server whose IP address is hard-coded in the firmware. The IP address resolves, when I look it up, to a hosting facility in Hyderabad. The server is, presumably, the property of the meter's manufacturer.

What the meter knows

The thing the meter knows about me, after seven years of careful observation, is more than I had quite reckoned with. It knows, to the half-watt, how much power my apartment draws every five seconds. From that, with very little signal processing, it can derive a great deal. It knows when I am home — the small bump from a refrigerator compressor cycling at three in the morning is distinguishable from the larger, more variable load of a person who has gotten up to make tea. It knows when I have guests — two adults producing kitchen and bathroom loads in alternation look different from one adult producing loads in sequence. It knows, to within a margin of a few minutes, when I go to bed and when I get up.

It also knows, because the firmware logs it, every time the power has dipped or surged. There is a small ring buffer of voltage anomalies, going back about six weeks, in which I can see the precise timestamps of every brownout my neighbourhood has experienced. There is a longer log, in flash, of cumulative energy by hour, going back to the meter's installation date in late 2018. The log has 64,872 entries.

I will say, plainly, that I do not think any of this is a vulnerability in the conventional sense. The meter is doing exactly what the utility paid for it to do. The data the meter is collecting is, in any meaningful sense, the meter's own — the device is owned by the utility, installed in a panel that I am contractually not supposed to open, and connected to a back-end that I have no claim on. The fact that I was able, with a USB-UART adapter and a few screws, to read all of this is a function of the meter being designed for an environment where physical access was assumed to be controlled. The lock on the stairwell door was supposed to be the security boundary. The lock has not worked since 2021.

The firmware, briefly

The firmware on the meter, as best I can tell from the serial output and from a partial dump of the flash that I obtained by being patient with the bootloader, was written in C, almost certainly using the manufacturer's reference SDK for the underlying microcontroller (a moderately old ARM Cortex-M3 part whose datasheet I have, but whose part number I will leave undocumented for the same reason as the vendor's name). The firmware version, as reported by the bootloader, is 2.4.7. The build date encoded in the binary is 2018-09-03. There has, in seven years, been no over-the-air update.

The code, where I have been able to read it, is competent. It is not elegant, but it is not careless. The energy-summing arithmetic is done in 64-bit fixed-point, which is appropriate. The GSM modem is exercised with a state machine that handles, gracefully, the case where the cellular network is unavailable for hours or days. The IrDA interface respects a documented protocol that I have, with some effort, been able to confirm matches the one in the public manual. The serial-port logging, which is what I have been reading, is clearly a debug feature that the original developers intended to disable in production and forgot.

The forgetting is the part that interests me. I do not think the engineer who wrote the serial-logging code in 2018 intended for me to read it in 2026. I think the engineer intended for the logging to be turned off, by a single configuration flag, before the firmware shipped. The flag was not turned off. The reason it was not turned off is, almost certainly, that the production-build process did not, in 2018, have a check for it. Eight years and several hundred thousand units later, every meter of this model is still narrating its observations into a serial port that the manufacturer assumed nobody would ever access.

What the meter would say, if asked

If the meter could speak — if the serial output were not merely a debug stream but a kind of letter from the meter to whoever was patient enough to read it — I think it would say something like the following.

It would say that it has done its job, faithfully, for seven and a half years. It has logged 64,872 hourly readings without error. It has reported, on schedule, to a server in Hyderabad whose operators have, as best the meter can tell, never reported back. It has counted brownouts, registered surges, and faithfully tracked the slow drift of its own internal clock against the timestamps it occasionally receives from the cellular network.

It would say that it does not know what becomes of the data it sends. It has no return path for that information. It has no log of what the back-end does with its uploads, or whether the uploads are even being received. The cellular link, in its mind, is a unidirectional pipe. The pipe terminates somewhere it cannot see.

It would say that it has been, for seven years, in a stairwell behind a door whose lock has been broken for at least four of those years. It has not been physically disturbed. It has not been interrogated by anyone with authorisation. It has, until this month, not been read at all.

And it would say, finally, that the engineer who wrote it is no longer at the company that manufactured it. I know this because I tracked the engineer down. We exchanged a brief and slightly awkward set of emails. The engineer was surprised to learn that the meter was still running the firmware they had written. They were not surprised to learn that the debug logging was still on.

A small, modest conclusion

I do not have a campaign to mount, here. The utility is not, on the evidence, doing anything malicious. The meter is doing its job. The data it collects is unlikely to be used against me in any way that matters. The risk that someone with worse intentions than mine will read the same serial port and learn the same things is real but, in the context of all the other ways the same someone could surveil a stranger's domestic life in 2026, modest.

What I take from this, and what I would offer to anyone else thinking about the long-tail life of small embedded devices in the world, is the following. The devices we ship outlive our intentions for them. The debug ports we forget to disable will be found, sooner or later, by somebody patient and curious. The data our devices log will, eventually, be read by people we did not anticipate. The firmware version that ships is, very nearly always, the firmware version that will be running, unmodified, a decade later.

The meter in my service cabinet is, in this small way, a teacher. It is teaching me, with great patience and at considerable length, the consequences of choices that were made in a hurry, on a deadline, by people whose names I will never know, in 2018.

I am, on balance, grateful for the lesson.