Janitza UMG 96-EL mit MQTT: 6 Monate später – was wir gelernt haben

TL;DR: Vor einem halben Jahr haben wir den Janitza UMG 96-EL erstmals per MQTT an Stromfee.AI angebunden. Heute laufen mehrere Installationen produktiv. Die MQTT-Integration ist stabil, aber nicht trivial. Dieser Beitrag fasst zusammen, was sich bewährt hat, wo wir uns die Finger verbrannt haben – und welcher Use-Case am Ende der wirtschaftlich interessanteste wurde.

Ausgangslage: Warum MQTT statt Modbus TCP?

Der Janitza UMG 96-EL ist ein Klasse-0,5S-Messgerät nach IEC 61557-12 und sitzt in vielen BGA-, PV- und Nahwärme-Anlagen als Hauptzähler oder auf Abgängen. Historisch haben wir ihn via Modbus TCP ausgelesen – funktioniert, ist aber pull-basiert: Der Server muss zyklisch pollen, jede Verbindung ist eine eigene TCP-Session, Firewall-Regeln werden schnell unübersichtlich.

Mit dem Firmware-Update, das MQTT nativ un

terstützt, hat sich das Bild geändert. MQTT ist push-basiert, läuft über einen zentralen Broker und skaliert deutlich besser, wenn man 20, 50 oder 200 Messpunkte in einem Betrieb hat.

Im ersten Blogpost haben wir das Setup beschrieben. Dieser Beitrag ist das ehrliche 6-Monats-Review.

Was wir erwartet haben

• Weniger Netzwerklast
• Einfachere Skalierung
• Echtzeitfähigere Datenflüsse für Lastspitzenerkennung

Was tatsächlich passiert ist

Zwei der drei Punkte haben sich bestätigt. Der dritte – Echtzeit – ist komplizierter, als es im Datenblatt klingt.

Das Setup in der Praxis

Unser Referenz-Setup bei einem 1-MW-BGA-Betrieb in Norddeutschland sieht aktuell so aus:

• 6x Janitza UMG 96-EL (Einspeisung, BHKW, PV, drei Lastabgänge)
• Mosquitto-Broker auf einem Industrie-PC im Schaltschrank (Debian 12, Docker)
• TLS-verschlüsselte Verbindung mit Client-Zertifikaten
• Bridge-Verbindung zum Stromfee-Broker in der Cloud
• ClickHouse als Zeitreihen-Speicher, gespeist über einen Python-Subscriber

Die Zykluszeit haben wir nach einigen Iterationen auf 5 Sekunden eingestellt – nicht 1 Sekunde, wie ursprünglich geplant. Dazu später mehr.

Topic-Struktur, die sich bewährt hat

```

janitza/<standort>/<messpunkt>/<messgroesse>

```

Konkret zum Beispiel:

```

janitza/bga-nord/einspeisung/p_total

janitza/bga-nord/einspeisung/u_l1

janitza/bga-nord/bhkw/p_total

```

Das klingt trivial, ist es aber nicht. Unsere erste Version hatte die Messgrößen als JSON-Payload in einem einzigen Topic. Funktioniert, aber macht Retain-Handling und Wildcard-Subscriptions unnötig kompliziert. Nach zwei Monaten haben wir umgestellt.

Was sich bewährt hat

1. Netzwerklast sinkt real um 60–70 %

Gegenüber dem Modbus-TCP-Polling mit 1 Sekunde Zyklus messen wir eine Reduktion der Broker-zu-Client-Traffic um rund zwei Drittel. Das liegt an drei Dingen: MQTT überträgt nur bei Änderung (wenn man Change-Detection im Gerät aktiviert), die Header sind kleiner, und es gibt keine wiederholten TCP-Handshakes.

2. Firewall-Regeln werden simpel

Statt N Modbus-Verbindungen von N Clients zu N Geräten hat man nur noch eine ausgehende TLS-Verbindung pro Standort zum Cloud-Broker. Das freut jede IT-Abteilung.

3. Integration in die Causal Engine

