MQTT-Architektur für MeshCore Hessen

Für MeshCore Hessen eignet sich eine Architektur, bei der Funkzugang, Nachrichtenvermittlung und Webdienste getrennte Aufgaben besitzen.

Funkseite

Ein dedizierter MeshCore-Companion stellt die Verbindung zum LoRa-Netz her. Er wird per USB, BLE oder – bei dafür vorgesehener Firmware – über eine unterstützte Netzwerkschnittstelle mit einem Host verbunden.

Gateway-Host

Ein Raspberry Pi kann dauerhaft neben dem Funkgerät laufen. Dort befinden sich die MeshCore-Anbindung, Automatisierungslogik und bei Bedarf der MQTT-Client.

Broker

Der MQTT-Broker kann auf demselben lokalen System oder auf einem externen Server betrieben werden. Für MeshCore Hessen ist ein externer Broker nur dann sinnvoll, wenn die Dienste von mehreren Standorten darauf zugreifen sollen.

Webserver

Webseite und öffentliche Karte müssen nicht direkt auf das Funkgerät zugreifen. Ein Backend kann ausschließlich die dafür freigegebenen Daten aus MQTT beziehungsweise einer Datenbank lesen.

Ausfallszenario

Fällt der externe Server aus, sollte der Raspberry Pi weiterhin mit MeshCore arbeiten können. Ein lokaler Testbot kann deshalb direkt gegen die MeshCore-Schnittstelle arbeiten und MQTT lediglich zusätzlich für Monitoring verwenden.

Keine ungeprüfte Bridge

Es wird nicht automatisch jedes empfangene Funkpaket ins Internet gespiegelt. Welche Daten exportiert werden, wird nach Funktion, Datenschutz und Sicherheitsbedarf ausgewählt.

Ausbau

Diese Trennung erlaubt später weitere Dienste, ohne die Funkhardware jedes Mal neu programmieren zu müssen.

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