From end-of-life to market-ready: rebuilding a 400,000-unit safety product as a Certification-Ready BLE IoT System

A two-decade-old stove-guard safety device – proprietary RF, assembler firmware, no mobile interface – rebuilt on bare-metal Nordic silicon as a modern, BLE-connected, EN 50615-ready system. Same install experience for the user; everything underneath replaced.

Executive Summary

Challenge:

A Nordic safety manufacturer with 400,000+ field installations faced the end of life of its flagship stove-guard product. The legacy architecture could no longer meet user expectations or tightening residential-safety regulation:

Proprietary sub-GHz radio; firmware written largely in assembler
No mobile app, no remote monitoring, no over-the-air update path
Rising EN 50615 certification pressure across target markets

Solution:

needCode rebuilt the product as a modern BLE IoT system: new silicon, new radio protocol, new application architecture, new mobile interface, new certification posture while keeping the device functionally identical for the end user. Framed as a refactor, the scope was effectively a new product generation, delivered end-to-end across firmware and hardware.

Do you need Smart Innovations?

Book a free discovery call and let's unlock new possibilities

Impact at a glance:

installed base modernized without forcing users to relearn how to install or operate the device

Battery-life KPI met

a commercial deal-breaker, solved through protocol-level redesign rather than hardware tuning alone

EN 50615 certification-ready

architecture built to pass independent accredited-lab testing across all mounting positions

Full-stack ownership

firmware and custom PCB delivered by one partner, closing a hardware gap on the client side

Zero silent failures

self-test built into the firmware so the device never claims a safety status it cannot guarantee

What we delivered

01

A future-proof firmware architecture
Three explicit layers (drivers → modules → application) that absorb silicon and component changes without touching product logic — so the next part swap doesn't trigger another rebuild.

02

Battery life that meets spec
An advertising-on-demand BLE model that keeps the battery-powered sensor near zero radio energy by default, shifting the cost of being "always listening" onto the mains-powered control unit.

03

A safety classifier validated at scale
The fire-detection algorithm verified against a database of ~1,000 real cooking and fire sequences through simulation replay — reproducible coverage without re-staging dangerous events.

04

Certification-grade safety behavior
Power-on and periodic self-tests plus defined fault states, so a degraded sensor signals failure instead of pretending to work.

"A product with twenty years in the field can't afford a bad rebuild. We took full ownership of both the hardware and the firmware and rebuilt it from the silicon up. Modern, connected, and certification-ready from day one. That's the kind of challenge we exist for."

Bartek Kling

CEO at needCode

Get a Free Estimate

Background & Challenges

The starting point was a product that already worked. The stove-guard device had been on the market for close to two decades and carried a substantial installed base; the problem was never its function, but the fact that the engineering underneath it belonged to a different era.

The device communicated over a proprietary sub-GHz radio with no realistic path to modern connectivity, and its firmware was written largely in assembler: hard to maintain, and no longer fully understood inside the organisation now that the original engineers had moved on. There was no mobile app, no remote monitoring, and no over-the-air update path, which left the product increasingly out of step with what every other connected appliance in the home now takes for granted. At the same time, regulators across the target markets were tightening the requirements that apply to active residential safety devices, steadily raising the bar the product would have to clear to remain certifiable (EN 50615).

What had been framed as a "refactor" was, in practice, a full new generation: new silicon, a new radio protocol, a new application architecture, a new mobile interface, and a new certification posture. One constraint sat above all of it and shaped every decision below — the device had to remain functionally indistinguishable from the legacy unit in its core safety role, so that no installer and no user would ever have to relearn how to set it up or operate it. Everything beneath that surface was open to change; the surface itself was not.

How we did it

1. A maintainable firmware foundation

Problem

The firmware runs bare-metal, with no RTOS beneath it — a deliberate trade. A kernel would have provided task scheduling and a pre-validated driver library, but it would also have cost the tight control over timing, memory layout, and power consumption that a battery-powered safety device lives or dies by.

Approach

Every driver and peripheral abstraction was written from scratch against the silicon's low-level register interface, and the codebase was organised into three strictly separated layers. Drivers handle register-level access and nothing else. Modules compose those primitives into reusable, independently testable behaviours: the BLE stack, the IR sensor, the LED, the buzzer, the relay control line. The application layer — the only product-specific code in the system — holds the detection logic, the alarm state machine, the user interface, and the self-test orchestration. Those boundaries aren't a convention anyone can quietly bypass; they are enforced by the build system and reviewed at every change.

Result

The payoff is long-term maintainability: a change at the driver level is absorbed without touching safety logic, and a change in the alarm logic never propagates down into driver code.

