Construire le maillage

Le strict minimum

Ce chapitre décrit le strict minimum pour mettre en service votre propre répéteur à Bruxelles : installer le logiciel dans le boîtier, quelques réglages, le placer près d'une fenêtre. Les opérations passent par le MeshCore Web Flasher et le Config Tool dans le navigateur : une interface web simple, sans console ni connaissances techniques poussées. Pour aller plus loin, voir Configuration avancée ci-dessous.

Configuration avancée

Réglages de référence pour les nœuds fixes (répéteur, room server) et la console CLI. Section pour aller plus loin : pas obligatoire pour un premier relais balcon si le strict minimum suffit. Réglages alignés sur les recommandations de la communauté belge.

Le filtrage par région est détaillé dans la section Filtrage régional. Les commandes region def / region default be de la fiche répéteur ci-dessous reflètent notre consensus local (firmware ≥ 1.16.0 requis) : table de régions (avec be-wal), scope be, et surtout allowf * pour continuer à relayer l’unscoped. Synthèse partageable : Les derniers changements.

Générer une clé publique

MeshCore identifie les nœuds en partie par les premiers octets de leur clé publique. Ne réutilisez jamais la clé d'un nœud déjà en service sur le maillage : choisissez un préfixe libre et une clé neuve (voir collisions de clé publique et hachage de chemin), sauf migration volontaire vers un autre appareil (voir ci-dessous). Procédure USB :

