MeshCore Nachrichtenformate und Payloads
Praxisnahe Erklaerung, wie MeshCore-Nachrichten fuer zuverlaessige LoRa-Textkommunikation aufgebaut sind, ohne falsche Annahmen aus anderen Protokollen.
Wie MeshCore-Nachrichten aufgebaut sind
MeshCore ist fuer leichtgewichtige Textkommunikation ueber LoRa mit wenig Overhead ausgelegt. Nachrichten muessen kompakt bleiben, weil LoRa-Airtime begrenzt ist und Reichweite, Latenz und Zuverlaessigkeit direkt beeinflusst.
Diese Seite beschreibt belastbar dokumentiertes MeshCore-Verhalten: Clients repeaten nicht, Forwarding laeuft ueber Repeater, Flood kann fuer erste Route Discovery genutzt werden, und Folgeverkehr kann ueber einen gelernten Repeater-Pfad laufen.
Wichtig: keine Feldnamen oder Nachrichtenschemata aus anderen Mesh-Projekten uebernehmen. Die Dokumentation bleibt auf Protokollverhalten und offiziell belegten MeshCore-Eigenschaften.
Schema und interne Nachrichtenstruktur
MeshCore nutzt kompakte interne Nachrichtendarstellungen fuer LoRa-Verkehr. Die oeffentliche Dokumentation definiert kein stabiles externes Schema als feste API.
MeshCore Nachricht (konzeptionell): - Quell-/Zielkontext - kompakte Payload - Forwarding-Kontext ueber Repeater-Verhalten - Integritaets- und Zustellkontext
Fuer Website-Texte ist eine konzeptionelle Protokollbeschreibung sicherer als nicht-offizielle Feldschemas. So vermeidest du Fehlimplementierungen und Verwechslungen mit anderen Protokollen.
Relevante Nachrichtenformen in MeshCore
Direktnachricht (Node-zu-Node)
Gezielte Nachricht an eine konkrete Node fuer private oder 1-zu-1-Kommunikation.
Room-Nachricht
Nachricht an einen Room (Chat-Kanal), damit mehrere Teilnehmer denselben Inhalt erhalten.
Discovery-Forwarding
Ist noch keine Route bekannt, kann das Routing per Flood ueber Repeater starten, um Erreichbarkeit aufzubauen.
Path Learning nach Zustellung
Nach erfolgreicher Zustellung kann Pfadinformation gelernt werden, sodass Folgeverkehr gezielter weitergeleitet wird.
Repeater-Verhalten
Forwarding passiert auf Repeater-Ebene; Clients bilden keine allgemeine Repeater-Schicht.
Verschluesselter Inhalt
MeshCore unterstuetzt Nachrichtenverschluesselung. Das sollte auf hoher Ebene dokumentiert werden, ohne unbestaetigte Schluessel-/Kanaldetails.
Payload und Transportkontext
Header- und Transportkontext
In MeshCore geht es hier vor allem um:
- <strong>Kompakte Payloads:</strong> Nachrichten bleiben klein, um LoRa-Airtime zu reduzieren.
- <strong>Forwarding-Kontext:</strong> Repeater uebernehmen Weiterleitung, Clients repeaten nicht.
- <strong>Hops/Flood:</strong> intern gibt es eine Obergrenze (64); praktisches Verhalten wird auf Repeater-Ebene abgestimmt (z. B. flood.max).
- <strong>Keine feste Feldschema-Behauptung:</strong> nicht-offizielle Paketfelder nicht als harte Spezifikation veroeffentlichen.
Payload-Groesse in der Praxis
Es gibt keine einzelne universelle Paketgroesse, die immer fuer MeshCore gilt. Effektive Payload haengt von LoRa-Parametern (z. B. SF, Bandbreite, Coding Rate), regionalen Einstellungen und Firmware-Verhalten ab.
Technische Leitlinien
| Parameter | Wert | Beschreibung |
|---|---|---|
| Haupteinsatz | Kompakte Textkommunikation | Ausgelegt auf zuverlaessigen Nachrichtenaustausch bei niedrigen Datenraten. |
| Forwarding-Modell | Repeater-basiert | Clients repeaten nicht; Forwarding erfolgt ueber Repeater/Room-Server mit aktivem Repeat. |
| Routenbildung | Flood Discovery + Path Learning | Initiale Erreichbarkeit kann Flood nutzen, danach folgt Forwarding gelernten Repeater-Pfaden. |
| Rooms | Unterstuetzt | MeshCore unterstuetzt Room-Kommunikation zusaetzlich zu Direktnachrichten zwischen Nodes. |
| Hop-Kontext | Interne Obergrenze 64 | Praktisches Verhalten wird durch Repeater-Einstellungen (z. B. flood.max) begrenzt. |
| Verschluesselung | Unterstuetzt | Auf hoher Ebene beschreiben; keine unbestaetigten Aussagen zu exakten Schluessel-/Kanalmodellen. |
Warum dieser Ansatz korrekt ist
Protokollgenau
Verhindert das Vermischen von MeshCore-Verhalten mit Details anderer Mesh-Protokolle.
Weniger irrefuehrend
Vermeidet harte Claims zu Paketfeldern oder Limits, die fuer MeshCore nicht offiziell definiert sind.
Einfacher wartbar
Konzeptbasierte Doku bleibt gueltig, auch wenn Firmware weiterentwickelt wird.
LoRa-realistisch
Macht klar, dass effektive Payload und Verhalten von Funkparametern und Topologie abhaengen.
Sauberer Sicherheitstext
Benennt Verschluesselung korrekt ohne nicht belegte Implementierungsdetails.
Klareres Entwickler-Modell
Leser bekommen das richtige Bild: Rooms, Repeater, Discovery und gelerntes Pfad-Forwarding.
Haeufig gestellte Fragen
Nutzt MeshCore dieselben Nachrichtenschemas wie andere bekannte LoRa-Mesh-Projekte?
Nein. Externe Schemas nicht 1:1 uebernehmen. MeshCore ueber offiziell dokumentiertes Verhalten beschreiben.
Repeaten alle Nodes Nachrichten?
Nein. Clients repeaten nicht. Forwarding erfolgt ueber Repeater (und Room-Server mit aktivem Repeat).
Wie wird Routenbildung gehandhabt?
Wenn keine Route bekannt ist, kann Flood Discovery genutzt werden. Nach erfolgreicher Zustellung kann Pfadinformation fuer gezielteres Follow-up-Forwarding gelernt werden.
Unterstuetzt MeshCore Rooms und Direktnachrichten?
Ja. MeshCore unterstuetzt sowohl Room-Kommunikation als auch direkte Node-zu-Node-Nachrichten.
Wie gross ist die maximale Paketgroesse?
Keinen festen Universalwert veroeffentlichen. Die effektive Paketgroesse haengt von LoRa-Einstellungen, Region und Firmware-Verhalten ab.
Sind Nachrichten verschluesselt?
MeshCore unterstuetzt Verschluesselung. Oeffentliche Dokumentation sollte high-level bleiben und keine unbestaetigten Detailclaims enthalten.
Protokollgenaue MeshCore-Dokumentation nutzen
Nutze ein sauberes MeshCore-Framing: kompakte Nachrichten, Repeater-Forwarding, Discovery + gelernte Pfade und realistische LoRa-Grenzen.