Knotenrollen

MeshCore Hessen – Knotenrollen

Rollen

Rollen

Repeater – Infrastruktur für das Mesh

Ein MeshCore-Repeater ist ein Infrastrukturknoten zur Weiterleitung geeigneter Pakete. Seine Aufgabe ist nicht, „die Sendeleistung des Benutzers zu verstärken“, sondern neue Funkwege zwischen Knoten beziehungsweise Netzbereichen zu schaffen.

Empfang und Weiterleitung

Ein Repeater empfängt MeshCore-Pakete und entscheidet anhand des Pakettyps, der Routinginformationen und seiner Konfiguration, ob und wie er sie weiterträgt. Dazu gehören Flood- und Direct-Routing sowie aktuelle Regions-/Scope-Mechanismen.

Eigene Identität

Auch ein Repeater besitzt eine eigene kryptografische Identität und kann Adverts aussenden. Dadurch kann er als eigener Knoten gefunden, adressiert und administriert werden.

Nachbarn

Die aktuelle Infrastruktur-CLI kann direkt erreichbare Repeater-Nachbarn anzeigen und aktiv nach Nachbarn suchen. Diese Informationen sind für Diagnose und Netzplanung wertvoll, weil sie reale Funkbeziehungen zwischen Infrastrukturknoten sichtbar machen.

Statistiken

Aktuelle CLI-Funktionen stellen Kern-, Funk- und Paketstatistiken bereit. Damit können unter anderem Betriebszustand, Radioinformationen und Paketverkehr untersucht werden. Solche Messwerte sind für einen dauerhaften Community-Repeater wesentlich hilfreicher als eine reine Aussage „er ist online“.

Administration

Ein Repeater kann lokal über Serial administriert werden. Zusätzlich sind über einen Companion und das Mesh Remote-Funktionen möglich. Die aktuelle meshcore-cli unterscheidet ausdrücklich zwischen direkter serieller Firmware-CLI und Remote-Kommandos über MeshCore.

Nicht jeder serielle Befehl ist deshalb automatisch remote verfügbar.

Zugriffsschutz

Repeater besitzen Administrations- und Berechtigungsmechanismen. Ein öffentlich erreichbarer Repeater sollte nicht mit Standard- oder trivialen Zugangsdaten betrieben werden. Zugriffsrechte und gespeicherte Geheimnisse gehören nicht in öffentliche Standortdokumentationen.

Standort

Der Standort ist häufig wichtiger als minimale Unterschiede zwischen zwei geeigneten Boards. Höhe, freie Sicht, Gelände, Antenne, Kabelverluste und lokale Störungen bestimmen maßgeblich, welchen Nutzen ein Repeater im Netz hat.

Community-Infrastruktur

Für MeshCore Hessen sollte ein Repeater eine dokumentierte Aufgabe besitzen: Versorgung eines Ortes, Überbrückung einer Abschattung, Verbindung zweier Teilnetze oder Redundanz eines wichtigen Pfads. „Hier war noch Platz für einen Repeater“ ist kein Netzkonzept.

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

Rollen

Geräterollen im Überblick

MeshCore trennt verschiedene Aufgaben bewusst in unterschiedliche Geräterollen. Diese Rollen sind wichtiger als der Produktname eines Boards: Ein und dieselbe Hardwarefamilie kann je nach verfügbarem Firmware-Build für unterschiedliche Zwecke eingesetzt werden, während nicht jede Rolle auf jedem Board angeboten wird.

Companion

Ein Companion ist der typische persönliche Kommunikationsknoten. Er stellt die Funkseite von MeshCore bereit und wird von einem Client bedient. Je nach Firmware und Hardware erfolgt diese Verbindung beispielsweise über Bluetooth Low Energy, USB/Serial oder eine andere unterstützte Schnittstelle.

Ein Companion ist primär Endgerät. Er sollte nicht als Ersatz für einen strategisch platzierten Repeater geplant werden.

Repeater

Ein Repeater ist Infrastruktur. Er empfängt dafür geeignete MeshCore-Pakete und kann sie entsprechend Routingregeln weitertragen. Dadurch verbindet er Funkbereiche, die sich nicht direkt erreichen.

Repeater besitzen eigene Konfigurations- und Administrationsmöglichkeiten. Dazu gehören unter anderem Funkparameter, Advert-Verhalten, Routingbegrenzungen, Regionskonfiguration, Statistiken, Nachbarn und Zugriffsschutz.

Room Server

