Meshtastic Moduleinstellungen: Unterschied zwischen den Versionen

Aus Wiki Meshhessen
Zur Navigation springen Zur Suche springen
Manuel.Lausmann (Diskussion | Beiträge)
Keine Bearbeitungszusammenfassung
Manuel.Lausmann (Diskussion | Beiträge)
text fehler ausgebessert
Zeile 6: Zeile 6:


=== Store & Forward Modul ===
=== Store & Forward Modul ===
Mit dem Modul Store & Forward (S&F) konfiguriert man eine node dazu Nachrichten, die innerhalb eines privaten Kanals ausgetauscht werden, für einen späteren Abruf zu speichern. Damit haben Anwender die Möglichkeit Nachrichten zeitlich versetzt abzurufen. Selbst wenn man sich zeitweilig außerhalb der Reichweite eines Meshes befindet oder seine node zum Zeitpunkt einer Nachricht nicht eingeschaltet hatte gehen Nachrichten nicht verloren, weil man sie innerhalb eines definierten Zeitfensters jederzeit wieder abrufen kann.
Mit dem Modul Store & Forward (S&F) konfiguriert man eine Node dazu Nachrichten, die innerhalb eines privaten Kanals ausgetauscht werden, für einen späteren Abruf zu speichern. Damit haben Anwender die Möglichkeit Nachrichten zeitlich versetzt abzurufen. Selbst wenn man sich zeitweilig außerhalb der Reichweite eines Meshes befindet oder seine Node zum Zeitpunkt einer Nachricht nicht eingeschaltet hatte gehen Nachrichten nicht verloren, weil man sie innerhalb eines definierten Zeitfensters jederzeit wieder abrufen kann.


Als S&F-Server können sowohl nodes mit der Rolle ROUTER als auch CLIENT eingesetzt werden. Die Konfiguration dieser beiden Rollen unterscheidet sich nur in einem einzigen Punkt: ein CLIENT muss explizit als Server deklariert sein. Eine Einschränkung der Funktionalität findet nicht statt. Sowohl CLIENT als auch ROUTER funktionieren weiterhin wie gewohnt, sie haben nur eine zusätzliche Aufgabe.
Als S&F-Server können sowohl Nodes mit der Rolle ROUTER als auch CLIENT eingesetzt werden. Die Konfiguration dieser beiden Rollen unterscheidet sich nur in einem einzigen Punkt: ein CLIENT muss explizit als Server deklariert sein. Eine Einschränkung der Funktionalität findet nicht statt. Sowohl CLIENT als auch ROUTER funktionieren weiterhin wie gewohnt, sie haben nur eine zusätzliche Aufgabe.


==== Hardware Voraussetzungen ====
==== Hardware Voraussetzungen ====
Das Modul S&F lässt sich nur auf einer ESP32-Hardware mit PSRAM aktivieren. PSRAM steht für “pseudo static RAM”, also ein Speicher der nur während der Laufzeit einer Node zur Verfügung steht. Nach dem restart einer Node ist dieser Speicher wieder gelöscht.
Das Modul S&F lässt sich nur auf einer ESP32-Hardware mit PSRAM aktivieren. PSRAM steht für “pseudo static RAM”, also ein Speicher der nur während der Laufzeit einer Node zur Verfügung steht. Nach dem Restart einer Node ist dieser Speicher wieder gelöscht.


==== PSRAM ====
==== PSRAM ====
Leider ist es fast unmöglich aus den Angaben der Hersteller darauf zu schließen ob der verbaute ESP32 PSRAM besitzt und falls dies der Fall sein sollte, ob Meshtastic bei dem jeweiligen Modell die Funktion S&F unterstützt. Allein von dem oft verwendeten Model
Leider ist es fast unmöglich aus den Angaben der Hersteller darauf zu schließen ob der verbaute ESP32 PSRAM besitzt und falls dies der Fall sein sollte, ob Meshtastic bei dem jeweiligen Modell die Funktion S&F unterstützt. Allein von dem oft verwendeten Modell


