MQTT & Internet

MeshCore Hessen – MQTT & Internet

Integration

Integration

MQTT-Broker sicher betreiben

Ein MQTT-Broker ist zentrale Infrastruktur für angeschlossene Internetdienste. Wird er öffentlich erreichbar betrieben, muss er entsprechend abgesichert werden.

Brokerwahl

Mosquitto ist ein verbreiteter Open-Source-MQTT-Broker und eignet sich für kleine bis große Installationen. Die konkrete Wahl ist unabhängig von MeshCore.

Keine anonymen Schreibrechte

Anonyme Clients sollten auf einem produktiven MeshCore-Hessen-Broker nicht pauschal veröffentlichen dürfen.

Benutzerkonten beziehungsweise andere unterstützte Authentifizierungsmechanismen werden nach Dienst getrennt.

ACL

Access Control Lists begrenzen, welche Topics ein Client lesen oder beschreiben darf. Eine öffentliche Kartenanwendung benötigt beispielsweise keine administrativen Schreibrechte.

TLS

Verbindungen über nicht vertrauenswürdige Netze sollten TLS verwenden. Zertifikatsmanagement und Erneuerung müssen zum Serverbetrieb gehören.

Firewall

Der Brokerport wird nur so weit geöffnet wie erforderlich. Wenn ausschließlich lokale Anwendungen zugreifen, muss MQTT nicht aus dem Internet erreichbar sein.

Protokollierung

Verbindungsfehler und Authentifizierungsprobleme werden geloggt. Passwörter und komplette sensible Payloads gehören dagegen nicht unkontrolliert in Logs.

Backup

Brokerkonfiguration, ACL und Zugangskonzept werden gesichert. Ob MQTT-Nachrichten selbst persistent gespeichert werden, hängt von Retain-, Session- und Anwendungsdesign ab.

Quellen, Rechte und redaktionelle Prüfung

Redaktioneller Hinweis: Diese Seite ist eine eigenständige Darstellung für MeshCore Hessen. Sachinformationen wurden anhand der oben genannten Quellen geprüft. Texte, Bilder und die Gliederung des MeshCore Wiki DE wurden nicht übernommen; die Seite wird nur als ergänzende Communityquelle zur Faktenkontrolle genannt. Für technische Details hat die aktuelle offizielle MeshCore-Dokumentation Vorrang. Deutschlandbezogene Funkrechtsangaben werden an den Veröffentlichungen der Bundesnetzagentur geprüft.

Urheberrecht: Technische Begriffe, Protokollnamen, Befehlsnamen, Zahlenwerte und andere notwendige Sachangaben werden unverändert verwendet, soweit dies für fachliche Richtigkeit erforderlich ist. Es werden keine längeren fremden Textpassagen oder Bilder reproduziert.

Prüfstand: 18. August 2026

Integration

Was ist MQTT?

MQTT ist ein leichtgewichtiges Nachrichtenprotokoll nach dem Publish/Subscribe-Prinzip. Es wird häufig für Telemetrie, Sensorik und die Kopplung verschiedener Dienste verwendet.

Broker

Im Mittelpunkt steht ein MQTT-Broker. Anwendungen verbinden sich mit ihm und veröffentlichen Nachrichten in sogenannten Topics oder abonnieren Topics.

Publisher und Subscriber

Ein Publisher sendet beispielsweise einen Messwert an ein Topic. Ein Subscriber, der dieses Topic abonniert hat, erhält die Nachricht.

Eine Anwendung kann gleichzeitig Publisher und Subscriber sein.

Topics

Topics bilden eine hierarchische Namensstruktur. Für ein MeshCore-Hessen-System könnten getrennte Bereiche für Telemetrie, Betriebsstatus oder interne Automatisierungsereignisse vorgesehen werden.

Konkrete produktive Topicnamen werden erst mit der tatsächlich eingesetzten Bridge festgelegt und nicht als vermeintlicher MeshCore-Standard erfunden.

MQTT ist nicht MeshCore

MQTT ist kein Bestandteil des LoRa-Mesh-Protokolls selbst. Ein MQTT-Broker kennt nicht automatisch MeshCore-Knoten, Kanäle oder Verschlüsselung.

Dazwischen benötigt man eine Anwendung oder Bridge, die MeshCore-Daten versteht und gezielt in MQTT-Nachrichten umsetzt beziehungsweise umgekehrt.

Nutzen

MQTT kann eine saubere Entkopplung ermöglichen: Ein MeshCore-Gateway liefert Ereignisse an den Broker, während Karte, Monitoring und Bot unabhängig davon abonnieren.

