IoT und KI

KI-HLK-Optimierung: intelligentere Sollwerte und Zeitpläne mit MQTT-Daten

Ein praxisnaher Anwendungsfall für KI-HLK-Optimierung: welche Gebäudedaten Sie per MQTT erfassen, wie Sie das thermische Verhalten einer Zone lernen, wie Sie optimale Startzeiten und Sollwerte berechnen und Empfehlungen sicher anwenden.

Dashboard zur KI-HLK-Optimierung mit Zonentemperatur, einem gelernten thermischen Modell und einer optimierten Vorkühl-Startzeit vor Belegungsbeginn
Probieren Sie es auf Ihrem eigenen MQTT-Broker ausHolen Sie sich im Free-Tarif einen privaten, verwalteten MQTT-Broker und starten Sie mit fertigen Codebeispielen.
Kostenlos testen Codebeispiele Keine Kreditkarte erforderlich

KI-HLK-Optimierung nutzt Daten aus der Heizungs-, Lüftungs- und Klimatechnik eines Gebäudes, um zu lernen, wie sich jede Zone tatsächlich verhält, und wählt dann Startzeiten, Sollwerte und Zeitpläne, die für Behaglichkeit bei geringerem Energieeinsatz sorgen. In diesem Anwendungsfall sehen Sie, welche Daten Sie per MQTT erfassen, wie Sie aus diesen Daten das thermische Verhalten einer Zone lernen, wie Sie eine optimale Startzeit berechnen und wie Sie Empfehlungen sicher an das Gebäude zurückgeben.

Wo konventionelle HLK-Regelung Energie verschenkt

Die meisten Gebäudeautomationssysteme laufen mit festen Zeitplänen und festen Sollwerten, die bei der Inbetriebnahme konfiguriert wurden. Das Lüftungsgerät startet jeden Werktag um 06:00 Uhr, weil irgendwann jemand entschieden hat, dass das früh genug ist – egal ob die Nacht mild oder kalt war. Sollwerte bleiben auch an einem halb leeren Freitagnachmittag unverändert. Gleichzeitiges Heizen und Kühlen in benachbarten Zonen bleibt monatelang unbemerkt.

Nichts davon ist ein Versagen der Regler, die ihre Aufgabe, einen Sollwert zu halten, gut erfüllen. Die Lücke liegt auf der übergeordneten Ebene: bei der Entscheidung, wie Sollwerte und Zeitpläne angesichts von Wetter, Belegung und thermischem Verhalten des Gebäudes aussehen sollten. Genau dort helfen datengetriebene Modelle, und deshalb sitzt die KI-HLK-Optimierung in der Regel über dem bestehenden Gebäudeautomationssystem, statt es zu ersetzen.

Daten für die KI-HLK-Optimierung

Daten Quelle Typisches Intervall Warum sie wichtig sind
Raumlufttemperatur der Zone GLT-Datenpunkte, Funksensoren 1–5 min Die geregelte Behaglichkeitsgröße
Zonensollwerte und Betriebsart GLT Bei Änderung Was der Regler erreichen will
Zulufttemperatur und Volumenstrom, Ventil- oder Klappenstellungen RLT- und VVS-Regler 1–5 min Wie viel Heiz- oder Kühlleistung geliefert wird
Außentemperatur, Luftfeuchte, Sonneneinstrahlung Wetterstation oder Wetterdienst 5–15 min Wichtigste äußere Störgröße
Belegung Zeitpläne, Personenzähler, CO2 5–15 min Erforderliche Behaglichkeit und interne Lasten
Elektrische oder thermische Energie Zähler an Kältemaschinen, Kesseln, RLT-Geräten 15 min Die zu minimierenden Kosten

Gebäudeautomationssysteme sprechen meist BACnet oder Modbus; in Gebäuden in Deutschland, Österreich und der Schweiz kommt häufig KNX hinzu (siehe KNX und MQTT). Ein Gateway liest die relevanten Datenpunkte aus und veröffentlicht sie unter einer einheitlichen Hierarchie an einen MQTT-Broker, sodass der Optimierungsdienst die herstellerspezifischen Datenpunktnamen nie kennen muss:

connectmq/hq/floor3/zone-east/temperature     {"ts":..., "value": 23.8, "unit":"degC"}
connectmq/hq/floor3/zone-east/setpoint        {"ts":..., "value": 22.0, "unit":"degC"}
connectmq/hq/floor3/ahu2/supply_temp          {"ts":..., "value": 14.2, "unit":"degC"}
connectmq/hq/weather/outdoor_temp             {"ts":..., "value": 31.5, "unit":"degC"}
connectmq/hq/floor3/zone-east/recommendation  {"ts":..., "start_at":"06:40", "reason":"..."}

Dasselbe Muster funktioniert in Produktionshallen: Dort hängen HLK-Topics oft im Unified Namespace (UNS) des Werks, etwa unter acme/werk-muenchen/halle-2/rlt-1/..., sodass Energiemonitoring und Produktionsdaten im selben Baum liegen. Wenn Sie am Gateway zwischen Gebäudeprotokollen wählen, hilft der Vergleich BACnet vs. Modbus.

Drei Optimierungspotenziale

  1. Optimaler Start und Stopp. Beginnen Sie mit der Konditionierung jeder Zone gerade früh genug, um das Behaglichkeitsband bei Belegungsbeginn zu erreichen, und schalten Sie früher ab, wenn die thermische Masse des Gebäudes die Temperatur hält, bis die Menschen gehen.
  2. Sollwertoptimierung. Lockern Sie Sollwerte innerhalb des Behaglichkeitsbands, wenn Zonen unbelegt oder schwach belegt sind, und kühlen oder heizen Sie in Stunden mit geringem Bedarf oder niedrigen Preisen vor.
  3. Erkennung von Fehlern und Verschwendung. Finden Sie Zonen, die gleichzeitig heizen und kühlen, Ventile, die nie schließen, oder Sensoren, die driften. Das sind oft die schnellsten Einsparungen.

Der optimale Start ist das beste erste Projekt: Er ist leicht zu erklären, seine Einsparungen sind messbar, und sein Fehlerfall (eine Zone, die bei Öffnung etwas zu warm ist) ist harmlos.

Das thermische Verhalten einer Zone lernen

Viele Gebäude verhalten sich über kurze Zeithorizonte annähernd wie ein thermisches System erster Ordnung. Die Änderung der Zonentemperatur pro Zeitschritt hängt von der Differenz zur Außentemperatur (Wärmeeintrag durch die Gebäudehülle) und von der durch die HLK gelieferten Kühl- oder Heizleistung ab:

T[k+1] - T[k] = a * (T_out[k] - T[k]) + b * u[k] + c

Dabei ist u die HLK-Leistung (zum Beispiel Kühlung ein oder aus oder die Ventilstellung), und c erfasst durchschnittliche interne und solare Lasten. Werden a, b und c pro Zone per linearer Regression auf einigen Wochen Daten angepasst, entsteht ein Grey-Box-Modell: einfach genug, um ihm zu vertrauen, und datengetrieben genug, um das reale Verhalten jeder Zone abzubilden. Fortgeschrittenere Projekte nutzen Gradient Boosting oder neuronale Modelle mit Belegungs- und Solarmerkmalen, doch das Grey-Box-Modell ist ein starker, erklärbarer Ausgangspunkt.

Beispiel: optimaler Start aus MQTT-Daten

Das folgende Skript passt das thermische Modell für eine Zone an und sucht dann die späteste Startzeit für die Kühlung, mit der die Zone bis zum Belegungsbeginn noch ins Behaglichkeitsband gelangt. Es verwendet simulierte Historie, damit es überall läuft, und veröffentlicht die Empfehlung an den öffentlichen MQTT-Broker, der für Tests und Prototypen gedacht ist, nicht für Produktionsdaten. In einem echten Einsatz käme die Historie von Ihrem Historian-Subscriber und die Wetterprognose von einem Wetterdienst.

import json
import random
import time
import uuid

import numpy as np
import paho.mqtt.client as mqtt
from sklearn.linear_model import LinearRegression

STEP_MIN = 5
COMFORT_MAX = 24.0
OCCUPANCY_START = "08:00"

