Traffic Netiquette für Meshtastic: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
(12 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 10: | Zeile 10: | ||
Auf dem Primären LongFast Kanal werden aber auch Positions-, Device- und Telemetriedaten versendet, die zu immer mehr Datenkollisionen führen und das “Mesh” unnötig belasten. | Auf dem Primären LongFast 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: | Hier einige Tipps zur Geräteeinstellung, um das Mesh zu entlasten: | ||
Zeile 15: | Zeile 17: | ||
|+'''Device:''' | |+'''Device:''' | ||
|Device role: | |Device role: | ||
|'''Client oder Client_Mute''' | |'''Client oder Client_Mute ?''' | ||
Fall A) | Fall A) | ||
Ihr habt Zugang zum Mesh über einen benachbarten, gut gelegenen Node (z.B. auf einem Berggipfel): → stellt euren Node auf Client_Mute | Ihr habt Zugang zum Mesh über einen benachbarten, gut gelegenen Node (z.B. auf einem Berggipfel): → stellt euren Node auf '''Client_Mute''' | ||
Fall B) | Fall B) | ||
Ihr habt selbst einen gut gelegenen Node, von dem andere profitieren, weil diese sonst keinen Zugang hätten: → stellt euren ''' | Ihr habt selbst einen gut gelegenen Node, von dem andere profitieren, weil diese sonst keinen Zugang hätten: → stellt euren Node auf '''Client''' | ||
Solltet Ihr mehrere Nodes zuhause haben, stellt bitte gegebenenfalls nur den Haupt-Node auf '''Client''', die anderen auf '''Client_Mute'''. | |||
Router, Repeater '''nur für Nodes | Auch der Node in eurem Auto, das bei euch vor dem Haus steht, sollte im Modus '''Client_Mute''' sein. | ||
'''Router''', '''Repeater''' <u>nur für Nodes</u> an topographisch sinnvollen Positionen wie Berggipfel oder Hochhäuser mit freier Sicht. | |||
Das Mesh wird nicht besser nur weil zusätzliche Nodes dazukommen. | Das Mesh wird nicht besser nur weil zusätzliche Nodes dazukommen. | ||
Zeile 36: | Zeile 47: | ||
Der Node benötigt auch die passende Rolle und Position. | |||
Siehe:https://meshhessen.de/#rollen | Siehe:https://meshhessen.de/#rollen | ||
|} | |} | ||
{| class="wikitable" | {| class="wikitable" | ||
|NodeInfo broadcast interval: | |NodeInfo broadcast interval: | ||
Zeile 55: | Zeile 69: | ||
Es ist darum nicht nötig weniger als 3h in den Settings einzustellen. | Es ist darum nicht nötig weniger als 3h in den Settings einzustellen. | ||
{| class="wikitable" | {| class="wikitable" | ||
Zeile 136: | Zeile 151: | ||
|'''Alle auf OFF''' (falls keine verbaut) | |'''Alle auf OFF''' (falls keine verbaut) | ||
|} | |} | ||
''<sup>'''<u>Was steckt in den Environment Telemetrie-Aussendungen ?</u>'''</sup>'' | ''<sup>'''<u>Was steckt in den Environment- u. Air Quality Telemetrie-Aussendungen ?</u>'''</sup>'' | ||
* ''<sup>Uhrzeit</sup>'' | * ''<sup>Uhrzeit</sup>'' | ||
* ''<sup>Temperatur, Luftdruck, Luftfeuchtigkeit usw. (falls diese Sensoren angeschlossen sind)</sup>'' | * ''<sup>Temperatur, Luftdruck, Luftfeuchtigkeit, Co2 usw. (falls diese Sensoren angeschlossen sind)</sup>'' | ||
''<sup>Das kann spannend sein, falls richtig gemacht und nicht ständig ausgesandt. Falls keine Sensoren verbaut, stellt im App alle Sensoren auf «OFF»</sup>'' | ''<sup>Das kann spannend sein, falls richtig gemacht und nicht ständig ausgesandt. Falls keine Sensoren verbaut, stellt im App alle Sensoren auf «OFF»</sup>'' | ||
''<sup><big>→ Falls ihr Sensoren verbaut habt, stellt die Intervall-Zeit für Environment und Air Quality bitte möglichst lange ein z.B. 3'600 Sekunden (1h) [bleibt euch natürlich überlassen]</big></sup>'' | ''<sup><big>→ Falls ihr Sensoren verbaut habt, stellt die Intervall-Zeit für Environment und Air Quality bitte möglichst lange ein z.B. 3'600 Sekunden (1h) [bleibt euch natürlich überlassen]</big></sup>'' | ||
{| class="wikitable" | {| class="wikitable" | ||
|Power Metrics Module: | |Power Metrics Module: | ||
Zeile 169: | Zeile 186: | ||
|'''Ignore MQTT''' | |'''Ignore MQTT''' | ||
|'''enable''' (Das heisst: das „Ignorieren“ ist aktiviert) | |'''enable''' (Das heisst: das „Ignorieren“ ist aktiviert) | ||
MQTT nur für spezifische Anwendungen verwenden und Upload zu LongFast '''<u>unbedingt ausschalten | Sämtliche MQTT Daten die ihr von anderen Nodes über Lora empfangt, werden nicht weiter geleitet. | ||
''<sup><big>→ Gut wenn Ihr ausschließlich Nachrichten und Telemetrie aus dem Lora Funktnetzwerk empfangen wollt.</big></sup>'' | |||
----'''disable''' leitet alle sämtliche MQTT Daten weiter, die es via Lora empfängt. | |||
''<sup><big>→ Gut wenn Ihr ein Gateway errichten wollt, welches für eure und andere Nodes eine Brücke zu MQTT aufbauen soll!</big></sup>'' | |||
>>> '''''Empfehlung:''''' stellt es auf '''disable''', das Mesh ist nicht lückenlos und ihr würdet keine Nachrichten mehr von Nachbarn empfangen, die eventuell irgendwo den einstieg über MQTT finden und dann via Lora über ein anderes Node bei euch ankommen. <<< | |||
|- | |||
|'''Ok to MQTT''' | |||
|'''disable''' (Das heisst: Andere Nodes werden aufgefordert, nichts von Euch an MQTT weiter zu leiten.) | |||
MQTT nur für spezifische Anwendungen verwenden und Upload zu LongFast '''<u>unbedingt ausschalten!</u>''' | |||
----'''enable''' ( Alle Daten von euch werden von anderen auch via MQTT weitergeleitet) | |||
''<sup><big>→ Sollte euer Mesh noch nicht gut genug ausgebaut sein und ihr zu entfernten Kanälen eine Verbindung aufbauen wollt,</big></sup>'' | |||
''<sup><big>dann stellt es natürlich auf '''enable''' und nutzt das Internet.</big></sup>.'' | |||
''' | |||
Um eure Nodes auf diversen Mesh Maps anzeigen zu lassen, müsst ihr den '''Upload''' im '''Longfast''' aktivieren. Stellt dann bitte die Einstellungen wie oben beschrieben, auf ein langen Intervall ein ! | |||
Und dann entweder selber MQTT aktivieren oder "Ok to MQTT" auf '''enable.''' | |||
|} | |} | ||
{| class="wikitable" | {| class="wikitable" | ||
Zeile 181: | Zeile 222: | ||
Wir möchten doch auch das neue Leute zu uns finden. belasst es bei dieser Root topic ;-) | Wir möchten doch auch das neue Leute zu uns finden. belasst es bei dieser Root topic ;-) | ||
|} | |} | ||
<u>Also kurz zusammen gefaßt, sollten eure Nodes eine Funktion zum Verteilen oder Wetterdaten haben, könnt ihr die Nötigen Intervalle auf '''Standard''' setzen.</u> | |||
<u>Sind es reine Nodes für die Kommunikation und die Telemetrie hat keinen Mehrwert für andere, stellt die Telemetrie Intervalle auf einen sehr großen Wert und benutzt ggf. die Rolle</u> | |||
'''Client_Mute'''. | |||
''(Ein '''Tracker''' der kurzweilig eingesetzt wird ist in Ordnung.)'' | |||
[[Datei:Achtung.png|links|rahmenlos|50x50px]] | [[Datei:Achtung.png|links|rahmenlos|50x50px]] | ||
Zeile 193: | Zeile 252: | ||
'''Vielen Dank für Eure Mithilfe und ganz viel Spaß bei unserem gemeinsamen Hobby''' | '''Vielen Dank für Eure Mithilfe und ganz viel Spaß bei unserem gemeinsamen Hobby''' | ||
Autor: Daniel Wegstroth | |||
<small>Der Autor/Ersteller übernimmt keine Haftung auf Vollständigkeit und Richtigkeit des erstellten Artikels. Sie sind selber für ihr handeln verantwortlich.</small> <small>Keine Haftung für Sach-oder Menschenschäden</small>. |
Aktuelle Version vom 17. Mai 2025, 13:32 Uhr

