KG Elektronik. 12.000 vernetzte Heizkessel. Über 1.000 Downloads. Umsetzung in 3 Monaten.

IoT-App zur Kesselsteuerung: wie Sie sie planen, wenn Sie Steuerungen herstellen

Dieser Text richtet sich an Hersteller von Steuerungen, Kesseln und anderen Heizgeräten, die eine eigene mobile App in Betracht ziehen. Er beantwortet die Frage, woraus eine IoT-App zur Kesselsteuerung besteht, welche technischen Entscheidungen am Anfang getroffen werden müssen und was Sie prüfen sollten, bevor die ersten Geräte zu Kunden gehen.

Aus Sicht des Nutzers wirkt eine IoT-App zur Kesselsteuerung einfach: Geräteliste, Temperatur, Zeitplan und eine Benachrichtigung, wenn etwas nicht stimmt. Darunter läuft jedoch ein System, das eine dauerhafte Verbindung zu Tausenden physischer Steuerungen in Häusern und Gebäuden halten muss. Ein Fehler in einem solchen System endet nicht mit einer falsch angezeigten Seite, sondern mit einer kalten Wohnung. Deshalb sollte das Projekt mit der Architektur beginnen, nicht mit den Screens.

Was eine IoT-App zur Kesselsteuerung können muss

Der Funktionsumfang ergibt sich daraus, wofür der Kunde bisher in den Heizungsraum gehen musste. Im oben beschriebenen Projekt für KG Elektronik war der Ausgangspunkt ein physisches Bedienfeld im Keller: Temperatur ändern, Zeitplan einstellen und prüfen, warum der Kessel ausgegangen ist, erforderte die Anwesenheit am Gerät.

• Geräteliste mit aktueller Temperatur und Verbindungsstatus, auch für mehrere Objekte in einem Konto.
• Temperatur und Zeitplan von überall ändern.
• Auslesen der Sensordaten in Echtzeit, mit einem Diagramm der letzten Stunden.
• Alarme mit vom Nutzer festgelegten Schwellenwerten und Push-Benachrichtigungen aufs Smartphone.
• Kopplung einer neuen Steuerung mit dem Nutzerkonto.

Eine eigene Zielgruppe sind Objektverwalter, also von Büros und Hallen. Für sie liegt der Wert in einer einzigen App statt mehrerer Systeme mit unterschiedlichen Panels. Das sollte vom ersten Tag an im Datenmodell berücksichtigt werden, denn die Unterstützung mehrerer Standorte nach dem Start nachzurüsten ist teuer.

Drei Systemebenen: App, Backend und Herstellerpanel

Der Endkunde sieht eine App. Der Hersteller sollte jedoch an drei Komponenten denken, von denen jede einen anderen Nutzer und andere Anforderungen hat.

Die mobile App lässt sich mit einer Codebasis für iOS und Android bauen. Bei KG Elektronik bedeutete das eine Codebase, zwei Stores und ein Team, das das Produkt betreut, was jedes weitere Update vereinfacht.

Kommunikation mit der Steuerung: MQTT und WLAN-Modul

Die wichtigste technische Entscheidung betrifft die Art, wie die Steuerung mit der Cloud kommuniziert. Im beschriebenen Projekt wurde MQTT eingesetzt, ein leichtgewichtiges Publish-Subscribe-Protokoll, das in IoT-Geräten weit verbreitet ist. Die Steuerung mit WLAN-Modul verbindet sich mit einem Broker im Backend, und die App erhält von ihm den aktuellen Gerätezustand.

Hat die Steuerung noch keine Konnektivität, gibt es drei Wege: ein WLAN-Modul im bestehenden Gerät nachrüsten, ein neues Kommunikationsmodul entwickeln oder mit einem Web-Dashboard als Übergangslösung starten. Die Wahl hängt vom Produktionsumfang ab und davon, wie viele Geräte bereits bei Kunden sind.

Sicherheit muss zusammen mit dem Protokoll geplant werden. In APP Smart Control hat jedes Gerät ein eigenes Zertifikat, und der Kunde authentifiziert sich über sein Konto in der App. So öffnet die Übernahme einer Steuerung keinen Zugriff auf die übrigen.

Fernsteuerung des Kessels und Sicherheit des Nutzers: Alarme und Diagnose

