Meshtastic : communication longue distance, hors réseaux et gratuite

Prenons un exemple simple. Vous êtes à la campagne et votre habitation est domotisée. Vous êtes très heureux ainsi, supervisant à loisir le chauffage, la consommation électrique, les luminaires, etc. Seulement voilà, vous avez un potager, un terrain de loisir ou un petit chalet qui se trouve hors de portée du Wi-Fi ou de tout autre protocole radio « local ». Comment ajouter des capteurs en ce lieu sans avoir à payer un abonnement (typiquement 3G, 4G ou GPRS) et sans avoir à intégrer un réseau hors de votre maîtrise, le tout parfaitement légalement ? Cette problématique fonctionne de la même manière avec plusieurs situations, que ce soit du côté particulier ou professionnel (on pense naturellement aux installations agricoles, par exemple).

1. Meshtastic et matériel

Meshtastic propose une solution à ce problème, est open source et géré par sa communauté d'utilisateurs. Ce nom désigne, en même temps, une initiative, un projet, un firmware et un ensemble d'outils. Ce dont il ne s'agit pas, en revanche, c'est de quelque chose de centralisé, comme le réseau TTN (The Things Network) que nous avons évoqué dans le numéro 19, il y a fort longtemps [1]. Meshtastic repose sur la technologie LoRa, un protocole de communication radio longue distance (record de 254 km pour Meshtastic, voir [2]) utilisant des fréquences de la bande ISM (Industriel, Scientifique et Médical) incluant 433 MHz et 868 MHz chez nous. Il est donc possible d'utiliser des équipements LoRa sans autorisation préalable, sans demande de licence et sans coût supplémentaire autre que le matériel lui-même. Bien entendu, la puissance est régulée ainsi que l'utilisation (rapport cyclique de 10 % par heure), mais ceci est parfaitement pris en charge par le code du projet.

Comme son nom l'indique, Meshtastic repose sur la notion de maillage (mesh) où chaque installation, ou nœud, établit une communication avec les nœuds à portée et peut relayer les messages (un peu comme Tor). L'ensemble des communications est chiffré de façon à garantir la sécurité des données lorsque des messages transitent de cette manière d'un nœud à un autre (message direct), tout en permettant également des diffusions globales (broadcast). C'est le concept de base et l'aspect participatif du projet décentralisé, mais en disposant de ses propres nœuds, cela fonctionne également. Il n'est donc pas nécessaire, pour profiter de Meshtastic, d'avoir des nœuds préexistants dans sa zone. LoRa est un standard spécialement destiné à ce genre d'utilisation et la portée des liaisons peut s'étendre sur plusieurs kilomètres en terrain dégagé (notion de « ligne de vue » ou « line of sight » en anglais). En environnement urbain, les choses sont drastiquement différentes et il est plus raisonnable de parler de centaines de mètres dans de bonnes conditions.

Ce qui nous amène justement au choix du matériel permettant de faire fonctionner le firmware Meshtastic. Le site officiel [3] liste un certain nombre de plateformes, pour la plupart basées, sans surprise, sur des microcontrôleurs ESP32, dont un grand nombre de chez LILYGO, le tout trouvable facilement sur les sites habituels (comprendre « Amazon » si vous êtes pressé ou « AliExpress » si vous êtes patient et économe). Notez qu'il existe également une solution reposant sur Raspberry Pi Pico avec un module LoRa additionnel ainsi qu'une approche consistant à utiliser un SBC GNU/Linux (typiquement Raspberry Pi) faisant fonctionner un service/démon meshtasticd.

Le point important, sinon critique, dans le choix du matériel concerne la partie LoRa et plus précisément la fréquence que le circuit va utiliser. En Europe, nous avons le choix entre deux bandes de fréquences pour LoRa :

• celle des 433 MHz limitant la puissance apparente rayonnée ou PAR (ERP en anglais) à +10 dBm (10 mW) ;
• et celle des 868 MHz avec la sous-bande P (869,4 MHz - 869,65 MHz) permettant une PAR jusqu'à +27 dBm (500 mW) avec un rapport cyclique de 10 % par heure.