ESP32-S3 gibt es 29 Variationen teils mit, teils ohne PSRAM.
ESP32-S3 gibt es 29 Variationen teils mit, teils ohne PSRAM.
Zeile 30: Zeile 30:
Dagegen bietet z.B. der Heltec Wireless Tracker, obwohl er einen ESP32-S3 FN8 Prozessor verbaut hat, keinen PSRAM. Letztendliche Gewissheit ob die zur Verfügung stehende Hardware S&F unterstützt lässt sich nur durch einen konkreten Test ermitteln, zumal Die Geräteeinstellung z.Zt. keinerlei Plausibilitätsprüfung der eingesetzten Hardware durchführt.
Dagegen bietet z.B. der Heltec Wireless Tracker, obwohl er einen ESP32-S3 FN8 Prozessor verbaut hat, keinen PSRAM. Letztendliche Gewissheit ob die zur Verfügung stehende Hardware S&F unterstützt lässt sich nur durch einen konkreten Test ermitteln, zumal Die Geräteeinstellung z.Zt. keinerlei Plausibilitätsprüfung der eingesetzten Hardware durchführt.


==== Konfiguration der node “Test S&F” als S&F-Server ====
==== Konfiguration der Node “Test S&F” als S&F-Server ====
Vorweg: S&F lässt sich nur für private Kanäle einrichten. Alle abweichenden Versuche werden mit der folgenden Fehlermeldung quittiert: '''S&F not permitted on the public Channel (siehe Galerie Bild 1)'''
Vorweg: S&F lässt sich nur für private Kanäle einrichten. Alle abweichenden Versuche werden mit der folgenden Fehlermeldung quittiert: '''S&F not permitted on the public Channel (siehe Galerie Bild 1)'''


Zeile 44: Zeile 44:
Heartbeat = ON
Heartbeat = ON


Diese Einstellung sendet in Intervallen von 15 Minuten ein Signal welches das Node im Mesh als S&F-Server bekannt macht. Um unnötigen Netzwerk traffic zu vermeiden sollte diese Option nicht dauerhaft aktiviert sein. Es sollte völlig ausreichen wenn das Nodes des privaten Kanals einmal den “S&F”-Server identifiziert haben. Leider wird unter Android der Server als solches nicht gekennzeichnet. Es empfiehlt sich also ihn über die Namensgebung mit einem Zusatz “S&F” kenntlich zu machen.
Diese Einstellung sendet in Intervallen von 15 Minuten ein Signal welches das Node im Mesh als S&F-Server bekannt macht. Um unnötigen Netzwerk Traffic zu vermeiden sollte diese Option nicht dauerhaft aktiviert sein. Es sollte völlig ausreichen wenn das Nodes des privaten Kanals einmal den “S&F”-Server identifiziert haben. Leider wird unter Android der Server als solches nicht gekennzeichnet. Es empfiehlt sich also ihn über die Namensgebung mit einem Zusatz “S&F” kenntlich zu machen.
 
'''Number of records'''


===== Number of records =====
Anzahl der Sätze die max. Im PSRAM gespeichert werden. Beim Defaultwert 0 werden 2/3 des Speichers für S&F reserviert was einer Anzahl von ca. 11.000 Sätzen entspricht.
Anzahl der Sätze die max. Im PSRAM gespeichert werden. Beim Defaultwert 0 werden 2/3 des Speichers für S&F reserviert was einer Anzahl von ca. 11.000 Sätzen entspricht.


===== History return max =====
'''History return max'''
Die max. Anzahl an Sätzen die an eine node nach einer Abfrage zurückgesendet wird.
 
Die max. Anzahl an Sätzen die an eine Node nach einer Abfrage zurückgesendet wird.
 
'''History return window'''


===== History return window =====
Anzahl Minuten die eine Nachricht auf dem Server zum Abruf vorgehalten wird.
Anzahl Minuten die eine Nachricht auf dem Server zum Abruf vorgehalten wird.


===== Server = ON =====
'''Server = ON'''
Auf einer node vom Typ CLIENT muss diese Option aktiviert sein.
 
Auf einer Node vom Typ CLIENT muss diese Option aktiviert sein.


(siehe Galerie Bild 3)
(siehe Galerie Bild 3)


