KNX und MQTT: Gebäudedaten für Dashboards und Cloud

Wer KNX-Daten in ein Dashboard, eine Energieplattform oder einen Cloud-Dienst bringen will, stösst früh auf MQTT. Das Protokoll ist leichtgewichtig, weit verbreitet und in nahezu jeder IoT-Plattform verfügbar. Genau deshalb wird es oft schnell eingesetzt, ohne dass vorher geklärt ist, welche Daten in welcher Struktur fliessen sollen, wer schreiben darf und wie die Verbindung abgesichert ist.

Dieser Beitrag zeigt, wie MQTT technisch funktioniert, was beim Übergang von KNX zu MQTT schiefgehen kann und worauf es bei einer sauberen Integration ankommt. Wir gehen dabei auf Broker-Architektur, Topic-Konventionen, Quality of Service, Sicherheit und die Frage ein, ob und wann Schreibzugriffe aus der Cloud auf KNX-Geräte vertretbar sind. Am Ende grenzen wir MQTT von BACnet ab, denn beide Protokolle lösen verwandte, aber unterschiedliche Aufgaben.

Was MQTT ist und was es nicht ist

MQTT steht für Message Queuing Telemetry Transport. Das Protokoll wurde ursprünglich für ressourcenschwache Geräte und unzuverlässige Netzwerke entwickelt und ist heute als ISO/IEC 20922 (MQTT 3.1.1) normiert. Die aktuelle Version 5.0 ist als OASIS-Standard veröffentlicht und bringt zusätzliche Funktionen wie Nachrichteneigenschaften, Reason Codes und verbesserte Fehlerbehandlung.

MQTT arbeitet nach dem Publish-Subscribe-Prinzip. Ein Client veröffentlicht eine Nachricht zu einem bestimmten Topic, ein anderer Client abonniert dieses Topic und empfängt die Nachricht. Dazwischen steht der Broker, der die Nachrichten entgegennimmt, verteilt und bei Bedarf zwischenspeichert. Publisher und Subscriber kennen sich nicht direkt, sie kommunizieren ausschliesslich über den Broker.

Was MQTT nicht mitbringt: ein einheitliches Datenmodell, eine verbindliche Topic-Struktur, eine Zugriffskontrolle auf Datenpunktebene oder eine semantische Beschreibung der Inhalte. All das muss die Anwendung selbst definieren. Genau hier liegt die grösste Gefahr bei schnellen Integrationen: MQTT ist so flexibel, dass ohne Vorgaben schnell ein Datenwildwuchs entsteht, der sich im Betrieb kaum noch beherrschen lässt.

Der Broker als zentrales Element

Der MQTT-Broker ist das Herzstück jeder MQTT-Architektur. Er nimmt Nachrichten von Publishern entgegen, verwaltet Abonnements und stellt sicher, dass Nachrichten die richtigen Subscriber erreichen. In Gebäudeintegrationsprojekten gibt es grundsätzlich zwei Varianten: einen Broker im lokalen Netz des Gebäudes oder einen Broker in der Cloud.

Ein lokaler Broker hat den Vorteil, dass er unabhängig von der Internetverbindung funktioniert. Fällt die Cloud-Anbindung aus, läuft die lokale Kommunikation weiter. Für Anwendungen, bei denen die Daten nur zur Visualisierung oder zum Monitoring genutzt werden, ist das oft ausreichend. Cloud-Broker bieten dagegen einfachere Skalierung und Integration mit weiteren Diensten, erfordern aber eine stabile und gesicherte Verbindung sowie eine sorgfältige Datenschutzbetrachtung.

In der Praxis sehen wir häufig hybride Architekturen: Ein lokaler Broker sammelt die Gebäudedaten, ein Bridge-Mechanismus leitet ausgewählte Topics an einen Cloud-Broker weiter. So bleibt die lokale Funktion erhalten, und nur die Daten, die tatsächlich in der Cloud benötigt werden, verlassen das Gebäudenetz. Welche Daten das sind, sollte vor der Implementierung schriftlich festgelegt sein, nicht nachträglich.

Topic-Struktur: das Fundament der Ordnung

Ein MQTT-Topic ist eine Zeichenkette, die mit Schrägstrichen in Ebenen gegliedert wird. MQTT schreibt keine bestimmte Struktur vor. Das bedeutet: Ohne Konvention entstehen Topics wie «sensor/42», «building/floor3/room12/temp» oder «knx/1.1.10/value» nebeneinander, je nachdem, wer den Gateway konfiguriert hat.

