KG Elektronik. 12,000 connected boilers. 1,000+ downloads. A 3-month rollout.

IoT app for boiler control: how to plan it when you manufacture controllers

This article is for manufacturers of controllers, boilers, and other heating devices who are considering their own mobile app. It answers what an IoT app for boiler control consists of, which technical decisions need to be made at the outset, and what to check before the first devices reach customers.

From the user's perspective, an IoT app for boiler control looks simple: a list of devices, temperature, a schedule, and a notification when something is wrong. Underneath, though, runs a system that has to maintain a constant connection with thousands of physical controllers in homes and buildings. A failure in such a system doesn't end with a badly rendered page but with a cold apartment. That's why the project should start with the architecture, not the screens.

What an IoT app for boiler control needs to do

The feature scope comes from what customers previously had to go down to the boiler room for. In the KG Elektronik project described above, the starting point was a physical panel in the basement: changing the temperature, setting a schedule, and checking why the boiler went out all required being next to the device.

• A list of devices with the current temperature and connection status, including multiple sites on one account.
• Change the temperature and schedule from anywhere.
• Real-time sensor readings, with a chart of the last few hours.
• Alarms with user-defined thresholds and push notifications to the phone.
• Pairing a new controller with a user account.

A separate group of users is facility managers, i.e., of offices and warehouses. For them, the value is one app instead of several systems with different panels. It's worth building this into the data model from day one, because adding multi-location support after launch is expensive.

Three layers of the system: app, backend, and manufacturer panel

The end customer sees a single app. The manufacturer, however, should think in terms of three components, each with a different user and different requirements.

A mobile app can be built from a single codebase for iOS and Android. For KG Elektronik, this meant one codebase, two app stores, and one team maintaining the product, which simplifies every subsequent update.

Communication with the controller: MQTT and a WiFi module

The most important technical decision concerns how the controller talks to the cloud. The implementation described used MQTT, a lightweight publish-subscribe protocol widely used in IoT devices. The controller with a WiFi module connects to the broker in the backend, and the app receives the current device state from it.

If the controller doesn't have connectivity yet, there are three paths: adding a WiFi module to the existing device, designing a new communication module, or starting with a web dashboard as an interim solution. The choice depends on production volume and how many devices are already in customers' hands.

Security has to be planned together with the protocol. In APP Smart Control, each device has its own certificate, and the customer authenticates through their app account. As a result, compromising one controller doesn't open access to the others.

Remote boiler control and user safety: alerts and diagnostics

Controlling a boiler remotely is a convenience. The real change comes from being told something is off before the user notices it themselves. A push notification about a temperature drop means the customer doesn’t discover a failure on a freezing Sunday evening when the house is getting cold.

On the manufacturer's side, the same telemetry feeds a dashboard. The team sees the entire device fleet, can diagnose a problem without a technician visit, and has the infrastructure for remote controller firmware updates. It's a feature that is easy to postpone, and later it turns out that without it every firmware fix means a visit to the client.

Scaling: from the first devices to 12,000

An app that works on a test bench with a few controllers won't necessarily work with several thousand. That's why the plan should include load tests with a growing number of devices and early end-to-end tests with physical hardware, not just a simulator.

The second decision concerns the broker. A managed service from a cloud provider is convenient at the start but can be expensive with a large number of connections. In the implementation described, a self-hosted broker instead of a managed service cut infrastructure costs by about 70% at a scale of over 12,000 devices. With a few hundred controllers, the math may come out differently, so it’s worth running it against your own sales forecast.

The “ship a quick first version, fix it later” strategy can be tempting. In projects combining hardware and software, it rarely works. A stable MVP after three months is better than a fast product that stops working at the thousandth device.

A mobile app for a device manufacturer: implementation plan and code ownership

For KG Elektronik, it took three months from brief to publication on Google Play and the App Store. The work was divided as follows:

• Month 1: workshop, mapping of existing controllers and protocols, architecture, backend with broker, database, and authorization.
• Month 2: mobile app with login, device pairing, and scheduling, notifications, controller-app integration, testing with physical hardware.
• Month 3: dashboard for the manufacturer's team, load testing, app store publishing, onboarding of the first customers, and code handover.

It's worth agreeing from the start who will own the code and infrastructure. A manufacturer for whom IoT isn't the core business doesn't need to build its own team from scratch. It can outsource development of the app and platform, retain full code ownership, and take over maintenance after deployment, just as KG Elektronik did.

The impact shows up beyond the statistics. Six months after launch, customers in stores started asking for “the one with WiFi,” and controller prices didn’t change. The app stopped being an add-on and became a selling point for the device itself.

When an IoT app isn't the best first step

Not every manufacturer should start with a full platform. If there are few devices, in the hundreds, the hardware doesn't have connectivity yet, or decisions in the company take longer than three months, a web dashboard or a Product configurator may be a cheaper route to a similar result. A well-run kickoff workshop should show which option makes sense.

You can find more about how we approach connecting hardware with software on the pages IoT solutions and mobile apps, and if you’d like to discuss your controller, get in touch.