Die Firewall entscheidet, nicht die Technik
Modbus TCP und MQTT können beide Zählerwerte transportieren. Der Unterschied liegt in der Richtung des Verbindungsaufbaus.
Bei Modbus TCP fragt ein Client den Zähler ab. Soll dieser Client im Internet stehen, braucht es eine eingehende Verbindung ins Messnetz – also eine Portfreigabe, eine Ausnahme in der Firewall und ein Gespräch mit der IT, das selten kurz ist.
Bei MQTT verbindet sich das Gerät zum Broker. Das ist eine ausgehende Verbindung, wie sie jeder Browser auch aufbaut. Keine Freigabe von aussen, keine exponierten Ports, kein dauerhaftes Loch in der Firewall. Das ist der eigentliche Grund, warum Cloud-Anbindungen über MQTT laufen.
Broker, Topic, Abonnement
MQTT arbeitet mit einem Broker in der Mitte. Das M-Center veröffentlicht Werte unter einem Topic – einem hierarchischen Pfad –, und wer sie braucht, abonniert dieses Topic. Sender und Empfänger kennen einander nie; sie kennen nur den Broker.
Daraus folgt der zweite praktische Vorteil: Ein weiterer Abnehmer – ein zweites Dashboard, eine Analyseplattform, ein Forschungsprojekt – abonniert einfach mit. Am Gerät im Keller ändert sich nichts. Bei Modbus TCP wäre das ein zusätzlicher Client, der zusätzlich pollt.
QoS: wie sicher muss die Zustellung sein?
| QoS 0 | Einmal senden, nicht nachfragen. Für hochfrequente Momentanwerte, bei denen der nächste gleich folgt. |
|---|---|
| QoS 1 | Mindestens einmal zustellen. Doppelte Nachrichten möglich, Verlust nicht. Der übliche Fall für Zählerwerte. |
| QoS 2 | Genau einmal. Höchster Aufwand, selten nötig, wenn die Nachricht ohnehin einen Zeitstempel trägt. |
Für Abrechnungsdaten ist QoS 1 in Kombination mit einem Zeitstempel in der Nutzlast der pragmatische Weg: Eine doppelt angekommene Nachricht lässt sich anhand des Zeitstempels verwerfen, eine verlorene nicht rekonstruieren.
Topics, die einen Gerätetausch überstehen
Ein Topic-Schema wirkt beim Einrichten nebensächlich und bestimmt danach jahrelang, wie gut die Daten nutzbar sind. Die Regel ist einfach: nach Ort und Funktion gliedern, nicht nach Gerätenummer.
Mehr dazu und ein konkretes Schema steht in MQTT-Topics planen.
Vor der Inbetriebnahme klären
- Broker-Adresse, Port und ob TLS verlangt wird
- Zugangsdaten oder Zertifikat, und wer sie verwaltet
- Topic-Schema, abgestimmt mit dem Empfängersystem
- Veröffentlichungsintervall – und ob es zum Auslesezyklus am Feldbus passt
- Was passiert, wenn der Broker eine Stunde nicht erreichbar ist
Die letzte Frage ist die wichtige. Ein Gerät mit lokalem Speicher – das M-Center hat 16 GB – überbrückt einen Ausfall und liefert nach. Ohne Zwischenspeicher ist die Lücke dauerhaft. Die MQTT-Funktion ist lizenzpflichtig und TLS-verschlüsselt.