Betrieb & Fehlersuche
MeshCore Hessen – Betrieb & Fehlersuche

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
meshcore-cli – offizielles Projekt
MeshCore Wiki DE – ergänzende Communityquelle
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
meshcore-cli – offizielles Projekt
MeshCore Wiki DE – ergänzende Communityquelle
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
meshcore-cli – offizielles Projekt
MeshCore Wiki DE – ergänzende Communityquelle
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
meshcore-cli – offizielles Projekt
MeshCore Wiki DE – ergänzende Communityquelle
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
meshcore-cli – offizielles Projekt
MeshCore Wiki DE – ergänzende Communityquelle
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
meshcore-cli – offizielles Projekt
MeshCore Wiki DE – ergänzende Communityquelle
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
meshcore-cli – offizielles Projekt
MeshCore Wiki DE – ergänzende Communityquelle
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
meshcore-cli – offizielles Projekt
MeshCore Wiki DE – ergänzende Communityquelle
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
meshcore-cli – offizielles Projekt
Bundesnetzagentur – Allgemeinzuteilungen
Bundesnetzagentur – Vfg. 91/2025
MeshCore Wiki DE – ergänzende Communityquelle
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