Hub

# Netiquette

Die Anzahl Meshtastic Nodes in der Schweiz erhöht sich Woche für Woche und damit wächst auch die Ausbreitung des Meshes. Theoretisch ist es mittlerweile möglich, Nachrichten vom Bodensee bis an den Genfersee zu schicken. Auf dem Primären Medium Fast Kanal werden aber auch Positions-, Device- und Telemetriedaten versendet, die zu immer mehr Datenkollisionen führen und das “Mesh” unnötig belasten. Hier einige Tipps zur Geräteeinstellung, um das Mesh zu entlasten.


# Device

# Device Role

Die Wahl der Node Rolle ist entscheidend für eine effiziente Funktion des Meshes, dabei ist zu erwähnen, das auch die Rolle CLIENT Nachrichten weiterleitet. Die Rolle CLIENT empfängt, sendet und wiederholt Nachrichten auf intelligente Weise, um das Mesh-Netzwerk optimal zu unterstützen. CLIENT ist ideal für Standorte, die anderen helfen können: Dachinstallationen, Standorte mit hoher Sichtbarkeit rundherum oder Knotenpunkte, die die Netzwerkabdeckung erweitern an einem Ort, wo es noch keine anderen CLIENT-Nodes oder ROUTER- und ROUTER_LATE Nodes hat. Quelle: https://meshtastic.org/docs/configuration/tips/#recommended-roles

# CLIENT oder CLIENT_MUTE

Ihr startet euren Heim Node und habt innerhalb ein paar Stunden >50 Nodes in der Liste, dann ist das Mesh bei euch schon gut ausgebaut. Das ist an den meisten Stellen der Deutschschweiz und Romandie so, besonders Raum AG, ZH, ZG, SZ, SO, BE, GE.

Wenn das Mesh bei euch noch nicht so dicht ist (GR, VS, TG), helft ihr mit Nachrichten weiterzuleiten in alle Richtungen, wenn der Node gut plaziert ist, zum Beispiel etwas höher auf dem Dach, auf einem hohen Turm oder auf einem Hügel, der in alle Richtungen sichtbar ist:

Solltet Ihr mehrere Nodes zuhause haben, stellt nur einen Node auf CLIENT: den, der mit einer sehr guten Antenne ausgestattet ist und wo Wände und andere Hindernisse die Ausbreitung in alle Richtungen nicht stören. Alle anderen Nodes, besonders auch Tracker-Nodes im Checkkartenformat, aber auch Nodes im Rucksack, am Fenster, in der Mitte der Wohnung, auf CLIENT_MUTE stellen. Auch der Node in eurem Auto, das bei euch vor dem Haus steht oder an vielen wechselnden Standorten umherfährt, sollte im Modus CLIENT_MUTE sein, dies gilt auch für alle Nodes, die ihr mobil mit euch herumtragt. Der Vorteil von CLIENT_MUTE ist, dass der Node nicht Nachrichten und Daten von anderen Nodes weiterleitet und den vielleicht letzten verbleibenden Hop eines anderen Pakets nicht herunterzählt.

# CLIENT_BASE

Hintergrund (Englisch): https://github.com/meshtastic/firmware/issues/7863#issue-3385800923

Falls ihr in eurer Wohnung durch viel Beton, oder Stahlfassaden schlechte Verbindungen habt, aber die Möglichkeit auf dem Hausdach einen Node zu setzen, so ist das, gerade in dicht bebauten Städten, eine gute Möglichkeit, dem Mesh zu helfen. Die optimale Rolle für solch einen Node auf dem Dach ist zunächst CLIENT.

Dass ein Paket vom Wohnungs-Node nicht aus der Stadt herauskommt, ist bei uns in der Schweiz, nur schon allein wegen all den Hügel-Nodes mit Rolle CLIENT (intelligente Weiterleiter) und Nodes auf den Bergen mit Rolle ROUTER und ROUTER_LATE, die Nachrichten immer weiterleiten, egal, ob ein CLIENT in der Nähe sie bereits weitergeleitet hat, sehr selten der Fall. Probiert bei Dach-Nodes also zuerst CLIENT-Rolle aus. Nur, wenn sich dort Probleme ergeben mit der Erreichbarkeit von Kontakten im allgemeinen Kanal 0, nur dann, stellt den Dachnode auf Rolle CLIENT_BASE. Die Rolle CLIENT_BASE leitet Nachrichten, die er von Nodes bekommt, die auf CLIENT_BASE als Favorit markiert sind, im Router-Modus sehr aggressiv im sogenannten „early rebroadcast window“ weiter. Favoriten-Nodes erkennt man in der App am Sternchen * Symbol. Stellt also, wenn ihr die CLIENT_BASE benutzt, zuerst die Node DB auf Werkszustand zurück (Node DB Reset). Dann nur Euren eigenen Heim- bzw. Wohnungs-Node auf dem Dachnode als Favorit markieren, wirklich nur diesen, keinesfalls andere Nodes aus dem Mesh, bitte. Das ist auch wichtig, weil bei Nodes von Favoriten, es sei denn es ist der erste Node in der Annahme-Kette, die Hops-verbleibend nicht heruntergezählt werden.

