Gebäudeautomation mit MQTT: Wie MQTT neben BACnet und KNX passt

Eine MQTT-Schicht für die Gebäudeautomation ermöglicht es, Daten, die in BACnet-Controllern, KNX-Linien und Modbus-Zählern eingeschlossen sind, an einem zentralen Ort zu veröffentlichen, an dem Dashboards, Analyse- und Alarmierungswerkzeuge sie nutzen können. Dieser Leitfaden erklärt, wo MQTT in einer Gebäudeleittechnik (GLT) hingehört, was es ersetzen sollte und was nicht, und wie Sie Topics, Gateways und Sicherheit so gestalten, dass sich Dutzende Gebäude einen einzigen Broker teilen können.

Warum Gebäude überhaupt ein weiteres Protokoll brauchen

Die meisten Gewerbegebäude betreiben bereits ein ausgereiftes Feldprotokoll. BACnet dominiert bei Heizung, Lüftung, Klima und zentraler Anlagentechnik, KNX ist in Europa für Beleuchtung, Jalousien und Raumsteuerung verbreitet, und Modbus RTU oder TCP findet sich in Energiezählern, Kältemaschinen und Frequenzumrichtern. Diese Protokolle sind gut in dem, wofür sie entwickelt wurden: deterministische Steuerung in einem lokalen Netz, mit Objektmodellen, die HLK-Ingenieure verstehen.

Schlecht sind sie darin, das Gebäude zu verlassen. BACnet/IP setzt auf UDP-Broadcasts und geht von einem flachen, vertrauenswürdigen LAN aus. KNX/IP-Routing nutzt Multicast. Keines von beiden überwindet eine Firewall elegant, keines wurde für Tausende entfernte Subscriber entworfen, und sie ins Internet zu öffnen, ist ein bekannter Sicherheitsfehler. Facility-Teams, die einen Portfolio-Überblick über Energieverbrauch, Komfortbeschwerden oder Anlagenstörungen wollen, landen bei einer Bedienoberfläche pro Standort, jede mit eigenem Login und eigenem Exportformat.

MQTT schließt genau diese Lücke. Es ist ein schlankes Publish/Subscribe-Protokoll, bei dem jedes Gerät und jede Anwendung eine ausgehende TCP- oder TLS-Verbindung zu einem zentralen MQTT-Broker aufbaut. Gateways in jedem Gebäude übersetzen lokale Datenpunkte in Topics, und alles, was die Daten benötigt, abonniert sie, ohne zu wissen, wo das Gateway steht oder wie viele Standorte es gibt.

Wo MQTT in der Gebäudeautomation sitzt

Stellen Sie sich ein Gebäude in drei Ebenen vor:

1. Feldebene – Sensoren, Aktoren, VVS-Boxen, KNX-Taster, Zähler. Die Kommunikation läuft über BACnet MS/TP, KNX TP, Modbus RTU, DALI oder proprietäre Busse.
2. Automationsebene – Controller und Leitstationen, die Regelkreise, Zeitprogramme und Verriegelungen ausführen. Hier ist es weiterhin BACnet/IP, KNX/IP oder Modbus TCP.
3. Integrationsebene – der Ort, an dem Daten normalisiert und mit dem Rest der Organisation geteilt werden. Hier gehört MQTT hin.

Die wichtige Regel lautet: Regelkreise bleiben lokal. Ein PID-Regelkreis für die Zulufttemperatur muss weiterlaufen, wenn die Internetverbindung abbricht, also lebt er im Controller, nicht in der Cloud. MQTT transportiert Telemetrie nach oben und, mit Bedacht, Sollwertänderungen oder Zeitplan-Übersteuerungen nach unten. In der Praxis ist die MQTT-Schicht der Gebäudeautomation eine nordgerichtete Schnittstelle, kein Ersatz für das Feldnetz.

Rollen der Protokolle im Vergleich

Gateways: Aus Datenpunkten werden Topics

