Energie-Lastprognose mit IoT-Zählerdaten und MQTT

Eine Energie-Lastprognose sagt vorher, wie viel Strom ein Gebäude, ein Werk oder ein Standort in den kommenden Stunden oder Tagen beziehen wird. Wenn IoT-Zähler ihre Messwerte per MQTT streamen, können Sie eine Prognose aus Ihren eigenen Daten erstellen, statt sich auf Monatsrechnungen zu verlassen. Dieser Anwendungsfall zeigt den Datenpfad vom Zähler zum Modell, die Merkmale, die für den Bedarf entscheidend sind, ein funktionierendes Day-Ahead-Prognoseskript und wie Sie das Ergebnis veröffentlichen, damit es Lastspitzenkappung und Planungsentscheidungen steuern kann.

Warum eine Lastprognose sinnvoll ist

Eine Lastprognose beantwortet praktische Fragen, mit denen Facility- und Produktionsverantwortliche täglich konfrontiert sind:

Lastspitzenmanagement. Viele Tarife enthalten Leistungspreise, die sich am höchsten Messintervall des Monats orientieren; in Deutschland betrifft das typischerweise Kunden mit registrierender Leistungsmessung (RLM) und 15-Minuten-Werten. Wenn Sie im Voraus wissen, dass sich der morgige Nachmittag der Grenze nähert, können Sie flexible Lasten verschieben.
Planung flexibler Lasten. Batch-Prozesse, das Laden von E-Fahrzeugen, Vorkühlung und Warmwasserbereitung lassen sich in Stunden mit geringerem Bedarf oder niedrigeren Preisen verlegen.
Beschaffung und Eigenverbrauch. Standorte mit Photovoltaik, Batteriespeichern oder zeitvariablen Tarifen brauchen eine Bedarfsprognose, um zu entscheiden, wann geladen, entladen oder eingekauft wird.
Erkennung von Auffälligkeiten. Eine große, anhaltende Abweichung zwischen Prognose und tatsächlicher Last deutet oft auf weiterlaufende Anlagen, einen ausfallenden Kompressor oder einen Messfehler hin.

Der Prognosehorizont hängt von der Entscheidung ab: Intraday-Prognosen (die nächsten Stunden) unterstützen die Echtzeitsteuerung, Day-Ahead-Prognosen die Planung und den Einkauf, längere Horizonte die Budgetierung.

Der Datenpfad: vom Zähler zum Modell

Ein typischer Aufbau besteht aus Stromzählern oder Unterzählern, die über ein Gateway angebunden sind. Das Gateway liest sie per Modbus, M-Bus oder Hersteller-API aus und veröffentlicht die Messwerte an einen MQTT-Broker. Wetterdaten sowie Produktions- oder Belegungspläne werden parallel dazu veröffentlicht oder gespeichert.

Meters (Modbus RTU/TCP) -> gateway -> MQTT broker -> historian subscriber -> forecasting service
                                           ^                                         |
                       weather / schedule publisher                 forecast topic <-+

Eine klare Topic-Struktur macht das Modell unabhängig vom Zählerhersteller:

connectmq/site1/main/meter1/energy       {"ts":..., "kwh_total": 183422.6}
connectmq/site1/main/meter1/power        {"ts":..., "kw": 142.8}
connectmq/site1/weather/outdoor          {"ts":..., "temp_c": 27.4}
connectmq/site1/main/meter1/forecast     {"generated":..., "points":[...]}

In Werken mit einem Unified Namespace (UNS) hängen Sie die Zähler am besten in die ISA-95-Hierarchie ein, etwa acme/werk-stuttgart/montage/linie-1/zaehler-1/energy. Dann lässt sich der Verbrauch direkt pro Linie oder Halle prognostizieren und neben OEE und Maschinendaten für das Energiemonitoring auswerten.

Veröffentlichen Sie Energie nach Möglichkeit als kumulativen Zählerstand statt als Werte pro Intervall. Geht eine Nachricht verloren, enthält der nächste Zählerstand den Verbrauch trotzdem, und der Intervallbedarf lässt sich durch Differenzbildung exakt rekonstruieren. Die momentane Leistung ist für Live-Dashboards nützlich, für Prognosen aber zu verrauscht. Wenn Ihre Zähler Modbus-Geräte sind, zeigt der Leitfaden Modbus TCP zu MQTT die Gateway-Seite.