Ein Room Server ist eine serverartige MeshCore-Rolle für einen Nachrichtenraum. Er ist nicht lediglich ein Repeater mit anderem Namen. Die aktuelle Repeater-/Room-Server-CLI enthält beispielsweise Room-Server-spezifische Einstellungen wie einen Read-only-Zugang.

Je nach Konfiguration kann eine Serverrolle zusätzlich Repeaterfunktionen besitzen; diese Möglichkeit darf aber nicht dazu führen, die beiden Aufgaben begrifflich gleichzusetzen.

Sensor

Sensor-Nodes stellen Messwerte bereit. Die aktuelle Infrastruktur-CLI enthält Befehle zum Auflisten, Lesen und Setzen von Sensorwerten. Das Companion-Protokoll und die CLI kennen Sensoren außerdem als eigenen Kontakttyp.

Rolle ist nicht gleich Hardware

Bezeichnungen wie nRF52, ESP32, SX1262 oder RAK4631 beschreiben Hardware beziehungsweise Komponenten, nicht die MeshCore-Rolle. Vor dem Flashen müssen daher immer zwei Fragen getrennt beantwortet werden:

  1. Welche Hardware liegt tatsächlich vor?
  2. Welcher aktuelle MeshCore-Build für die gewünschte Rolle existiert dafür?

Für die Netzplanung

Ein regionales Netz benötigt nicht möglichst viele Geräte derselben Art. Persönliche Companions, gezielte Repeater und gegebenenfalls Room Server oder Sensoren erfüllen unterschiedliche Aufgaben. Eine klare Rollenverteilung erleichtert Betrieb, Dokumentation und Fehlersuche.

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

Rollen

Room Server – Nachrichtenraum im Mesh

Der Room Server ist eine eigene MeshCore-Serverrolle. Er bietet einen Raum, mit dem Benutzer über das Mesh interagieren können. Damit unterscheidet er sich sowohl vom persönlichen Companion als auch vom reinen Weiterleitungszweck eines Repeaters.

Zugriff

Die aktuelle meshcore-cli kann einen Room Server als eigenen Kontakttyp auswählen. Innerhalb eines Rooms können Nachrichten gesendet werden; die CLI beschreibt dafür unter anderem einen send-Befehl beziehungsweise einen Nachrichtenpräfix.

Administration

Room Server teilen einen großen Teil der Infrastruktur-CLI mit Repeatern. Dazu gehören beispielsweise Version, Uhrzeit, Funkparameter, Adverts, Passwort, Statistiken und weitere Konfigurationswerte.

Es existieren aber Room-spezifische Einstellungen. Die offizielle CLI-Referenz dokumentiert beispielsweise allow.read.only: Bei entsprechender Konfiguration kann ein Zugang ohne Passwort nur lesend zugelassen werden, ohne neue Beiträge in den Raum schreiben zu dürfen.

Room Server ist kein Gruppenkanal

Ein Gruppenkanal verteilt verschlüsselte Kanalnachrichten zwischen Teilnehmern mit passendem Schlüssel. Ein Room Server ist dagegen ein adressierbarer Serverknoten mit eigenem Zustand und Zugriffsmodell.

Beide können aus Anwendersicht Gruppenkommunikation ermöglichen, technisch sind sie jedoch unterschiedliche Konzepte.

Room Server und Repeaterfunktion

Die Infrastruktur-Firmware kennt eine Einstellung zur Repeaterfunktion. Ob und wie ein konkreter Room Server zusätzlich als Repeater betrieben werden soll, ist eine bewusste Betriebsentscheidung. Für kritische Infrastruktur ist eine klare Dokumentation sinnvoll, damit bekannt ist, welche Aufgaben ein einzelner Knoten übernimmt.

Einsatz für MeshCore Hessen

Ein Room Server kann beispielsweise einen dauerhaft erreichbaren Community-Raum bereitstellen. Vor einem produktiven Einsatz sollten jedoch Zugriffskonzept, Moderation, Speicherverhalten, Backupmöglichkeiten und die Auswirkungen zusätzlicher Funklast geklärt werden.

Ein Room Server ersetzt keine externe Internetplattform und besitzt nicht automatisch dieselben Komfort- und Moderationsfunktionen wie ein klassischer Webchat.

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

Rollen

Sensor-Nodes

MeshCore unterstützt Sensoren als eigenen Knotentyp. Sensor-Nodes sind für Messdaten gedacht und nicht primär für die normale Chatbedienung.

Sensorkontakte