2. BLE power optimisation through protocol redesign

Problem

Battery life was a primary commercial KPI rather than a finishing touch. Customers don't tolerate frequent battery changes in a ceiling-mounted safety device. The first implementation followed the conventional pattern: the sensor and control unit held a persistent BLE connection and exchanged link-layer keepalives at every connection interval. That is simple and low-latency, but for a device that sends a meaningful payload only occasionally, most of the energy budget ends up spent on maintaining the link rather than on moving data.

Approach

The redesign turned the asymmetry between the two devices into an advantage. The battery-powered sensor now stays disconnected by default, drawing near-zero radio energy, and starts advertising only when it actually has something to say — a status update, a heartbeat, or an alarm. The mains-powered control unit, which has energy to spare, scans continuously, picks up the advertisement, connects, pulls the message, and drops the link again. Connection intervals, slave latency, supervision timeouts, and advertising parameters were then tuned on top of that base.

Result

Most of the energy budget now goes to moving data rather than maintaining an idle link, extending battery life in a device where frequent battery changes are commercially unacceptable.

3. Architected validation framework for thermal detection classifier

Problem

The detection algorithm reads the heatmap from an 8×8 IR thermal array and classifies the scene as idle, normal cooking, or warning/alarm, carrying state across frames so it responds to sustained patterns rather than to a single transient spike. The algorithm itself was specified by the client's domain experts from years of field data on stove-fire behaviour; our work was to implement it in firmware, integrate it cleanly behind the IR module's interface, and validate it. Validation is where the real discipline sits, because staging genuine fire events under controlled conditions is demanding, costly, and not something that can be repeated at will.

Approach

The scenarios were captured once, in carefully instrumented test runs, and turned into a labelled measurement database — roughly a thousand normal-cooking sequences alongside a smaller set of real fire and warning events. A simulation harness then replays those recordings into the very same module interface the live sensor feeds, and checks each classification against its expected label.

Result

Regression-testing the classifier across hundreds of cases became a routine, automatable activity, with no need to re-stage costly live fire events.

4. Safety that fails loud, never silent

Problem

For a safety device, failing silently is worse than not being there at all: the user trusts that the unit on the ceiling is watching the stove, and a device that has quietly stopped working betrays that trust invisibly.

Approach

The firmware is built so the guarantee is structural rather than assumed. At boot, a power-on self-test exercises every peripheral the device depends on — the IR sensor, the radio, the battery monitor, the user-interface elements — and the device enters its monitoring state only if all of them pass; a failure is reported through coded LED and buzzer signals that identify the subsystem at fault. Because the product is expected to run for years between battery changes, a lighter periodic self-test repeats the critical checks every few hours during normal operation, without disturbing the device's monitoring duty. Unrecoverable faults move the device into a defined, externally visible fault state rather than a silent reset or an undefined condition. A heartbeat contract requires the sensor to announce its presence at a fixed interval; if that heartbeat is missed beyond tolerance, the control unit disconnects mains power to the stove.

Result

Continued operation has to be earned by continuous, verifiable proof that the safety chain is intact.

5. Authenticated mobile control

Problem

The mobile app covers the conventional ground for a connected home device — commissioning, configuration, status, and alerts — but the security boundary at the BLE interface is anything but routine for this product category. An arbitrary BLE-capable device in radio range must not be able to connect to the system, change its parameters, or interfere with its operation.

Approach

Only app instances that have been paired and authenticated are admitted; everything else is rejected at the protocol layer. The Nordic BLE security stack is combined with a custom application-level authentication procedure, designed explicitly against the threats that matter most for a connected safety device: unauthorised interception, data tampering, and rogue-device impersonation.

Result

Data integrity and user safety hold as primary design constraints enforced from the first line of the protocol, not as features layered on once the product worked.

The value, beyond the build

Strategic value

The biggest return here was continuity: a product line with two decades in the field was carried forward rather than quietly retired. Timing mattered just as much – by owning both firmware and hardware, needCode closed a gap the client couldn't have staffed in time and held the launch on schedule, avoiding the cost and delay of hiring into a specialized, hard-to-find skill set.

A 20-year product line carried forward instead of discontinued
Launch timeline protected against an unfillable hardware and hiring gap
Certification designed in from day one – late-stage work was documentation, not architectural rework

Technical value

The engineering value is what stays behind once the project closes. The architecture was built to survive change – portable across silicon revisions and product variants, so the next component swap doesn't force a rewrite – and the testing discipline keeps that foundation from quietly decaying over time.