On voit clairement que, pour une utilisation très intermittente maximisant la portée, comme c'est le cas pour des sondes et capteurs, mieux vaut privilégier le matériel supportant la bande des 868 MHz (863 - 928 MHz) plutôt que celle des 433 MHz déjà bien occupée par de nombreux périphériques type sonnettes et télécommandes. Attention, la bande 902 - 928 MHz n'est pas utilisable en Europe, car hors ISM, ceci ne concerne que les USA et le Canada.

À cela s'ajoute le fait que tous les contrôleurs LoRa ne se valent pas et n'utilisent pas un transceiver forcément capable d'émettre à la puissance maximale autorisée. Nous avons là deux puces, la SX1276 et la SX1262. Cette dernière équipe le matériel récent et permet une émission avec une PAR de +22 dBm, par opposition au SX1276 limité à +20 dBm et équipant les cartes et modules les moins coûteux. 2 dBm de différence semblent peu, mais on parle ici de +50 % de puissance au bénéfice du SX1262, avec une sensibilité plus importante en réception et une consommation moindre.

Ici, j'ai jeté mon dévolu sur une paire de cartes Heltec Wi-Fi LoRa 32 V3 (attention, la V2 utilise un SX1276), acquises sur Amazon (pressé donc) pour environ 50 euros (les deux). Il s'agit de cartes basées sur de l'ESP32-S3, intégrant un contrôleur Semtech SX1262 ainsi qu'un écran OLED monochrome (bleu) de 0,96 pouce (128×64 pixels), un contrôleur de charge pour accu LiPo (non inclus) et une interface CP2102 pour la liaison USB/série. Le tout est livré avec un connecteur à souder pour l'accu et une antenne LoRa avec un connecteur IPEX1.0.

2. Architecture générale

Comme précisé précédemment, la structure générale de Meshtastic consiste en un maillage et même si ici nous n'avons que deux nœuds, ceci ne change rien à l'affaire. Dans la configuration par défaut, vous devez voir tous les nœuds en votre possession comme des passerelles vers le réseau Meshtastic et chacun d'eux communique à la fois avec le réseau via LoRa et potentiellement avec vous par un autre biais. Il peut s'agir de Bluetooth, d'une liaison série, de Wi-Fi, d'USB ou encore, tout simplement, d'une IHM (écran + périphérique d'entrée). Ceci est totalement dépendant du matériel utilisé et dans le cas des Heltec V3, nous avons de base le choix entre l'interface série accessible via CP2102 et le Bluetooth activé par défaut. Ceci permet une connexion et une configuration soit via un PC/Mac (outil CLI Python ou Web client), soit un smartphone et l'application Meshtastic dédiée (Android ou iOS).

Un peu à la manière d'ESPHome, le firmware Meshtastic est avant toute chose le socle logiciel permettant de faire fonctionner le réseau et d'établir la liaison avec votre ou vos équipements (PC, Pi, montage Arduino, etc.). De la même manière qu'un périphérique ESPHome s'intègre dans une configuration Home Assistant, un nœud s'intègre au réseau Meshtastic, mais peut également prendre en charge des capteurs directement et, en cas de connexion Wi-Fi locale, établir le contact avec un broker MQTT pour diffuser l'information. Un certain nombre de « modules » (logiciels) peuvent être activés dans la configuration pour adapter le comportement du firmware à vos besoins. De manière générale, cependant, il sera plus courant et plus souple de tout simplement utiliser un montage quelconque à base de microcontrôleur et de garder le nœud dans son simple rôle de passerelle.

En parlant de rôle justement, plusieurs profils sont prévus dans la configuration que nous allons voir sous peu. Celui par défaut est CLIENT, définissant que le nœud en question participe au réseau en relayant les messages et supporte l'utilisation de clients (Bluetooth, Wi-Fi, série, etc.). D'autres rôles peuvent être choisis, comme REPEATER ou ROUTER, principalement destinés aux nœuds placés stratégiquement pour une émission/réception LoRa optimale. Ici, la partie « cliente » sera donc désactivée et les nœuds en question ne feront que participer à la topologie du réseau.