Die Fernsteuerung des Kessels an sich ist Komfort. Den echten Unterschied macht die Information, dass etwas von der Norm abweicht, bevor der Nutzer es selbst bemerkt. Eine Push-Benachrichtigung über einen Temperaturabfall sorgt dafür, dass der Kunde den Ausfall nicht an einem frostigen Sonntagabend entdeckt, wenn es im Haus kalt wird.

Auf Herstellerseite speist dieselbe Telemetrie ein Dashboard. Das Team sieht den gesamten Gerätepark, kann Probleme ohne Technikereinsatz diagnostizieren und hat die Infrastruktur für Remote-Updates der Steuerungssoftware. Diese Funktion schiebt man leicht auf, und später zeigt sich, dass ohne sie jede Firmware-Korrektur einen Besuch beim Kunden bedeutet.

Skalierung: von den ersten Geräten bis 12 000

Eine App, die auf dem Testtisch mit einigen Steuerungen funktioniert, muss das bei mehreren Tausend nicht tun. Deshalb gehören Lasttests mit wachsender Gerätezahl und erste End-to-End-Tests mit physischer Hardware in den Plan, nicht nur mit einem Simulator.

Die zweite Entscheidung betrifft den Broker. Ein Managed Service beim Cloud-Anbieter ist zum Start bequem, kann bei vielen Verbindungen aber teuer werden. Im beschriebenen Projekt senkte ein eigener Broker statt eines Managed Service die Infrastrukturkosten um etwa 70 % bei einer Größenordnung von über 12 Tausend Geräten. Bei einigen hundert Steuerungen kann diese Rechnung anders ausfallen, daher lohnt es sich, sie für Ihre eigene Absatzprognose durchzurechnen.

Verlockend ist oft die Strategie „schnelle erste Version, verbessern wir später“. In Projekten, die Hardware und Software verbinden, funktioniert sie selten. Ein stabiles MVP nach drei Monaten ist besser als ein schnelles Produkt, das beim tausendsten Gerät nicht mehr funktioniert.

Mobile App für Gerätehersteller: Implementierungsplan und Eigentum am Code

Bei KG Elektronik vergingen vom Briefing bis zur Veröffentlichung in Google Play und im App Store drei Monate. Die Arbeitsaufteilung sah so aus:

• Monat 1: Workshop, Erfassung der bestehenden Steuerungen und Protokolle, Architektur, Backend mit Broker, Datenbank und Autorisierung.
• Monat 2: mobile App mit Login, Gerätekopplung und Zeitplan, Benachrichtigungen, Integration von Steuerung und App, Tests mit physischer Hardware.
• Monat 3: Dashboard für das Team des Herstellers, Lasttests, Veröffentlichung in den Stores, Onboarding der ersten Kunden und Übergabe des Codes.

Klären Sie von Anfang an, wem Code und Infrastruktur gehören werden. Ein Hersteller, für den IoT nicht das Kerngeschäft ist, muss kein eigenes Team von null aufbauen. Er kann den Bau von App und Plattform beauftragen, den vollständigen Code behalten und die Wartung nach der Implementierung übernehmen, so wie es KG Elektronik getan hat.

Der Effekt zeigt sich nicht nur in Statistiken. Ein halbes Jahr nach dem Start fragten Kunden im Handel nach „dem mit WLAN“, und die Preise der Steuerungen blieben unverändert. Die App war kein Zusatz mehr, sondern wurde zum Verkaufsargument für das Gerät selbst.

Wann eine IoT-App nicht der beste erste Schritt ist

Nicht jeder Hersteller sollte mit einer vollständigen Plattform beginnen. Wenn es nur wenige Geräte gibt, in der Größenordnung von einigen hundert, die Hardware noch keine Konnektivität hat oder Entscheidungen im Unternehmen länger als drei Monate dauern, kann ein Web-Dashboard oder ein Produktkonfigurator der günstigere Weg zu einem ähnlichen Ergebnis sein. Ein gut durchgeführter Workshop zu Beginn sollte zeigen, welche Option sinnvoll ist.

Mehr darüber, wie wir die Verbindung von Hardware und Software angehen, finden Sie auf den Seiten IoT-Lösungen und mobile Anwendungen, und wenn Sie Ihre Steuerung besprechen möchten, schreiben Sie uns.