Die aktuelle meshcore-cli unterscheidet Sensoren von Clients, Repeatern und Rooms. Für Sensorkontakte stehen spezielle Abfragen zur Verfügung, darunter Telemetrie, Min/Max/Avg-Anfragen und ACL-bezogene Funktionen.

Sensorbefehle auf Infrastruktur

Die aktuelle Repeater-/Infrastruktur-CLI enthält sensor list, sensor get und sensor set. Damit können verfügbare Sensoren beziehungsweise Werte über die Firmware-Schnittstelle angesprochen werden.

Datenmenge

LoRa ist kein breitbandiger Telemetriekanal. Sensoranwendungen sollten deshalb kleine, sinnvoll getaktete Datensätze verwenden. Eine hohe Messrate kann unnötige Airtime erzeugen.

Energie

Sensor-Nodes können von stromsparender Hardware besonders profitieren. Der tatsächliche Verbrauch hängt aber nicht nur vom Mikrocontroller ab, sondern auch von Sensoren, GNSS, Display, Spannungswandlern, Firmware, Sendeintervallen und Schlafmodi.

Sicherheit

Messdaten können je nach Anwendung sensibel sein. Positionen, Gebäudedaten oder Betriebszustände sollten nicht automatisch öffentlich ausgesendet werden. Zugriffskontrolle und Transportweg müssen zur Anwendung passen.

Abgrenzung

Ein Sensor-Node ist kein Ersatz für einen Repeater. Soll ein Standort gleichzeitig Messdaten liefern und Infrastrukturaufgaben übernehmen, muss geprüft werden, ob der konkrete Firmware-Build diese Kombination unterstützt und ob sie betrieblich sinnvoll ist.

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

Rollen

Companion – persönlicher MeshCore-Knoten

Der Companion ist die Rolle, mit der die meisten Anwender MeshCore kennenlernen. Er verbindet den Benutzer beziehungsweise dessen Client mit dem LoRa-Netz.

Aufgabe

Der Companion verwaltet die eigene MeshCore-Identität, Kontakte, Kanäle und Funkkommunikation. Der Client liefert die Benutzeroberfläche. Abhängig vom konkreten Build kann die Verbindung zwischen Client und Companion über BLE, Serial oder TCP erfolgen; die offizielle meshcore-cli unterstützt diese drei Transportwege zu Companion-Nodes.

Companion und Smartphone

Ein Smartphone ist nicht grundsätzlich Bestandteil der LoRa-Funkstrecke. Bei einem BLE-Companion bedient das Smartphone den Companion über Bluetooth; das eigentliche MeshCore-LoRa-Paket wird vom Funkgerät gesendet und empfangen.

Daraus folgt auch: Die Bluetooth-Reichweite zwischen Telefon und Companion ist eine andere technische Größe als die LoRa-Reichweite zwischen MeshCore-Knoten.

Kontakte und Pfade

Ein Companion kann Kontakte verwalten, Kontaktinformationen anzeigen, Pfade entdecken oder zurücksetzen und Telemetrie anfordern. Die aktuelle meshcore-cli bietet dafür unter anderem contacts, contact_info, path, disc_path und reset_path.

Diese Funktionen zeigen, dass der Companion mehr ist als ein „serielles Funkmodem“. Er hält für die Anwendung relevante MeshCore-Zustände vor.

Kanäle

Companions verwalten Gruppenkanäle. Dabei gelten die im Kommunikationsbereich beschriebenen Unterschiede zwischen öffentlichem Standardkanal, Hashtag-Kanal und privatem Kanal.

Adverts

Ein Companion kann sich durch Adverts bekannt machen. Dabei sollte zwischen lokaler Bekanntmachung und Flood-Advert unterschieden werden. Persönliche Positionsdaten sollten nur bewusst veröffentlicht werden.

Companion als Repeater?

Für die Netzplanung sollte ein Companion nicht automatisch als Infrastruktur gezählt werden. Die dedizierte Repeaterrolle besitzt eigene Weiterleitungs-, Verwaltungs- und Infrastrukturmechanismen.

Auch wenn eine konkrete Firmwareversion Zusatzfunktionen anbietet, bleibt die planerische Trennung sinnvoll: Mobile persönliche Geräte sind keine verlässlich stationäre Backbone-Infrastruktur.

Geeignete Hardware

Für mobile Companions spielen neben LoRa-Leistung auch Stromverbrauch, Bluetooth, Display, Akku, Größe und Bedienbarkeit eine Rolle. Die konkrete Hardwareauswahl wird deshalb im Hardwarebereich separat behandelt und nicht aus der Geräterolle abgeleitet.

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