Merkmale, die die Energie-Lastprognose bestimmen

Merkmalsgruppe	Beispiele	Warum sie wichtig ist
Kalender	Tageszeit, Wochentag, Feiertagskennung, Monat	Belegung und Produktion folgen Zeitplänen
Verzögerte Last	Gleiche Stunde gestern, gleiche Stunde letzte Woche	Starke Persistenz im Bedarf
Wetter	Außentemperatur, deren Prognose, Luftfeuchte, Sonneneinstrahlung	Heiz- und Kühllasten hängen davon ab
Abgeleitete Wettergrößen	Kühl- und Heizgradstunden, Temperaturverzögerung	Gebäude reagieren mit thermischer Trägheit
Betrieb	Produktionsplan, Schichtmodell, Belegungszahlen	Erklärt nicht wetterbedingte Schwankungen

Bei Day-Ahead-Prognosen muss jedes Merkmal verfügbar sein, bevor die Prognose erstellt wird. Das bedeutet: Für künftige Stunden wird die Wetterprognose verwendet, nicht die gemessene Temperatur, und Verzögerungen (Lags) müssen mindestens 24 Stunden betragen. Werden gemessenes und prognostiziertes Wetter im Training vermischt, ist das ein häufiger Grund dafür, dass Modelle im Test hervorragend aussehen und im Betrieb enttäuschen.

Eine Day-Ahead-Prognose in Python

Das folgende Skript simuliert über vier Wochen den Zählerstand und die Außentemperatur eines Gewerbegebäudes, veröffentlicht die Werte an den kostenlosen öffentlichen MQTT-Broker, sammelt sie wieder ein, rechnet den Zählerstand in 15-Minuten-Bedarf um, trainiert ein Gradient-Boosting-Modell und veröffentlicht eine 24-Stunden-Prognose. In einem echten Einsatz würde der Sammelschritt aus Ihrem Historian lesen statt aus einem Simulator.

import json
import math
import random
import time
import uuid

import numpy as np
import pandas as pd
import paho.mqtt.client as mqtt
from sklearn.ensemble import HistGradientBoostingRegressor

BROKER = "broker.connectmq.com"
BASE = f"connectmq/demo/{uuid.uuid4().hex[:8]}/site1"
START = 1767225600  # 2026-01-01 00:00 UTC
STEPS = 28 * 96     # 4 Wochen in 15-Minuten-Intervallen
rows = []


def on_message(client, userdata, msg):
    p = json.loads(msg.payload)
    p["kind"] = msg.topic.rsplit("/", 1)[1]
    rows.append(p)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="elf-" + uuid.uuid4().hex[:8])
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=60)
client.subscribe([(f"{BASE}/meter1/energy", 1), (f"{BASE}/weather/temp", 1)])
client.loop_start()
time.sleep(1)

counter = 100000.0
for i in range(STEPS):
    t = START + i * 900
    hour = (t % 86400) / 3600
    workday = time.gmtime(t).tm_wday < 5
    temp = 24 + 7 * math.sin((hour - 9) / 24 * 2 * math.pi) + random.gauss(0, 1)
    occupied = workday and 7 <= hour < 19
    kw = 40 + (90 if occupied else 0) + 6 * max(temp - 22, 0) + random.gauss(0, 5)
    counter += kw * 0.25
    client.publish(f"{BASE}/meter1/energy", json.dumps({"ts": t * 1000, "kwh_total": round(counter, 2)}))
    client.publish(f"{BASE}/weather/temp", json.dumps({"ts": t * 1000, "temp_c": round(temp, 2)}))
    time.sleep(0.21)  # zwei Nachrichten pro Schritt, unter 10 msg/s bleiben

time.sleep(3)

df = pd.DataFrame(rows)
df["ts"] = pd.to_datetime(df["ts"], unit="ms", utc=True)
energy = df[df.kind == "energy"].set_index("ts")["kwh_total"].sort_index().resample("15min").last()
temp = df[df.kind == "temp"].set_index("ts")["temp_c"].sort_index().resample("15min").mean()

