Formats de messages et payloads MeshCore
Explication pratique de la conception des messages MeshCore pour une communication texte fiable sur LoRa, sans hypotheses incorrectes venant d autres protocoles.
Comment les messages MeshCore sont structures
MeshCore est concu pour une communication texte legere sur LoRa avec peu d overhead. Les messages doivent rester compacts, car l airtime LoRa est limite et influence directement portee, latence et fiabilite.
Cette page decrit le comportement MeshCore documente : les clients ne repetent pas, le forwarding est gere par les repetiteurs, le flood peut etre utilise pour la premiere route discovery, puis le trafic suivant peut passer par un chemin repeater appris.
Important : ne pas copier des noms de champs ou des schemas depuis d autres projets mesh. Garder la documentation au niveau du comportement protocolaire et des elements verifies pour MeshCore.
Schema et structure interne des messages
MeshCore utilise des representations internes compactes pour le trafic LoRa. La documentation publique ne fournit pas de schema externe stable a traiter comme API figee.
Message MeshCore (conceptuel): - contexte source/destination - payload compacte - contexte de forwarding via comportement repeater - contexte d integrite et de livraison
Pour une page web technique, preferer une description conceptuelle du protocole plutot que des schemas de champs non officiels. Cela evite les erreurs d implementation et la confusion avec d autres protocoles.
Formes de messages importantes dans MeshCore
Message direct (node-to-node)
Message cible vers un node precis pour la communication privee ou un-a-un.
Message de room
Message envoye a une room (canal de discussion) pour que plusieurs participants recoivent le meme contenu.
Discovery forwarding
Si aucune route n est encore connue, le routage peut commencer par un flood via repetiteurs pour etablir la joignabilite.
Path learning apres livraison
Apres une livraison reussie, des informations de chemin peuvent etre apprises pour un forwarding suivant plus direct.
Comportement repeater
Le forwarding se fait au niveau repeater ; les clients ne forment pas une couche de repetition generale.
Contenu chiffre
MeshCore prend en charge le chiffrement des messages. Documenter cela au niveau high-level sans details non verifies sur l implementation des cles/canaux.
Payload et contexte de transport
Contexte d entete et de transport
Dans MeshCore, cette partie concerne surtout :
- Payloads compactes : les messages restent courts pour reduire l airtime LoRa.
- Contexte de forwarding : les repetiteurs gerent le forwarding ; les clients ne repetent pas.
- Hops/flood : le protocole a une limite interne (64) ; la propagation pratique se regle au niveau repeater (ex. flood.max).
- Pas de schema de champs fige public : ne pas publier des champs non officiels comme specification stricte.
Taille de payload en pratique
Il n existe pas une taille de paquet universelle valable partout pour MeshCore. La payload effective depend des reglages LoRa (SF, bande passante, coding rate), des parametres regionaux et du comportement firmware.
Guide technique
| Parametre | Valeur | Description |
|---|---|---|
| Usage principal | Communication texte compacte | Concu pour un echange de messages fiable a bas debit. |
| Modele de forwarding | Base sur repetiteurs | Les clients ne repetent pas ; le forwarding est assure par repetiteurs/room servers avec repeat actif. |
| Formation des routes | Flood discovery + path learning | La joignabilite initiale peut utiliser flood, puis le forwarding peut suivre des chemins repetiteurs appris. |
| Rooms | Pris en charge | MeshCore prend en charge la communication en room en plus des messages directs node-to-node. |
| Contexte hops | Limite interne 64 | Le comportement pratique reste contraint par les reglages repeater (ex. flood.max). |
| Chiffrement | Pris en charge | Decrire au niveau global ; eviter les affirmations non verifiees sur le modele exact de cles/canaux. |
Pourquoi cette approche est correcte
Fidele au protocole
Evite de melanger le comportement MeshCore avec des details d autres protocoles mesh.
Moins trompeur
Evite les affirmations rigides sur des champs ou limites non officiellement definis pour MeshCore.
Plus facile a maintenir
Une documentation au niveau conceptuel reste valable quand le firmware evolue.
Realiste pour LoRa
Montre que payload effective et comportement dependent des reglages radio et de la topologie.
Texte securite plus propre
Mentionne le chiffrement correctement, sans details d implementation non verifies.
Modele developpeur plus clair
Les lecteurs gardent la bonne image mentale : rooms, repetiteurs, discovery et learned-path forwarding.
Questions frequentes
MeshCore utilise-t-il les memes schemas de messages que d autres projets LoRa mesh connus ?
Non. Ne pas copier des schemas externes en 1:1. Decrire MeshCore a partir du comportement officiellement documente.
Est-ce que tous les nodes repetent les messages ?
Non. Les clients ne repetent pas. Le forwarding est assure par les repetiteurs (et room servers avec repeat actif).
Comment la formation de route est-elle geree ?
Quand aucune route n est connue, on peut utiliser flood discovery. Apres livraison reussie, le chemin peut etre appris pour un forwarding suivant plus cible.
MeshCore prend-il en charge rooms et messages directs ?
Oui. MeshCore prend en charge la communication en room et la messagerie directe node-to-node.
Quelle est la taille maximale de paquet ?
Ne pas publier une valeur universelle fixe. La taille effective depend des reglages LoRa, de la region et du comportement firmware.
Les messages sont-ils chiffres ?
MeshCore prend en charge le chiffrement. Garder la documentation publique high-level, sans affirmations non verifiees sur les details de cles/canaux.
Utiliser une documentation MeshCore correcte
Utilise un cadrage propre : messages compacts, forwarding via repetiteurs, discovery + chemins appris, et contraintes LoRa realistes.