# ROUTER/REPEATER

Die Rolle REPEATER gibt es seit Firmware 2.7.13 nicht mehr, weil sie die ultra-agressive „early rebroadcast window“ ROUTER-Rolle mit Unsichtbarkeit für alle anderen Mesh-Teilnehmer verband. Die Rolle ROUTER wird in der Schweiz nicht mehr eingesetzt, mit unserer Topographie sind diese Rollen zu aggressiv und verursachen nur unnötige Hops.

# ROUTER_LATE

Auf Berggipfeln und in langgezogenen Tälern, leitet diese Rolle Nachrichten am effektivsten zusätzlich nach den CLIENTs weiter. Ab Firmware 2.7.11 kann man ROUTER_LATE die sich gegenseitig sehen, gegenseitig in der Favoritenliste markieren (aber nur diese) und profitiert so von 0-cost-hops.

Wenn viele ROUTER_LATE (übrigens auch ROUTER) in einem Gebiet 80x80km eingesetzt werden (z.b Zentralschweiz), kann es vorkommen, das Nachrichten mehrmals weitergeleitet werden, da ROUTER_LATE und auch ROUTER im Gegensatz zum intelligenten CLIENT nicht schaut, ob das Paket schonmal durch andere Nodes in Funkreichweite weiterversendet wurde. Das führt dann, man kann es in der z.B. Android-App Benachtigungsleiste oben sehen bei den Details, zu über 50% RX Dupes (RX Dupe / RX Total *100). In diesem Fall macht es Sinn, einige Nodes in der Region „nur“ als, ja sehr intelligenter, CLIENT zu betreiben, weil sonst die Nachrichten-De-Duplikation der Nodes überlastet wird aufgrund zu wenig History-Speicher (RAM), aber auch, weil ein und dieselbe Nachricht mehrfach umherschwirrend in einem dichten Mesh ungünstig ist.

# Node Info

NodeInfo broadcast interval 3 Stunden (wird seit Firmware 2.7 in Stunden angegeben)

Die Standard Einstellung ist 3h (3 Stunden). Unsere Smartphones merken sich in der Nodeliste diese Information für jeden. Es ist darum nicht nötig weniger als 3h in den Settings einzustellen. Sven fox 71 sendet NodeInfo bei seinen stationären Nodes und Bergnodes sogar nur alle 12h / 12 Stunden.

# Rebroadcast

Rebroadcast mode ALL

In der Schweiz/EU gilt eine gesetzliche Grenze von 10% Sendezeit pro Stunde und Gerät. Sollte die “Airtime” eurer Nodes zu hoch sein, also unter Protokolle – Funkauslastung (Logs – Device Metrics) es also knapp werden mit den 10% Sendezeit (ChUtil > 30%, AirUtilTX >5%), könnt ihr versuchsweise den “Rebroadcast Mode” auf LOCAL_ONLY stellen. Dadurch werden von eurem Node nur noch Nachrichten weitergegeben, die eurem Primary 0 Kanal und Direktnachrichten entsprechen.

# Position

Broadcast intervall 6h (6 Stunden)
Smart position Disabled (Schieberegler nacht links)

Unsere Empfehlung ist die Position bei mobilen Nodes nur alle 6h (Six Hours) auszusenden. Natürlich könnt Ihr auch mal eine andere Zeit einstellen, wenn ihr unterwegs seid, am Wandern oder Bergfunken. Wenn ihr aber euren Node fix montiert habt, dann sind 6h ausreichend. Unsere Smartphones merken sich ja auf der Karte wo jeder ist.

Bitte schaltet „Smart Position“ bei euren Home-Nodes unbedingt aus! Nodes mit eigenem GPS und schlechtem GPS- Signal, wie auch Home_Nodes, die das GPS Signal von eurem Mobilphone beziehen, können alle paar Minuten die Position

aussenden und damit das Mesh unnötig belasten. Das sieht dann so aus, viele kleine, minimale Positionsänderungen, die ausgesendet werden. Selbst bei mobilen Nodes lieber Smart Position ausschalten, dafür alle 3h oder 6h übertragen. Und bei festen Bergnodes langt sogar alle 24h.

# Telemetrie

# Device Metrics

Send Device Telemetry Disabled (Schieberegler nach links).
Device Metrics Update Interval 72h (72 Stunden). Android-User: lasst den Wert nicht auf 0 stehen. Sonst wird der Standard-Intervall von 30min benutzt.

Diese Information kann interessant sein, wenn ihr einen Remote Node (z.B. irgendwo auf dem Berg) betreibt und den Zustand überwachen wollt.