==== Anwendungsbeispiel ====
==== Anwendungsbeispiel ====
Eine Dorfgemeinschaft hat sich entschlossen ihre sozialen Interessen auch mit Meshtastic zu unterstützen. Es wird ein zentraler Client mit dem Namen “Babenhausen” installiert. Als primärer Kanal wird “Babenhausen” und als sekundärer Kanal LongFast mit dem Default PSK “AW==”. Alle Beteiligten wählen ebenso “Babenhausen” als primären Kanal und die sekundären Kanäle nach eigenem Interesse. Es stellt sich schnell heraus, dass es Teilnehmer gibt die tagsüber arbeitsbedingt sich außerhalb des Meshes aufhalten. Andere wiederum beklagen sich über die zu geringe Akkulaufzeit ihrer node und vergessen den Akku rechtzeitig aufzuladen. Als Lösung wird nun die zentrale node “Babenhausen ” zusätzlich als S&F-Server konfiguriert und damit gewährleistet, dass jeder Teilnehmer Nachrichten auch zeitversetzt abrufen kann. Zu beachten ist, dass die Nachrichten immer an den Kanal und nicht an die einzelne Node geschickt werden müssen. Der “S&F”-Server speichert die Nachrichten für jede einzelne Node die zum Kanal gehört. Dies sollte auch bei der Einrichtung im Feld “Number of records” berücksichtigt werden.
Eine Dorfgemeinschaft hat sich entschlossen ihre sozialen Interessen auch mit Meshtastic zu unterstützen. Es wird ein zentraler Client mit dem Namen “Babenhausen” installiert. Als primärer Kanal wird “Babenhausen” und als sekundärer Kanal LongFast mit dem Default PSK “AQ==”. Alle Beteiligten wählen ebenso “Babenhausen” als primären Kanal und die sekundären Kanäle nach eigenem Interesse. Es stellt sich schnell heraus, dass es Teilnehmer gibt die tagsüber arbeitsbedingt sich außerhalb des Meshes aufhalten. Andere wiederum beklagen sich über die zu geringe Akkulaufzeit ihrer node und vergessen den Akku rechtzeitig aufzuladen. Als Lösung wird nun die zentrale node “Babenhausen ” zusätzlich als S&F-Server konfiguriert und damit gewährleistet, dass jeder Teilnehmer Nachrichten auch zeitversetzt abrufen kann. Zu beachten ist, dass die Nachrichten immer an den Kanal und nicht an die einzelne Node geschickt werden müssen. Der “S&F”-Server speichert die Nachrichten für jede einzelne Node die zum Kanal gehört. Dies sollte auch bei der Einrichtung im Feld “Number of records” berücksichtigt werden.


===== Testszenario =====
===== Testszenario =====
Es werden 3 nodes verwendet. Alle haben den privaten Kanal Babenhausen als primary und LongFast als secondary konfiguriert und die FW 2.6 installiert.
Es werden 3 Nodes verwendet. Alle haben den privaten Kanal Babenhausen als Primary und LongFast als Secondary konfiguriert und die FW 2.6 installiert.


1. RH Home (RH), Heltec V3, CLIENT_MUTE, Kanäle privat, privat, LongFast
1. RH Home (RH), Heltec V3, CLIENT_MUTE, Kanäle privat, privat, LongFast
Zeile 75: Zeile 79:
1. Nachrichten von “RH” an gemeinsamen Kanal Babenhausen. Auf dem Display des S&F-Servers (TS) wird nichts angezeigt, da er die Nachricht nur speichern soll. Alle Teilnehmer die im Netz aktiv eingebunden sind erhalten diese Nachricht direkt übermittelt. (siehe Galerie Bild 4)
1. Nachrichten von “RH” an gemeinsamen Kanal Babenhausen. Auf dem Display des S&F-Servers (TS) wird nichts angezeigt, da er die Nachricht nur speichern soll. Alle Teilnehmer die im Netz aktiv eingebunden sind erhalten diese Nachricht direkt übermittelt. (siehe Galerie Bild 4)


2. Da die node “Rm” nicht angemeldet oder außerhalb der Reichweite war sendet sie, sobald sie wieder “Zugriff” auf den S&F-Server (TS) hat die Message “SF”. Der Server meldet das er eine neue Nachricht hat:  
2. Da die Node “Rm” nicht angemeldet oder außerhalb der Reichweite war sendet sie, sobald sie wieder “Zugriff” auf den S&F-Server (TS) hat die Message “SF”. Der Server meldet das er eine neue Nachricht hat:  


Total messages: 1
Total messages: 1
Zeile 87: Zeile 91:




Unmittelbar darauf wird die Nachricht an die node “Rm” übermittelt (siehe Galerie Bild 6)
Unmittelbar darauf wird die Nachricht an den Node “Rm” übermittelt (siehe Galerie Bild 6)


Der Server übermittelt die Nachricht die von “RH” gesendet wurde mit der Uhrzeit der Absendung. Bei einer erneuten “SF” Nachricht an den S&F-Server kommt die Meldung “Total messages: 0”, d.h. die Nachricht wurde auf dem Server für die node gelöscht da sie bereits abgefragt wurde. Für alle anderen nodes bleibt sie innerhalb des voreingestellten Zeitfensters noch hinterlegt. (siehe Galerie Bild 7)
Der Server übermittelt die Nachricht die von “RH” gesendet wurde mit der Uhrzeit der Absendung. Bei einer erneuten “SF” Nachricht an den S&F-Server kommt die Meldung “Total messages: 0”, d.h. die Nachricht wurde auf dem Server für die Node gelöscht da sie bereits abgefragt wurde. Für alle anderen Nodes bleibt sie innerhalb des voreingestellten Zeitfensters noch hinterlegt. (siehe Galerie Bild 7)


