A smart breaker looks simple from the outside. It switches mains power, measures how much energy passed through it, shows a number on a small display, and sends that number to a cloud dashboard.
It is also one of those products where every layer has to be right at the same time. A firmware bug is not a UI glitch — it is a device inside a customer's distribution box. A calibration error is not a rounding issue — it is a billing dispute. And a device that reconnects badly is a device that quietly stops reporting.
I led hardware and firmware for a 35A smart energy-metering breaker that has shipped 6,300+ units into the field. Here is what the build actually looked like, and the decisions that mattered more than the feature list.
No client-specific details, schematics or BOM here — just the engineering choices that generalise to other connected mains products.
What the product does
- AC 100-250V input, rated 35A
- Mains switching with relay drive
- Energy metering, reported in kWh
- Local display and physical controls, so the device stays usable with no network
- ESP12S (ESP8266) with a 2.4 GHz radio
- MQTT uplink, kWh reported every 30 seconds
- A cloud API for device data
Two layers, two jobs
The control board is a 2-layer design with a deliberately strict split. The top layer carries the ESP12S module, its 2.4 GHz antenna, the MCU-side circuitry and the user interface. The bottom layer carries the AC-DC supply, current sampling and the relay drive.
That split is not cosmetic. Mains switching and current sensing are noisy, high-energy neighbours; a 2.4 GHz radio and a display are not. Keeping them on opposite faces of the same board outline makes the routing intent obvious to anyone who has to debug or re-spin it, and it keeps the antenna keep-out away from the supply and relay traces. When you only have two layers, the floor plan is your isolation strategy.
The mechanical stack is the other half of that decision: several boards, a display, terminals and the mains section all have to fit the same housing, with spacers that survive assembly variation. A board that works on the bench but cannot be assembled 6,000 times is not a finished design.
Four firmware decisions that mattered most
1. Metering is a calibration problem, not a driver problem
Reading a sampling channel is the easy part. The hard part is that no two units leave the line identical — sensing components, references and layout parasitics all vary. Calibration therefore belongs in the manufacturing flow, not in a one-off lab script: per-unit coefficients need a defined place to live on the device, and a firmware path to write and verify them without reflashing the whole image. Get that path wrong and you cannot correct a drift issue in the field.
2. A 30-second cadence is a product decision
Reporting every 30 seconds sounds arbitrary. It is a trade: short enough that a dashboard feels live, long enough that thousands of devices do not become a self-inflicted load on your own broker, and long enough that a brief WiFi hiccup does not turn into a burst of catch-up traffic. Once you pick a cadence, the timestamp belongs to the sample, not to the moment the packet finally leaves — otherwise a reconnecting device quietly rewrites history.
3. Treat offline as the normal state
Site WiFi is not a lab network. APs reboot, credentials change, and a metal enclosure changes the signal. Firmware has to assume disconnection: bounded buffering, reconnect with backoff, and — most importantly — never letting a network failure block local switching, display or metering. Protection and measurement stay local; the cloud is an observer, not a dependency. That boundary is the single most important architectural decision in this kind of product.
4. OTA and a safe mode are part of the product, not a phase two
Any connected mains product will need firmware changes after installation. Plan for OTA, a rollback path and a safe mode from the first board spin. If a new image cannot reach a healthy state, the device must still fall back to something that switches and displays safely.
What production adds that prototypes never show you
Prototype validation asks one question: does it work? Production asks a harder one: does the six-thousandth unit behave like the first? The things that bite are the boring ones — a calibration fixture that is repeatable across operators, an end-of-line functional test that exercises relay, display, buttons and radio in a single pass, and a mechanical stack that tolerates assembly variation. Design the test points and the fixture interface into the PCB early; adding them after the enclosure is tooled is expensive.
What I would do differently
I would freeze the telemetry contract — topic, payload, units, timestamp semantics, and what offline means — before the PCB is finalised. Firmware and cloud can then evolve independently, and a field issue can be diagnosed from a payload instead of from a phone call. It is a document, not code, and it outlives every firmware revision.
Takeaways
- Split the board by domain: noisy mains, sampling and relay on one side, radio and digital on the other.
- Put calibration in the factory flow, not in a lab script.
- Keep safety-critical behaviour local. The cloud observes; it does not decide.
- Decide the telemetry contract early, and design the test fixture into the board.
I work on connected hardware end to end — PCB, firmware and the cloud API behind it. This breaker is one of the products we design and manufacture in-house.
Disclosure: this article was drafted with AI assistance and reviewed and edited by the author. All specifications and figures come from our own shipped hardware.
Questions about calibration, the 30-second cadence or field reliability? Happy to go deeper in the comments.
Top comments (1)
Really useful write-up — the part that stuck with me is treating calibration as a factory problem, not a driver problem. That shift in framing explains a lot of field headaches. Same with timestamping at the sample rather than when the packet finally leaves; that is the kind of quiet detail that saves you from chasing phantom usage spikes after a reconnect. Keeping safety-critical behaviour local while the cloud just observes also feels like the right line to draw. Did you find the 30-second cadence held up once you had a few thousand units in the field, or did noisy sites push you toward buffering more locally?