# Diagnose # Störungsprotokoll und Wartungsablauf Ein regionales Communitynetz profitiert von einem einfachen, einheitlichen Störungsprotokoll. Dadurch werden wiederkehrende Probleme und kritische Standorte sichtbar. ## Störung erfassen Ein Eintrag enthält mindestens Datum und Uhrzeit, betroffenen Knoten, beobachtetes Problem, meldende Person beziehungsweise internen Kontakt und erste Prüfergebnisse. ## Auswirkung Es wird festgehalten, ob nur Administration, lokale Versorgung oder eine wichtige Backbone-Verbindung betroffen ist. ## Maßnahmen Jeder durchgeführte Schritt wird dokumentiert. Dazu gehören Neustart, Firmwareupdate, Antennenwechsel, Akkuwechsel oder Regionsänderung. ## Ergebnis Nach Abschluss wird die tatsächliche Ursache angegeben, sofern sie ermittelt werden konnte. „Nach Neustart wieder gut“ ist eine Maßnahme, aber noch keine bewiesene Ursache. ## Wiederholung Mehrere ähnliche Vorfälle am selben Standort können auf ein grundlegendes Problem hinweisen, beispielsweise Energieversorgung, Feuchtigkeit oder instabile Firmware. ## Wartungsfenster Geplante Änderungen an wichtigen Repeatern sollten angekündigt werden, wenn dadurch ein Netzbereich vorübergehend ausfallen kann. ## Wissensbasis Gelöste, allgemein nützliche Fehlerfälle können anonymisiert in das öffentliche Wiki übernommen werden. Standort- oder zugangssensible Details bleiben im internen Betriebsprotokoll. ## 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 # Neighbor Discovery und Pfade diagnostizieren Die Kenntnis realer Repeater-Nachbarn ist eine wichtige Grundlage für Routingdiagnose und Netzplanung. ## Neighbor Discovery Aktuelle MeshCore-Infrastruktur kann direkt erreichbare Repeater-Nachbarn suchen beziehungsweise anzeigen. Das Ergebnis beschreibt die unmittelbare Funknachbarschaft des betreffenden Knotens. ## Erwartung und Realität Die Planungskarte kann zwei Repeater als ideale Nachbarn zeigen. Wenn sie sich real nicht sehen, werden Antennen, Geländeprofil, Funkparameter und lokale Störungen untersucht. ## Pfade Direktkommunikation kann bekannte Routingpfade verwenden. Ein alter Pfad kann nach Änderungen im Netz ungültig werden. ## Pfad neu entdecken Die Companion-Werkzeuge bieten Funktionen zur Pfadentdeckung beziehungsweise zum Zurücksetzen. Damit kann getestet werden, ob ein neuer Weg gefunden wird. ## Mobile Infrastruktur Ein Repeater, der seinen Standort ändert, kann gelernte Pfade destabilisieren. Das ist ein weiterer Grund, Backbone-Repeater stationär zu betreiben. ## Topologie dokumentieren Gemessene Nachbarbeziehungen werden in der Infrastrukturkarte gespeichert. So entsteht mit der Zeit eine reale Topologie statt einer reinen Reichweitenschätzung. ## Veränderungen Verschwindet eine langjährig stabile Nachbarschaft, ist das ein konkretes Diagnoseereignis. Änderungen an Antenne, Firmware, Vegetation oder Standort können gezielt geprüft werden. ## 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 # Nachricht kommt nicht an Eine nicht zugestellte Nachricht kann mehrere Ursachen haben: Zielidentität, Kanal, Funkweg, Routing, Regionsbegrenzung oder temporäre Funkstörung. ## Direktnachricht Bei einer Direktnachricht wird geprüft, ob der richtige Kontakt ausgewählt ist und ob ein alter gespeicherter Pfad problematisch sein könnte. Die aktuelle CLI bietet Funktionen zur Pfadermittlung und zum Zurücksetzen eines Kontaktpfades. ## Gruppenkanal Bei Kanalnachrichten müssen die Teilnehmer denselben Kanal beziehungsweise Schlüssel verwenden. Gleich aussehende Kanalnamen garantieren bei privaten Kanälen nicht denselben Schlüssel. ## Scope Bei scoped Flood-Verkehr kann eine Regions-/Scope-Konfiguration die Weiterleitung bewusst begrenzen. Ein physisch erreichbarer Repeater muss deshalb nicht jedes Paket transportieren. ## Ziel offline MeshCore ist kein zentraler Mobilfunkdienst mit garantierter permanenter Zustellung. Ist das Ziel nicht erreichbar, kann eine Nachricht ausbleiben. ## Paketverlust LoRa-Funk ist nicht verlustfrei. Kollisionen und Störungen können einzelne Pakete betreffen. ## Wiederholbarer Test Für die Diagnose werden mehrere definierte Testnachrichten gesendet und Zeitpunkt, Pfad beziehungsweise Antwort dokumentiert. Ein einzelner Fehlschlag reicht nicht zur Bewertung eines gesamten Standortes. ## 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 # Radio- und Paketstatistiken auswerten MeshCore-Infrastruktur stellt Statistiken bereit, die bei der Diagnose helfen. Zahlen sollten jedoch immer im zeitlichen und topologischen Kontext gelesen werden. ## RSSI RSSI beschreibt die empfangene Signalleistung. Ein stärkerer Wert kann auf einen besseren Link hindeuten, sagt allein aber nichts über Kollisionen oder zeitweise Störungen. ## SNR SNR beschreibt das Signal-Rausch-Verhältnis. LoRa kann auch bei negativen Werten noch decodieren. Wie viel Reserve vorhanden ist, hängt von den Funkparametern ab. ## Noise Floor Ein erhöhter Rauschpegel kann die nutzbare Linkreserve reduzieren. Vergleiche zu verschiedenen Zeiten können lokale Störsituationen sichtbar machen. ## Uptime Eine unerwartet kurze Uptime weist auf Neustart, Stromausfall oder Reset hin. Bei Solar-Repeatern kann dies ein wichtiges Indiz für Energieprobleme sein. ## Paketstatistik Sende- und Empfangszähler helfen, ungewöhnlich hohe Last oder fehlende Aktivität zu erkennen. Ohne Vergleichswert eines normalen Zeitraums sind absolute Zahlen aber schwer einzuordnen. ## Queue Warteschlangeninformationen können Hinweise geben, wenn Pakete schneller anfallen als sie verarbeitet beziehungsweise gesendet werden können. ## Baseline Für wichtige MeshCore-Hessen-Standorte sollte nach stabiler Inbetriebnahme eine Baseline dokumentiert werden. Spätere Abweichungen lassen sich dann wesentlich leichter erkennen. ## 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 # Companion verbindet sich nicht Wenn App oder CLI den Companion nicht erreicht, liegt das Problem zunächst zwischen Benutzergerät und Companion – noch nicht im LoRa-Mesh. ## Rolle prüfen Zuerst wird geprüft, ob tatsächlich ein Companion-Build installiert ist. Ein Repeater oder Room Server verhält sich nicht wie ein normaler BLE-Companion. ## BLE Bei BLE werden Bluetooth, Betriebssystemberechtigungen und eventuell bereits bestehende Verbindungen geprüft. Ein Companion kann je nach Implementierung nicht beliebig viele gleichzeitige Clientverbindungen akzeptieren. ## USB/Serial Bei serieller Verbindung werden Datenkabel, Port und Zugriffsrechte geprüft. Ein Kabel, das ein Gerät lädt, muss nicht zwingend Daten übertragen. ## CLI-Transport Die offizielle meshcore-cli unterstützt für Companion-Verbindungen BLE, TCP und Serial. Der ausgewählte Transport muss zur tatsächlich laufenden Schnittstelle passen. ## Neustart Ein kontrollierter Neustart von Companion und Client kann festhängende Verbindungen lösen. Er ersetzt aber keine Ursachenanalyse, wenn das Problem regelmäßig wiederkehrt. ## Firmwarestand Hardwaremodell und Firmwarebuild werden kontrolliert. Ein Build für ein ähnlich benanntes Board kann falsche Pin- oder Funkkonfiguration enthalten. ## Erst danach LoRa prüfen Solange der Client den Companion nicht zuverlässig bedienen kann, sind Tests von Kanälen, Kontakten und Routing wenig aussagekräftig. ## 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 # Repeater ist nicht erreichbar Ein Repeater kann funkseitig, administrativ oder vollständig ausgefallen sein. Diese Fälle sollten getrennt werden. ## Advert fehlt Ein fehlendes Advert bedeutet nicht automatisch, dass der Repeater ausgeschaltet ist. Advert-Intervalle und Flood-Verhalten können geändert worden sein. ## Direkter Nachbar Wenn möglich, wird geprüft, ob ein bekannter benachbarter Repeater den Standort noch als Nachbarn sieht. ## Remote-Administration Scheitert nur der Remote-Login, kann die Repeaterfunktion trotzdem weiterlaufen. Zugangsdaten, Berechtigungen und Routing zum Administrationsziel werden getrennt geprüft. ## Stromversorgung Bei Solarstandorten sind Akkuspannung, Wetterverlauf und letzter bekannter Telemetriestand wichtige Hinweise. ## Neustarts Core-Statistiken beziehungsweise Uptime können häufige Neustarts sichtbar machen, sofern der Knoten wieder erreichbar wird. ## Vor-Ort-Zugriff Bei kritischer Infrastruktur sollte bekannt sein, wie ein lokaler serieller Zugriff hergestellt werden kann. Dieser bietet mehr Diagnosemöglichkeiten als Remote-Kommandos. ## Nicht sofort löschen Ein `erase` beziehungsweise vollständiges Löschen des Dateisystems ist keine normale Reparaturmaßnahme. Vor solchen Schritten werden Konfiguration und Identitätsfolgen geklärt. ## 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 # Kein Funkkontakt trotz funktionierendem Companion Wenn der Companion lokal funktioniert, aber keine MeshCore-Gegenstelle erreicht, wird die Funkseite untersucht. ## Antenne Vor jedem Sendetest wird geprüft, ob die richtige LoRa-Antenne angeschlossen beziehungsweise aktiv ist. Antennenanschlüsse und Umschaltmöglichkeiten sind boardspezifisch. ## Frequenzvariante Die Hardware muss zum verwendeten Frequenzbereich passen. Eine falsche Regionalvariante kann nicht durch Software „repariert“ werden. ## Funkparameter Frequenz, Bandbreite, Spreading Factor und Coding Rate müssen kompatibel sein. ## Nahbereichstest Zwei bekannte Geräte werden mit etwas Abstand getestet. Extrem dicht nebeneinander ist nicht immer die beste Testbedingung; ein normaler Raum- oder Außenabstand ist sinnvoller. ## Advert versus Nachricht Das Sehen eines Adverts beweist Empfang in einer Richtung. Für einen vollständigen Test wird eine bidirektionale Kommunikation beziehungsweise erwartete Bestätigung geprüft. ## Standort Funktioniert der Nahbereich, aber nicht der geplante Fernweg, werden Gelände, Antennenhöhe, Kabel und Störungen untersucht. ## Repeater nicht vorschnell beschuldigen Wenn zwei Endgeräte schon direkt nicht mit identischen Einstellungen kommunizieren, ist Routing noch nicht die erste Fehlerquelle. ## 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 # Systematische Fehlersuche im Mesh MeshCore-Probleme lassen sich schneller lösen, wenn Funk, Client, Routing und Infrastruktur getrennt geprüft werden. ## Problem genau beschreiben „MeshCore geht nicht“ ist keine Diagnose. Hilfreich sind konkrete Aussagen wie: Companion wird per BLE gefunden, aber Kontakt B antwortet nicht; oder Repeater ist seriell erreichbar, sendet aber keine erwarteten Adverts. ## Ebene 1: Strom und Hardware Zuerst werden Versorgung, Antenne, Stecker und offensichtliche Hardwarefehler geprüft. ## Ebene 2: Clientverbindung Beim Companion wird geprüft, ob App beziehungsweise CLI zuverlässig mit dem Gerät verbunden ist. ## Ebene 3: Funkparameter Zwei Geräte müssen kompatible Frequenz-, Bandbreiten-, SF- und Coding-Rate-Einstellungen verwenden. ## Ebene 4: Nahbereich Ein direkter Test in kurzer Entfernung zeigt, ob grundsätzlich Funkkommunikation möglich ist. ## Ebene 5: Routing Erst wenn direkter Funk funktioniert, werden Pfade, Repeater, Flooding und Regionsregeln untersucht. ## Ebene 6: Netzlast und Störungen Bei sporadischen Fehlern werden Radio- und Paketstatistiken, Noise Floor und zeitliche Muster betrachtet. ## Eine Änderung nach der anderen Wer gleichzeitig Firmware, Antenne, Frequenz und Standort ändert, weiß anschließend nicht, welche Maßnahme geholfen hat. ## Protokoll Hardware, Firmware, Konfiguration, Uhrzeit und Testergebnis werden notiert. Das erleichtert Community-Support und verhindert wiederholtes Probieren derselben Schritte. ## 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 # Logs und lokale Diagnose Logs sind besonders hilfreich, wenn ein Problem nur sporadisch auftritt oder Remote-Diagnose nicht genügend Details liefert. ## Direkter serieller Zugriff Die offizielle Infrastruktur-CLI stellt lokal über Serial umfassende Diagnosemöglichkeiten bereit. Die meshcore-cli-Dokumentation weist darauf hin, dass nicht alle lokalen Firmware-CLI-Funktionen remote verfügbar sind. ## Paketlogging Paketlogs können zeigen, welche Ereignisse der Repeater tatsächlich sieht beziehungsweise verarbeitet. Sie sollten nur so lange wie nötig aufgezeichnet werden, um Datenmenge und mögliche sensible Metadaten zu begrenzen. ## Zeitbezug Logs sind nur dann wirklich hilfreich, wenn Uhrzeit und Zeitzone nachvollziehbar sind. Bei einem Test wird der genaue Zeitpunkt der gesendeten Nachricht notiert. ## Datenschutz Öffentlich gepostete Logs können Knotennamen, IDs, Positions- oder Kommunikationsmetadaten enthalten. Vor Veröffentlichung werden sie geprüft und nötigenfalls anonymisiert. ## Vergleich Bei einem Routingproblem sind Logs von zwei benachbarten Infrastrukturknoten oft hilfreicher als ein einzelner Log. Dadurch lässt sich erkennen, an welcher Stelle ein Paket nicht weiterkommt. ## Nicht interpretieren ohne Kontext Ein einzelner Warnhinweis muss nicht die Ursache des beobachteten Problems sein. Firmwareversion, Hardware und unmittelbar vorhergehende Ereignisse gehören zur Auswertung. ## Support Für eine Entwickler- oder Communityanfrage werden nur die relevanten Logausschnitte zusammen mit reproduzierbaren Schritten bereitgestellt. Riesige unkommentierte Logdateien erschweren die Analyse. ## 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