===== Ausblick =====
===== Ausblick =====

Version vom 5. März 2025, 21:07 Uhr

MQTT Modul

Serial Modul

External Notification Modul

Store & Forward Modul

Mit dem Modul Store & Forward (S&F) konfiguriert man eine Node dazu Nachrichten, die innerhalb eines privaten Kanals ausgetauscht werden, für einen späteren Abruf zu speichern. Damit haben Anwender die Möglichkeit Nachrichten zeitlich versetzt abzurufen. Selbst wenn man sich zeitweilig außerhalb der Reichweite eines Meshes befindet oder seine Node zum Zeitpunkt einer Nachricht nicht eingeschaltet hatte gehen Nachrichten nicht verloren, weil man sie innerhalb eines definierten Zeitfensters jederzeit wieder abrufen kann.

Als S&F-Server können sowohl Nodes mit der Rolle ROUTER als auch CLIENT eingesetzt werden. Die Konfiguration dieser beiden Rollen unterscheidet sich nur in einem einzigen Punkt: ein CLIENT muss explizit als Server deklariert sein. Eine Einschränkung der Funktionalität findet nicht statt. Sowohl CLIENT als auch ROUTER funktionieren weiterhin wie gewohnt, sie haben nur eine zusätzliche Aufgabe.

Hardware Voraussetzungen

Das Modul S&F lässt sich nur auf einer ESP32-Hardware mit PSRAM aktivieren. PSRAM steht für “pseudo static RAM”, also ein Speicher der nur während der Laufzeit einer Node zur Verfügung steht. Nach dem Restart einer Node ist dieser Speicher wieder gelöscht.

PSRAM

Leider ist es fast unmöglich aus den Angaben der Hersteller darauf zu schließen ob der verbaute ESP32 PSRAM besitzt und falls dies der Fall sein sollte, ob Meshtastic bei dem jeweiligen Modell die Funktion S&F unterstützt. Allein von dem oft verwendeten Modell

ESP32-S3 gibt es 29 Variationen teils mit, teils ohne PSRAM.

Eindeutig bestätigt von Meshtastic sind bisher nur die Modelle

- T3-S3 Prozessor: ESP32-S3 FH4R2

- T-Beam Prozessor: ESP32

- T-Beam Supreme Prozessor: ESP32-S3 FN8

Diese Modelle besitzen alle 8MB PSRAM.

Dagegen bietet z.B. der Heltec Wireless Tracker, obwohl er einen ESP32-S3 FN8 Prozessor verbaut hat, keinen PSRAM. Letztendliche Gewissheit ob die zur Verfügung stehende Hardware S&F unterstützt lässt sich nur durch einen konkreten Test ermitteln, zumal Die Geräteeinstellung z.Zt. keinerlei Plausibilitätsprüfung der eingesetzten Hardware durchführt.

Konfiguration der Node “Test S&F” als S&F-Server

Vorweg: S&F lässt sich nur für private Kanäle einrichten. Alle abweichenden Versuche werden mit der folgenden Fehlermeldung quittiert: S&F not permitted on the public Channel (siehe Galerie Bild 1)

Mit der Beschränkung auf private Kanäle wird eine unnötige Überlastung des öffentlichen Netzes durch “SF”-Anfragen verhindert.

Die Funktion des Servers wird mit einer Lilygo T3-S3 node als CLIENT besetzt. Als primärer Kanal wird “Babenhausen” eingerichtet. Up- und Download sind aktiviert. Der sekundäre Kanal ist der Standard-Kanal mit dem default Schlüssel “AQ==” (siehe Galerie Bild 2)

Einstellungen des Moduls “Store & Forward”

Store & Forward enabled = ON

Da wir einen CLIENT für den Test benutzen ist diese Einstellung erforderlich.

Heartbeat = ON

Diese Einstellung sendet in Intervallen von 15 Minuten ein Signal welches das Node im Mesh als S&F-Server bekannt macht. Um unnötigen Netzwerk Traffic zu vermeiden sollte diese Option nicht dauerhaft aktiviert sein. Es sollte völlig ausreichen wenn das Nodes des privaten Kanals einmal den “S&F”-Server identifiziert haben. Leider wird unter Android der Server als solches nicht gekennzeichnet. Es empfiehlt sich also ihn über die Namensgebung mit einem Zusatz “S&F” kenntlich zu machen.

