Janitza UMG 96-EL mit MQTT: Energiemessung direkt im IoT-Datenfluss

TL;DR: Das Janitza UMG 96-EL kann per Firmware-Update nun MQTT sprechen. Das vereinfacht die direkte Integration in Energiemanagementsysteme erheblich – ersetzt aber weder Modbus in der Industrie-Automatisierung noch macht es eine sorgfältige Topic-Planung überflüssig.

Was das UMG 96-EL bisher leistete

Das Janitza UMG 96-EL ist seit Jahren ein bewährtes Gerät zur Erfassung elektrischer Messgrössen: Spannung, Strom, Wirk- und Blindleistung, Oberschwingungen bis zur 41. Harmonischen sowie Netzqualitäts­parameter nach EN 50160. In vielen Betrieben hängt es im Unterverteiler und liefert per Modbus TCP die Rohdaten an übergeordnete Systeme.

Der Anschluss über Modbus funktioniert zuverlässig, erfordert aber auf der Empfängerseite einen Poll-Mechanismus: Das übergeordnete System fragt in konfigurierten Intervallen aktiv ab. Bei mehreren Geräten an einem Gateway summiert sich der Abfrage-Overhead, und bei schlechter Netzverbindung entstehen Lücken in der Zeitreihe.

Was MQTT technisch ändert

MQTT ist ein Publish-Subscribe-Protokoll, das ursprünglich für bandbreitenarme Verbindungen in der Fernüberwachung entwickelt wurde. Ein Gerät publisht Messwerte an einen Broker, sobald sie vorliegen – oder in konfigurierten Intervallen. Abonnenten empfangen die Daten ohne aktives Polling.

Das UMG 96-EL kann nach dem Firmware-Update als MQTT-Client konfiguriert werden: IP-Adresse des Brokers, Port, Topic-Struktur und optionale TLS-Absicherung werden im Web-Interface hinterlegt. Die Messwerte werden dann als JSON-Payload publiziert. Der genaue Funktionsumfang und unterstützte Firmware-Version ist in den offiziellen Janitza-Release-Notes zu prüfen, da Janitza die Spezifikation weiterentwickelt.

Wann MQTT gegenüber Modbus sinnvoller ist

Beide Protokolle haben ihre Domäne. MQTT liegt vorn, wenn:

• Messdaten an eine Cloud-Plattform oder ein MQTT-fähiges EMS gesendet werden sollen, ohne ein zwischengeschaltetes Gateway programmieren zu müssen
• mehrere Geräte parallel an denselben Broker publishen und ein zentrales System alle Datenströme konsumiert
• das Netzwerk nicht zuverlässig genug für synchrones Polling ist (z. B. Mobilfunk-Anbindung von Aussenstandorten)
• ein Energiemanagement-System wie Node-RED, Home Assistant oder eine proprietäre SCADA-Lösung bereits auf MQTT aufgebaut ist

Modbus bleibt die erste Wahl bei deterministischen SPS-Zyklen, bei bereits bestehenden Gateway-Infrastrukturen und überall dort, wo die Abfrage-Reihenfolge und -Frequenz exakt kontrolliert werden muss.

Stolperfallen aus der Praxis

Die Konfiguration klingt einfacher als sie ist. In der Praxis treten folgende Probleme regelmässig auf:

• Topic-Struktur ohne Konzept: Wer Topics ad hoc vergibt, kämpft später mit uneinheitlichen Pfaden, wenn mehrere Geräte verschiedener Hersteller am selben Broker hängen. Eine klare Namenskonvention – etwa anlage/gebaeude/geraet/messgroesse – sollte vor der ersten Inbetriebnahme festgelegt sein.
• QoS-Level falsch gewählt: QoS 0 («fire and forget») verliert Nachrichten bei Verbindungsunterbrechungen. Für Energiemessung ist QoS 1 oder 2 zu empfehlen, kostet aber höheren Datenverkehr. Der Kompromiss hängt von der Infrastruktur ab.
• TLS-Zertifikate: Self-signed Certificates führen häufig zu Verbindungsproblemen, wenn der Broker das Root-Zertifikat nicht kennt. Öffentliche CA oder ein gut gepflegtes internes PKI sind Voraussetzung für stabile Verbindungen.
• Zeitstempel-Synchronisation: Das UMG 96-EL nutzt NTP. Wenn die NTP-Quelle ausfällt oder nicht erreichbar ist, entstehen Zeitstempel-Driften in der Zeitreihe – besonders kritisch, wenn Messdaten mit Marktdaten korreliert werden sollen.
• Broker-Ausfall und Puffer: MQTT-Clients puffern Nachrichten bei QoS ≥ 1 lokal, bis der Broker wieder erreichbar ist. Der Pufferumfang im Gerät ist begrenzt. Bei längeren Ausfällen gehen Daten verloren. Redundante Broker oder ein Retained-Message-Konzept mildern das Risiko.

Fazit

Die MQTT-Erweiterung des Janitza UMG 96-EL ist ein sinnvoller Schritt in Richtung direkter IoT-Integration. Für Betriebe, die ein MQTT-fähiges Energiemanagementsystem betreiben oder aufbauen wollen, sinkt der Integrationsaufwand spürbar: kein zusätzliches Gateway, keine Poll-Logik, direkter Datenfluss vom Messgerät zur Auswerteplattform.

Die Erwartung, dass damit alle Integrationsprobleme verschwinden, ist jedoch unrealistisch. Topic-Design, QoS-Wahl, Zertifikatsverwaltung und Zeitstempel-Synchronisation erfordern weiterhin sorgfältige Planung. Wer diese Grundlagen setzt, gewinnt mit dem UMG 96-EL ein Gerät, das sowohl klassische Modbus-Umgebungen als auch moderne MQTT-basierte Architekturen bedient.

FAQ

Welche Firmware-Version aktiviert MQTT beim UMG 96-EL?

Janitza veröffentlicht die unterstützten Firmware-Versionen im offiziellen Download-Bereich. Vor dem Update empfiehlt sich ein Blick in die aktuelle Release-Note, da der Funktionsumfang je nach Version variiert.

Kann MQTT und Modbus gleichzeitig am UMG 96-EL betrieben werden?

Nach aktuellem Stand der Gerätedokumentation ist die parallele Nutzung beider Schnittstellen möglich. Die genaue Konfiguration und eventuelle Einschränkungen – etwa bei der Abfratefrequenz – sind im Handbuch zu prüfen.

Welchen MQTT-Broker empfiehlt sich für den Einstieg?

Eclipse Mosquitto ist ein quelloffener, ressourcenschonender Broker, der auf einem Raspberry Pi oder einem kleinen Server betrieben werden kann. Für grössere Installationen mit vielen Geräten bieten sich HiveMQ oder EMQX mit integrierter Persistenz und Monitoring-Schnittstelle an.

Wie verhält sich das UMG 96-EL bei Verbindungsunterbrechung zum Broker?

Bei konfiguriertem QoS ≥ 1 puffert der Client Nachrichten lokal und sendet sie nach Wiederverbindung nach. Der Pufferspeicher ist geräteabhängig begrenzt. Bei längeren Ausfällen – mehrere Stunden bis Tage – sind Datenlücken möglich.