Die Stromfee Causal Engine verarbeitet MQTT-Streams direkt in den 15 Kausalketten für BGA-Monitoring. Wir müssen keine Polling-Layer mehr dazwischenschalten, was die Latenz von Messung bis Anomalie-Erkennung deutlich reduziert hat – in der Größenordnung von 3–8 Sekunden statt vorher 15–30 Sekunden.

Stolperfallen, die wir gelernt haben

Zykluszeit: 1 Sekunde ist meist zu ambitioniert

Wir haben mit 1-Sekunden-Takt gestartet. Das Gerät kann das, aber der Broker, das Netzwerk und vor allem ClickHouse-Inserts werden bei 6 Geräten mit je 20 Messgrößen schnell zur Bremse. 5 Sekunden reichen für 95 % aller Use-Cases – inklusive Lastspitzenerkennung im 15-Minuten-RLM-Raster.

Wer wirklich hochauflösend messen will (z. B. für Netzqualität), sollte das lokal im Gerät machen und nur Aggregate per MQTT übertragen.

Retain-Flags: Mit Vorsicht genießen

Retain ist verlockend – neue Subscriber bekommen sofort den letzten Wert. Aber bei hochfrequenten Messgrößen wie Momentanleistung ist ein retainter Wert nach 10 Minuten Offline-Zeit des Geräts irreführend. Wir setzen Retain nur noch bei Konfigurations-Topics und Zählerständen, nicht bei Momentanwerten.

TLS-Zertifikate laufen ab