1. Branchez le répéteur en USB et ouvrez l'outil MeshCore Config Tool dans Chrome ou Edge (Web Serial requis).
2. Cliquez sur Connect et sélectionnez le port série de l'appareil.
3. Dans le générateur de clé (vanity key generator), saisissez un préfixe hexadécimal peu utilisé repéré dans l'outil de collisions (1 à 6 caractères ; 2 caractères suffisent souvent). Évitez les préfixes commençant par 00 ou FF : ils sont réservés par MeshCore.
4. Lancez la génération et attendez qu'une paire de clés correspondante soit trouvée (calcul local dans le navigateur).
5. Appliquez la clé privée générée au répéteur : via le bouton d'application proposé dans l'outil, ou dans la console avec set prv.key <clé_privée_128_caractères> (128 caractères hex, sans espace ni guillemet).
6. Redémarrez le répéteur (Reboot dans l'outil ou reboot en console).
7. Vérifiez que la clé publique affichée commence bien par le préfixe choisi, puis exportez la configuration (Export) pour conserver une sauvegarde.

Sauvegarder la clé privée du répéteur

La clé privée est l'identité du répéteur sur le maillage : même nom affiché, clé publique différente = nœud différent aux yeux du réseau, des observateurs et des cartes en ligne (voir Ressources).

Si vous flashez un nouveau firmware ou remplacez la carte sans réimporter la même clé privée, le répéteur obtient une nouvelle identité. L'ancienne clé reste visible pendant un long moment comme entrée « fantôme » : le nœud d'origine n'émet plus, mais les observateurs et l'historique du maillage conservent encore son ancienne clé publique. Vous vous retrouvez avec deux points sur la carte pour un seul site physique.

Bonne pratique : après la configuration initiale, exportez la configuration complète depuis le Config Tool (Export) ou notez au minimum la clé privée (128 caractères hex), le nom, les mots de passe admin/invité et, le cas échéant, la position GPS. Conservez cette sauvegarde dans un endroit sûr (gestionnaire de mots de passe, coffre chiffré).

Lors d'un remplacement matériel ou d'un reflash : reconnectez-vous en USB, Importez la sauvegarde JSON ou réappliquez la même clé privée (set prv.key <clé_privée_128_caractères>), redémarrez, puis vérifiez que la clé publique est identique à celle d'avant. Le répéteur reprend la même identité sur le maillage, sans laisser d'ancien nœud fantôme.

Générez une nouvelle clé uniquement si vous installez un répéteur supplémentaire ou si vous acceptez volontairement de changer l'identité du nœud (en vérifiant d'abord les collisions via l'outil listé).

Pour choisir et acheter du matériel, voir Matériel suggéré sur Rejoindre.

Puissance d'émission (TX)

La communauté flamande #BEmesh suggère souvent une puissance d'émission réduite, typiquement 14–17 dBm (~25–50 mW), par exemple via set tx 17. Ce conseil est documenté dans le configurateur #BEmesh et les guides Radio-Actief (voir Ressources).

En Flandre, le maillage MeshCore est plus mature et atteint sa masse critique : assez de relais voisins pour que baisser la TX ait du sens. Le message passe de relais en relais ; une puissance trop élevée augmente les interférences sans gain net de portée. Là-bas, ce réglage est pertinent.

Pourquoi ne pas l'appliquer à Bruxelles aujourd'hui

À Bruxelles (BE-BRU), le maillage est encore naissant (voir Découvrir : Et Bruxelles dans tout ça ?). L'enjeu immédiat est de joindre le prochain relais : urbanisme radio difficile (béton, pentes, vallée de la Senne). À la mise en service, gardez la puissance par défaut du boîtier (souvent ~22 dBm) : ne copiez pas set tx 17 par mimétisme du preset flamand.

Le hachage de chemin à 2 octets se prépare tôt car la densité future de Bruxelles est anticipée (voir Routage par chemins). La TX suit un calendrier différent : on la baisse quand la densité actuelle le justifie, pas avant.

Quand Bruxelles aura atteint sa masse critique

Quand plusieurs répéteurs seront proches (même quartier, interférences locales, saturation du voisinage), il faudra adopter la même discipline que la Flandre : baisser progressivement les émissions (14–17 dBm, ajuster au cas par cas). Commandes utiles : get tx pour lire la valeur actuelle, set tx 17 puis reboot pour appliquer.

MeshCore fonctionne en bande ISM avec un plafond légal de 500 mW ERP (27 dBm) sur la sous-bande utilisée ; la puissance réelle dépend aussi du gain d'antenne.

Routage par chemins et hachage de chemin

Pour joindre un contact ou un nœud distant, MeshCore ne « connaît » pas une adresse IP : il mémorise des chemins (path), c'est-à-dire la séquence de relais par laquelle un message est passé avec succès. Votre compagnon réutilise ce chemin jusqu'à ce qu'il échoue ; d'où l'utilité d'Effacer le chemin (Clear Path) côté app (voir Rejoindre : Premier contact).

Hachage de chemin : identifiants courts sur le chemin

Chaque relais du chemin est résumé par un hachage de chemin (path hash) : un identifiant court ajouté au routage. Sa taille fixe l'espace d'adressage : plus il est long, moins deux nœuds risquent de partager le même identifiant.

• 1 octet : set path.hash.mode 0 (défaut) : 256 valeurs possibles, environ 1 chance sur 256 qu'un nouvel identifiant entre en collision.
• 2 octets : set path.hash.mode 1 : 65 536 valeurs, environ 1 chance sur 16 000.
• 3 octets : set path.hash.mode 2 : plus de 16 millions de valeurs, risque de collision encore plus faible.

Sur un maillage dense comme Bruxelles, le mode 1 octet sature vite. Nous recommandons 2 octets sur le répéteur (set path.hash.mode 1, libellé app : Mode de hachage de chemin) et 2 octets dans Network settings du compagnon (Taille hachage de chemin). Voir les réglages dans Rejoindre le maillage et la Q&R compagnon.

Collisions de clé publique et hachage de chemin

MeshCore identifie les nœuds en partie par les premiers octets de leur clé publique. Si plusieurs répéteurs partagent le même préfixe hexadécimal, les cartes, observateurs et outils d'analyse peuvent confondre deux nœuds distincts : chemins ambigus, doublons sur la carte, débogage difficile. Avant la première mise en service, consultez donc quels préfixes sont déjà saturés sur le maillage.

Deux répéteurs proches avec le même premier octet de hachage de chemin (ou des préfixes de clé publique en collision) peuvent aussi perturber le routage et les cartes du maillage. Les deux notions sont liées : le préfixe de clé publique identifie le nœud, le hachage de chemin le résume sur les chemins du maillage.

Dans l'outil de détection des collisions (page Ressources), les matrices montrent, pour chaque taille de hash (1, 2 ou 3 octets), quels préfixes sont libres, peu utilisés ou en collision. Repérez une case Available ou One node plutôt qu'une case en collision. Comme nous recommandons le hachage de chemin à 2 octets, portez une attention particulière à la matrice 2-Byte en plus de la matrice 1-Byte (qui reflète aussi les conflits réels observés dans le trafic).

Raccourci : Q&R hachage de chemin.

Room server

Un room server est un nœud fixe qui stocke les derniers messages (jusqu'à 32) pour les personnes autorisées : boîte aux lettres asynchrone sur le maillage. Dans l'app, on le joint comme un contact avec un mot de passe (souvent hello par défaut). Voir Rejoindre : Canaux privés et room server pour l'usage côté compagnon.

Création et configuration

1. Flashez un boîtier compatible avec le rôle room server (même base matérielle qu'un répéteur ; voir matériel).
2. Branchez en USB, ouvrez le MeshCore Config Tool et sélectionnez le preset Room server (ou équivalent selon la version).
3. Appliquez les réglages radio comme pour un répéteur (set radio 869.618,62.5,8,8, set path.hash.mode 1, etc.) : la section Configuration avancée liste les commandes CLI de référence.
4. Définissez un mot de passe d'accès autre que le défaut si le nœud est exposé.
5. Alimentez le boîtier sur le secteur plutôt que sur batterie : un room server ne peut pas économiser l'énergie comme un répéteur.

Après la mise en service, envoyez une annonce manuelle pour que le maillage connaisse le nœud, puis réglez les intervalles d'auto-annonce comme pour un répéteur (voir la Q&R « À quelle fréquence mon répéteur doit-il s'annoncer ? »).

Filtrage régional

MeshCore associe chaque message à une région (Bruxelles : be-bru, voir le configurateur de région). Sur un répéteur, la personne qui le gère définit l'arbre de régions et ce qui est relayé pour tout le voisinage ; le scope d'émission recommandé reste pour l’instant be (Belgique) ; le passage au code de région (be-bru / be-wal) viendra plus tard.

Depuis le 1er août 2026, la communauté flamande #BEmesh resserre les messages sans région (unscoped). À Bruxelles, couper l’unscoped trop tôt casse la portée. Chez nous : arbre de régions (incluant be-wal), scope répéteur be, home be-bru (province en Wallonie), et surtout allowf * + flood.max.unscoped 64.

Consensus local

Sur le répéteur : arbre region def (eu → bx → be → be-bru / be-vlg / be-wal…), region default be (Belgique ; région/province plus tard), region home be-bru (en Wallonie : code province), region allowf *, puis region save. Le point critique : garder la répétition unscoped. Blocs CLI complets par zone : Configuration avancée et Catch-up.

Le default reste be (Belgique) à Bruxelles comme en Wallonie ; le home est be-bru à Bruxelles et le code de province en Wallonie. Un paquet déjà scoped n'est relayé que si le répéteur a cette région dans sa liste : d'où l'importance de l'arbre region def (avec be-wal).

Nous gardons region allowf * et le plafond unscoped par défaut (set flood.max.unscoped 64). Contrairement à la Flandre, on ne prescrit pas region denyf * ni une valeur basse type 5. Voir la Q&R flood unscoped.