Ce dernier point nous amène également à parler du GPS et des données associées. Le Heltec V3 n'intègre pas de récepteur GPS contrairement à d'autres périphériques, mais il est toutefois possible d'associer une information de position fixe « en dur » dans la configuration. Le positionnement géographique du nœud peut être intéressant pour cartographier le réseau et positionner les nœuds voisins afin de déterminer la portée de la liaison. Il peut également être utile de mettre en œuvre un récepteur GPS dans le cas d'un nœud mobile, sur accu ou dans un véhicule, par exemple. Il s'agit là, à mon sens, d'installations ayant des besoins spécifiques, et mieux vaut donc faire l'économie de quelques euros qui seront bien plus utiles ailleurs (autres nœuds, antenne plus performante, accu LiPo, etc.).

Étant donné la très faible densité de nœuds sur le territoire français (pour l'instant), la structure de l'installation consistera typiquement en un nœud relié à un ordinateur (PC, Mac, SBC) et un ou plusieurs autres nœuds faisant office de capteurs et dialoguant localement avec des montages divers. Meshtastic constituera ainsi le « média » sur lequel les informations circuleront d'un bout à l'autre de la liaison radio.

3. Firmware et mise à jour

Une fois le matériel réceptionné, il est très peu probable que le firmware installé soit dans une version récente. La première opération consistera donc à mettre à jour le logiciel et pour cela, la façon la plus simple de procéder consiste à pointer votre navigateur sur l'URL https://flasher.meshtastic.org. Vous trouverez là un flasher permettant de reprogrammer la mémoire de vos nœuds, quel que soit leur modèle, à condition d'utiliser un navigateur compatible avec l'API WebSerial. Ceci ne fonctionnera pas avec Firefox qui ne supporte pas cette fonctionnalité (et ne la supportera sans doute jamais) et vous devrez vous tourner vers Chromium, Chrome, Opera ou Edge.

Pour flasher votre Heltec V3, maintenez le bouton « PRG » enfoncé en connectant le périphérique en USB-C (« PRG » puis « RST » ne semble pas fonctionner, contrairement à d'autres cartes ESP32). Ceci le placera en mode bootloader et vous pourrez alors choisir « Heltec V3 » dans la liste, sélectionner une version récente (mais stable) du firmware (2.3.2.63df972 Beta à ce jour) et cliquer sur Flash. Un résumé des informations de la version s'affichera et vous pourrez défiler et cliquer sur Continue. Dans le formulaire qui apparaît alors, assurez-vous de cliquer Full Erase and Install, puis Erase Flash and Install. Le navigateur vous demandera de choisir le port série à utiliser pour terminer la procédure (attention aux permissions). Ceci prend un certain temps et vous pourrez suivre le déroulé des opérations directement à l'écran.

Voilà pour l'approche rapide. Si vous ne comptez pas utiliser un autre navigateur que votre Firefox (ce que je comprends tout à fait), une alternative est à votre disposition via la ligne de commandes. Précisons de suite que, généralement, j'aime reconstruire les firmwares moi-même pour ce type d'opération. Malheureusement ici, les développeurs, sans doute en raison du caractère très multiplateforme du projet, ont opté pour le duo PlatformIO + Visual Studio Code, ce qui ne va pas du tout dans le sens de mes préférences. J'aurais, en effet, préféré simplement utiliser l'ESP-IDF pour construire et flasher ce qui est, après tout, un simple ESP32. Les sources du firmware [4] comprennent un Dockerfile, ce qui laisse supposer un fonctionnement possible similaire à ESPHome, mais aucune indication n'est fournie.

On ne peut donc que se rabattre sur la solution la plus proche consistant à flasher le firmware binaire manuellement. Dans le cas de plateforme ESP32 comme le « Heltec V3 », nous pouvons utiliser l'outil esptool.py livré avec l'environnement ESP-IDF (ou installable séparément via pip3 install --upgrade esptool). Vous trouverez sur le GitHub officiel une section « Releases » où, pour la dernière version Beta (la plus stable) vous pourrez obtenir une archive ZIP (firmware-2.3.2.63df972.zip actuellement) regroupant tous les firmwares binaires pour tout le matériel supporté. Téléchargez et décompressez cette archive et parmi tous les fichiers, vous trouverez firmware-heltec-v3-2.3.2.63df972.bin. Nous n'allons pas utiliser le script fourni (device-install.sh), mais plutôt flasher manuellement avec esptool.py. Nous commençons par placer le périphérique en mode bootloader en le branchant tout en pressant le bouton « PRG », puis nous effaçons la flash :

Et enchaînons immédiatement sur le flashage du firmware, de l'image OTA BLE et du système de fichiers embarqué :

Comme nous avons utilisé --after no_reset, notre ESP32 reste en mode bootloader. Nous devons alors le déconnecter/reconnecter pour démarrer sur ce nouveau firmware.

Quelle que soit la méthode que vous avez utilisée, et si vous avez également opté pour ce matériel Heltec, l'écran OLED devrait vous afficher un message précisant que le périphérique n'est pas configuré et que vous devez choisir une région avec l'un des outils de configuration disponibles. En effet, il n'est pas question pour le firmware de commencer à utiliser LoRa sans savoir à quelle régulation locale se plier.

4. Configuration

De base, avec les Heltec V3 et leur ESP32, le Wi-Fi n'est pas actif et vous avez alors deux options de connexion : le port série (via le CP2102 intégré) ou le Bluetooth avec votre smartphone et l'application Meshtastic (disponible dans les stores Google et Apple). Pour la liaison série, là encore nous avons deux options : le client web (local ou via https://client.meshtastic.org/) ou le client Python en ligne de commandes.

Commençons par le plus simple en procédant à une configuration minimale permettant, au moins, de communiquer via LoRa. Commencez par installer l'application Meshtastic sur votre smartphone (ici, Android) et assurez-vous de bien avoir le Bluetooth activé. Lancez ensuite l'application et, dans la configuration (le dernier écran) utiliser le bouton +. Votre appareil va alors détecter un périphérique avec un nom débutant par « Meshtastic » suivi d'une valeur hexadécimale correspondant aux deux derniers octets de son adresse MAC. Dès ce moment, l'écran OLED du Heltec V3 vous affichera un message vous présentant un code à 6 chiffres permettant de vous appairer en Bluetooth. Ceci fait, la communication est établie et, sur le même écran, vous verrez en haut à droite la région définie à « UNSET ». Tapotez et choisissez « EU_868 » (Europe 868 MHz), votre nœud Meshtastic va alors redémarrer pour utiliser cette nouvelle configuration et immédiatement rechercher d'autres nœuds via LoRa. Votre smartphone est maintenant un « terminal » connecté au nœud et, si vous avez des voisins Meshtastic, ils devraient apparaître dans le second écran de l'application.

Dans la continuité de cette configuration, nous allons maintenant nous occuper du second nœud, mais cette fois via l'outil en ligne de commande sur Raspberry Pi, par exemple (ou PC GNU/Linux). Pour cela, commencez par créer un environnement virtuel Python avec la commande python3 -m venv /chemin/meshtastic. Ceci vous permettra de télécharger et installer l'outil et ses dépendances (modules) sans interférer avec le reste du système. Pour activer cet environnement, utilisez source /chemin/meshtastic/bin/activate, puis installez avec pip3 install --upgrade pytap2 meshtastic. Ceci fait, tant que vous serez dans l'environnement (que vous pouvez quitter avec deactivate), vous aurez accès à la commande meshtastic.

Votre nœud connecté en USB, vous devez avoir un nouveau port série (/dev/ttyUSB*) et c'est via cette interface que vous pourrez utiliser le client Python. Pour tester le bon fonctionnement, vous pouvez utiliser l'option --info accompagnée de --port /dev/ttyUSBx pour spécifier le port. Vous devrez alors voir apparaître un gros paquet d'informations concernant le périphérique, sous forme de données JSON. L'option -h vous indiquera, classiquement, toutes les commandes utilisables. Un autre test qui peut s'avérer très utile par la suite, surtout si vous êtes déjà habitué à la syntaxe de configuration d'ESPHome et/ou Home Assistant, est l'export de la configuration actuelle en YAML avec meshtastic --port /dev/ttyUSB1 --export-config, qu'on redirigera vers un fichier avec quelque chose comme > maconfig.yaml. Ce fichier pourra ensuite être modifié, puis réimporté avec --configure.

Mais pour l'heure, nous souhaitons juste activer LoRa et donc spécifier la région. Chose que nous faisons avec :

Notez qu'à chaque utilisation de --set, la configuration est immédiatement modifiée puis appliquée, ce qui provoque un redémarrage du périphérique. Ceci peut être embêtant lorsqu'il s'agit de modifier plusieurs paramètres liés entre eux. Un bon exemple est la configuration du Wi-Fi, et nous pouvons faire cela, immédiatement, en cumulant plusieurs options en une ligne :

Avec les plateformes ESP32, le fait d'activer le Wi-Fi désactive le Bluetooth automatiquement, mais vous pouvez également décider de le faire explicitement avec :

Une fois le périphérique redémarré une dernière fois, celui-ci sera connecté à notre réseau et accessible via http://meshtastic.local/ (mDNS) ou directement avec l'IP obtenue par DHCP. En pointant votre navigateur à cet endroit, vous verrez une page web fournie par l'ESP32, en tout point similaire à celle de https://client.meshtastic.org/. Un nœud configuré de cette manière est également accessible localement (LAN) via l'application mobile. Vous pouvez donc désactiver le Bluetooth sur votre smartphone (ce qui est toujours une bonne chose). Notez qu'il est également possible d'utiliser le client Python via LAN en utilisant --host et l'IP du nœud en lieu et place de --port.

L'idée est ici d'avoir l'un des nœuds connecté en Wi-Fi et le ou les autres étant déconnectés pour être éventuellement reconfigurés via le port USB ou en Bluetooth. Notez qu'il est également possible de configurer ces nœuds pour les rendre administrables à distance, via le réseau mesh, de façon sécurisée pour éviter des accès physiques potentiellement pénibles.

Une fois nos deux nœuds ainsi configurés, vous devez voir, sur l'un comme sur l'autre, le second nœud présent dans le « voisinage », que ce soit dans l'application smartphone, dans l'interface web (série ou HTTP) à la section « Nodes » ou via le client Python, avec l'option --nodes. Chaque nœud est désigné par un nom, un alias de 4 caractères et son identifiant composé des 4 derniers octets de son adresse MAC. Le nom et l'alias sont deux éléments que vous pouvez changer dans la configuration.

5. Canaux

Pour configurer plus avant nos nœuds, nous devons nous pencher sur la notion de « canal ». Les canaux ne sont pas des « bandes de fréquences », mais un mécanisme permettant la ségrégation des messages. Par défaut, un seul canal de communication est actif, c'est le canal 0 également désigné comme primary et celui-ci est chiffré avec AES en utilisant une clé partagée (ou PSK pour Pre-Shared Key) connue, c'est "AQ==" (ou 0x01 en hexadécimal). Le canal primaire est celui utilisé pour diffuser les informations comme la télémétrie et la position entre les nœuds, c'est le canal par défaut. Il ne peut exister qu'un seul canal primaire dans la configuration.

Dans un réseau plus vaste que deux nœuds isolés (pour le moment), les échanges sur le canal primaire sont donc publics et visibles par tous (puisque tout le monde à la même PSK). Ce n'est pas nécessairement ce que vous pouvez souhaiter si vous devez faire circuler des informations concernant vos capteurs. Pour cela, vous avez à disposition 7 autres canaux configurables, utilisant des PSK de votre choix à renseigner en base64 dans l'interface web ou en base64/hexadécimal via l'outil Python. Pour configurer un canal, je pense que la manière la plus simple est de commencer par un nœud et via l'outil en ligne de commande ainsi :

Nous activons ainsi le canal 1 en lui donnant un nom et réglons un mot de passe aléatoire. Nous pouvons ensuite afficher les informations du périphérique pour retrouver l'information qui nous intéresse :

Nous avons, à présent, le nom et le PSK en base64 que nous pouvons répercuter sur les autres nœuds via l'interface web ou l'application smartphone d'un simple copier/coller. Une fois cet ajout fait sur l'ensemble des nœuds, nous avons alors trois moyens de communication à notre disposition :

• via le canal primaire : pour tout le monde sur tout le réseau mesh ;
• via des messages directs d'un nœud à un autre en spécifiant l'ID de la cible : Messages/Nodes dans l'interface web, tapez sur un nœud et Message direct dans l'application mobile ou --sendtext "mon message" accompagné de --dest suivi de l'ID précédé d'un !. Attention, il faut échapper ce caractère qui a une utilisation spécifique dans le shell, c'est donc \! qu'il faut utiliser ;
• via un canal privé protégé par une clé AES où les messages restent donc privés entre les nœuds qui possèdent cette clé, notre « sous-réseau mesh », en somme.

Notez que si vous configurez plusieurs canaux, ceux-ci doivent être consécutifs. Vous ne pouvez pas avoir un « trou » dans la liste des canaux.

6. Modules

Le firmware Meshtastic ne fait pas que de s'occuper de la communication sur le réseau maillé et de fournir l'interface avec le monde extérieur. Il intègre également, selon la plateforme, plusieurs modules logiciels permettant d'activer des fonctionnalités sans avoir à modifier ou reconstruire le firmware. En réalité, il ne s'agit pas du tout d'une sorte de SDK prévu pour être adapté en fonction des capteurs à mettre en œuvre. Un nœud doit surtout être vu comme une interface à mettre en œuvre avec un microcontrôleur complémentaire, chargé de gérer les capteurs. La question est donc, comment faire cela et, en même temps, ajouter des fonctionnalités au firmware, et la réponse tient en un mot : module.

Si vous faites un tour dans la section éponyme, dans l'interface web par exemple, vous trouverez une série de formulaires vous permettant d'activer et configurer ces modules. Nous n'allons pas tout traiter ici, mais uniquement nous concentrer sur trois d'entre eux.

Premièrement, nous avons Serial permettant d'établir une nouvelle liaison série, plus simple à utiliser que celle disponible via l'interface USB (CP2102 avec les Heltec V3) permettant certes de récupérer les messages reçus et d'en envoyer, mais utilisant un protocole qui permet aussi la configuration, impliquant de passer, par exemple, par un client Python. Ici, avec cette nouvelle interface, nous définissons deux GPIO pour RX/TX (47 et 48, par exemple) et ce sont uniquement les messages qui transiteront. Ceci nous permettra alors de connecter une carte ESP8266, RP2040 ou Arduino (attention c'est 3,3 V) pour simplement envoyer et recevoir des messages sans autre forme de procès, en texte brut.

Nous avons ensuite le module Telemetry qui, comme son nom l'indique, permet de mesurer et diffuser des informations sur « l'état de santé » d'un nœud. En activant ce module, de base, ce sont les mesures de charge d'accu, de tension, d'utilisation des canaux et du « temps d'antenne » qui sont concernées, mais il est possible d'aller plus loin. Dans le cas des Heltec V3, par exemple, les GPIO 41 et 42 (respectivement SDA et SCL) donnent accès par défaut à un bus i2c scanné automatiquement au démarrage. Si un capteur pris en charge par le module (voir [5]) est détecté, il sera automatiquement utilisé. C'est le cas, par exemple, du BME280 (température, pression et hygrométrie) qu'il suffira de brancher à ces GPIO (plus la masse et l'alimentation) pour que ces mesures s'ajoutent et apparaissent directement dans la liste des nœuds voisins sur l'application smartphone, par exemple.

D'autres modules de ce genre sont également disponibles comme la notification externe, la lumière ambiante, la détection de changement d'état d'une GPIO (capteur PIR, par exemple) ou encore MQTT (avec une connexion Wi-Fi) qui offre une possibilité d'intégration à Home Assistant, et est le troisième module qui nous intéresse...

7. Intégration rapide à Home Assistant

En ayant un de nos nœuds connecté en Wi-Fi au réseau local, le module MQTT activable dans le firmware Meshtastic peut remonter les informations qu'il reçoit directement à un broker MQTT comme Mosquitto. En parallèle, Home Assistant (ou HA dans la suite du texte) peut également utiliser ce broker comme source d'information (et plus encore) pour collecter des mesures et intégrer les valeurs dans ses statistiques. En d'autres termes, il est possible de déployer ses capteurs avec Meshtastic et en faire des entités dans HA.

Pour ce faire, nous devons tout d'abord disposer d'un broker MQTT sur notre réseau. Inutile de chercher plus loin que HA lui-même, proposant directement Mosquitto sous la forme d'un module complémentaire (ou add-on) installable via le menu Paramètres en un simple clic. Le broker local détecté apparaîtra alors automatiquement dans les intégrations et pourra être configuré. Sans plus de configuration, le broker utilisera les informations des utilisateurs locaux (votre compte pour l'interface web HA) pour authentifier les connexions. Vous pourrez donc rapidement vérifier le bon fonctionnement de l'installation de base en allant dans Paramètres, Appareils et services, MQTT, CONFIGURER et Écouter un sujet. Là, mettez un # comme sujet (pour « tout » écouter), activez Mettre en forme le contenu JSON et cliquez COMMENCER A ÉCOUTER. Sur une autre machine, comme une Pi, utilisez la commande mosquitto_pub -u utilisateur -P mot2passe -h machineHA.local -t homeassistant/switch/1/on -m “ON” (paquet mosquitto-clients) et le message doit alors apparaître côté HA, démontrant que la configuration et l'authentification fonctionnent.