Netiquette für den Traffic in Meshtastic
Die Anzahl der Meshtastic Nodes in Deutschland erhöht sich Woche für Woche und damit wächst auch die Ausbreitung des Mesh-Netzwerkes.
Theoretisch ist es mittlerweile möglich, Nachrichten durch die halbe Bundesrepublik zu schicken.
Auf dem Primären LongFast 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 role: | Client oder Client_Mute ?
Ihr habt Zugang zum Mesh über einen benachbarten, gut gelegenen Node (z.B. auf einem Berggipfel): → stellt euren Node auf Client_Mute
Ihr habt selbst einen gut gelegenen Node, von dem andere profitieren, weil diese sonst keinen Zugang hätten: → stellt euren Node auf Client
Auch der Node in eurem Auto, das bei euch vor dem Haus steht, sollte im Modus Client_Mute sein.
Das Mesh wird nicht besser nur weil zusätzliche Nodes dazukommen.
Der Node benötigt auch die passende Rolle und Position. |
NodeInfo broadcast interval: | 10800 Sekunden (3h) |
Was steckt in den NodeInfo-Aussendungen ?
- Long- und Short-Name
- Node-Typ (z.B. LILYGO_TBEAM, HELTEC usw.)
- Rolle (z.B. Client_Mute, Router usw.)
Die Standard Einstellung ist 3h (10'800 Sekunden). 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.
Rebroadcast Mode: | ALL (*) |
(*) In der EU gilt eine gesetzliche Grenze von 10% Sendezeit pro Stunde und Gerät.
Sollte die “Airtime” eurer Node zu hoch sein, es also knapp werden mit den 10% Sendezeit, könnt ihr versuchsweise den “Rebroadcast Mode” auf “Local only” stellen.
Dadurch werden von eurer Node nur noch Nachrichten weitergegeben, die eurem Primary oder Sekundary Kanal entsprechen.
Broadcast Interval: | 21600 Sekunden (6h) |
Smart position: | Disabled |
Was steckt in den Positions-Aussendungen ?
- Länge- und Breiten-Angabe und falls gewählt auch die:
- Höhe,
- Uhrzeit,
- Anzahl der empfangenen Satelliten,
- Geschwindigkeit über Grund
Unsere Empfehlung ist die Position nur alle 6h (21'600 Sekunden) 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, oder ihr gebt feste Koordinaten ein.
Unsere Smartphones merken sich ja auf der Karte wo jeder ist.

Bitte schaltet unbedingt die «Smart-Position» Funktion aus.
Ansonsten sendet euer Node alle 2-3 Minuten eure Position und müllt das ganze Mesh zu.
Device Metrics update Interval: | 259200 Sekunden (72h)
Android-User: lasst den Wert nicht auf 0 stehen. Sonst wird der Standard-Intervall von 30min benutzt. |
Was steckt in den DeviceTelemetrie-Aussendungen ?
- Uhrzeit
- Batterie-Spannung
- „Channel_Utilization“: wie sehr der Kanal bei euch belegt ist (in %)
- „Air_Util_Tx“: wie oft euer Node sendet (in %)
- „Uptime_Seconds“: Wie lange ihr schon online seid
Diese Information kann interessant sein, wenn ihr einen Remote Node (z.B. irgendwo auf dem Berg) betreibt und den Zustand überwachen wollt.

Steht aber das Node bei euch zuhause auf dem Fensterbrett, liegt im Auto, oder er steckt in eurer Tasche, dann ist es recht sinnbefreit diese Information ständig ins Netz zu senden.
Ihr seht ja euren Batterielevel mittels Bluetooth oder WLAN auf eurem Smartphone.
Die anderen User im Mesh interessieren sich sicher recht wenig für den Ladezustand eures Nodes.
Unsere Empfehlung ist daher die DeviceTelemetrie auf das Maximum einzustellen: 72h (= 259'200 Sekunden)
Environment Metrics Module: | Alle auf OFF (falls keine verbaut) |
Air Quality Metrics Module: | Alle auf OFF (falls keine verbaut) |
Was steckt in den Environment- u. Air Quality Telemetrie-Aussendungen ?
- Uhrzeit
- Temperatur, Luftdruck, Luftfeuchtigkeit, Co2 usw. (falls diese Sensoren angeschlossen sind)
Das kann spannend sein, falls richtig gemacht und nicht ständig ausgesandt. Falls keine Sensoren verbaut, stellt im App alle Sensoren auf «OFF»
→ Falls ihr Sensoren verbaut habt, stellt die Intervall-Zeit für Environment und Air Quality bitte möglichst lange ein z.B. 3'600 Sekunden (1h) [bleibt euch natürlich überlassen]
Power Metrics Module: | OFF (falls nichts gemessen wird) |
Was steckt in den PowerTelemetrie-Aussendungen ?
- Strom und Spannungswerte
Das hat nichts mit dem Batterie-Level eurer Node zu tun.
Hierbei handelt es sich um externe Sensoren zur Strom- und Spannung-Messung.
Hop limit | "3"
Die Mesh Struktur ist nicht für die Größe des Netzes ausgelegt, die wir mittlerweile haben. Darum sollte das Hop limit nicht über 3 liegen |
Override Duty Cycle | disabled In der EU gilt eine gesetzliche Grenze von 10% Sendezeit pro Stunde und Gerät. (in seltenen fällen, OK) |
Ignore MQTT | enable (Das heisst: das „Ignorieren“ ist aktiviert)
Sämtliche MQTT Daten die ihr von anderen Nodes über Lora empfangt, werden nicht weiter geleitet. → Gut wenn Ihr ausschließlich Nachrichten und Telemetrie aus dem Lora Funktnetzwerk empfangen wollt.
disable leitet alle sämtliche MQTT Daten weiter, die es via Lora empfängt. → Gut wenn Ihr ein Gateway errichten wollt, welches für eure und andere Nodes eine Brücke zu MQTT aufbauen soll! >>> Empfehlung: stellt es auf disable, das Mesh ist nicht lückenlos und ihr würdet keine Nachrichten mehr von Nachbarn empfangen, die eventuell irgendwo den einstieg über MQTT finden und dann via Lora über ein anderes Node bei euch ankommen. <<< |
Ok to MQTT | disable (Das heisst: Andere Nodes werden aufgefordert, nichts von Euch an MQTT weiter zu leiten.)
MQTT nur für spezifische Anwendungen verwenden und Upload zu LongFast unbedingt ausschalten!
enable ( Alle Daten von euch werden von anderen auch via MQTT weitergeleitet) → Sollte euer Mesh noch nicht gut genug ausgebaut sein und ihr zu entfernten Kanälen eine Verbindung aufbauen wollt, dann stellt es natürlich auf enable und nutzt das Internet..
Und dann entweder selber MQTT aktivieren oder "Ok to MQTT" auf enable. |
Root topic: | msh/EU_868 mit Regionsbedingten Root topics könnt ihr den Traffic auch minimieren, aber ihr schließt damit auch alle anderen aus.
Wir möchten doch auch das neue Leute zu uns finden. belasst es bei dieser Root topic ;-) |
Also kurz zusammen gefaßt, sollten eure Nodes eine Funktion zum Verteilen oder Wetterdaten haben, könnt ihr die Nötigen Intervalle auf Standard setzen.
Sind es reine Nodes für die Kommunikation und die Telemetrie hat keinen Mehrwert für andere, stellt die Telemetrie Intervalle auf einen sehr großen Wert und benutzt ggf. die Rolle
Client_Mute.
(Ein Tracker der kurzweilig eingesetzt wird ist in Ordnung.)

Bitte aktualisiert eure Firmware regelmässig
Das geht mit dem Web-Flasher wirklich kinderleicht und ist in 3 Minuten erledigt.
Die Software wird stetig weiterentwickelt und die Mesh Struktur dadurch immer effizienter !
→ Den Web-Flasher findet ihr hier: https://flasher.meshtastic.org/
Vielen Dank für Eure Mithilfe und ganz viel Spaß bei unserem gemeinsamen Hobby
Autor: Daniel Wegstroth
Der Autor/Ersteller übernimmt keine Haftung auf Vollständigkeit und Richtigkeit des erstellten Artikels. Sie sind selber für ihr handeln verantwortlich. Keine Haftung für Sach-oder Menschenschäden.