Publish und Subscribe statt Frage und Antwort
Die meisten Feldbusprotokolle arbeiten nach dem Muster Frage-Antwort: Ein Master fragt, ein Gerät antwortet. MQTT dreht das um. Ein Gerät veröffentlicht seine Werte, ohne zu wissen, ob jemand zuhört. Wer die Werte braucht, abonniert sie beim Broker.
Daraus folgt die wichtigste Eigenschaft: Entkopplung. Ein zweites Dashboard, eine Analyseplattform oder ein Forschungsprojekt kann dieselben Werte abonnieren, ohne dass am Gerät im Keller irgendetwas geändert wird. Bei Modbus wäre das ein zusätzlicher Client, der zusätzlich pollt.
Topics: Pfade, keine Adressen
Ein Topic ist ein hierarchischer Pfad, etwa liegenschaft/haus-a/ug/zaehler-03/wirkenergie-import. Es gibt keine zentrale Registrierung – ein Topic entsteht, indem jemand darauf veröffentlicht.
Abonniert wird mit Platzhaltern: + für eine Ebene, # für alle darunterliegenden. liegenschaft/haus-a/# liefert alles aus Haus A. Das macht die Struktur des Topic-Baums zur eigentlichen Datenarchitektur – und erklärt, warum sich ein durchdachtes Schema auszahlt. Konkrete Empfehlungen stehen in MQTT-Topics planen.
QoS, Retain und Last Will
| QoS 0 | Senden und vergessen. Für Werte, die ohnehin gleich wieder kommen. |
|---|---|
| QoS 1 | Mindestens einmal zustellen. Duplikate möglich, Verlust nicht. Der Normalfall für Zählerwerte. |
| QoS 2 | Genau einmal. Aufwendig, selten nötig. |
| Retain | Der Broker merkt sich den letzten Wert je Topic. Ein neu verbundenes Dashboard sieht sofort Daten statt einer leeren Oberfläche. |
| Last Will | Eine Nachricht, die der Broker veröffentlicht, wenn die Verbindung unerwartet abreisst. Damit ist ein Ausfall sichtbar, statt still zu bleiben. |
Die letzten beiden sind in Messanlagen unterschätzt. Retain löst das Problem des leeren Dashboards nach einem Neustart. Last Will löst das grössere Problem: dass ein ausgefallenes Gerät nicht auffällt, weil Schweigen in einem Publish-Modell wie Normalbetrieb aussieht.
Warum MQTT für Gebäudedaten passt
- Ausgehende Verbindung – keine Firewall-Freigabe von aussen nötig
- Geringer Overhead, funktioniert auch über Mobilfunk
- Mehrere Abnehmer ohne Mehrlast am Gerät
- TLS-Verschlüsselung
- Verträgt unterbrochene Verbindungen
Der erste Punkt ist in der Praxis der entscheidende. Mehr dazu in Zählerdaten in die Cloud.
Was MQTT nicht ist
MQTT ist kein Speicher. Der Broker stellt zu und vergisst – abgesehen von der Retain-Nachricht. Wer Historie braucht, braucht eine Datenbank dahinter oder einen lokalen Zwischenspeicher davor. Das EMU M-Center bringt für diesen Zweck 16 GB mit und kann nach einer Unterbrechung nachliefern.
MQTT ist ausserdem kein Abfrageprotokoll. Ein Wert, den niemand veröffentlicht hat, lässt sich nicht anfordern. Wer Momentanwerte auf Abruf braucht, ist mit Modbus TCP besser bedient – oder nutzt beides parallel.