Number of records

Anzahl der Sätze die max. Im PSRAM gespeichert werden. Beim Defaultwert 0 werden 2/3 des Speichers für S&F reserviert was einer Anzahl von ca. 11.000 Sätzen entspricht.

History return max

Die max. Anzahl an Sätzen die an eine Node nach einer Abfrage zurückgesendet wird.

History return window

Anzahl Minuten die eine Nachricht auf dem Server zum Abruf vorgehalten wird.

Server = ON

Auf einer Node vom Typ CLIENT muss diese Option aktiviert sein.

(siehe Galerie Bild 3)

Anwendungsbeispiel

Eine Dorfgemeinschaft hat sich entschlossen ihre sozialen Interessen auch mit Meshtastic zu unterstützen. Es wird ein zentraler Client mit dem Namen “Babenhausen” installiert. Als primärer Kanal wird “Babenhausen” und als sekundärer Kanal LongFast mit dem Default PSK “AQ==”. Alle Beteiligten wählen ebenso “Babenhausen” als primären Kanal und die sekundären Kanäle nach eigenem Interesse. Es stellt sich schnell heraus, dass es Teilnehmer gibt die tagsüber arbeitsbedingt sich außerhalb des Meshes aufhalten. Andere wiederum beklagen sich über die zu geringe Akkulaufzeit ihrer node und vergessen den Akku rechtzeitig aufzuladen. Als Lösung wird nun die zentrale node “Babenhausen ” zusätzlich als S&F-Server konfiguriert und damit gewährleistet, dass jeder Teilnehmer Nachrichten auch zeitversetzt abrufen kann. Zu beachten ist, dass die Nachrichten immer an den Kanal und nicht an die einzelne Node geschickt werden müssen. Der “S&F”-Server speichert die Nachrichten für jede einzelne Node die zum Kanal gehört. Dies sollte auch bei der Einrichtung im Feld “Number of records” berücksichtigt werden.

Testszenario

Es werden 3 Nodes verwendet. Alle haben den privaten Kanal Babenhausen als Primary und LongFast als Secondary konfiguriert und die FW 2.6 installiert.

1. RH Home (RH), Heltec V3, CLIENT_MUTE, Kanäle privat, privat, LongFast

2. RH Mobil (Rm), RAK4631, CLIENT

3. Test S&F (TS), Tlora T3-S3, CLIENT

Testablauf

1. Nachrichten von “RH” an gemeinsamen Kanal Babenhausen. Auf dem Display des S&F-Servers (TS) wird nichts angezeigt, da er die Nachricht nur speichern soll. Alle Teilnehmer die im Netz aktiv eingebunden sind erhalten diese Nachricht direkt übermittelt. (siehe Galerie Bild 4)

2. Da die Node “Rm” nicht angemeldet oder außerhalb der Reichweite war sendet sie, sobald sie wieder “Zugriff” auf den S&F-Server (TS) hat die Message “SF”. Der Server meldet das er eine neue Nachricht hat:

Total messages: 1

History Window: 480min

Last Request: 1

(siehe Galerie Bild 5)


Unmittelbar darauf wird die Nachricht an den Node “Rm” übermittelt (siehe Galerie Bild 6)

Der Server übermittelt die Nachricht die von “RH” gesendet wurde mit der Uhrzeit der Absendung. Bei einer erneuten “SF” Nachricht an den S&F-Server kommt die Meldung “Total messages: 0”, d.h. die Nachricht wurde auf dem Server für die Node gelöscht da sie bereits abgefragt wurde. Für alle anderen Nodes bleibt sie innerhalb des voreingestellten Zeitfensters noch hinterlegt. (siehe Galerie Bild 7)

Ausblick

Da Nodes mit dem Nordic nRF52840 Modul wegen fehlendem PSRAM das “S&F” feature nicht unterstützen wurde ein sogenannter pull request erstellt um z.B. das SD-Modul RAK15002 von RAKWireless zu unterstützen:

Use SD card as store&forward memory #5083

https://github.com/meshtastic/firmware/pull/5083

Ob und wann diese Anforderung realisiert wird kann zum jetzigen Zeitpunkt nicht gesagt werden.

Verfasser/Autor: Möchte nicht genannt werden

Besten Dank für diesen Gastbeitrag/Artikel