Jedes Gebäude braucht mindestens ein Gateway. Es liest Datenpunkte aus dem Feldprotokoll und veröffentlicht sie als MQTT-Nachrichten. Realistisch haben Sie drei Optionen:

• Integriertes MQTT im Controller oder in der Leitstation. Viele aktuelle GLT-Controller und Gebäudebetriebssysteme können direkt per MQTT veröffentlichen. Prüfen Sie, ob sie TLS und Authentifizierung mit Benutzername und Passwort unterstützen, bevor Sie sich darauf verlassen.
• Ein kleines Linux-Gateway. Ein Gerät der Raspberry-Pi-Klasse oder ein Industrie-PC mit einem Skript oder einem Node-RED-Flow. Unsere Tutorials zu BACnet zu MQTT und KNX zu MQTT zeigen vollständige Open-Source-Bridges.
• Ein kommerzielles Protokoll-Gateway. Sinnvoll, wenn Sie zertifiziertes BACnet-Verhalten benötigen oder Hunderte Datenpunkte pro Gerät haben.

Was Sie auch wählen: Das Gateway sollte lokal pollen oder abonnieren (BACnet-COV-Abonnements, KNX-Gruppentelegramme), Totbänder anwenden, damit der Broker nicht mit Rauschen überflutet wird, und JSON mit Zeitstempel, Wert, Einheit und Qualitätskennzeichen veröffentlichen.

{
  "ts": "2026-10-16T08:15:02Z",
  "value": 13.4,
  "unit": "degC",
  "quality": "good",
  "source": "bacnet:1201/analogInput:3"
}

Die ursprüngliche Objektreferenz in source mitzuführen, erleichtert die Fehlersuche erheblich, wenn jemand fragt, warum ein Dashboard-Wert von der GLT-Oberfläche abweicht.

Topics für mehrere Standorte entwerfen

Das Topic-Design ist die Entscheidung, mit der Sie am längsten leben werden. Eine Hierarchie nach physischem Standort funktioniert für Gebäude gut, weil Menschen in diesen Kategorien denken:

<org>/<site>/<building>/<floor>/<zone>/<equipment>/<point>
acme/ist01/tower-a/f12/zone-east/ahu-2/supply-air-temp
acme/ist01/tower-a/f12/zone-east/ahu-2/filter-dp
acme/ank02/hq/f03/meeting-301/occupancy/present

Das spiegelt die ISA-95-Gerätehierarchie aus Fabriken wider (Enterprise, Site, Area, Line, Cell), die in der Industrie die Grundlage eines Unified Namespace (UNS) bildet: Jede ISA-95-Ebene wird zu einer Topic-Ebene auf dem Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Im Gebäude treten Gebäude, Etage und Zone an die Stelle von Area, Line und Cell. Das ist relevant, weil ConnectMQ ISA-95- und UNS-Topic-Strukturen erkennt und Geräte in seiner Geräteansicht nach diesen Ebenen gruppiert anzeigen kann. Facility Manager können ein Portfolio dann nach Standort und Etage durchsuchen, statt flache Topic-Listen zu durchforsten. Betreibt dasselbe Unternehmen auch Produktionshallen, lassen sich Gebäude- und Maschinendaten so in einem gemeinsamen UNS zusammenführen, etwa für Energiemonitoring über Werk und Verwaltung hinweg.

Ein paar praktische Regeln:

• Verwenden Sie Kleinbuchstaben, Bindestriche statt Leerzeichen und keine Personennamen in Topics.
• Setzen Sie den Datenpunktnamen ans Ende, damit Wildcards nützlich bleiben: acme/+/+/+/+/+/supply-air-temp liefert jede Zulufttemperatur im Portfolio.
• Veröffentlichen Sie sich langsam ändernde Metadaten (Einheiten, Sollwerte, Anlagenmodell) als retained Nachrichten, damit neue Subscriber sofort den aktuellen Zustand kennen.
• Trennen Sie Befehle von Telemetrie, zum Beispiel .../ahu-2/cmd/setpoint gegenüber .../ahu-2/supply-air-temp, und lassen Sie nur autorisierte Clients auf Befehls-Topics veröffentlichen.

