MTronic building automation
Motion and Light Sensor
The MTronic motion and light sensor is a ceiling-mounted, battery-powered device for the MTronic smart home automation platform. It detects room occupancy through a 360-degree passive infrared field and measures ambient light continuously, and it is the input the rest of the system depends on to automate lighting and climate. If the sensor is unreliable or frequently out of battery, the automations that sell the whole ecosystem stop feeling automatic.
I was the sole firmware engineer on this sensor across two hardware generations. I joined when the first ESP32-C3 prototypes (V1) had been fabricated, and through systematic power profiling I found that the platform could not be pushed past a roughly 9-month battery life. That was below the product's hard 1-year requirement and made V1 effectively unsellable. I made the technical and supply case for moving to a Nordic Semiconductor nRF52832, rebuilt almost the entire firmware from scratch, and worked closely with the hardware team on the V2 design. The shipped sensor is rated for 3+ years, and units installed in late 2022 are now 3.5 years in with good remaining battery capacity. This provides field-backed evidence that the battery life will likely be at least 4 years.
Project Brief
- My role
- Sole firmware engineer; hardware-design collaborator on V2
- Product
- Ceiling motion and light sensor for the MTronic smart-home mesh
- V1 platform
- Espressif ESP32-C3, ESP-IDF, FreeRTOS
- V2 platform
- Nordic nRF52832, nRF Connect SDK, Zephyr
- Connectivity
- Bluetooth Mesh
- Power
- 2 x AA alkaline cells
- Battery life
- Rated 3+ years; field units at ~3.5 years and still running strong
Where the sensor fits
01 The MTronic system
MTronic is a smart home and building automation platform built around a central hub. It connects lighting, climate, security, and appliance control across a Bluetooth Mesh network, with control through touch panels, a mobile app, and voice assistants. The pitch is energy efficiency: devices respond to real occupancy and real light levels instead of fixed schedules.
Most devices in the range, like dimmers, relays, and panels, are mains-powered. The motion and light sensor is not. It runs on two AA cells, and it is the device that tells the rest of the system whether a room is occupied and how bright it is. The headline automations, lights that come on as you walk in, air conditioning that shuts off once a room empties, corridors that illuminate as you move through them, all depend on this one battery-powered node being accurate and present on the mesh.
02 Why battery life was so important
Because the ecosystem leans on the sensor, the sensor's battery life is a property of the whole product. A sensor that dies every few months turns the flagship automations into a maintenance chore and makes the entire system feel unreliable.
Management set a hard requirement of at least one year. One year is a psychological magic line: under it, customers are constantly wondering whether the battery is about to go. The sensor had to clear that bar before it could ship at all, and clearing it comfortably was the difference between a selling point and a liability.
1.A power crisis born from the chip shortage
01 The platform was forced, not chosen
This was during the global chip shortage. The original sensor generation (V0) ran on another SoC capable of Bluetooth Mesh that simply became unavailable, so the whole MTronic lineup migrated to the Espressif ESP32-C3: a single-core RISC-V part with a lower-power radio and lower clock than the classic ESP32, and one of Espressif's first Bluetooth Mesh capable chips. It was cheap and, more importantly, abundantly in stock. V1 of the sensor was designed around it. I joined to write the firmware for those first V1 prototypes.
02 The datasheet did not match the silicon
V1 hardware was designed assuming the published figures: about 5 µA in deep sleep, 20 mA CPU-only with the radio off, and a maximum of 80 mA peak during transmit at the minimum -20 dBm. [1]
My profiling told a different story. Deep sleep would not drop below roughly 25 µA, the radio drew about 80 mA constantly when on, and Bluetooth Mesh transmit produced 150 mA spikes. For an alkaline battery budget, those gaps already made the battery life unfeasible. A good share of the blame sat with the misleading datasheet numbers. [2]
03 A bet on the ESP32-H2 that never arrived
Espressif had announced the ESP32-H2 back in 2021 with far better numbers: roughly 5 µA deep sleep, around 10 mA CPU-only, and about 20 mA Bluetooth transmit at 0 dBm. [1]
Its expected release was right around when we started development on the ESP32 platform, and that timing was part of the decision: the plan was to develop the sensor on ESP32-C3 and then drop in the ESP32-H2 for instant low-power benefits, ideally without touching the firmware.
The H2 became commercially available roughly two years after we needed it. By then MTronic had already launched at the end of 2022.
04 Unexpected bootup current spikes
The power figures were not the only surprise. After a series of "mysterious" brownouts, we found out that the V1 regulator could not reliably absorb the ESP32-C3's startup current peaks, which reached roughly 350 mA and were not obvious from the datasheet. That put the regulator under strain, which was rated for 200 or so mA, and would often dip the voltage below brownout limits during startup
That design lapse came from a power profiling tool that could only measure up to 100 mA. On its display, it would clamp the current consumption at this limit, so we only found out about the 350 mA spike when I coincidentally, for a different reason, used the old-school setup: an oscilloscope, a shunt, and a bench supply.
It led to the search for a better current profiler and a regulator that could handle the higher current spike without having a lower efficiency at micro amp level, where the regulator's efficiency mattered the most.
2.Power profiling and a battery-life model
01 A better profiling tool
After the 100 mA limit profiler missed the 350 mA spike, we clearly needed a new regulator. But this meant delays, additional hardware revisions, and loss of valuable R&D time and resources
In parallel, I found a much better tool: the Nordic Power Profiler Kit 2. It could measure currents up to 1 amp, and to my delight could also control the source voltage.
02 Measure every micro amp
I profiled power bottom-up: each peripheral and behavior in isolation, then summed, then cross-checked the sum against top-down measurements of the combined and sequential profiles. The two numbers never matched exactly. There was always a gap, made up of interactions between peripherals, timing effects, and current draws I had not yet classified. Closing that gap was an iterative process: classify more events, make an educated guess about what remained, re-measure, repeat. The result was never a perfect accounting, but it reached a point where the model was accurate enough to trust for real decisions.
The per-component measurements covered the smallest possible individual operations: the TWI bus, GPIO, sleep and wake states, radio on and off, and the cost of sending and receiving a given number of Bluetooth Mesh packets. On top of those I measured whole features: reading the light sensor, reading internal flash, and each wake-up cycle.
- Per-peripheral and per-feature current measured in isolation
- Cross-checked bottom-up sum against top-down; gap closed iteratively through event classification and estimation
03 Turn measurements into a battery-life estimator
From those numbers I built a model that estimated battery life from the sequence, frequency, and duration of every event in the device's cycle. It started as a spreadsheet and grew into a comprehensive model implemented in C# and .NET. The early versions missed things I only caught by measuring combined behavior, but after several refinement passes the model was accurate enough to trust for decisions.
The model let me benchmark the algorithm itself in battery terms. I was not committed to any particular peripheral or algorithm, only to the end goal: reliably knowing whether a person is in the space. So I could propose a variation of the device cycle, how often it wakes, which sensor it reads when, what work it defers, and read out the battery-life cost.
I later open-sourced a simplified offshoot of the model as a general tool: Power Estimator.
- Model parameterized by event sequence, frequency, and duration
- Spreadsheet first, then a .NET tool
- Algorithmic choices benchmarked directly against battery life
04 Trade accuracy where accuracy was not needed
With the model I could make deliberate trade-offs instead of guessing, and simulate numerous variations. For example, I gave up on highly accurate light readings, battery measurements and truly instant motion response in exchange for "good enough", because good enough was all the task required. Fine-tuning those parameters took a lot of real-world testing in actual rooms.
Two more findings that decreased power consumption substantially: Reducing transmit count and duration was the obvious lever, but maximizing how frequently and how long the device sleeps turned out to matter even more.
The sensor's algorithm and its interactions with other MTronic devices were designed so mesh traffic load did not affect the sensor's own power budget, which kept battery life predictable regardless of how busy the network was.
05 Re-profile regularly
The model told me what the battery life should be; profiling regularly told me whether the firmware still hit it. The smallest changes could increase the power consumption and would slip undetected for many weeks. A feature that added tens of microamps to the deep-sleep current, or a few milliseconds to the radio ON time, looked harmless in isolation but quietly erased months of estimated life.
After this happened a couple of times, I made it a hard rule to profile current draw after every feature and every refactor, and to keep records I could diff against past runs. It was regression testing for the power profile, and it kept battery-life degradation from ever creeping in unnoticed as the firmware grew.
- Current profiled after every feature and refactor, not just at the end
- Each run recorded and compared against past profiles
- Caught silent regressions before they reached a release
3.Battery life ceiling
V1 still hit a wall at nine months
All of that work did matter. V1 was where the sensor's concept was validated, where the algorithm took shape, and where many hardware and integration issues were discovered and worked through. Mains-powered devices on the mesh also had their behavior altered to take load off the sensor, and I optimized relentlessly, my first time doing power optimization at this depth.
But even after all of that, the modeled battery life only stretched from 1.5 months to about nine months. That was still below the one-year requirement, which meant V1 remained unsellable on battery life alone. Shipping it in that state would have turned a flagship automation product into a maintenance problem and damaged trust in the MTronic brand.
We started looking for rescue options
Once it was clear that V1 would not cross one year, the discussion turned from optimization to rescue options. We explored several ways to keep the ESP32-C3 platform alive. The main workaround we kept coming back to was offloading PIR signal processing to a separate ultra-low-power MCU, because the ESP32-C3 had no ULP coprocessor, which was another disappointment.
We also looked at building much of the sensor processing out of discrete analog parts. Resistors, op-amps, capacitors, and transistors, so the ESP32-C3 would be spared of wakeups. Sadly, an ad-hoc analog processor like that is much more exposed to noise, temperature drift, and RF than a digital path (analog computers gave way to digital ones for a reason), which made it the riskiest option on the table. But at that point we were throwing everything at the wall to see what sticks.
We even considered more outlandish alternatives, including presence sensing by observing how people affected the radio signals between mains-powered MTronic devices, which could have removed the need for a battery-powered motion sensor altogether.
But these options were all risky, unfamiliar, and slow to develop at exactly the wrong time. During the chip shortage with a launch deadline hanging over our heads, betting on more complex hardware or an unproven sensing concept would have stretched development and supply risk even further. The only workaround we could agree on was adding a very low-power companion MCU for sensor processing and having the ESP32 do nothing but Bluetooth TX and RX. We were about to start design and evaluations for this when the nRF52 supply breakthrough happened.
4.Making the case for the nRF52
The technical argument
I had my eye on the nRF52 from the moment I measured the power profile of ESP32-C3. I already trusted its low-power behavior from earlier work on a wearable epilepsy monitor built on the same chip, where the part had proven itself.
During late 2021 to early 2022 chip shortage, for small buyers, the only practically obtainable nRF52832 module options were often around $10 or higher. The challenge was justifying such a module against the ESP32's $2 at the BOM level. The answer was simple once framed correctly: a sensor that can't clear one year is unsellable, and an unsellable sensor undermines the entire ecosystem that depends on it.
Solving the supply problem under a shortage
Cost, however, was not the real blocker. Availability was. Early on, the nRF52 was scarce because the large IoT manufacturers had stockpiled it. I tracked module manufacturers directly rather than resellers and stockists, and checked each one's track record on recent orders.
Supply finally opened up
Over time, the situation improved, and we found an nRF series module manufacturer in China with thousands of new modules available in stock, at a (comparatively) reasonable $6 per unit cost, and confirmed with them that they were actively producing more. That meant a large order could secure our supply, which was ultimately what let management greenlight the nRF52-based V2.
Making the migration possible
Committing to a more expensive part on an unfamiliar RTOS during a chip shortage was a real business risk. My role was to remove as much of that uncertainty as possible before anyone had to sign off: real measured power numbers, a battery-life model that could be interrogated, prior proof that the nRF52 delivered, and a vetted in-stock supply line. With that evidence on the table, the migration was a safe and calculated move.
5.Designing V2 with the hardware team
A tight hardware-firmware loop
V2 kept the shape and outline of V1, but most of the internals changed: the SoC, the regulator, a specialized processing IC, and even the placement of the PIR sensor itself.
The hardware team kept me in the loop with their designs for feedback before finalizing them for review and prototyping, and I took that trust seriously. I reviewed schematics, drew on my own hardware background to critique choices at the design stage, and ran tests continuously, reporting findings the moment I had them.
In many smaller hardware issues, instead of just flagging them as hardware problems, I narrowed them down to the exact cause and tested likely fixes myself before bringing them to the hardware team, which made review and correction much faster.
This led to the hardware and firmware work being more collaborative and iterative than on other MTronic products.
Validating assumptions by measurement
Rather than trust assumptions, we tested them and re-tested them. My test work fed directly back into the design and into tuning the algorithm.
- Per-component current draw and pin assignments
- Regulator stress testing and low-voltage testing of the SoC and full sensor
- PIR signal filtering and its response to sudden and gradual temperature changes
- Light sensor limits and ideal operating range
- PIR area coverage and sensor placement across different parts of a room
The component that mattered as much as the MCU
Every component was scrutinized for its power consumption. The biggest hardware win besides the nRF52 itself came from a specialized IC that offloads some basic but essential analog processing of the PIR signal off the MCU.
I was already familiar with the broader idea from earlier work on a wearable epilepsy monitor, where I had dealt with analog front ends that pushed difficult filtering and signal-conditioning work closer to the sensor instead of leaving it all to the host MCU.
The same low-power logic showed up again in Silicon Labs' Manage the IoT on an Energy Budget: sleep as deeply as possible, and wake up as seldom as possible.
We were confident that a part like that had to exist for our use case, and we found exactly that in an application note. It meant the nRF52 had to wake from deep sleep even less often. Even without it, the nRF52 platform would still have cleared the one-year requirement comfortably. What the IC changed was the margin: together with the mature algorithm and the lower-power MCU, it is what pushed the final product into the guaranteed 3+ year range. The specific part is a trade secret and is not named here. [4]
6.Rebuilding the firmware on Zephyr
Two phases on an unfamiliar RTOS
The V1 firmware ran on ESP-IDF with FreeRTOS, and that was where most of my RTOS learning had already happened. The nRF52 meant Zephyr, which no one on the team had used, but the RTOS concepts carried over, so translating FreeRTOS patterns into Zephyr turned out to be straightforward. V2 firmware took about four months in two roughly equal halves.
The first two months were the low-level stack from scratch: GPIO, TWI, SPI, timers, low-power modes, and Bluetooth Mesh. The next two months were porting the application layer and the sensing algorithm, translating FreeRTOS concepts where they mapped cleanly while exploiting Zephyr-only features where they were worth it.
The hardest part was Zephyr's device model. The abstractions and devicetree were unfamiliar and took time to get used to. Bluetooth Mesh, by contrast, went smoothly: Nordic's nRF Connect SDK ships a comprehensive example, and Zephyr's mesh implementation is very intuitive. Overall the platform gave me very little trouble, with no significant Zephyr or SDK bugs eating into the schedule.
Verifying the power management of Zephyr
Implementing low power states was another task. And at that point, handling the on, off and transitioning states for all peripherals had become a part of driver/module development. I verified that the device entered the sleep states, and profiled them the same way I had profiled V1. The contrast between the two platforms was the single biggest surprise of the project, with the nRF52 beating the ESP32-C3 in essentially every aspect.
The algorithm was V1's, carried over unchanged
The "algorithm" in this case study roughly means the entire device cycle. It was developed and squeezed to its limit during the seven months on V1. It was already so optimized that it was the reason V1 reached nine months at all... on a part that fought it every step of the way.
V2 reused that same algorithm. A good part of it was covered by unit tests, and although that was a tiny share of the firmware in line and branch terms, it was the most critical part. Its full coverage was why the algorithm ported to Zephyr with zero issues and ran flawlessly from the first build.
The jump from nine months to a projected four-plus years did not only come from cleverer firmware. It came from running a mature, already-tuned algorithm on a platform that finally cooperated. The nRF52 was the change that made the one-year requirement easy to clear, and the specialized IC helped push the final design much further by removing wake-ups that V1 could not avoid. Together, they let the same sensing strategy land in a completely different battery class.
7.Outcome
V2 did not just meet the one-year requirement, it cleared it by a wide margin. The sensor is rated for guaranteed 3+ years on the approved two AA alkaline cells, validated by long-running accelerated tests checked against the battery estimation model. Units installed in late 2022 are now 3.5 years in with strong battery capacity still reported, which firmly supports the projected real-world life of around 4 years. At that threshold a user essentially never thinks about the battery; at one year, they might still be counting the months.
Thanks to MTronic's strong QA and testing culture, V1 had already flushed out most of the non-battery issues: algorithm behavior, hardware bugs, and integration problems. It validated the sensor's concept and use in the real system, even though the battery life still made that version unsellable. By release, the few V2-specific issues had been resolved. The sensor became one of the most stable products in the lineup, something the service staff later confirmed. The Zephyr and nRF52 foundation I built also unblocked a pipeline of other battery-powered MTronic devices that simply were not feasible before. The sensor remains in active production and sale.
8.Retrospectives
This project seeded several threads I carried much further later. The nRF52 and low-power Bluetooth expertise became the basis for my work on the smart insole firmware. The exposure to full product lifecycle, including QA and a first taste of production testing and tooling, is something I developed fully in the production test cabinet.
Two specific habits from here carried straight into my later work on the Simplifier Gateway. The first was unit testing. The coverage was small, aimed only at the algorithm's most critical part, but it was the seed of the certification-grade testing I later built for the Gateway.
The second was MISRA compliance. MTronic held its firmware to MISRA by choice, for the reliability it bought rather than any regulation, and ran regular reviews to check adherence. By the time I met MISRA as a formal requirement on the Gateway, in an entirely different domain, I was already fluent in the rules and the style of C they enforce. The discipline paid off for the company directly too, feeding into the UL certification MTronic later earned, though that came through after I had moved to Safety System Products.
Those two habits were the visible part of a larger engineering practice. The deepest thing MTronic and its parent MRS Technologies gave me was a culture of rigor I could not name at the time: requirements analysis and traceability, architecture settled before any code, module reviews followed by system and architecture reviews from senior engineers before every major release, QA tested against documented results, meticulous changelogs, SDK versions frozen across the team, and reproducible release builds handed to QA through an automated, traceable pipeline. It was simply how the company worked.
Functional safety and IEC 61508, the field I work in now, demands similar practices, only stricter and more auditable. When I later met the standard as a formal requirement, it was mostly a matter of putting names and audit trails to habits I already had.
9.Clarifications
[1] Vendor-published or vendor-announced figures for the ESP32-C3 and ESP32-H2.
[2] Representative ESP32-C3 figures that can be measured at the SoC/platform level. They describe the chip in relevant states, not the complete assembled sensor.
[3] Representative SoC-level comparison points for the ESP32-C3 and nRF52 in sleep, CPU-active, and radio states. They compare the platforms, not the actual sensor power consumptions.
[4] Some component identities and low-level implementation details are intentionally generalized or withheld, including the earliest SoC, the specialized helper IC, and exact sensing or interface details.