Repeater in MeshCore: das Rückgrat des Netzes

24.07.2026 · 6 Min. Lesezeit

Ein einzelner MeshCore-Companion kommt nur so weit, wie seine eigene Antenne reicht – meist einige hundert Meter bis wenige Kilometer, je nach Gelände und Bebauung. Damit aus einzelnen Geräten tatsächlich ein Netz wird, das ganze Stadtteile, Landkreise oder Regionen abdeckt, braucht es eine zweite Geräterolle: den Repeater. Dieser Artikel erklärt, was einen Repeater von einem Companion unterscheidet, wie MeshCore-Repeater tatsächlich Pakete weiterleiten, worauf bei Standort und Stromversorgung zu achten ist, und warum sich Repeater und Room Server in der Praxis nicht auf demselben Gerät vertragen.

Warum ein Netz überhaupt Repeater braucht

Ohne zusätzliche Infrastruktur kann ein Companion nur mit Geräten kommunizieren, die er entweder direkt hört oder die über einen bereits bekannten, funktionierenden Pfad erreichbar sind. In einer Umgebung mit nur wenigen, verstreuten Nutzern bedeutet das schnell: Zwei Personen, die eigentlich gerne miteinander kommunizieren würden, sind schlicht zu weit voneinander entfernt, um sich direkt zu hören – die Verbindung bricht irgendwo dazwischen ab.

Ein Repeater schließt genau diese Lücke. Er nimmt an keiner eigenen Konversation teil, schreibt selbst keine Nachrichten und erzeugt keinen eigenen Nutzverkehr – seine einzige Aufgabe ist es, Pakete anderer Geräte entgegenzunehmen und gezielt weiterzuleiten, damit sie eine größere Distanz überbrücken können, als es die Reichweite einzelner Geräte erlauben würde. Ein gut platzierter Repeater kann so den Unterschied ausmachen zwischen einem Netz, das nur im eigenen Garten funktioniert, und einem, das eine ganze Nachbarschaft oder mehr abdeckt.

Wie MeshCore-Repeater tatsächlich weiterleiten

Ein verbreitetes Missverständnis bei Neueinsteigern – gerade mit Vorerfahrung aus anderen Mesh-Systemen – ist die Annahme, ein Repeater würde grundsätzlich jedes empfangene Paket blind an alle Nachbarn weiterreichen. MeshCore verfolgt stattdessen ein zweistufiges, “hybrides” Routing-Modell, das deutlich gezielter arbeitet:

Phase 1 – Flood-Discovery beim ersten Kontakt. Will ein Node eine Nachricht an ein Ziel senden, zu dem noch kein bekannter Weg existiert, wird die Nachricht zunächst per Flood verschickt: Jeder Repeater, der das Paket empfängt, prüft, ob er es bereits kennt (um doppelte Weiterleitungen zu vermeiden), hängt seine eigene Kennung an den im Paket mitgeführten Pfad an und sendet es nach einer kurzen, zufällig gestreuten Verzögerung weiter. Ein mitgeführter Hop-Zähler sorgt dabei dafür, dass sich Pakete nicht endlos im Netz verbreiten können.

Phase 2 – gelernter, direkter Pfad für Folgenachrichten. Kommt die Nachricht beim Ziel an, schickt dieses eine Zustellbestätigung zurück, die alle Repeater auflistet, über die die ursprüngliche Nachricht tatsächlich gelaufen ist. Diese Information speichert der Absender fortan beim jeweiligen Kontakt. Alle weiteren Nachrichten an dasselbe Ziel tragen diesen bekannten Pfad bereits im Paket – ein Repeater leitet ein solches Paket dann nur weiter, wenn seine eigene Kennung tatsächlich im vorgesehenen Pfad steht, andernfalls lässt er es fallen. Dadurch sinkt der Funkverkehr für wiederkehrende Kommunikation erheblich, verglichen mit einem System, das jede einzelne Nachricht erneut flutet.

Bricht ein bekannter Pfad irgendwann ab – etwa, weil ein bislang genutzter Repeater ausgefallen ist oder sich einer der Kommunikationspartner bewegt hat –, schlägt die Zustellung über den alten Pfad fehl, und die App wechselt nach einigen erfolglosen Versuchen automatisch wieder zurück auf Flood-Discovery, um einen neuen funktionierenden Weg zu finden. Eine Ausnahme bilden Gruppen-Channels: Da Nachrichten dort grundsätzlich an eine unbestimmte Zahl an Empfängern statt an ein einzelnes, bekanntes Ziel gehen, gibt es keinen festen Pfad zu lernen – Channel-Nachrichten werden deshalb grundsätzlich immer geflutet.

Für den Alltag ist dieses Detail vor allem deshalb wichtig, weil es erklärt, warum ein Netz mit mehreren Repeatern nicht zwangsläufig mehr Funkverkehr erzeugt, als nötig ist: Nach einer kurzen Lernphase läuft der Großteil des Verkehrs gezielt über wenige, bekannte Repeater statt über alle gleichzeitig.

Standortwahl: Höhe schlägt fast alles andere

Da ein Repeater seinen Nutzen ausschließlich aus seiner Reichweite zieht, entscheidet der Standort maßgeblich über seinen Wert für das Netz. Ein paar Grundsätze haben sich in der Praxis durchgesetzt:

