Infrastruktur Stromversorgung und Solar-Repeater Ein Solar-Repeater muss nicht nur an einem sonnigen Sommertag funktionieren. Entscheidend ist, ob Energieerzeugung, Akku und Verbrauch auch über ungünstige Wetterperioden zusammenpassen. Verbrauch messen Die Planung beginnt mit einer Messung des realen Systems. Datenblattwerte einzelner Chips reichen nicht aus. Spannungswandler, LoRa-Empfang, Sendeereignisse, LEDs, Display, GNSS und weitere Komponenten beeinflussen den Gesamtverbrauch. Aus mittlerem Strom und Betriebsspannung lässt sich der tägliche Energiebedarf abschätzen. Für eine belastbare Anlage sollten zusätzlich Spitzenströme und Verluste berücksichtigt werden. Akku Die nutzbare Akkukapazität hängt von Zellchemie, Temperatur, Alter, Entladetiefe und Schutzschaltung ab. Die aufgedruckte Nennkapazität darf nicht vollständig als jederzeit nutzbare Reserve eingeplant werden. Parallel geschaltete Lithiumzellen müssen für diesen Aufbau geeignet und auf gleichem Ladezustand zusammengeführt werden. Schutz- und Ladeelektronik müssen zur Zellchemie passen. Solarregler Ein Solarpanel sollte nicht direkt an einen beliebigen Batterieeingang angeschlossen werden. Ein geeigneter Solar-Laderegler beziehungsweise ein dafür vorgesehener Ladepfad übernimmt die kontrollierte Ladung. Ob ein konkretes Board bereits einen geeigneten Solar-Eingang besitzt oder ein externer Regler benötigt wird, ist hardwareabhängig. Panelgröße Die notwendige Panelleistung ergibt sich aus täglichem Verbrauch, lokalen Einstrahlungsbedingungen, Ausrichtung, Reglerverlusten und gewünschter Schlechtwetterreserve. Ein „10-Watt-Panel reicht immer“ wäre deshalb keine seriöse allgemeine Aussage. Winter In Mittelhessen ist die Winterplanung entscheidend. Kurze Tage, niedriger Sonnenstand, Bewölkung und mögliche Verschattung reduzieren den Ertrag. Ein System, das im August deutlichen Überschuss produziert, kann im Dezember trotzdem ausfallen. Temperatur Akkus besitzen temperaturabhängige Lade- und Entladegrenzen. Insbesondere das Laden bestimmter Lithiumchemien bei niedrigen Temperaturen kann problematisch sein. Das konkrete Datenblatt und die Schutzschaltung sind maßgeblich. Monitoring Für abgelegene Infrastruktur sind Spannungs- und Telemetriedaten hilfreich. Sie erlauben, einen langsam leer werdenden Akku zu erkennen, bevor der Repeater vollständig ausfällt. 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 Standort, Antenne und Funkweg Die Antenne ist die Schnittstelle zwischen Elektronik und Funkweg. Ein leistungsfähiges Board kann durch einen schlechten Antennenstandort deutlich schlechter funktionieren als einfachere Hardware an einer guten Position. Höhe Mehr Höhe verbessert häufig die Sicht über lokale Hindernisse. Entscheidend ist aber nicht die absolute Höhe über dem Meeresspiegel, sondern die Funkgeometrie zu den gewünschten Zielgebieten. Ein Dach im Tal kann für den Ort hervorragend sein, aber den nächsten Höhenzug nicht überwinden. Ein Bergstandort kann dagegen mehrere Regionen verbinden, während er unmittelbar unterhalb des Gipfels tote Winkel besitzt. Freie Umgebung Antennen sollten nicht unnötig direkt neben großen Metallflächen, Stahlkonstruktionen oder abschirmenden Bauteilen montiert werden. Auch das Gehäusematerial und die Montageposition können die Antenne beeinflussen. Koaxialkabel Bei externen Antennen entstehen Verluste im Kabel und an Steckverbindungen. Ein langer Kabelweg kann den Vorteil einer besseren Außenantenne teilweise wieder zunichtemachen. Daher ist es häufig sinnvoll, Funkgerät und Antenne relativ nah beieinander zu montieren und Strom beziehungsweise Daten über den längeren Weg zu führen, sofern das Gesamtkonzept dies erlaubt. Steckverbinder U.FL/IPEX-Anschlüsse auf kleinen Boards sind mechanisch empfindlich und nicht für häufiges Umstecken oder als wetterfeste Außendurchführung gedacht. Für Außenboxen wird typischerweise ein geeignetes Pigtail zu einer robusteren Durchführung verwendet. Die genaue Steckervariante muss am Board geprüft werden; ähnlich aussehende Mikrostecker sind nicht beliebig kompatibel. Antennenabstimmung Die Antenne muss für den tatsächlich verwendeten Frequenzbereich geeignet sein. Eine bloße Produktaufschrift ersetzt bei kritischer Infrastruktur keine Messung. Wetterfestigkeit Eine IP-Schutzklasse des Gehäuses bleibt nur erhalten, wenn alle nachträglichen Durchführungen fachgerecht abgedichtet werden. Antennenbuchsen, Kabelverschraubungen und Befestigungslöcher sind typische Schwachstellen. Blitz und Überspannung Außenantennen an exponierten Standorten können Anforderungen an Blitzschutz und Potentialausgleich auslösen. Das ist keine reine Bastelfrage. Bei Gebäuden oder professionellen Maststandorten sollte die vorhandene Blitzschutzplanung berücksichtigt und gegebenenfalls eine Fachkraft einbezogen 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 Sicherheit und Zugriff auf Infrastruktur Ein öffentlich erreichbarer Repeater ist Infrastruktur und sollte entsprechend administriert werden. Funkreichweite bedeutet, dass ein möglicher Angreifer nicht physisch neben dem Gerät stehen muss, um angebotene Remote-Funktionen zu erreichen. Administrationspasswort Für Repeater und Room Server existieren Passwortfunktionen. Ein produktiver Knoten sollte ein individuelles, nicht triviales Administrationspasswort besitzen. Reale Passwörter gehören weder in das öffentliche Wiki noch in Screenshots, Git-Repositories oder frei zugängliche Konfigurationsarchive. ACL und Berechtigungen Aktuelle Infrastruktur unterstützt Access-Control- beziehungsweise Permission-Funktionen. Damit können Rechte gezielter vergeben werden, statt Administrationszugang pauschal zu teilen. Konfigurationsbackups Die offizielle Web-Konfiguration kann Einstellungen als JSON exportieren. Solche Backups sind nützlich, können aber sensible Werte enthalten. Sie sollten deshalb nicht automatisch in öffentlich synchronisierte Ordner gelegt werden. Physischer Zugriff Ein Maststandort kann funkseitig gut geschützt und physisch trotzdem leicht manipulierbar sein. Gehäuse, Kabel, Stromversorgung und Befestigung sollten gegen unbeabsichtigtes Öffnen und einfache Manipulation geschützt sein. Schlüsselverlust Vor Änderungen an Identität, Dateisystem oder Firmware muss geklärt werden, welche Schlüssel beziehungsweise Konfigurationen verloren gehen können. Ein unüberlegtes erase löscht laut offizieller CLI das lokale Dateisystem und ist kein normaler Neustartbefehl. Updates Sicherheitsrelevante und funktionale Firmwareupdates sollten geplant erfolgen. Vor einem Update sind Versionshinweise, Hardwarekompatibilität und gegebenenfalls Backupmöglichkeiten zu prüfen. Öffentliche Dokumentation Öffentlich sinnvoll sind Knotenname, Funktion, ungefährer Versorgungsbereich und technische Eckdaten. Nicht öffentlich gehören Administratorpasswörter, private Schlüssel, unnötig genaue Zugangsbeschreibungen zu nicht öffentlichen Standorten und sensible Konfigurationsgeheimnisse. Quellen, Rechte und redaktionelle Prüfung MeshCore – offizielle Dokumentation meshcore-cli – offizielles Projekt MeshCore Web Config – 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 Betrieb, Wartung und Ausfallvorsorge Ein Repeaterprojekt endet nicht mit der Montage. Dauerhafte Community-Infrastruktur braucht Wartung und eine klare Vorstellung davon, was bei einem Ausfall passiert. Regelmäßige Kontrolle Bei wichtigen Standorten sollten in sinnvollen Abständen Firmwarestand, Uptime, Versorgungsspannung, Nachbarn und auffällige Funk-/Paketstatistiken geprüft werden. Bei Solarstandorten sind insbesondere längere Schlechtwetterphasen interessant. Ein System, das nur bei voller Batterie kontrolliert wird, liefert keine Information über seine tatsächliche Winterreserve. Firmwareupdates Nicht jeder neue Build muss sofort auf jeden produktiven Repeater. Für Backbone-Standorte ist ein gestuftes Vorgehen sinnvoll: Releasehinweise prüfen, auf Testhardware erproben, Konfiguration sichern und erst danach produktive Knoten aktualisieren. Ersatzhardware Bei schwer zugänglichen Standorten kann vorkonditionierte Ersatzhardware Ausfallzeiten reduzieren. Dazu gehören ein passendes Board, Firmware, dokumentierte Funkparameter und die notwendigen Adapter. Geheime Identitäten und Schlüssel dürfen dabei nicht unkontrolliert dupliziert werden. Single Point of Failure Ein hervorragend gelegener Repeater kann für mehrere Regionen gleichzeitig kritisch werden. Netzplanung sollte erkennen, welche Verbindungen vollständig von einem einzigen Standort abhängen. Wo der Nutzen den Aufwand rechtfertigt, sollte ein alternativer Funkweg vorhanden sein. Wartungsprotokoll Ein einfaches Wartungsprotokoll sollte mindestens Datum, durchgeführte Änderung, Firmwareversion, relevante Messwerte und Ergebnis enthalten. Damit kann später nachvollzogen werden, ob ein Problem beispielsweise seit einem Antennenwechsel oder Firmwareupdate besteht. Verantwortlichkeit Für Community-Infrastruktur sollte klar sein, wer einen Standort betreut. Das bedeutet nicht, private Kontaktdaten öffentlich zu machen; eine zentrale Projektadresse oder interne Betreiberliste kann genügen. Außerbetriebnahme Wird ein Repeater dauerhaft entfernt, sollte dies dokumentiert werden. Andernfalls suchen Nutzer möglicherweise weiter nach einem bekannten Infrastrukturknoten oder interpretieren eine verschwundene Route als allgemeines Netzproblem. Quellen, Rechte und redaktionelle Prüfung MeshCore – offizielle Dokumentation meshcore-cli – offizielles Projekt MeshCore Web Config – 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 Adverts, Nachbarn und Statistiken eines Repeaters Ein Repeater sollte nicht nur „irgendwie erreichbar“ sein. MeshCore stellt Informationen bereit, mit denen seine tatsächliche Rolle im Netz untersucht werden kann. Repeater-Advert Der Infrastrukturknoten kann einen Namen und – sofern gewünscht – Standortinformationen in seinen Adverts veröffentlichen. Die CLI besitzt getrennte Einstellungen für lokale Advert-Intervalle und Flood-Advert-Intervalle. Ein zu häufiges Flood-Advert erzeugt unnötige Airtime. Ein zu seltenes Advert kann dagegen die Auffindbarkeit neuer Infrastruktur erschweren. Die passende Einstellung hängt vom Netz ab und sollte nicht aus alten Standardwerten blind übernommen werden. Nachbarn Die aktuelle CLI kann direkt erreichbare Repeater-Nachbarn anzeigen und eine aktive Neighbor Discovery starten. Das ist für Backbone-Planung besonders nützlich. Eine Nachbarbeziehung zeigt, dass Infrastrukturknoten sich direkt erreichen können. Sie sagt aber noch nicht automatisch, wie stabil die Verbindung über alle Tageszeiten und Wetterlagen ist. Core-Statistiken Core-Statistiken können Informationen wie Uptime, Batterie und Warteschlangenstatus liefern. Sie helfen zu erkennen, ob ein Knoten häufig neu startet oder Energieprobleme besitzt. Radio-Statistiken Radio-Statistiken umfassen Empfangsgrößen wie RSSI, SNR beziehungsweise Noise-Floor-Informationen. Solche Werte müssen im Kontext interpretiert werden; ein einzelner RSSI-Wert ist keine vollständige Qualitätsbewertung. Paketstatistiken Paketstatistiken zeigen Sende- und Empfangsaktivität. Sie können Hinweise auf Last, Weiterleitung und ungewöhnliches Verhalten geben. Logs Die Infrastruktur-CLI kann Paketlogging starten und stoppen. Ein vollständiger Log-Dump ist nach aktueller meshcore-cli-Dokumentation eine Funktion des direkten seriellen Zugriffs; nicht jede lokale Logfunktion hat ein Remote-Gegenstück. Monitoring-Konzept Für MeshCore Hessen wäre sinnvoll, bei wichtigen Backbone-Standorten regelmäßig mindestens Firmwarestand, Uptime, Versorgung, Nachbarn und auffällige Paketstatistiken zu dokumentieren. Daraus kann später eine belastbare Betriebsübersicht entstehen. 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 Einen Repeater sinnvoll planen Ein guter Repeater beginnt nicht mit dem Kauf eines Boards, sondern mit einer konkreten Netzaufgabe. Die wichtigste Frage lautet: Welche Funklücke oder Verbindung soll dieser Standort verbessern? Versorgungsziel festlegen Mögliche Ziele sind die lokale Versorgung einer Ortschaft, die Verbindung zweier Täler, die Anbindung eines bisher isolierten Teilnetzes oder die Schaffung eines alternativen Weges bei Ausfall eines anderen Standorts. Das Ziel sollte vor der Installation schriftlich festgehalten werden. So lässt sich später anhand realer Messungen beurteilen, ob der Standort seinen Zweck erfüllt. Vorhandene Infrastruktur prüfen Ein weiterer Repeater ist nicht automatisch ein Gewinn. Befinden sich bereits mehrere gut erreichbare Repeater im selben Funkbereich, kann ein zusätzlicher Standort mehr Flood-Airtime erzeugen, ohne eine relevante neue Verbindung zu schaffen. Vor der Planung sollten deshalb vorhandene Knoten, bekannte Funkwege und Regionsstruktur betrachtet werden. Gelände Für LoRa sind Sichtbeziehungen und Fresnelzone wesentlich. Digitale Geländemodelle und Sichtlinienwerkzeuge helfen bei der Vorauswahl, ersetzen aber keine reale Messung. Ein hoher Standort kann weit reichen, wird aber durch unmittelbar benachbarte Gebäude, Metallflächen, Wald, Hanglagen oder eine ungünstig montierte Antenne trotzdem eingeschränkt. Strom und Wartung Ein dauerhaft erreichbarer Standort ist wertvoller als eine theoretisch perfekte Position, an der Akku, Solarversorgung oder Gehäuse regelmäßig ausfallen. Bei netzversorgten Standorten sind stabile Spannungsversorgung und Überspannungs-/Installationskonzept wichtig. Bei Solarstandorten müssen Energieertrag, Winterreserve, Akkutemperatur und Eigenverbrauch realistisch dimensioniert werden. Genehmigung An fremden Gebäuden, Masten oder kommunalen Einrichtungen ist die Zustimmung des Eigentümers beziehungsweise Betreibers erforderlich. Montage, elektrische Sicherheit und Blitzschutz dürfen nicht improvisiert werden. Dokumentation Vor Inbetriebnahme sollte ein Standortdatensatz angelegt werden: Zweck, grobe Lage, Hardware, Antenne, Stromversorgung, Firmware, Funkparameter, Regionskonfiguration und Ansprechpartner. Geheime Zugangsdaten werden getrennt und nicht öffentlich dokumentiert. 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 Regions und Flood-Begrenzung auf Repeatern Repeater sind die Stelle, an der Regions-/Scope-Konzepte praktisch in Infrastruktur umgesetzt werden. Sie können Regionsdefinitionen verwalten und Flood-Berechtigungen für Regionen steuern. Regionshierarchie Die aktuelle CLI unterstützt das Anzeigen, Anlegen, Aktualisieren und Entfernen von Regionsdefinitionen sowie eine Home-Region. Regions sollten nicht spontan auf jedem einzelnen Repeater unterschiedlich erfunden werden. Für ein Communitynetz ist eine abgestimmte Hierarchie erforderlich. Flood erlauben oder verweigern Die Infrastruktur-CLI kennt Funktionen zum Erlauben und Verweigern von Flood-Verkehr für Regionen. Damit kann ein Repeater gezielt entscheiden, welche regional begrenzten Floods er weiterträgt. Das ist wichtig, wenn lokale Netze miteinander verbunden werden, aber nicht jede lokale Nachricht automatisch durch das gesamte überregionale Netz laufen soll. Flood-Maximum Zusätzlich existiert eine Einstellung zur Begrenzung eingehender Flood-Pakete anhand ihrer bisherigen Hopzahl. Solche Grenzwerte sollten nicht isoliert verändert werden, weil sie die Erreichbarkeit des Netzes beeinflussen. Regionsdateien Die aktuelle meshcore-cli kann im direkten seriellen Repeater-Modus Regionsdefinitionen aus Dateien laden beziehungsweise speichern. Das erleichtert eine konsistente Konfiguration mehrerer Infrastrukturknoten. Änderungen testen Eine fehlerhafte Regionsregel kann einen Teil des Netzes logisch abschneiden, obwohl die Funkstrecke technisch hervorragend ist. Änderungen sollten deshalb zunächst dokumentiert, kontrolliert ausgerollt und anschließend mit definierten Testnachrichten geprüft werden. MeshCore Hessen Eine spätere hessenweite Regionsstruktur sollte zentral dokumentiert werden. Lokale Gruppen können darunter eigene Bereiche erhalten, ohne dass die Hierarchie jedes Mal neu erfunden wird. Bis eine solche Struktur beschlossen und real getestet ist, darf ein Beispiel im Wiki nicht als bereits gültige Produktivkonfiguration ausgegeben 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 Repeater konfigurieren und administrieren MeshCore-Infrastruktur kann lokal und – für dafür freigegebene Funktionen – über das Mesh administriert werden. Die aktuelle meshcore-cli dokumentiert zwei grundsätzlich verschiedene Wege. Direkte serielle Verbindung Im Repeater-Modus verbindet sich die CLI direkt per USB/Serial mit der Firmware. Dabei werden Textbefehle unmittelbar an die Repeater-CLI gesendet. Dieser Weg bietet den umfassendsten lokalen Zugriff. Er eignet sich besonders für Erstkonfiguration, Recovery, vollständige Logs und Funktionen, die nicht remote übertragen werden. Remote über einen Companion Im normalen Client-Modus verbindet sich meshcore-cli zunächst mit einem Companion über BLE, TCP oder Serial. Befehle an einen Repeater werden anschließend als MeshCore-Kommandos über Funk zum Infrastrukturknoten übertragen. Die Transportart zwischen Computer und Companion ändert dabei nicht das MeshCore-Protokoll auf der Funkseite. Befehle und Status Aktuelle Befehlsgruppen umfassen unter anderem: Firmwareversion, Board und Uhrzeit Core-, Radio- und Paketstatistiken Nachbarn und Neighbor Discovery Adverts Regionsverwaltung GPS- und Sensorfunktionen Passwort und Berechtigungen Power-Saving Neustart und Dateisystem-Löschung Die genaue Syntax gehört in eine versionsbezogene Befehlsreferenz; dieses Grundlagenkapitel beschreibt bewusst die Funktionen. Remote Login Für Remote-Administration stellt die CLI Login-/Logout-Funktionen und Statusabfragen bereit. Passwörter sollten nicht in Skripten, öffentlichen Screenshots oder Wiki-Beispielen mit realen Zugangsdaten veröffentlicht werden. Web-Konfiguration Das offizielle Projekt config.meshcore.io stellt eine Weboberfläche für Repeater, Room Server und Sensor-Nodes über USB Serial bereit. Es kann Konfigurationswerte lesen und schreiben sowie Konfigurationen als JSON exportieren und importieren. Damit existiert neben der Text-CLI eine komfortablere lokale Verwaltungsoption. Änderungen dokumentieren Bei Community-Infrastruktur sollte jede relevante Änderung an Funkparametern, Regionsstruktur, Firmware oder Antennenkonzept mit Datum dokumentiert werden. So lassen sich spätere Netzprobleme zeitlich zuordnen. Quellen, Rechte und redaktionelle Prüfung MeshCore – offizielle Dokumentation meshcore-cli – offizielles Projekt MeshCore Web Config – 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