# --- 1. Simulierte Historie (durch Historian-Daten ersetzen) ---------------
rng = np.random.default_rng(1)
true_a, true_b, true_c = 0.004, -0.06, 0.004
T, rows = 25.0, []
for k in range(14 * 24 * 12):  # zwei Wochen in 5-Minuten-Schritten
    hour = (k * STEP_MIN / 60) % 24
    t_out = 24 + 7 * np.sin((hour - 9) / 24 * 2 * np.pi)
    u = 1.0 if 7 <= hour < 18 else 0.0
    T_next = T + true_a * (t_out - T) + true_b * u + true_c + rng.normal(0, 0.03)
    rows.append((T, t_out, u, T_next - T))
    T = T_next

data = np.array(rows)
X = np.column_stack([data[:, 1] - data[:, 0], data[:, 2]])
model = LinearRegression().fit(X, data[:, 3])
a, b = model.coef_
c = model.intercept_
print(f"learned a={a:.4f} b={b:.4f} c={c:.4f}")

# --- 2. Suche nach dem optimalen Start ------------------------------------
def simulate(start_index, T0, t_out_forecast, occ_index):
    T = T0
    for k in range(occ_index):
        u = 1.0 if k >= start_index else 0.0
        T = T + a * (t_out_forecast[k] - T) + b * u + c
    return T

T_now = 25.2                                     # Zonentemperatur um 05:00
steps_until_occ = (8 - 5) * 60 // STEP_MIN       # 05:00 -> 08:00
t_out_fc = [22 + 0.08 * k for k in range(steps_until_occ)]  # Prognose für einen wärmer werdenden Morgen

best = 0
for start in range(steps_until_occ, -1, -1):     # spätester Start zuerst
    if simulate(start, T_now, t_out_fc, steps_until_occ) <= COMFORT_MAX - 0.3:  # kleine Sicherheitsmarge
        best = start
        break
start_minutes = 5 * 60 + best * STEP_MIN
start_at = f"{start_minutes // 60:02d}:{start_minutes % 60:02d}"
print("recommended cooling start:", start_at)

# --- 3. Empfehlung veröffentlichen ----------------------------------------
BASE = f"connectmq/demo/{uuid.uuid4().hex[:8]}/hq/floor3/zone-east"
rec = {
    "ts": int(time.time() * 1000),
    "start_at": start_at,
    "occupancy_start": OCCUPANCY_START,
    "comfort_max": COMFORT_MAX,
    "model": {"a": round(a, 5), "b": round(b, 5), "c": round(c, 5)},
    "reason": "latest start meeting comfort band with forecast outdoor temperature",
}
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="hvac-opt-" + uuid.uuid4().hex[:8])
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()
client.publish(f"{BASE}/recommendation", json.dumps(rec), qos=1, retain=True).wait_for_publish()
client.loop_stop()
client.disconnect()
print("published to", f"{BASE}/recommendation")

Installation mit pip install paho-mqtt numpy scikit-learn. Die angepassten Koeffizienten liegen nahe an den simulierten Werten, und die Empfehlung liegt deutlich später als ein fester früher Start. Vergleichen Sie in einem realen Gebäude die empfohlene Zeit einige Wochen lang mit dem festen Zeitplan, bevor Sie sie wirken lassen; die Differenz in der Laufzeit des Lüftungsgeräts ist Ihre erwartete Einsparung.

Empfehlungen sicher anwenden

Sollwerte an reale Anlagen zu senden, erfordert mehr Sorgfalt als das Veröffentlichen eines Diagramms. Eine praxistaugliche Abfolge:

  1. Beratungsmodus. Veröffentlichen Sie nur Empfehlungen; das Facility-Personal prüft sie in einem Dashboard neben den tatsächlichen Ergebnissen.
  2. Begrenzte Automatisierung. Ein Gateway oder eine GLT-Integration akzeptiert Empfehlungen nur innerhalb harter Grenzen, etwa Start nicht vor 05:00 Uhr, Sollwerte nur zwischen 21 und 25 °C, und ignoriert Nachrichten, die älter als einige Minuten sind. Hier ist die Message Expiry von MQTT 5 nützlich, damit veraltete Befehle vom Broker verworfen werden.
  3. Rückfallebene. Kommen keine Empfehlungen mehr an, kehrt die GLT automatisch zu ihrem normalen Zeitplan zurück.
  4. Manuelle Übersteuerung. Lokale Übersteuerungen haben immer Vorrang, und jede Übersteuerung wird als Ereignis erfasst, damit das Modell daraus lernen kann.

