Meshtastic Moduleinstellungen: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
text fehler ausgebessert |
||
Zeile 6: | Zeile 6: | ||
=== Store & Forward Modul === | === Store & Forward Modul === | ||
Mit dem Modul Store & Forward (S&F) konfiguriert man eine | 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 | 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 | 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 | 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 | ==== 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 | 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. | 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 | |||
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. | Anzahl Minuten die eine Nachricht auf dem Server zum Abruf vorgehalten wird. | ||
'''Server = ON''' | |||
Auf einer | |||
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 | 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 | 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 | 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 | 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 | 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.
-
Galerie Bild 1
-
Galerie Bild 2
-
Galerie Bild 3
-
Galerie Bild 4
-
Galerie Bild 5
-
Galerie Bild 6
-
Galerie Bild 7
Verfasser/Autor: Möchte nicht genannt werden
Besten Dank für diesen Gastbeitrag/Artikel