Unsere Empfehlung ist daher die DeviceTelemetrie auf das Maximum einzustellen: 72h (= 259'200 Sekunden oder allgemein Geräte-Telemetrie Senden / Send Device Telemetry ganz auszustellen.. Gut ab Firmware 2.7: wenn Send Device Telemetrie Disabled / ausgestellt ist, dann werden keine Telemetrie-,Umweltdaten / Environment Telemetry, Energiedaten / Power Metrics rausgesendet. Dies, weil diese Metriken alle zum Modul Telemetrie gehören.

# Einvironment Metrics

Einvironment Metrics Module enabled Disabled (Schieberegler nach links), falls keine Sensoren verbaut oder nicht von Interesse für andere im Mesh
Environment Metrics Update Interval 12h (12 Stunden)

Das kann spannend sein, falls richtig gemacht und nicht ständig ausgesandt. Falls keine Sensoren verbaut, stellt im App alle Sensoren auf «OFF». Modul Umweltdaten aktiviert / Environment metrics module enabled: disabled (Schieberegler nach links)

# Power Metrics

Power Metrics Module enabled Disabled (Schieberegler nach links), falls keine externen Batteriemanagement-Systeme (BMS) verbaut und am I2C-Bus mit Kabel angeschlossen. Ebenfalls aus, falls nicht von Interesse für andere im Mesh, sondern nur lokal.
Power Metrics Update Interval 12h (12 Stunden)

# Lora

Number of Hops Das ist das Limit von jedem selbst versandten Paket vom eigenen Node (eigene Nachrichten, eigene NodeInfo, Sensordaten, Positionsdaten). Jeder Node, der danach die Pakete weiterleitet, zählt jeweils einen Hop runter von diesem Anfangs-Hop-Count. Wenn auf 0, wird das Paket nicht mehr weitergeleitet von anderen Nodes. Das ist eine ganz zentrale Sicherheitsmassnahme in Meshtastic. Ideal sind 3 oder 4 hops, maximal 5 hops (für Nodes ohne direkten Zugang zu Berg-Nodes).

Die Mesh Struktur ist nicht für die Grösse des Netzes ausgelegt, die wir mittlerweile haben. Darum sollte das Hop Limit keinesfalls über 5 liegen. Man kommt über 4-5 Zwischen-Stationen / Hops (Berg-Nodes) mittlerweile sehr gut bis in die Westschweiz / Romandie bzw. umgekehrt von der Romandie in die Deutschschweiz. Alle Hops über 5 überlasten das Mesh und sind kontraproduktiv.
Override Duty Cycle Disabled (Schieber nach links)

In der Schweiz/EU gilt eine gesetzliche Grenze von 10% Sendezeit pro Stunde und Gerät auf den ISM-Bändern EU_433 und EU_868. Bei User / Benutzer nicht auf EU_868 „HAM User / Amateurfunk lizenziert“ aktivieren (Schieber also nach links lassen). EU_868 ist kein Amateurfunkband und HAM Mode führt zu duty cycle override Aktivierung, was auf EU_868 illegal ist. HAM User können aber natürlich trotzdem auf EU_868 ihren Benutzer long name / langen Namen auf ihre Funkamateur-Kennung einstellen als Identifizierung.
Ignore MQTT Enabled (Das heisst: das „Ignorieren“ ist aktiviert, Schieber nach rechts)<br
MQTT ignorieren heisst, dass der eigene Node keine MQTT-Pakete, die über Internet-Gateways ins Netz kamen, weiterleitet an andere Nodes. MQTT nur für spezifische Anwendungen verwenden und Upload zu MediumFast unbedingt ausschalten. Das heisst, bei Channel 0 / Kanal 0 MQTT Uplink und Downlink aktiviert unbedingt aus lassen (Schieber nach Links). Wir empfehlen auch bei sekundären und privaten Channels kein MQTT Downlink.
OK to MQTT Disabled (Schieber nach links)

Wenn diese Option aktiviert ist, signalisiert diese Konfiguration, dass der Benutzer der Übertragung seiner Pakete an MQTT-Broker im Internet zustimmt. Meshmap funktioniert auch ohne diese Option zu aktivieren.

# Firmware

Das geht mit dem Web-Flasher mit Chrome-Browser https://flasher.meshtastic.org/ über USB-Kabel wirklich kinderleicht und ist in 3 Minuten erledigt. Die Software wird stetig weiterentwickelt und die Mesh Struktur dadurch immer effizienter! Wir empfehlen, immer nur beta-Versionen zu nutzen, da diese stabiler und ausgereifter sind als alpha-Versionen.

Stand 7 Dez 2025: Firmware 2.7.15. Fox 71 Sven hatte beim Upgrade seinen RAK Gerätes und seines Seeed Studio Solar Node P1 keine Probleme beim Update von der alten Version 2.6.11 auf 2.7.15.

Bald wird man auch über die Smartphone-App und Bluetooth einfach drahtlos updaten können. Auf Android: App 2.7.8 bei Einstellungen – Advanced / Fortgeschritten – Firmware Update. Wir empfehlen das Stand Dezember 2025 aber noch nicht für das Update von Firmware 2.6.11 auf 2.7.15.

# Fragen?

Bei Fragen wendet Euch bitte an:

# Netiquette Autoren