Tournez-vous ensuite vers votre nœud disposant d'une connexion Wi-Fi, puis activez et configurez le module MQTT. Renseignez l'adresse IP de votre hôte HA (la résolution mDNS ne semble pas fonctionner, il faut une IP), le nom d'utilisateur et son mot de passe, et activez l'option JSON Enabled. Enregistrez les changements pour appliquer le tout (reboot).

À ce stade, nous devons avoir une connexion possible entre notre mesh et le broker MQTT, et de ce fait, vers l'intégration HA. Mais nous n'avons dit nulle part ce qui devait être transféré du réseau mesh au broker. Pour une utilisation privée, c'est via notre canal précédemment configuré que ceci va se passer. Retournez donc dans la configuration de ce canal et activez l'option Uplink Enabled pour que tous les messages en question soient publiés en MQTT.

La configuration appliquée, utilisez ce canal privé pour envoyer un message et vous verrez alors apparaître dans HA quelque chose comme :

Notre message sur ce canal a été capté par un nœud avec une liaison au LAN et celui-ci a été relayé au broker depuis lequel l'intégration HA l'a récupéré et affiché. Nous avons donc un moyen de remonter les informations de n'importe quel nœud directement dans HA ! Notez que dans cette sortie exemple, le message est envoyé (sender) par le nœud !fa6baf80, celui avec Wi-Fi et MQTT activé, mais qu'en réalité il provient de l'autre nœud, comme précisé par la propriété from qui vaut 4201363136, et donc 0xfa6bb6c0, l'ID du nœud qui n'est pas connecté en Wi-Fi. Cette gymnastique décimale/hexadécimale est pénible et les termes sender et from sont clairement source de confusion, mais c'est bel et bien from qu'il faut considérer.