Architecture portable across silicon revisions and product variants
Per-commit automated regression testing that stops the codebase from re-accumulating brittleness
Near-complete branch coverage on the critical paths, plus a reusable measurement-replay framework for ongoing algorithm regression

"The real value isn't just a device that works. It's what stays behind: a maintainable architecture, a fully tested codebase, and a certification-ready foundation. That's value the client keeps drawing on long after delivery"

Bartek Kling

CEO at needCode

Do you need Smart Innovations?

Book a free discovery call and let's unlock new possibilities

Final Thoughts

This project shows how needCode takes an end-of-life product and delivers a market-ready, certification-grade replacement – owning both firmware and hardware, and building value that outlasts the initial engagement. If you're modernizing a connected or safety-critical product, let's talk.

If you need a partner to drive your next innovation, we’re here to help. Let’s talk and explore how we can bring your vision to life.

#TurnIdeasIntoLife

Let’s talk.

Also interesting

Rebuilding a 400,000-unit safety product as a Certification-Ready BLE IoT System

$2,500 Per Acre Added Value: Creating a Scalable Prototype for Corn Pollination System

NeedCode-case study - IoT Solution for Boat Lift Modernization - cover2s

$1,640,652 Total Delivered Value: Developing an integrated IoT Solution

More case studies

We work with Industry Leaders

Let's work on your next project together

Book a demo and discovery call with our CEO to get a look at:

Strategic Expertise

End-to-End Solutions

Advanced Technology

Custom Hardware Devices

Bartek Kling / CEO

Book a discovery call

Partnerships

Qorvo Nordic Semiconductor UWB Alliance Creative Werks

Resources

Blog E-books About

Case studies Contact

From end-of-life to market-ready: rebuilding a 400,000-unit safety product as a Certification-Ready BLE IoT System

A two-decade-old stove-guard safety device – proprietary RF, assembler firmware, no mobile interface – rebuilt on bare-metal Nordic silicon as a modern, BLE-connected, EN 50615-ready system. Same install experience for the user; everything underneath replaced.

Executive Summary

Challenge:

Solution:

Do you need Smart Innovations?

Impact at a glance:

installed base modernized without forcing users to relearn how to install or operate the device

Battery-life KPI met

a commercial deal-breaker, solved through protocol-level redesign rather than hardware tuning alone

EN 50615 certification-ready

architecture built to pass independent accredited-lab testing across all mounting positions

Full-stack ownership

firmware and custom PCB delivered by one partner, closing a hardware gap on the client side

Zero silent failures

self-test built into the firmware so the device never claims a safety status it cannot guarantee

What we delivered

01

A future-proof firmware architectureThree explicit layers (drivers → modules → application) that absorb silicon and component changes without touching product logic — so the next part swap doesn't trigger another rebuild.

02

Battery life that meets specAn advertising-on-demand BLE model that keeps the battery-powered sensor near zero radio energy by default, shifting the cost of being "always listening" onto the mains-powered control unit.

03

A safety classifier validated at scale The fire-detection algorithm verified against a database of ~1,000 real cooking and fire sequences through simulation replay — reproducible coverage without re-staging dangerous events.

04

Certification-grade safety behavior Power-on and periodic self-tests plus defined fault states, so a degraded sensor signals failure instead of pretending to work.

Background & Challenges

How we did it

1. A maintainable firmware foundation

Problem

Approach

Result

2. BLE power optimisation through protocol redesign

Problem

Approach

Result

3. Architected validation framework for thermal detection classifier

Problem

Approach

Result

4. Safety that fails loud, never silent

Problem

Approach

Result

5. Authenticated mobile control

Problem

Approach

Result

The value, beyond the build

Strategic value

Technical value

Do you need Smart Innovations?

Final Thoughts

If you need a partner to drive your next innovation, we’re here to help. Let’s talk and explore how we can bring your vision to life.

Also interesting

We work with Industry Leaders

Let's work on your next project together

A future-proof firmware architecture
Three explicit layers (drivers → modules → application) that absorb silicon and component changes without touching product logic — so the next part swap doesn't trigger another rebuild.

Battery life that meets spec
An advertising-on-demand BLE model that keeps the battery-powered sensor near zero radio energy by default, shifting the cost of being "always listening" onto the mains-powered control unit.

A safety classifier validated at scale
The fire-detection algorithm verified against a database of ~1,000 real cooking and fire sequences through simulation replay — reproducible coverage without re-staging dangerous events.

Certification-grade safety behavior
Power-on and periodic self-tests plus defined fault states, so a degraded sensor signals failure instead of pretending to work.