Klingt banal, ist aber im Feld ein Dauerthema. Unsere ersten Zertifikate hatten 90 Tage Laufzeit (Let's Encrypt-Denke). Im Industrieumfeld, wo Geräte teilweise ohne Internet-Zugang im Schaltschrank sitzen, ist Automatisierung der Erneuerung nicht trivial. Wir arbeiten jetzt mit 2-Jahres-Zertifikaten aus einer eigenen CA und dokumentiertem Rollover-Prozess.

Zeitstempel: Gerät oder Broker?

Der UMG 96-EL kann Zeitstempel mitsenden. Sollte er auch. Wir haben zwei Installationen erlebt, wo der interne NTP-Sync nicht funktionierte und das Gerät um mehrere Sekunden abwich. Wer sich allein auf den Broker-Zeitstempel verlässt, merkt das nie – bis die Korrelation mit dem Lastgang eines anderen Zählers nicht mehr stimmt.

Empfehlung: NTP am Gerät prüfen, Gerätezeitstempel übertragen, Broker-Zeit als Fallback loggen.

Der Killer-Use-Case: §14a EnWG-Nachweisführung

Ehrlich gesagt hatten wir einen anderen Use-Case im Kopf, als wir mit MQTT angefangen haben. Wir dachten: Lastspitzenkappung, BESS-Steuerung, Echtzeit-Arbitrage.

Was sich in der Praxis als wirtschaftlich wertvollster Fall herausgestellt hat: §14a-Nachweisführung und Redispatch-2.0-Dokumentation.

Warum?

Seit 2024 verlangen Netzbetreiber belastbare Nachweise über tatsächliche Leistungsreduktionen bei Steuerungsmaßnahmen. Mit Modbus-Polling im Minutentakt hat man Lücken, Retransmits, Zeitversatz. Mit MQTT im 5-Sekunden-Takt plus QoS 1 plus Gerätezeitstempel hat man eine lückenlose, verifizierbare Messkette.

Für einen Kunden – ein mittelständisches Nahwärmenetz mit BHKW-Kaskade – hat die saubere Nachweisführung im letzten Quartal ca. 11.000 € an sonst strittigen Redispatch-Abrechnungen gerettet. Das ist nicht revolutionär, aber es ist real.

Wer tiefer in die Redispatch-Thematik einsteigen will: Unser Redispatch-Portal mit 4,4 Millionen Maßnahmen seit 2013 gibt einen guten Überblick, was Netzbetreiber tatsächlich abfragen.

Wo MQTT an Grenzen stößt

Bei aller Begeisterung: MQTT ist kein Allheilmittel.

• Für Schutzfunktionen ungeeignet. Wer echte Echtzeit braucht (< 100 ms), nimmt hardwareverdrahtete Signale oder IEC 61850 GOOSE, nicht MQTT.
• Broker ist Single Point of Failure. Ohne Redundanz-Konzept (Cluster, Bridge-Failover) ist ein Broker-Ausfall der Verlust der gesamten Messkette.
• Datenhoheit. Wer per MQTT in die Cloud sendet, sollte sich über DSGVO und Netzbetreiber-Anforderungen an Datenlokalität im Klaren sein. Wir empfehlen immer eine lokale Speicherung zusätzlich.

Empfehlungen für eigene Projekte

1. Starte mit 5 Sekunden Zyklus, nicht 1 Sekunde. Optimiere nach Messung, nicht nach Bauchgefühl.
2. Topic-Struktur flach halten, eine Messgröße pro Topic.
3. TLS ab Tag 1, nicht "machen wir später".

1. Gerätezeitstempel übertragen, NTP-Sync überwachen.
2. Retain nur bei statischen Werten.
3. Lokaler Broker + Cloud-Bridge statt direkter Cloud-Verbindung je Gerät.
4. Zählerstände zusätzlich per Modbus oder als Tages-Aggregat absichern – MQTT-QoS 1 ist gut, aber nicht perfekt.

FAQ

Unterstützt jeder UMG 96-EL MQTT?

Nein. Die MQTT-Funktionalität kam mit einer Firmware-Version, die ältere Geräte nicht unbedingt bekommen. Prüfen Sie die Hardware-Revision und das Firmware-Datum bei Janitza.

Kann ich Modbus und MQTT parallel betreiben?

Ja. Wir nutzen das oft in der Migrationsphase: Modbus für Zählerstände (sicher, pull-basiert), MQTT für Momentanwerte (effizient, push-basiert).

Welche QoS-Stufe ist richtig?

QoS 1 für Messwerte (mindestens einmalige Zustellung), QoS 0 reicht bei sehr hochfrequenten Momentanwerten, QoS 2 ist meistens Overkill und teuer.

Wie viele Geräte schafft ein Mosquitto-Broker?

Auf einem mittleren Industrie-PC problemlos mehrere hundert Geräte mit 5-Sekunden-Zyklus. Der Flaschenhals ist fast immer der Subscriber, nicht der Broker.

Reicht MQTT für die Eichrechtskonformität?

Nein. Für eichrechtsrelevante Messungen brauchen Sie zertifizierte Zähler mit entsprechender Protokollierung. MQTT kann ergänzend eingesetzt werden, ersetzt aber kein MsbG-konformes Messsystem.

Wie integriere ich die Daten in Stromfee?

Entweder per Bridge zu unserem Cloud-Broker oder über eine direkte Subscriber-Anbindung an die ClickHouse-Pipeline. Kontakt für technische Details.

Lohnt sich der Umstieg von Modbus auf MQTT?

Ab 5–10 Messpunkten pro Standort: Ja, tendenziell. Darunter: Modbus reicht meist.

Fazit

Nach 6 Monaten Produktivbetrieb ist unser Urteil: Der Janitza UMG 96-EL mit MQTT ist eine sinnvolle Ergänzung, kein Modbus-Ersatz. Die Stärken liegen in Skalierbarkeit, Netzwerkhygiene und der Integration in Stream-basierte Monitoring-Architekturen. Die Schwächen liegen im Detail – TLS-Handling, Zeitsynchronisation, Retain-Semantik.

Der überraschendste Gewinn war nicht Echtzeit-Regelung, sondern saubere Nachweisführung für regulatorische Zwecke. Das hätte ich vor einem halben Jahr nicht so vorhergesagt.

Wer selbst in die Integration einsteigen will: Schauen Sie sich unser BESS Live-Dashboard an, um zu sehen, wie die MQTT-Ströme am Ende visualisiert werden. Für tiefergehende Fragen zur Topic-Struktur oder Causal-Engine-Anbindung: Direktkontakt.

— Holger Roswandowicz, Stromfee.AI

Aktuelle Beiträge

Kommentare