Sicherheit

Ein öffentlich erreichbarer Broker darf nicht anonym mit Schreibrechten betrieben werden. Authentifizierung, TLS, Topic-Berechtigungen und Netzwerkzugriff gehören zum Betriebskonzept.

Quellen, Rechte und redaktionelle Prüfung

Redaktioneller Hinweis: Diese Seite ist eine eigenständige Darstellung für MeshCore Hessen. Sachinformationen wurden anhand der oben genannten Quellen geprüft. Texte, Bilder und die Gliederung des MeshCore Wiki DE wurden nicht übernommen; die Seite wird nur als ergänzende Communityquelle zur Faktenkontrolle genannt. Für technische Details hat die aktuelle offizielle MeshCore-Dokumentation Vorrang. Deutschlandbezogene Funkrechtsangaben werden an den Veröffentlichungen der Bundesnetzagentur geprüft.

Urheberrecht: Technische Begriffe, Protokollnamen, Befehlsnamen, Zahlenwerte und andere notwendige Sachangaben werden unverändert verwendet, soweit dies für fachliche Richtigkeit erforderlich ist. Es werden keine längeren fremden Textpassagen oder Bilder reproduziert.

Prüfstand: 18. August 2026

Integration

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, Rechte und redaktionelle Prüfung

Redaktioneller Hinweis: Diese Seite ist eine eigenständige Darstellung für MeshCore Hessen. Sachinformationen wurden anhand der oben genannten Quellen geprüft. Texte, Bilder und die Gliederung des MeshCore Wiki DE wurden nicht übernommen; die Seite wird nur als ergänzende Communityquelle zur Faktenkontrolle genannt. Für technische Details hat die aktuelle offizielle MeshCore-Dokumentation Vorrang. Deutschlandbezogene Funkrechtsangaben werden an den Veröffentlichungen der Bundesnetzagentur geprüft.

Urheberrecht: Technische Begriffe, Protokollnamen, Befehlsnamen, Zahlenwerte und andere notwendige Sachangaben werden unverändert verwendet, soweit dies für fachliche Richtigkeit erforderlich ist. Es werden keine längeren fremden Textpassagen oder Bilder reproduziert.

Prüfstand: 18. August 2026

Integration

MQTT ist kein Pflichtbestandteil von MeshCore

Bei Dokumentationen zu Mesh-Systemen entsteht leicht der Eindruck, ein MQTT-Server gehöre zwingend zum Netz. Für MeshCore wäre das irreführend.

MeshCore ohne MQTT

Ein normales MeshCore-Netz aus Companions, Repeatern und Room Servern benötigt keinen MQTT-Broker.

Warum trotzdem MQTT?

MQTT kann bei MeshCore Hessen als interne Integrationsschicht eingesetzt werden, wenn mehrere eigene Dienste dieselben Ereignisse nutzen sollen.

Keine Protokollgleichsetzung

MeshCore-Pakete werden nicht zu MQTT-Paketen und ein MQTT-Broker routet keine LoRa-Nachrichten zwischen Repeatern.

Internetabhängigkeit vermeiden

Eine Kernfunktion wie ein lokaler Empfangstest sollte möglichst auch dann funktionieren, wenn der externe Broker oder VPS nicht erreichbar ist.

Dokumentation

Im öffentlichen Wiki wird deshalb klar zwischen „MeshCore-Funktion“ und „MeshCore-Hessen-Zusatzdienst“ unterschieden.

Diese Kennzeichnung verhindert, dass Nutzer lokale Projektentscheidungen fälschlich als Voraussetzung des offiziellen MeshCore-Projekts verstehen.

Quellen, Rechte und redaktionelle Prüfung

Redaktioneller Hinweis: Diese Seite ist eine eigenständige Darstellung für MeshCore Hessen. Sachinformationen wurden anhand der oben genannten Quellen geprüft. Texte, Bilder und die Gliederung des MeshCore Wiki DE wurden nicht übernommen; die Seite wird nur als ergänzende Communityquelle zur Faktenkontrolle genannt. Für technische Details hat die aktuelle offizielle MeshCore-Dokumentation Vorrang. Deutschlandbezogene Funkrechtsangaben werden an den Veröffentlichungen der Bundesnetzagentur geprüft.

Urheberrecht: Technische Begriffe, Protokollnamen, Befehlsnamen, Zahlenwerte und andere notwendige Sachangaben werden unverändert verwendet, soweit dies für fachliche Richtigkeit erforderlich ist. Es werden keine längeren fremden Textpassagen oder Bilder reproduziert.

Prüfstand: 18. August 2026

Integration