Diese Grenzen gehören in die anlagenseitige Integration, nicht nur in den KI-Dienst, damit ein Fehler im Modell die Anlagen nicht aus sicheren Bereichen drängen kann. Der Artikel Sichere KI-Steuerung von IoT-Geräten behandelt diese Leitplanken ausführlich.

Ergebnisse messen

Einsparungen zu behaupten ist leicht, sie zu belegen schwer. Vergleichen Sie Gleiches mit Gleichem: Werktage mit ähnlicher Außentemperatur und Belegung vorher und nachher, oder abwechselnde Tage mit altem und neuem Zeitplan. Erfassen Sie die Behaglichkeit ebenso sorgfältig wie die Energie, etwa in Minuten außerhalb des Behaglichkeitsbands pro Zone. Veröffentlichen Sie beides als Topics, damit es neben den Betriebsdaten erscheint. Ein Modell zur Energie-Lastprognose hilft hier als Baseline: Die Differenz zwischen dem prognostizierten Bedarf unter der alten Strategie und dem gemessenen Bedarf unter der neuen ist eine faire Schätzung der Wirkung.

Die Datenschicht mit ConnectMQ betreiben

ConnectMQ stellt den verwalteten MQTT-Broker bereit, der GLT-Datenpunkte, Wetterdaten, Empfehlungen und Ergebnisse zwischen Ihrem Gateway und Ihrem Optimierungsdienst transportiert. Der Live-Topic-Explorer zeigt Empfehlungen neben den Zonentemperaturen, die sie beeinflussen, und Schwellenwert-Alarmregeln können Zonen markieren, die das Behaglichkeitsband verlassen. Die Modelle selbst laufen in Ihren eigenen Clients, zum Beispiel in einem Python-Dienst oder einem Node-RED-Flow. Das Gesamtbild von KI mit vernetzten Geräten finden Sie im Leitfaden zu KI und IoT, wiederverwendbare Prognosetechniken unter IoT-Zeitreihenprognose.

Mit ConnectMQ starten

Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte. Verbinden Sie Ihr GLT-Gateway mit den generierten Werten YOUR_USERNAME, YOUR_PASSWORD und YOUR_CLIENT_ID, sammeln Sie einige Wochen Zonendaten und führen Sie das Beispiel zum optimalen Start in Ihrem eigenen Gebäude aus. Wenn weitere Gebäude hinzukommen, skaliert ein Tarif für Ihren Cloud-MQTT-Broker die Zahl der Verbindungen, ohne dass Sie Ihre Topics ändern müssen.

Häufig gestellte Fragen

Was ist KI-HLK-Optimierung?

KI-HLK-Optimierung nutzt Gebäudedaten und Modelle, um bessere HLK-Startzeiten, Sollwerte und Zeitpläne zu wählen als feste Konfigurationen. So sinkt der Energieverbrauch, während die Zonen im Behaglichkeitsband bleiben.

Ersetzt KI-HLK-Optimierung die Gebäudeleittechnik?

Nein. Sie arbeitet in der Regel als übergeordnete Schicht, die Sollwerte und Zeitpläne empfiehlt oder sendet, während die bestehenden GLT-Regler weiterhin die Anlagen betreiben und die lokale Sicherheit gewährleisten.

Wie viele Daten braucht man für den Einstieg?

Einige Wochen mit Zonentemperatur, HLK-Status und Außentemperatur in Intervallen von 5–15 Minuten reichen aus, um ein einfaches thermisches Modell für den optimalen Start anzupassen. Saisonale Effekte erfordern eine längere Historie.

Wie bleiben automatisierte Sollwertänderungen sicher?

Setzen Sie harte Grenzen und Prüfungen des Nachrichtenalters in der anlagenseitigen Integration durch, fallen Sie auf den normalen Zeitplan zurück, wenn keine Empfehlungen mehr kommen, und lassen Sie lokale Übersteuerungen immer Vorrang haben.

Verwandte Artikel

Alle Artikel →

Ihr privater MQTT-Broker ist nur wenige Klicks entfernt

Konto anlegen, Broker-Zugangsdaten erhalten und das erste Gerät verbinden — ohne Server, die installiert, gepatcht oder skaliert werden müssen.