Wenn Sie bereits Industriestandorte betreiben, finden Sie dieselben Überlegungen in unserem Artikel zu Sparkplug B und dem Unified Namespace.

Sicher in das Gebäude zurückschreiben

Daten zu lesen, birgt wenig Risiko. Sollwerte aus der Cloud zu schreiben, schon. Bevor eine MQTT-Nachricht einen Wert in einem BACnet- oder KNX-Gerät ändern kann, bauen Sie Leitplanken in das Gateway ein:

1. Führen Sie eine explizite Allow-List schreibbarer Datenpunkte. Stellen Sie niemals ein generisches Topic „beliebiges Objekt schreiben“ bereit.
2. Prüfen Sie Wertebereiche im Gateway (zum Beispiel einen Zonensollwert zwischen 18 und 26 Grad Celsius).
3. Schreiben Sie bei BACnet mit einer festgelegten Priorität und geben Sie diese frei, wenn die Übersteuerung endet, damit lokale Zeitprogramme wieder übernehmen.
4. Spiegeln Sie den übernommenen Wert auf einem State-Topic zurück und protokollieren Sie, wer ihn angefordert hat.
5. Verwenden Sie QoS 1 für Befehle und gestalten Sie den Handler idempotent, denn eine QoS-1-Nachricht kann zweimal ankommen. Unser Leitfaden zu MQTT-QoS-Stufen erklärt, warum.

Viele Gebäude in einem Broker bündeln

Sobald jedes Gateway ausgehend veröffentlicht, wird die Zentralisierung eines Portfolios zur Hosting-Entscheidung. Sie können einen Broker im eigenen Rechenzentrum betreiben, tragen dann aber die Verantwortung für Patches, Zertifikate, Monitoring und Kapazitätsplanung eines Systems, von dem Facility-Teams erwarten, dass es rund um die Uhr läuft.

Ein verwalteter MQTT-Broker nimmt Ihnen diese Arbeit ab. Mit ConnectMQ verbindet sich jedes Gebäude-Gateway mit eigenen generierten Zugangsdaten über TLS auf Port 8883 mit demselben Broker, und das Portal bietet einen Live-Topic-Explorer, um zu prüfen, was jeder Standort veröffentlicht. Regeln für Schwellenwertalarme können Zustände wie eine dauerhaft außerhalb des Bereichs liegende Zulufttemperatur melden, und das Alarmprotokoll hält fest, wann sie ausgelöst wurden. Dashboards, Node-RED-Flows, Telegraf-Collectors oder Python-Dienste, die in Ihre Datenbank schreiben, verbinden sich als gewöhnliche MQTT-Clients und abonnieren mit Wildcards.

Checkliste zur Dimensionierung

1. Zählen Sie Gateways pro Standort plus jede konsumierende Anwendung; jede ist eine Verbindung.
2. Schätzen Sie Nachrichten pro Sekunde nach Anwendung der Totbänder, nicht die rohen Polling-Raten.
3. Prüfen Sie die größte benötigte Nachricht (ein vollständiger Anlagen-Snapshot kann größer sein als ein einzelner Datenpunkt).
4. Entscheiden Sie, ob Sie QoS 2 oder Shared Subscriptions für lastverteilte Verbraucher benötigen.
5. Planen Sie die Isolation: Ein Portfolio mit strikter Mandantentrennung kann einen Dedicated-Cluster rechtfertigen.

Kleine Pilotprojekte passen in den kostenlosen Serverless-Tarif (bis zu 25 Verbindungen, QoS 0 und 1, Nachrichten bis 256 KB). Größere Portfolios wechseln zur kostenpflichtigen Serverless-Stufe (bis zu 1.000 Verbindungen, QoS 2, Shared Subscriptions) oder zu einem Dedicated-Cluster.

