HLK-Überwachung mit IoT-Sensoren und MQTT-Alarmen

Die HLK-Überwachung mit IoT-Sensoren verschafft Ihnen einen kontinuierlichen Einblick, wie sich Lüftungsgeräte, Gebläsekonvektoren und Dachgeräte tatsächlich verhalten, nicht nur, ob sie eingeschaltet sind. Dieser Anwendungsfall zeigt, welche Messungen die häufigsten Störungen erfassen, wie Sie sie per MQTT veröffentlichen und wie Sie daraus mit einem Cloud-Broker Alarme und Laufzeitberichte machen.

Was in HLK-Anlagen schiefgeht

Die meisten HLK-Probleme kündigen sich nicht mit einem Alarm an. Sie zeigen sich als langsame Abweichungen: Ein Filter setzt sich zu und der Luftstrom sinkt, ein Ventil klemmt und die Leistung des Registers fällt ab, ein Verdichter taktet wegen eines ungünstig platzierten Thermostats, oder ein Gerät läuft das ganze Wochenende, weil ein Zeitprogramm übersteuert und nie zurückgesetzt wurde. Die Nutzer bemerken es erst, wenn der Komfort leidet, und bis dahin wurde wochenlang Energie verschwendet.

Eine Gebäudeleittechnik kann einiges davon erkennen, doch viele Standorte haben gar keine GLT oder eine, auf die nur ein Dienstleister Zugriff hat. Ein paar nachgerüstete IoT-Sensoren, die an MQTT veröffentlichen, schließen die Lücke schnell und funktionieren im gesamten Portfolio gleich, ob es sich um ein Kompaktdachgerät in einer Filiale oder ein Lüftungsgerät in einem Bürohochhaus handelt.

Die Signale, auf die es ankommt

Sie brauchen keine Dutzende Datenpunkte pro Gerät. Die folgenden Messungen decken den Großteil der praktischen Fehlererkennung ab:

Der nützlichste abgeleitete Wert ist Delta-T, die Differenz zwischen Abluft- und Zulufttemperatur. Läuft ein Kühlgerät mit sehr kleinem Delta-T, erhält entweder das Register kein Kaltwasser oder Kältemittel, der Luftstrom ist viel zu hoch oder ein Sensor sitzt an der falschen Stelle. Ein Filterdruck, der über Wochen stetig steigt, ist normal; einer, der plötzlich gegen null fällt, bedeutet, dass der Filter zusammengebrochen ist oder fehlt.

Architektur

Es gibt zwei gängige Wege, diese Signale zu MQTT zu bringen:

1. Vorhandene Controller. Haben die Geräte bereits BACnet-Controller, liest ein Gateway die Datenpunkte und veröffentlicht sie, wie in unserem Tutorial BACnet zu MQTT gezeigt.
2. Nachgerüstete Sensorknoten. Ein ESP32 oder ein kleines industrielles IoT-Modul pro Gerät liest die Fühler direkt aus und veröffentlicht über WLAN oder Ethernet. Das ESP32-MQTT-Tutorial behandelt die Grundlagen der Verbindung.

In beiden Fällen veröffentlicht der Knoten ausgehend an einen Broker, und jeder Verbraucher abonniert: der Topic-Explorer des Portals für die Inbetriebnahme, ein Analyseskript für abgeleitete Werte und ein Dashboard für das Facility-Personal. Die Topic-Struktur folgt der Gebäudehierarchie, ähnlich wie ein Unified Namespace (UNS) in der Fabrik die ISA-95-Ebenen Enterprise, Site, Area, Line und Cell abbildet. Sitzen die Lüftungsgeräte in Produktionshallen, hängen Sie sie am besten direkt in den UNS des Werks ein, etwa unter acme/werk-stuttgart/halle-2/lueftung/ahu-2/telemetry, damit HLK- und Maschinendaten gemeinsam ins Energiemonitoring einfließen:

acme/ist01/tower-a/roof/ahu-2/telemetry
acme/ist01/tower-a/roof/ahu-2/derived
acme/ist01/tower-a/roof/ahu-2/status

Eine einzige Telemetrienachricht pro Intervall hält den Datenverkehr gering und erleichtert die zeitliche Zuordnung:

{
  "ts": "2026-10-16T10:30:00Z",
  "supply_c": 13.6,
  "return_c": 23.1,
  "outdoor_c": 27.4,
  "filter_dp_pa": 182,
  "fan_a": 6.8,
  "comp_a": 14.2,
  "mode": "cooling"
}

Delta-T und Laufzeit aus MQTT berechnen