Pour l'intégration à proprement parler, ceci dépendra de ce que vous comptez faire avec vos nœuds, quels capteurs seront utilisés et comment. Ceci sort du cadre du présent article qui se concentre sur le réseau mesh LoRa et non sur l'intégration MQTT dans HA. Mais la documentation de Meshtastic donne un bon point de départ [6] et il en va de même pour celle de HA [7].

8. Conclusion

Pour l'heure, ne vous étonnez pas de ne pas voir vos voisins Meshtastic. Il n'existe, à ce jour, pas énormément de nœuds en France, selon l'une des cartes accessibles en ligne [8]. Celle-ci n'en montre seulement qu'un peu plus d'une centaine pour la France contre plus de 1500 au Royaume-Uni. Personnellement, je suis relativement isolé étant donné que le nœud le plus proche se trouve à quelque 50 km de chez moi à la frontière suisse (mais qui sait, avec une bonne antenne...). Espérons que le présent article suscite de la motivation pour participer au réseau, car en ce qui me concerne, je compte effectivement apporter ma pierre à l'édifice en procédant à une installation permanente sur le toit de mon habitat.

Ceci dit, même en dehors de l'aspect participatif, Meshtastic constitue une solution vraiment intéressante pour déployer des capteurs en dehors de la portée d'autres solutions, et ce pour un coût tout à fait raisonnable, voir nul pour ce qui est du fonctionnement même de l'installation.

Mais, oui, j'aimerais vraiment, mais vraiment, beaucoup voir apparaître des nœuds autour de moi. Mes Heltec V3 se sentent tellement seuls...

Références

[1] https://connect.ed-diamond.com/Hackable/hk-019

[2] https://meshtastic.org/docs/overview/range-tests/

[3] https://meshtastic.org/docs

[4] https://github.com/meshtastic/firmware

[5] https://meshtastic.org/docs/configuration/module/telemetry/

[6] https://meshtastic.org/docs/software/integrations/mqtt/home-assistant/

[7] https://www.home-assistant.io/integrations/mqtt/

[8] https://meshtastic.liamcottle.net/

[9] https://discord.com/invite/UQJ5QuM7vq