Gebäudespezifische Sicherheitsaspekte

Gebäudenetze sind häufig flach, alt und werden mit Dienstleistern geteilt. MQTT hilft, weil Gateways nur ausgehende Verbindungen benötigen, sodass Sie nie eingehende Firewall-Ports für BACnet oder KNX öffnen. Darüber hinaus gilt:

• Verwenden Sie immer TLS (Port 8883 oder 8084 für Dashboards über sicheren WebSocket).
• Geben Sie jedem Gateway eigene Zugangsdaten, damit ein kompromittiertes Gerät gesperrt werden kann, ohne andere zu berühren. ConnectMQ bindet Client-IDs an ausgestellte Zugangsdaten und sperrt IPs nach wiederholten fehlgeschlagenen Anmeldungen.
• Betreiben Sie das Gateway in einem vom Feldnetz getrennten VLAN, nur mit den Ports, die es benötigt.
• Veröffentlichen Sie niemals personenbezogene Daten wie Ausweis-IDs auf Topics, die viele Anwendungen lesen können.

Die umfassendere Checkliste in Best Practices für MQTT-Sicherheit gilt für Gebäude ebenso wie für Fabriken.

Ein realistischer Rollout-Plan

Beginnen Sie mit einem Gebäude und einer kleinen Auswahl wertvoller Datenpunkte: Zu- und Ablufttemperaturen, Filterdifferenzdruck, Hauptenergiezähler und einige Zonentemperaturen. Veröffentlichen Sie sie nur dann auf dem öffentlichen MQTT-Broker, wenn die Daten nicht sensibel sind und Sie lediglich Payloads testen wollen, denn er ist für Tests und Prototypen gedacht, nicht für Produktionsdaten; wechseln Sie zu einem privaten Broker, sobald echte Adressen oder Belegungsdaten im Spiel sind. Ergänzen Sie als Nächstes die Alarmierung, dann Dashboards, dann einen zweiten Standort. Spätestens beim dritten Gebäude wissen Sie, ob Ihr Topic-Schema skaliert. Weitere Anwendungsfälle finden Sie in unserem Leitfaden zur IoT-Automatisierung, konkrete Anwendungen im Beitrag HLK-Überwachung mit IoT-Sensoren.

Verbinden Sie Ihre Gebäude mit ConnectMQ

Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte. Sie erhalten in wenigen Minuten Benutzername, Passwort und Client-ID für Ihr erstes Gateway, und der Topic-Explorer zeigt Ihre Gebäudedaten, sobald sie eintreffen. Wenn das Portfolio wächst, wechseln Sie den Tarif, ohne Ihr Topic-Design zu ändern.

Häufig gestellte Fragen

Ersetzt MQTT BACnet in der Gebäudeautomation?

Nein. BACnet und KNX bleiben die Steuerungsnetze im Gebäude. MQTT ist die Integrationsschicht, die ausgewählte Datenpunkte zu Dashboards, Analysen und anderen Standorten transportiert.

Kann ich HLK-Anlagen über MQTT steuern?

Ja, über ein Gateway, das in den Controller schreibt. Beschränken Sie es jedoch auf eine Allow-List von Datenpunkten, prüfen Sie Wertebereiche und halten Sie Regelkreise lokal, damit das Gebäude weiterfunktioniert, wenn die Verbindung abbricht.

Welche QoS sollte Gebäudetelemetrie verwenden?

QoS 0 genügt für häufige Messwerte, bei denen der nächste Wert bald folgt. Verwenden Sie QoS 1 für Alarme und Befehle und gestalten Sie Befehls-Handler idempotent.

Wie viele Verbindungen braucht ein Gebäude?

In der Regel eine pro Gateway plus eine pro konsumierender Anwendung. Ein typisches Pilotgebäude mit einem Gateway und einem Dashboard benötigt nur eine Handvoll Verbindungen.