data = pd.DataFrame({"kw": energy.interpolate().diff() * 4, "temp": temp.interpolate()})
data["hour"] = data.index.hour + data.index.minute / 60
data["dow"] = data.index.dayofweek
data["lag_1d"] = data["kw"].shift(96)
data["lag_7d"] = data["kw"].shift(7 * 96)
data["cdh"] = (data["temp"] - 22).clip(lower=0)
FEATS = ["hour", "dow", "lag_1d", "lag_7d", "temp", "cdh"]
data = data.dropna()

train, test = data.iloc[:-96], data.iloc[-96:]
model = HistGradientBoostingRegressor(max_iter=300, learning_rate=0.05).fit(train[FEATS], train["kw"])
pred = model.predict(test[FEATS])
mae = np.mean(np.abs(pred - test["kw"]))
print(f"Day-ahead MAE: {mae:.1f} kW, peak forecast {pred.max():.0f} kW, actual peak {test['kw'].max():.0f} kW")

forecast = {
    "generated": int(time.time() * 1000),
    "model": "gbr-load-v1",
    "unit": "kW",
    "points": [{"ts": int(ts.timestamp() * 1000), "kw": round(float(v), 1)} for ts, v in zip(test.index, pred)],
}
client.publish(f"{BASE}/meter1/forecast", json.dumps(forecast), qos=1, retain=True).wait_for_publish()
client.loop_stop()
client.disconnect()

Installation mit pip install paho-mqtt pandas numpy scikit-learn. Der Lauf dauert etwa zehn Minuten, weil der Simulator das Ratenlimit des öffentlichen MQTT-Brokers einhält, der für Tests und Prototypen und nicht für Produktionsdaten gedacht ist. Der Testtag verwendet hier die simulierte gemessene Temperatur als Ersatz für eine Wetterprognose; im Produktivbetrieb geben Sie dem Modell für künftige Stunden die prognostizierte Temperatur. Hintergründe zum Backtesting mit mehreren Prognoseursprüngen und zum Vergleich mit einer naiven Baseline finden Sie unter IoT-Zeitreihenprognose.

Aus der Prognose Maßnahmen ableiten

Eine Prognose zahlt sich nur aus, wenn sie Entscheidungen verändert. Gängige Muster:

Lastspitzenwarnungen. Vergleichen Sie die prognostizierte Spitze mit Ihrer Leistungsgrenze und informieren Sie das Facility-Team am Vorabend.
Lastverschiebung. Ein Planungsskript abonniert das Prognose-Topic und verlegt flexible Lasten wie das Laden von E-Fahrzeugen oder Batch-Heizprozesse in Intervalle mit geringem Bedarf.
Vorkühlen und Vorheizen. Die HLK-Anlage kann günstige Stunden oder Stunden mit geringem Bedarf nutzen, um thermische Energie in der Gebäudemasse zu speichern – ein Muster, das in KI-gestützte HLK-Optimierung behandelt wird.
Überwachung von Prognose und Ist-Wert. Veröffentlichen Sie die Live-Abweichung als eigenes Topic und lösen Sie bei anhaltenden Abweichungen Warnungen aus.

Mit ConnectMQ können Sie die Prognose- und die gemessenen Leistungs-Topics im Live-Topic-Explorer beobachten und Schwellenwert-Alarmregeln für den gemessenen Bedarf festlegen, sodass das Alarmprotokoll jedes Intervall festhält, das Ihre Grenze überschritten hat. Weitergehende Aktionen laufen in Ihren eigenen Clients, etwa in Node-RED-Flows oder Python-Diensten, die denselben Broker abonnieren.

Prognosen im Tagesverlauf aktualisieren

Eine Day-Ahead-Prognose wird einmal erstellt, doch der Tag verläuft selten genau wie geplant. Eine ungeplante Überstundenschicht oder ein heißerer Nachmittag als vorhergesagt verschiebt die Last. Eine einfache Verbesserung besteht darin, die Prognose stündlich mit dem zuletzt gemessenen Bedarf als zusätzlichem Eingang neu zu berechnen und jede neue Version mit einem Erstellungszeitstempel auf dasselbe Retained-Topic zu veröffentlichen. Konsumenten sehen so immer den aktuellen Stand, und Sie können jede Version speichern, um zu messen, wie stark Intraday-Aktualisierungen die Genauigkeit gegenüber dem ursprünglichen Day-Ahead-Lauf verbessern.

