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](https://www.janitza.de/umg-96-el.html) 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](https://www.stromfee.me/post/janitza-umg-96-el-jetzt-mit-mqtt) 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](https://stromfee.ai/academy) 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](https://stromfee.ai) 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".

4. **Gerätezeitstempel übertragen**, NTP-Sync überwachen.

5. **Retain nur bei statischen Werten.**

6. **Lokaler Broker + Cloud-Bridge** statt direkter Cloud-Verbindung je Gerät.

7. **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](https://stromfee.ai/contact) 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](https://stromfee.ai) 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](https://stromfee.ai/contact).

— Holger Roswandowicz, Stromfee.AI