Für eine wartbare Integration empfehlen wir eine hierarchische Topic-Struktur, die mindestens folgende Ebenen enthält: Liegenschaft oder Standort, Gebäude, Stockwerk oder Zone, Raum oder Anlage, Datenpunkt und Richtung (Status oder Befehl). Eine solche Struktur könnte beispielhaft so aussehen: «liegenschaften/gebaeude-a/eg/buero-101/temperatur/status». Die genaue Benennung ist weniger wichtig als die Konsequenz, mit der sie durchgehalten wird.

Besonders wichtig ist die Trennung zwischen Status-Topics und Befehls-Topics. Status-Topics transportieren Istwerte, die der KNX-Bus meldet. Befehls-Topics nehmen Sollwerte oder Schaltbefehle entgegen, die auf den Bus geschrieben werden sollen. Diese Trennung macht im Topic-Baum sofort sichtbar, wo Lesezugriff und wo Schreibzugriff stattfindet, und erleichtert die Zugriffskontrolle erheblich.

Wer mehrere Gebäude oder Liegenschaften über denselben Broker verwaltet, sollte die Standortebene konsequent als erste Ebene einsetzen. Wildcard-Abonnements mit «#» oder «+» funktionieren dann nur innerhalb des eigenen Bereichs, wenn die Zugriffsrechte entsprechend konfiguriert sind.

Quality of Service: was QoS wirklich bedeutet

MQTT kennt drei Stufen der Zustellgarantie, die als Quality of Service bezeichnet werden.

QoS 0 bedeutet: Die Nachricht wird einmal gesendet, ohne Bestätigung. Geht sie verloren, ist sie weg. Das ist akzeptabel für häufig aktualisierte Messwerte wie Temperaturen oder Helligkeitswerte, bei denen der nächste Wert ohnehin bald folgt.

QoS 1 garantiert, dass die Nachricht mindestens einmal ankommt. Der Broker bestätigt den Empfang, und der Publisher sendet erneut, wenn keine Bestätigung eintrifft. Das kann dazu führen, dass eine Nachricht mehrfach zugestellt wird. Für Schaltbefehle ist das problematisch: Ein Befehl, der zweimal ausgeführt wird, kann das Gegenteil des Gewünschten bewirken.

QoS 2 garantiert genau eine Zustellung. Das erfordert einen vierstufigen Handshake und erzeugt mehr Netzwerklast. Für kritische Steuerbefehle ist QoS 2 die richtige Wahl, sofern der Einsatz von Schreibzugriffen überhaupt vertretbar ist.

In der Praxis empfehlen wir für reine Monitoring-Anwendungen QoS 0 oder QoS 1, je nach Wichtigkeit der Daten. Für Schreibzugriffe auf Gebäudetechnik sollte QoS 2 verwendet werden, und zwar zusammen mit einer Logik, die doppelte Ausführungen erkennt und verhindert. Allein auf QoS zu vertrauen, reicht nicht.

Dazu kommt das Retained-Message-Konzept: Ein Broker kann die letzte Nachricht zu einem Topic speichern und neuen Subscribern sofort zustellen. Das ist nützlich für Statuswerte, die sich selten ändern, zum Beispiel Betriebsmodi oder Sollwerte. Für Schaltbefehle ist Retained dagegen gefährlich, weil ein neu verbundener Client einen alten Befehl erneut ausführen könnte.

Sicherheit: TLS, Authentifizierung und Autorisierung

MQTT selbst definiert keine Sicherheitsmechanismen auf Protokollebene. Die Absicherung liegt vollständig bei der Infrastruktur und der Konfiguration. Das ist ein wesentlicher Unterschied zu KNX Secure, das Sicherheit auf Anwendungsebene mit AES-128 im CCM-Modus direkt im Protokoll verankert. Wer KNX-Daten über MQTT weitergibt, muss die Sicherheit also auf der MQTT-Seite explizit einrichten.

Die Transportverschlüsselung erfolgt über TLS. Ohne TLS werden alle Nachrichten, einschliesslich Zugangsdaten, im Klartext übertragen. Das ist in einem abgeschlossenen lokalen Netz möglicherweise tolerierbar, sobald aber Daten das Gebäudenetz verlassen, ist TLS Pflicht. Zertifikate müssen verwaltet und rechtzeitig erneuert werden, das ist eine Betriebsaufgabe, die oft unterschätzt wird.