Gateway ausfallsicher betreiben

Ein Gateway, das Bots oder Monitoring bereitstellt, sollte nach Strom- oder Netzwerkausfällen ohne manuellen Eingriff wieder starten.

Dienstverwaltung

Auf Linux-Systemen werden dauerhafte Gatewayprozesse als verwaltete Dienste betrieben, beispielsweise über systemd. Dadurch können sie automatisch beim Booten starten und bei Fehlern kontrolliert neu gestartet werden.

Hardwareverbindung

USB-Gerätenamen können sich ändern. Wo möglich, werden stabile Gerätepfade beziehungsweise eindeutige Geräteattribute verwendet.

Abhängigkeiten

Ein Bot sollte nicht dauerhaft abstürzen, nur weil MQTT oder Internet kurzzeitig nicht erreichbar sind. Wiederverbindung und Backoff gehören zur Anwendung.

Watchdog

Für kritische Prozesse kann ein Healthcheck überwachen, ob die MeshCore-Verbindung und der Dienst noch reagieren.

Offline-Puffer

Ob Ereignisse bei Internetausfall lokal zwischengespeichert werden, hängt vom Dienst ab. Für Statusdaten kann dies sinnvoll sein; für Chatdaten sind Datenschutz und gewünschte Semantik vorher zu klären.

Zeit

Der Host benötigt eine nachvollziehbare Uhrzeit. Nach längerem Internetausfall sollte berücksichtigt werden, wie Zeit synchronisiert beziehungsweise validiert wird.

Wartung

Betriebssystem, Bibliotheken und Botsoftware erhalten definierte Update- und Backupabläufe. Ein einmal eingerichteter Raspberry Pi ist keine wartungsfreie Appliance.

Quellen, Rechte und redaktionelle Prüfung

Redaktioneller Hinweis: Diese Seite ist eine eigenständige Darstellung für MeshCore Hessen. Sachinformationen wurden anhand der oben genannten Quellen geprüft. Texte, Bilder und die Gliederung des MeshCore Wiki DE wurden nicht übernommen; die Seite wird nur als ergänzende Communityquelle zur Faktenkontrolle genannt. Für technische Details hat die aktuelle offizielle MeshCore-Dokumentation Vorrang. Deutschlandbezogene Funkrechtsangaben werden an den Veröffentlichungen der Bundesnetzagentur geprüft.

Urheberrecht: Technische Begriffe, Protokollnamen, Befehlsnamen, Zahlenwerte und andere notwendige Sachangaben werden unverändert verwendet, soweit dies für fachliche Richtigkeit erforderlich ist. Es werden keine längeren fremden Textpassagen oder Bilder reproduziert.

Prüfstand: 18. August 2026

Integration

Datenschutz bei Internet-Bridges

Eine Internet-Bridge verändert den Charakter von Funkdaten. Informationen, die ursprünglich nur lokal über LoRa empfangen wurden, können durch Speicherung oder Veröffentlichung weltweit verfügbar werden.

Datensparsamkeit

Es werden nur Daten exportiert, die für den jeweiligen Dienst benötigt werden. Eine Coverage-Karte benötigt beispielsweise nicht automatisch Nachrichteninhalte.

Positionen

Standortdaten von öffentlichen Infrastrukturknoten können bewusst veröffentlicht werden. Positionsdaten persönlicher Companions werden nicht ohne klare Grundlage automatisch auf eine öffentliche Karte übertragen.

Nachrichten

Private oder verschlüsselte Kommunikationsinhalte gehören nicht in allgemeine Monitoring- oder Debugdatenbanken.

Metadaten

Auch ohne Nachrichteninhalt können Zeit, Knotenkennung und Kommunikationsbeziehungen sensible Informationen ergeben.

Aufbewahrung

Für jede gespeicherte Datenklasse wird festgelegt, wie lange sie benötigt wird. „Vielleicht später interessant“ ist kein ausreichendes technisches Löschkonzept.

Zugriffsrechte

Interne Diagnoseinformationen werden von öffentlichen Daten getrennt. Administratoren erhalten nur die Rechte, die sie tatsächlich benötigen.

Transparenz

Wenn MeshCore Hessen Daten über eine Internet-Bridge sammelt oder veröffentlicht, sollte dies für die Community verständlich dokumentiert sein.

Quellen, Rechte und redaktionelle Prüfung

