# MQTT & Internet MeshCore Hessen – MQTT & Internet # 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 - [MeshCore – offizielle Dokumentation](https://github.com/meshcore-dev/MeshCore/tree/main/docs) - [meshcore-cli – offizielles Projekt](https://github.com/meshcore-dev/meshcore-cli) - [Bundesnetzagentur – Allgemeinzuteilungen](https://www.bundesnetzagentur.de/DE/Fachthemen/Telekommunikation/Frequenzen/Allgemeinzuteilungen/start.html) - [Bundesnetzagentur – Vfg. 91/2025](https://www.bundesnetzagentur.de/DE/Fachthemen/Telekommunikation/Frequenzen/Allgemeinzuteilungen/_DL/vfg91_2025.pdf) - [MeshCore Wiki DE – ergänzende Communityquelle](https://meshcore-de.fyi/start) **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 # 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 - [MeshCore – offizielle Dokumentation](https://github.com/meshcore-dev/MeshCore/tree/main/docs) - [meshcore-cli – offizielles Projekt](https://github.com/meshcore-dev/meshcore-cli) - [MeshCore Wiki DE – ergänzende Communityquelle](https://meshcore-de.fyi/start) **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 # 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 - [MeshCore – offizielle Dokumentation](https://github.com/meshcore-dev/MeshCore/tree/main/docs) - [meshcore-cli – offizielles Projekt](https://github.com/meshcore-dev/meshcore-cli) - [MeshCore Wiki DE – ergänzende Communityquelle](https://meshcore-de.fyi/start) **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 # 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 - [MeshCore – offizielle Dokumentation](https://github.com/meshcore-dev/MeshCore/tree/main/docs) - [meshcore-cli – offizielles Projekt](https://github.com/meshcore-dev/meshcore-cli) - [MeshCore Wiki DE – ergänzende Communityquelle](https://meshcore-de.fyi/start) **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 # 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 - [MeshCore – offizielle Dokumentation](https://github.com/meshcore-dev/MeshCore/tree/main/docs) - [MeshCore Wiki DE – ergänzende Communityquelle](https://meshcore-de.fyi/start) **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 # 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 - [MeshCore – offizielle Dokumentation](https://github.com/meshcore-dev/MeshCore/tree/main/docs) - [meshcore-cli – offizielles Projekt](https://github.com/meshcore-dev/meshcore-cli) - [MeshCore Wiki DE – ergänzende Communityquelle](https://meshcore-de.fyi/start) **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 # 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 - [MeshCore – offizielle Dokumentation](https://github.com/meshcore-dev/MeshCore/tree/main/docs) - [meshcore-cli – offizielles Projekt](https://github.com/meshcore-dev/meshcore-cli) - [MeshCore Wiki DE – ergänzende Communityquelle](https://meshcore-de.fyi/start) **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 # 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 - [MeshCore – offizielle Dokumentation](https://github.com/meshcore-dev/MeshCore/tree/main/docs) - [meshcore-cli – offizielles Projekt](https://github.com/meshcore-dev/meshcore-cli) - [MeshCore Wiki DE – ergänzende Communityquelle](https://meshcore-de.fyi/start) **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