Die Authentifizierung von Clients erfolgt bei MQTT 3.1.1 über Benutzername und Passwort im CONNECT-Paket. MQTT 5.0 erweitert das um Enhanced Authentication mit Challenge-Response-Mechanismen. Zertifikatsbasierte Client-Authentifizierung über TLS ist ebenfalls möglich und für produktive Umgebungen empfehlenswert.

Die Autorisierung, also wer welche Topics lesen oder beschreiben darf, ist nicht Teil des MQTT-Protokolls. Sie muss im Broker konfiguriert werden. Gängige Broker wie Mosquitto oder HiveMQ bieten ACL-Mechanismen (Access Control Lists), mit denen sich Topic-Berechtigungen pro Client oder Clientgruppe festlegen lassen. Ohne diese Konfiguration kann jeder authentifizierte Client alle Topics lesen und beschreiben, was in einer Gebäudeintegration inakzeptabel ist.

Wir empfehlen, die Zugriffsrechte nach dem Prinzip der minimalen Berechtigung zu vergeben: Jeder Client erhält nur Zugriff auf die Topics, die er tatsächlich benötigt. Dashboard-Clients lesen Status-Topics, schreiben aber nicht. Nur explizit freigegebene Clients dürfen Befehls-Topics beschreiben. Diese Trennung sollte dokumentiert und regelmässig überprüft werden.

Nur lesend oder auch schreibend: eine Grundsatzfrage

Die Frage, ob MQTT nur zur Datenerfassung oder auch zur Steuerung genutzt werden soll, ist keine technische, sondern eine betriebliche und sicherheitstechnische Grundsatzentscheidung. Sie sollte vor der Implementierung getroffen und schriftlich festgehalten werden.

Rein lesende Integrationen sind vergleichsweise unkritisch. Der KNX-Gateway liest Gruppentelegrammwerte vom Bus und veröffentlicht sie als MQTT-Nachrichten. Dashboards, Energieplattformen und Reporting-Tools abonnieren diese Topics und zeigen die Daten an. Selbst wenn der MQTT-Broker kompromittiert wird, kann kein Angreifer Gebäudefunktionen auslösen.

Schreibende Integrationen sind eine andere Kategorie. Wenn ein Cloud-Dienst oder ein Dashboard-Nutzer über MQTT einen Befehl senden kann, der über den Gateway auf den KNX-Bus geschrieben wird, entsteht ein direkter Steuerungspfad aus dem Internet in die Gebäudetechnik. Das erfordert eine vollständige Sicherheitsbetrachtung: Wer darf steuern? Welche Datenpunkte sind freigegeben? Wie wird verhindert, dass ein kompromittierter Cloud-Account Heizung, Lüftung oder Zutrittssysteme beeinflusst?

In unserer Erfahrung ist es sinnvoll, Schreibzugriffe aus der Cloud auf ein klar definiertes, minimales Set von Datenpunkten zu beschränken, zum Beispiel Sollwertverschiebungen innerhalb enger Grenzen oder Betriebsmodusumschaltungen. Sicherheitsrelevante Funktionen wie Zugang, Brandschutz oder Notfallsysteme dürfen über diesen Pfad grundsätzlich nicht erreichbar sein. Und jeder Schreibzugriff sollte protokolliert werden, damit im Ereignisfall nachvollziehbar ist, was wann von wo ausgelöst wurde.

Semantische Modelle: Brick und Haystack

MQTT transportiert Nachrichten, beschreibt aber nicht, was die Daten bedeuten. Ein Topic wie «gebaeude-a/eg/101/temp/status» mit dem Wert «21.4» sagt einem Menschen viel, einer Maschine wenig. Welche Einheit? Welcher Sensor? Welcher Raum nach welchem Raumkonzept? Für einfache Dashboards reicht das oft aus. Für Energieplattformen, die Daten aus verschiedenen Gebäuden und Systemen zusammenführen, oder für Proptech-Anwendungen, die automatisiert auswerten, braucht es mehr.

Hier kommen semantische Modelle ins Spiel. Brick Schema und Project Haystack sind zwei verbreitete Ansätze, um Gebäudedaten maschinenlesbar zu beschreiben. Beide definieren Konzepte wie Raum, Zone, Anlage, Sensor und Datenpunkt und setzen sie in Beziehung zueinander. Ein Temperatursensor wird nicht nur als Wert, sondern als «Raumtemperatursensor im Büro 101 im Erdgeschoss von Gebäude A» beschrieben.