Redaktioneller Hinweis: Diese Seite ist eine eigenständige Darstellung für MeshCore Hessen. Sachinformationen wurden anhand der oben genannten Quellen geprüft. Texte, Bilder und die Gliederung des MeshCore Wiki DE wurden nicht übernommen; die Seite wird nur als ergänzende Communityquelle zur Faktenkontrolle genannt. Für technische Details hat die aktuelle offizielle MeshCore-Dokumentation Vorrang. Deutschlandbezogene Funkrechtsangaben werden an den Veröffentlichungen der Bundesnetzagentur geprüft.

Urheberrecht: Technische Begriffe, Protokollnamen, Befehlsnamen, Zahlenwerte und andere notwendige Sachangaben werden unverändert verwendet, soweit dies für fachliche Richtigkeit erforderlich ist. Es werden keine längeren fremden Textpassagen oder Bilder reproduziert.

Prüfstand: 18. August 2026

Integration

MeshCore und Internetanbindung richtig einordnen

MeshCore funktioniert grundsätzlich ohne Internet. Das LoRa-Mesh und eine zusätzliche Internetanbindung sind deshalb zwei getrennte Ebenen.

Das Funknetz bleibt eigenständig

Companions, Repeater, Room Server und Sensor-Nodes kommunizieren über MeshCore und LoRa. Ein Ausfall von DSL, Mobilfunk oder einem Server muss nicht automatisch das lokale Funknetz außer Betrieb setzen.

Internet als Zusatz

Ein Internetdienst kann zusätzliche Funktionen ermöglichen: Daten sammeln, Karten aktualisieren, Statistiken speichern, externe Anwendungen anbinden oder automatisierte Dienste bereitstellen.

Diese Funktionen sollten so geplant werden, dass das eigentliche Funknetz nicht unnötig von ihnen abhängig wird.

Gateway statt „Internet-Repeater“

Ein Rechner wie Raspberry Pi oder Server kann über einen Companion beziehungsweise eine geeignete Host-Schnittstelle mit MeshCore interagieren. Er wird dadurch nicht automatisch zu einem LoRa-Repeater.

Schnittstellen

Die offizielle meshcore-cli kann Companion-Nodes über BLE, TCP oder Serial ansprechen. Für eigene Anwendungen existieren außerdem offizielle beziehungsweise projektnahe Bibliotheken und Protokolldokumentationen.

Krisenkommunikation

Für MeshCore Hessen ist die Trennung besonders wichtig. Internetdienste können Komfort und Übersicht erhöhen, aber die lokale Kommunikation soll gerade auch dann sinnvoll bleiben, wenn Internetzugänge ausfallen.

Architekturregel

Jeder neue Onlinedienst wird deshalb mit zwei Fragen bewertet: Was verbessert er im Normalbetrieb? Und was funktioniert im Mesh noch, wenn dieser Dienst vollständig ausfällt?

Quellen, Rechte und redaktionelle Prüfung

Redaktioneller Hinweis: Diese Seite ist eine eigenständige Darstellung für MeshCore Hessen. Sachinformationen wurden anhand der oben genannten Quellen geprüft. Texte, Bilder und die Gliederung des MeshCore Wiki DE wurden nicht übernommen; die Seite wird nur als ergänzende Communityquelle zur Faktenkontrolle genannt. Für technische Details hat die aktuelle offizielle MeshCore-Dokumentation Vorrang. Deutschlandbezogene Funkrechtsangaben werden an den Veröffentlichungen der Bundesnetzagentur geprüft.

Urheberrecht: Technische Begriffe, Protokollnamen, Befehlsnamen, Zahlenwerte und andere notwendige Sachangaben werden unverändert verwendet, soweit dies für fachliche Richtigkeit erforderlich ist. Es werden keine längeren fremden Textpassagen oder Bilder reproduziert.

Prüfstand: 18. August 2026

Integration

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, Rechte und redaktionelle Prüfung

Redaktioneller Hinweis: Diese Seite ist eine eigenständige Darstellung für MeshCore Hessen. Sachinformationen wurden anhand der oben genannten Quellen geprüft. Texte, Bilder und die Gliederung des MeshCore Wiki DE wurden nicht übernommen; die Seite wird nur als ergänzende Communityquelle zur Faktenkontrolle genannt. Für technische Details hat die aktuelle offizielle MeshCore-Dokumentation Vorrang. Deutschlandbezogene Funkrechtsangaben werden an den Veröffentlichungen der Bundesnetzagentur geprüft.

Urheberrecht: Technische Begriffe, Protokollnamen, Befehlsnamen, Zahlenwerte und andere notwendige Sachangaben werden unverändert verwendet, soweit dies für fachliche Richtigkeit erforderlich ist. Es werden keine längeren fremden Textpassagen oder Bilder reproduziert.

Prüfstand: 18. August 2026