• Höhe vor allem anderen. Ein Repeater auf einem Dach, einem Hügel oder einem hohen Mast erreicht typischerweise ein Vielfaches der Reichweite desselben Geräts auf Bodenhöhe, weil LoRa-Signale von freier Sichtlinie profitieren und durch Gebäude, Bewuchs und Geländeformationen gedämpft werden.
• Antennenqualität zählt mit. Eine hochwertige, zum Frequenzbereich passende Antenne kann die effektive Reichweite spürbar verbessern – wichtiger als eine besonders hohe Sendeleistung, die ohnehin gesetzlichen Grenzen unterliegt.
• Freie Sicht statt Zentralität. Ein Standort mit freier Sicht in mehrere Richtungen ist meist wertvoller als ein geografisch “zentraler”, aber von Gebäuden umgebener Standort.

Für die Stromversorgung eines dauerhaft installierten Repeaters an einem exponierten Standort ohne Steckdose hat sich eine Solarpanel-mit-Pufferakku-Lösung als gängige Praxis etabliert, die einen wartungsarmen 24-Stunden-Betrieb unabhängig vom Stromnetz ermöglicht. Wer einen Repeater dagegen an einem Ort mit ohnehin vorhandener Stromversorgung betreibt – etwa im eigenen Dachgeschoss –, kann natürlich auch einfach ein Netzteil verwenden.

Grundkonfiguration: mehr Verwaltung als App-Bedienung

Anders als ein Companion wird ein Repeater nicht über die Smartphone-App im eigentlichen Sinne bedient, sondern über ein separates Konfigurationswerkzeug, das per USB am Computer verwendet wird – ähnlich einem Router-Verwaltungs-Interface. Zu den wichtigsten Einstellungen beim Ersteinrichten gehören:

• ein aussagekräftiger Name, unter dem der Repeater im Netz sichtbar ist,
• das passende Regions-Preset, damit der Repeater dieselben Funkparameter wie die übrigen Geräte im Netz verwendet,
• ein Admin-Passwort, das ab Werk auf einen einfachen Standardwert gesetzt ist und unbedingt geändert werden sollte, um zu verhindern, dass Unbefugte die Konfiguration des Geräts über Funk verändern können,
• optional ein Gast-Passwort, mit dem sich eingeschränkte, lesende Zugriffe auf Statusinformationen erlauben lassen, ohne die eigentliche Konfiguration freizugeben.

Ist ein Repeater einmal eingerichtet und läuft stabil, ist er in der Regel ein “Fire and forget”-Gerät: Er braucht anders als ein Companion keine tägliche Bedienung, sondern lediglich einen zuverlässigen Standort und eine stabile Stromversorgung. Zur Fernwartung – etwa um Einstellungen zu ändern, ohne physisch am Gerät zu sein – lässt sich ein Repeater bei Bedarf auch per Funk aus der App heraus fernadministrieren, sofern man das entsprechende Passwort kennt.

Warum Repeater und Room Server getrennte Geräte verdienen

Technisch spricht nichts dagegen, ein einzelnes Gerät gleichzeitig als Repeater und als Room Server zu betreiben – beide Rollen lassen sich kombinieren. In der Praxis wird davon dennoch abgeraten, sofern genügend Hardware zur Verfügung steht. Der Grund liegt im unterschiedlichen Charakter beider Aufgaben: Ein Repeater muss möglichst schnell und unterbrechungsfrei reagieren, um Pakete zeitnah weiterzuleiten, während ein Room Server zusätzlich Nachrichten speichert, Logins verwaltet und größere Datenmengen vorhält. Teilen sich beide Aufgaben ein Gerät, kann das insbesondere in stärker frequentierten Netzen zulasten der Zuverlässigkeit beider Funktionen gehen. Wer die Wahl hat, betreibt Repeater und Room Server daher auf getrennten Geräten – wie ein Room Server im Detail funktioniert und eingerichtet wird, ist Thema eines eigenen, folgenden Artikels.

Eine Sonderform: Companion als temporärer Repeater

Für Situationen, in denen keine fest installierten Repeater zur Verfügung stehen – etwa bei einem spontanen Einsatz im Gelände ohne vorhandene Infrastruktur –, bietet MeshCore zusätzlich eine Funktion namens “Off-Grid Repeat”. Damit lässt sich ein gewöhnlicher Companion vorübergehend so einstellen, dass er zusätzlich zu seiner normalen Funktion auch Pakete für andere Nodes weiterleitet – eine Ausnahme von der sonst geltenden Regel, dass Companions grundsätzlich nicht repeaten. Für den Dauerbetrieb ist das kein Ersatz für einen richtigen, fest installierten Repeater, wohl aber eine praktische Lücke für temporäre Einsätze ohne bestehende Infrastruktur.

Das Wichtigste in Kürze

Ein Repeater ist reine Netzinfrastruktur ohne eigenen Nutzverkehr: Seine einzige Aufgabe ist es, Pakete anderer Geräte gezielt weiterzuleiten und so die Reichweite eines MeshCore-Netzes zu vergrößern. Statt jedes Paket blind zu fluten, arbeitet MeshCore mit einem zweistufigen Modell: Der erste Kontakt zu einem neuen Ziel läuft per Flood-Discovery über alle erreichbaren Repeater, danach folgen Nachrichten einem gelernten, festen Pfad über konkret bekannte Repeater, was Funkverkehr spart. Für den praktischen Nutzen zählt vor allem der Standort – möglichst hoch und mit freier Sicht –, ergänzt um eine zuverlässige, oft solargestützte Stromversorgung, und aus Zuverlässigkeitsgründen idealerweise ein eigenes Gerät statt eines geteilten Repeater-Room-Server-Kombibetriebs.