Diese Modelle sind kein Bestandteil von MQTT, sie ergänzen es. Die Metadaten werden typischerweise separat gepflegt, zum Beispiel in einer Datenbank oder einem digitalen Zwilling, und mit den MQTT-Topics verknüpft. Der Aufwand für diese Verknüpfung ist nicht gering, aber er zahlt sich aus, sobald mehrere Systeme oder Gebäude zusammengeführt werden sollen.

Wir empfehlen, das Thema semantische Modellierung bereits in der Konzeptphase anzusprechen, auch wenn es zunächst nur um ein einzelnes Gebäude geht. Eine nachträgliche Modellierung ist aufwendiger und führt häufig zu Inkonsistenzen, weil Topic-Strukturen und Benennungen dann nicht mehr angepasst werden können, ohne bestehende Abonnenten zu stören.

MQTT und BACnet: zwei Protokolle für unterschiedliche Aufgaben

Eine Frage, die uns in Projekten regelmässig begegnet: Brauchen wir MQTT oder BACnet? Die Antwort ist meistens: beides, für unterschiedliche Zwecke.

BACnet ist ein Leittechnikprotokoll, das für die Gebäudeautomation entwickelt wurde. Es kennt Objekte, Eigenschaften, Alarme, Trends und Zeitprogramme. Es bringt ein definiertes Datenmodell mit, unterstützt Polling und Change-of-Value-Meldungen und ist in der SN EN ISO 16484-5 (SIA 386.155) normiert. BACnet eignet sich für die Kommunikation zwischen Automationsstationen, Reglern und der Gebäudeleittechnik, also für den Betrieb der Anlage selbst.

MQTT ist ein Nachrichtenprotokoll, das für die Weiterleitung von Daten an übergeordnete Systeme, Dashboards und Cloud-Dienste optimiert ist. Es ist leichtgewichtig, skaliert gut und ist in IT-Plattformen weit verbreitet. Es bringt kein eigenes Datenmodell mit und ist für den direkten Anlagenbetrieb weniger geeignet.

In einer typischen Architektur kommuniziert KNX über einen Gateway mit einem MQTT-Broker, der die Daten an Dashboards und Energieplattformen weitergibt. Gleichzeitig kann KNX über einen anderen Gateway mit einem BACnet-Netz verbunden sein, das die Gebäudeleittechnik bedient. Beide Pfade haben ihre Berechtigung, und sie sollten nicht vermischt werden. Wer BACnet als Leittechnikprotokoll einsetzt, findet dazu mehr im Beitrag «KNX und BACnet: Raumautomation an die Gebäudeleittechnik», Teil 4 dieser Serie.

Der KNX-MQTT-Gateway: wo die Übersetzung stattfindet

Zwischen dem KNX-Bus und dem MQTT-Broker steht ein Gateway, der Gruppentelegrammwerte liest, in MQTT-Nachrichten umwandelt und veröffentlicht. Im Schreibfall nimmt er MQTT-Nachrichten entgegen und schreibt die entsprechenden Werte auf den Bus.

Dieser Gateway ist eine kritische Komponente. Er muss wissen, welche Gruppenadressen welchen Topics entsprechen, welche Datenpunkttypen (DPT) zu verwenden sind und in welche Richtung der Datenfluss erlaubt ist. Eine saubere Gruppenadressstruktur und eine vollständige Datenpunktliste sind deshalb Voraussetzung für eine funktionierende MQTT-Integration. Wer die Grundlagen der Gruppenadressierung vertiefen möchte, findet dazu mehr in Teil 3 der Serie «KNX richtig planen» mit dem Titel «Gruppenadressen und Namenskonvention als Fundament» sowie in Teil 5 der Serie «KNX Grundlagen: die Schulungsreihe» mit dem Titel «Gruppenadressen: So sprechen KNX-Geräte miteinander».

Die Konfiguration des Gateways sollte versioniert und dokumentiert sein. Änderungen an der KNX-Anlage, zum Beispiel neue Gruppenadressen oder geänderte DPT, müssen im Gateway nachgeführt werden, sonst entstehen stille Fehler: Der Wert wird übertragen, aber falsch interpretiert. Ein Temperaturwert, der als Prozentwert gelesen wird, erscheint im Dashboard als plausible Zahl, ist aber schlicht falsch.

Wir empfehlen ausserdem, im Gateway eine Filterlogik zu implementieren, die nur Änderungen sendet, die einen definierten Schwellenwert überschreiten, und die Sendefrequenz begrenzt. Ein KNX-Bus kann viele Telegramme pro Sekunde erzeugen. Nicht jede Änderung muss sofort als MQTT-Nachricht weitergeleitet werden. Eine sinnvolle Filterung reduziert die Broker-Last und verbessert die Datenqualität im Dashboard.

