Shipping 6,300+ 35A Smart Breakers: PCB, Firmware and Cloud Lessons

A smart breaker appears simple from the outside. It switches mains power, measures energy flow, displays that energy in kWh, and sends the data to a cloud dashboard. However, every layer of the product must work together seamlessly. A firmware bug is not a UI problem - it can cause device failure in a customer's distribution box.

A calibration error is not just a rounding issue - it can lead to billing disputes. The product has shipped over 6,300 units. The engineering choices behind the smart breaker are critical and inform similar connected mains products.

The product operates on an AC 100-250V input, with a 35A rating for mains switching using a relay drive. It meters energy consumption in real-time and reports it every 30 seconds. The device features a local display and physical controls, ensuring usability even without a network. The ESP12S (ESP8266) microcontroller with a 2.4 GHz radio handles the MQTT uplink. The cloud API allows for device data exchange.

The PCB design splits into two layers for a reason. The top layer houses the ESP12S module, its antenna, MCU-side circuitry, and user interface. Meanwhile, the bottom layer accommodates the AC-DC supply, current sampling circuitry, and relay drive. This separation prevents high-energy mains switching and current sensing from interfering with the radio and display functions. It simplifies routing and debugging, as well as antenna placement.

Mechanical stack considerations are crucial too. With only two layers, board layout dictates isolation strategies. Multiple boards, displays, terminals, and the mains section must fit within a single housing. Proper spacers are necessary to accommodate assembly variations, ensuring the device can be assembled 6,000 times without issues.

The firmware incorporates four crucial decisions. First, metering is a calibration problem, not a driver problem. Each unit has unique components, references, and parasitics, so calibration must be implemented during manufacturing rather than in a one-time lab script. Incorrect calibration can result in permanent issues in the field.

Second, a 30-second data reporting cadence balances product usability with network load management. Reporting every 30 seconds provides a live dashboard feel while minimizing unnecessary traffic. Timestamps are assigned to the sample measurement for consistency. Third, offline conditions are the normal state for the product. Firmware must handle disconnections gracefully, including bounded buffering and reconnecting with backoff protocols.

However, safety-critical functions like switching, displaying energy, and metering must remain local even when offline. Lastly, over-the-air (OTA) updates and a safe mode are integral to the product, not just an after-thought. This ensures firmware changes can be deployed after installation, with a reliable fallback mechanism in place.

Production considerations differ from prototype testing. Production demands ensure the six-thousandth unit behaves identically to the first. Prototype validation focuses on "does it work?" whereas production requires answering "does the six-thousandth unit behave like the first?" Boring, yet essential aspects include calibration fixtures, end-of-line functional tests, and a mechanically robust design that tolerates assembly variations. Early PCB design should incorporate test points and interfaces for easier debugging and testing.

Looking back, the author would have frozen the telemetry contract earlier in the development process. Defining the topic, payload, units, timestamp semantics, and offline behavior before finalizing the PCB allows for independent evolution of firmware and cloud components. This approach enables effective field issue diagnosis through telemetry data, reducing reliance on phone calls and facilitating smoother updates and maintenance.