Abgeleitete Werte berechnet man am besten an einer Stelle statt in jedem Sensorknoten. Das folgende Skript abonniert die Telemetrie aller Geräte, berechnet Delta-T, summiert die Laufzeit von Ventilator und Verdichter, zählt die Verdichterstarts pro Stunde, um Takten zu erkennen, und veröffentlicht die Ergebnisse zurück an MQTT. Probieren Sie es mit dem Demo-Präfix auf dem kostenlosen öffentlichen MQTT-Broker aus, der für Tests und Prototypen gedacht ist, und wechseln Sie für echte Anlagendaten zu privaten Zugangsdaten.

import json
import time
import uuid
from collections import defaultdict, deque

import paho.mqtt.client as mqtt

BROKER, PORT = "broker.connectmq.com", 1883
PREFIX = "connectmq/demo/hvac-q81z"
FAN_ON_A = 1.0          # Strom darüber bedeutet: Ventilator läuft
COMP_ON_A = 3.0         # Strom darüber bedeutet: Verdichter läuft
MAX_STARTS_PER_HOUR = 6

state = defaultdict(lambda: {"last_ts": None, "fan_s": 0.0, "comp_s": 0.0,
                             "comp_on": False, "starts": deque()})


def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)
    client.subscribe(f"{PREFIX}/+/telemetry", qos=0)


def on_message(client, userdata, msg):
    unit = msg.topic.split("/")[-2]
    try:
        t = json.loads(msg.payload)
    except json.JSONDecodeError:
        return
    s = state[unit]
    now = time.time()

    if s["last_ts"] is not None:
        dt = min(now - s["last_ts"], 120)      # Lücken begrenzen, damit Ausfälle die Laufzeit nicht aufblähen
        if t.get("fan_a", 0) > FAN_ON_A:
            s["fan_s"] += dt
        if s["comp_on"]:
            s["comp_s"] += dt
    s["last_ts"] = now

    comp_on = t.get("comp_a", 0) > COMP_ON_A
    if comp_on and not s["comp_on"]:
        s["starts"].append(now)
    s["comp_on"] = comp_on
    while s["starts"] and now - s["starts"][0] > 3600:
        s["starts"].popleft()

    delta_t = None
    if "return_c" in t and "supply_c" in t:
        delta_t = round(t["return_c"] - t["supply_c"], 2)

    derived = {
        "ts": t.get("ts"),
        "delta_t_c": delta_t,
        "fan_runtime_h": round(s["fan_s"] / 3600, 2),
        "comp_runtime_h": round(s["comp_s"] / 3600, 2),
        "comp_starts_last_hour": len(s["starts"]),
        "short_cycling": len(s["starts"]) > MAX_STARTS_PER_HOUR,
    }
    client.publish(f"{PREFIX}/{unit}/derived", json.dumps(derived), qos=1, retain=True)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"hvac-analytics-{uuid.uuid4().hex[:6]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, PORT, keepalive=60)
client.loop_forever()

Simulieren Sie ein Gerät über die Kommandozeile, um es in Aktion zu sehen:

mosquitto_pub -h broker.connectmq.com -p 1883 -i hvac-sim-q81z \
  -t "connectmq/demo/hvac-q81z/ahu-2/telemetry" \
  -m '{"ts":"2026-10-16T10:30:00Z","supply_c":13.6,"return_c":23.1,"filter_dp_pa":182,"fan_a":6.8,"comp_a":14.2}'

Die Laufzeitzähler liegen hier im Arbeitsspeicher und werden beim Neustart des Skripts zurückgesetzt. Für abrechnungsfähige Laufzeiten schreiben Sie die abgeleiteten Werte aus demselben Subscriber in eine Zeitreihendatenbank oder lassen ein Werkzeug wie Telegraf die Topics abonnieren und speichern.

Schwellenwertalarme für HLK-Störungen

Mit ConnectMQ können Sie im Portal Regeln für Schwellenwertalarme auf eingehende Werte definieren, und jeder ausgelöste Alarm wird im Alarmprotokoll festgehalten. Praxistaugliche Startregeln für ein kühlendes Lüftungsgerät:

Passen Sie die Schwellenwerte nach einer Woche Beobachtung pro Gerät an. Anlagen, Klima und Filterklassen unterscheiden sich zu stark für allgemeingültige Zahlen, und das Datenblatt des Herstellers nennt die richtigen Grenzwerte für den Filterdruck.

Verlauf speichern und berichten

