Topics und Datenmodell planen

Ein gutes MQTT-Datenmodell verhindert, dass später jede Anwendung eigene inkompatible Topicnamen und Payloadformate erfindet.

Funktionsbereiche

Topics werden nach Funktion statt nach zufälligen Programmnamen gegliedert. Sinnvolle Kategorien können Infrastrukturstatus, Telemetrie, Gatewaystatus, Botereignisse und öffentliche Kartendaten sein.

Knotenkennungen

Ein Anzeigename ist nicht immer eine stabile technische Kennung. Für interne Zuordnung sollte eine geeignete stabile MeshCore-Identität verwendet werden, während der Anzeigename ein zusätzliches Feld bleibt.

JSON-Payloads

Für komplexere Ereignisse ist JSON praktisch. Ein Datensatz kann Zeitstempel, Gateway, Ereignistyp, Knotenkennung und die tatsächlich benötigten Werte enthalten.

Schema-Version

Ein Versionsfeld erleichtert spätere Änderungen. Anwendungen können dadurch erkennen, ob sie ein Payloadformat verstehen.

Rohdaten und öffentliche Daten

Interne Rohdaten werden von bereits gefilterten öffentlichen Daten getrennt. Eine Webseite sollte nicht direkt Zugriff auf den vollständigen internen Eventstrom erhalten.

Retained Messages

Retain eignet sich für Zustandsinformationen wie „Gateway online“ oder den letzten bekannten Messwert. Für jedes einzelne Chatereignis ist Retain dagegen normalerweise nicht die passende Semantik.

Dokumentation

Das produktive Topic-Schema von MeshCore Hessen wird als eigene technische Spezifikation geführt und erst nach Implementierung als verbindlich markiert.

Quellen und Aktualisierung

Diese Seite wurde eigenständig für MeshCore Hessen formuliert. Offizielle MeshCore-Funktionen werden von projektspezifischen MeshCore-Hessen-Diensten getrennt. MQTT und Bots werden ausdrücklich nicht als zwingender Bestandteil des MeshCore-Protokolls dargestellt.

Letzte inhaltliche Prüfung: 18. August 2026