Jede Node hat eine Rolle (device.role), die bestimmt, wie sie sich beim Empfang, Rebroadcasting und Priorisieren von Paketen verhält. Falsche Rollenwahl ist die häufigste Ursache für Airtime-Überlastung und Range-Probleme im Mesh — die Rolle ist keine kosmetische Einstellung.
Grundprinzip #
Meshtastic hat keinen zentralen Controller. Jede Node entscheidet selbst, ob und wann sie ein gehörtes Paket erneut sendet (rebroadcastet). Standardmäßig gilt: Wenn eine Node ein Paket rebroadcastet hat, das eine andere Node ebenfalls hört, verwirft die zweite Node ihren eigenen Rebroadcast (Kollisionsvermeidung). Router-artige Rollen brechen dieses Verhalten absichtlich auf, um Vorrang zu bekommen.
Standard-Rollen (für die meisten Nodes) #
| Rolle | Verhalten | Einsatz |
|---|---|---|
| CLIENT | Standard. Rebroadcastet nur, wenn keine andere Node das Paket schon rebroadcastet hat. | Normale Handheld-/App-Nodes. In fast allen Fällen die richtige Wahl. |
| CLIENT_MUTE | Sendet/empfängt eigene Nachrichten, rebroadcastet nie. | Mehrere eigene Nodes am selben Standort (z. B. Auto + Rucksack) — nur eine davon sollte aktiv rebroadcasten. |
| CLIENT_HIDDEN | Wie CLIENT_MUTE, sendet zusätzlich nur bei Bedarf (Stealth/Stromsparen) und taucht nicht in der Node-Liste anderer auf. | Verdeckter Einsatz, maximale Stromersparnis. |
| CLIENT_BASE | Verhält sich wie CLIENT, außer für favorisierte Nodes: dafür wie ROUTER_LATE priorisiert (verzögertes, aber garantiertes Rebroadcast). | Eigene „Basisstation“ (Dach/Dachboden), die bevorzugt die eigenen schwächeren Indoor-Nodes bedient — ohne fremden Traffic aggressiv zu pushen. |
Infrastruktur-Rollen (nur für gezielt platzierte Nodes) #
Die ROUTER-Rolle ist für Geräte gedacht, die primär Nachrichten zu anderen Geräten im Mesh weiterleiten sollen, und nur für stationäre Geräte an strategisch besonders geeigneten Standorten geeignet, die als inoffizielle Hubs fürs Routing fungieren. Router priorisieren das Weiterleiten, indem sie sich vordrängeln, bevor andere Nodes ihren eigenen Rebroadcast versuchen, und rebroadcasten immer — anders als die meisten anderen Rollen, die darauf verzichten, sobald sie einen Nachbarn zuerst rebroadcasten hören.
| Rolle | Verhalten | Einsatz |
|---|---|---|
| ROUTER | Rebroadcastet immer, mit höchster Priorität („drängelt sich vor“). Sichtbar in der Node-Liste. Aktiviert automatisch Power Saving (ESP32). | Sehr wenige, exzellent positionierte Backbone-Nodes (Berg, hoher Mast). |
| ROUTER_LATE | Rebroadcastet ebenfalls fast alles, aber erst nachdem alle anderen Rollen ihre Chance hatten (spätes Contention-Fenster). Füllt Funklöcher, ohne bevorzugten Traffic zu blockieren. | Lückenfüller für Cluster/Täler, die sonst schlecht angebunden sind. Sichtbar in der Node-Liste. |
| REPEATER ⚠️ | Wie ROUTER, aber ohne eigene Telemetrie/Broadcasts, nicht in der Node-Liste sichtbar. Seit Firmware 2.7.11 deprecated — nicht mehr für neue Deployments verwenden, stattdessen ROUTER oder ROUTER_LATE. | — |
Zu viele Infrastruktur-Nodes im selben Gebiet erzeugen Kollisionen statt mehr Reichweite. Ein Netz aus CLIENT-Nodes mit wenigen gut platzierten ROUTERn ist meist die effizienteste und stabilste Konfiguration.
Spezial-Rollen #
| Rolle | Zweck |
|---|---|
| TRACKER | Priorisiert regelmäßige GPS-Positionspakete. |
| SENSOR | Priorisiert regelmäßige Telemetriepakete (Umweltsensorik). |
| LOST_AND_FOUND | Sendet regelmäßig Position auf dem Standardkanal — für Wiederauffinden verlorener Geräte. |
| TAK / TAK_TRACKER | Integration mit ATAK-Systemen (Cursor-on-Target), reduziert Routine-Broadcasts. |
Deprecated #
- ROUTER_CLIENT — entfernt in Firmware 2.3.15, war ein Fehlgriff (Router-Verhalten kombiniert mit Client-BLE, führte zu unklarem Einsatzzweck).
- REPEATER — deprecated seit 2.7.11 (siehe oben), noch als Enum vorhanden, aber nicht mehr empfohlen.
Empfehlung für Mesh SH #
Für unsere überwiegend nRF52-basierte Fleet:
- Default: CLIENT. Für praktisch jede Handheld-/mobile Node die richtige Wahl.
- Mehrere eigene Nodes am gleichen Ort → CLIENT_MUTE auf allen außer einer.
- Dachboden-/Fensternode mit Blick über die Nachbarschaft → CLIENT_BASE, mit den eigenen Nodes als Favoriten.
- ROUTER/ROUTER_LATE nur nach Rücksprache mit der Community und nur an nachweislich gut positionierten Standorten (Mast, Kirchturm, exponierte Anhöhe) — nicht „weil man kann“. Vorher ChUtil/AirUtilTX am geplanten Standort beobachten.
- REPEATER nicht mehr verwenden — stattdessen ROUTER_LATE, falls das Ziel „Lücken füllen, ohne bevorzugten Traffic zu stören“ ist.