Typische Fallstricke

Zählerrücksetzungen und Überläufe. Zähler laufen über oder werden nach einem Austausch zurückgesetzt; behandeln Sie negative Differenzen als Rücksetzung, nicht als negativen Bedarf.
Zeitzonen und Sommerzeit. Speichern Sie in UTC und berechnen Sie Kalendermerkmale in Ortszeit, sonst verschiebt sich Ihr Anlauf um 08:00 Uhr zweimal im Jahr um eine Stunde.
Feiertage und Stillstände. Ohne Feiertagskennung prognostiziert das Modell an einem gesetzlichen Feiertag die Last eines normalen Werktags. In Deutschland, Österreich und der Schweiz unterscheiden sich Feiertage zudem je nach Bundesland oder Kanton, und Brückentage oder Werksferien sollten ebenfalls als Merkmal einfließen.
Veränderte Ausgangsbasis. Neue Anlagen, Modernisierungen oder geänderte Öffnungszeiten machen ältere Historie irreführend; gewichten Sie aktuelle Daten stärker oder trainieren Sie auf einem gleitenden Zeitfenster neu.
Summen der Unterzähler, die nicht zum Hauptzähler passen. Nicht erfasste Lasten und Verluste gibt es immer; prognostizieren Sie den Hauptzähler direkt, statt Unterzählerprognosen zu summieren, und nutzen Sie die Unterzähler zur Diagnose.

Skalierung über mehrere Standorte

Ein Gebäude ist ein Skript, fünfzig Standorte sind eine Plattform. Halten Sie die Topic-Struktur an jedem Standort identisch, betreiben Sie einen Prognosedienst, der mit Wildcards abonniert, und speichern Sie die Ergebnisse pro Standort. Ein verwalteter MQTT-Broker nimmt Ihnen den Betriebsaufwand für die Messaging-Schicht ab, und ConnectMQ bietet Dedicated-Cluster und BYOC-Bereitstellungen, wenn Standorte Isolation erfordern. Mehr zur Kombination von Modellen mit vernetzten Geräten lesen Sie im Leitfaden zu KI und IoT, eine modellbasierte Sicht auf Energiesysteme bietet Digitale Zwillinge für Energie.

Mit ConnectMQ starten

Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte. Verbinden Sie Ihr Zähler-Gateway und Ihren Prognosedienst mit den generierten Werten YOUR_USERNAME, YOUR_PASSWORD und YOUR_CLIENT_ID und beginnen Sie, die Historie aufzubauen, die Ihr Modell für die Energie-Lastprognose braucht. Wenn weitere Standorte hinzukommen, wechseln Sie zu einem größeren Tarif für Ihren Cloud-MQTT-Broker, ohne Ihre Topics zu ändern.

Häufig gestellte Fragen

Was ist eine Energie-Lastprognose?

Eine Energie-Lastprognose sagt den Strombedarf eines Gebäudes, eines Werks oder eines Netzgebiets für künftige Zeitintervalle vorher, typischerweise auf Basis historischer Zählerdaten sowie Wetter- und Kalenderinformationen.

Wie viele Daten brauche ich für eine Lastprognose?

Einige Wochen 15-Minuten-Daten reichen für eine brauchbare Day-Ahead-Prognose eines Gebäudes mit stabilen Zeitplänen. Um saisonale Heiz- und Kühlmuster sowie Feiertage abzubilden, ist ein Jahr oder mehr nötig.

Sollte ich Energie oder Leistung von meinen Zählern veröffentlichen?

Veröffentlichen Sie für Prognose- und Abrechnungsgenauigkeit den kumulativen Energiezählerstand, denn verlorene Nachrichten führen dann nicht zu verlorenem Verbrauch. Veröffentlichen Sie zusätzlich die momentane Leistung, wenn Sie Live-Dashboards benötigen.

Welches Modell eignet sich am besten für Lastprognosen?

Gradient Boosting auf Kalender-, Lag- und Wettermerkmalen ist ein starker, erklärbarer Standard. Vergleichen Sie es mit einer Baseline „gleicher Tag letzte Woche“ und wechseln Sie nur, wenn ein anderes Modell in einem rollierenden Backtest besser abschneidet.