Der rote Faden zu unseren Fachbeiträgen

Wer die Grundlagen der KNX-Gruppenadressierung noch einmal vertiefen möchte, findet diese in Teil 3 der Serie «KNX richtig planen» mit dem Titel «Gruppenadressen und Namenskonvention als Fundament». Die Absicherung des KNX-Busses selbst, also KNX Data Secure und KNX IP Secure, behandelt Teil 4 derselben Serie: «KNX Secure im Projekt: Data Secure und IP Secure». Wer verstehen will, wie KNX-Daten über BACnet an die Gebäudeleittechnik übergeben werden, findet das in Teil 4 dieser Serie: «KNX und BACnet: Raumautomation an die Gebäudeleittechnik». Den Abschluss der Serie «Schnittstellen rund um KNX» bildet Teil 6: «Wer mappt was? Schnittstellenliste und Verantwortung», der die Frage klärt, wer in einem Projekt für welche Schnittstelle verantwortlich ist.

Für den Kontext der übergeordneten Gebäudeautomation empfehlen wir den Beitrag «GA verstehen, Teil 1: Was ist Gebäudeautomation, und was nicht?» sowie «Energiemonitoring: mehr als Zählerablesung, was man wirklich ablesen sollte», der zeigt, welche Daten im Monitoring tatsächlich relevant sind und wie sie interpretiert werden. Wer MQTT im Zusammenhang mit Energiemonitoring und Betriebsoptimierung einsetzen will, findet in «Betriebsoptimierung dokumentieren: So wird der Nachweis prüfsicher» weitere Hinweise zur Datenqualität und Nachvollziehbarkeit.

Fazit

MQTT ist ein leistungsfähiges und flexibles Protokoll, das sich gut eignet, um KNX-Daten an Dashboards, Energieplattformen und Cloud-Dienste weiterzugeben. Seine Stärke, die Einfachheit und Offenheit, ist gleichzeitig seine grösste Schwäche: Ohne Topic-Konvention, Datenmodell, Zugriffssteuerung und Sicherheitskonzept entsteht schnell ein Datenwildwuchs, der im Betrieb kaum noch beherrschbar ist.

Die wichtigsten Punkte aus unserer Erfahrung: Eine hierarchische Topic-Struktur mit klarer Trennung von Status und Befehl ist Pflicht, nicht Option. TLS und Client-Authentifizierung sind keine Extras, sondern Grundvoraussetzung, sobald Daten das lokale Netz verlassen. Schreibzugriffe aus der Cloud auf KNX-Datenpunkte erfordern eine explizite Entscheidung, eine enge Begrenzung auf freigegebene Datenpunkte und eine lückenlose Protokollierung. Und MQTT ersetzt BACnet nicht, sondern ergänzt es für andere Anwendungsfälle.

Wer diese Grundlagen von Anfang an berücksichtigt, schafft eine Integration, die wartbar bleibt, auch wenn Systeme, Nutzer oder Anforderungen sich ändern.

Sie haben Fragen dazu?

Sie planen eine MQTT-Integration für Ihre KNX-Anlage oder möchten bestehende Datenflüsse strukturieren und absichern? Wir unterstützen Sie bei der Konzeption, der Gateway-Konfiguration und der Dokumentation. Nehmen Sie Kontakt auf über wenget.ch oder info@wenget.ch.

Quellenverzeichnis

• OASIS MQTT Version 5.0, OASIS Standard, März 2019 (oasis-open.org)
• ISO/IEC 20922:2016: Information technology, Message Queuing Telemetry Transport (MQTT) v3.1.1
• EN 50090 / ISO/IEC 14543-3: Home and Building Electronic Systems (HBES), KNX-Standard; Markeninhaberin: KNX Association, Brüssel (knx.org)
• SN EN ISO 16484-5 (SIA 386.155): Datenkommunikationsprotokoll BACnet
• SN EN ISO 52120-1 (SIA 386.111): Energieeffizienz von Gebäuden, Beitrag der Gebäudeautomation
• Brick Schema: brickschema.org (semantisches Gebäudedatenmodell)
• Project Haystack: project-haystack.org (semantisches Tagging-Modell für Gebäudedaten)
• Eigene Projekterfahrung der WENGET GmbH aus KNX-Planung, GA-Integration und Schnittstellenprojekten