Live-Werte erkennen Störungen; der Verlauf belegt Einsparungen und steuert die Wartung. Da jeder Verbraucher einfach ein weiterer MQTT-Client ist, berührt das Hinzufügen eines Speichers die Sensorknoten nicht. Gängige Optionen sind eine Telegraf-Instanz mit ihrem MQTT-Consumer-Input, die in InfluxDB schreibt, ein Node-RED-Flow, der in PostgreSQL einfügt, oder ein kleiner Python-Subscriber, der in die Datenbank schreibt, die Ihre Organisation ohnehin betreibt. Speichern Sie Rohtelemetrie im ursprünglichen Intervall für einige Monate und stündliche Aggregate für Jahre.

Nützliche Monatsberichte für Facility-Teams umfassen die Laufzeitstunden pro Gerät im Vergleich zu den geplanten Stunden, die Anzahl der Stunden, die jedes Gerät mit niedrigem Delta-T verbracht hat, das Datum, an dem jeder Filter seinen Wechseldruck überschritten hat, sowie eine Rangliste der Geräte nach Verdichterstarts. Diese Zahlen verwandeln vage Beschwerden wie „im dritten Stock ist es immer warm“ in konkrete Arbeitsaufträge.

Checkliste für den Rollout

1. Wählen Sie drei bis fünf repräsentative Geräte aus, nicht das ganze Portfolio.
2. Montieren Sie Zuluftfühler weit genug hinter dem Register, damit die Luft durchmischt ist, und Abluftfühler vor der Mischkammer.
3. Setzen Sie Stromwandler auf einen einzelnen Leiter, nicht auf das gesamte Kabel.
4. Nehmen Sie jeden Sensor in Betrieb, indem Sie die Live-Werte im Topic-Explorer beobachten, während das Gerät seine Zyklen durchläuft.
5. Lassen Sie den Analyse-Subscriber laufen und beobachten Sie eine Woche lang, bevor Sie Alarme aktivieren.
6. Schreiben Sie für jeden Alarm ein kurzes Runbook, damit Techniker wissen, was zu prüfen ist.
7. Weiten Sie das System auf die übrigen Geräte aus, sobald Fehlalarme im Griff sind.

Hochskalieren

Ein nachgerüsteter Knoten pro Gerät und ein Analysedienst passen für ein Pilotprojekt problemlos in den kostenlosen Serverless-Tarif. Wenn Sie Gebäude hinzufügen, wächst die Zahl der Verbindungen linear mit den Geräten, und die kostenpflichtige Serverless-Stufe unterstützt bis zu 1.000 Verbindungen mit Shared Subscriptions, sodass Sie mehrere Analyse-Worker betreiben können, die sich die Last teilen. Da der Broker ein Cloud-MQTT-Broker ist, installieren Sie in den Gebäuden nichts außer den Sensorknoten.

Luftqualität und Belegung liefern wertvollen Kontext zu HLK-Daten: siehe Raumluftqualitätsüberwachung und Belegungssensoren im Büro. Das Gesamtbild behandeln Gebäudeautomation mit MQTT und der Leitfaden zur IoT-Automatisierung.

Starten Sie die HLK-Überwachung mit ConnectMQ

Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte. Verbinden Sie einen Sensorknoten, beobachten Sie die Werte im Live-Topic-Explorer und fügen Sie dann Schwellenwert-Alarmregeln für Delta-T und Filterdruck hinzu. ConnectMQ betreibt den Broker, damit sich Ihr Team auf die Anlagen konzentrieren kann.

Häufig gestellte Fragen

Welche einzelne HLK-Messung ist am nützlichsten?

Zu- und Ablufttemperatur zusammen, denn Delta-T zeigt, ob das Gerät tatsächlich Wärme überträgt. Als Nächstes sollten Sie den Filterdifferenzdruck ergänzen.

Brauche ich eine GLT für die HLK-Überwachung mit IoT-Sensoren?

Nein. Nachgerüstete Sensorknoten können direkt an MQTT veröffentlichen. Ist eine GLT vorhanden, kann ein Gateway deren Datenpunkte wiederverwenden, statt neue Sensoren zu installieren.

Wie oft sollte HLK-Telemetrie gesendet werden?

Alle 30 bis 60 Sekunden genügen für Temperaturen und Drücke. Strommessungen für Laufzeit und Takterkennung profitieren von Intervallen von 10 bis 15 Sekunden.

Können Alarme direkt vom Broker gesendet werden?

ConnectMQ wertet Schwellenwert-Alarmregeln aus und hält sie im Alarmprotokoll fest. Für SMS, E-Mail oder Ticketsysteme betreiben Sie einen Subscriber wie Node-RED, der auf die relevanten Topics reagiert.