Ce que la norme apporte, et ce qu’elle ne dit pas
LoRaWAN est une norme, portée par une alliance de fabricants. La conséquence pratique est qu’il existe un choix très important de modèles de devices, pour toutes sortes d’usages. On achète un compteur chez un fournisseur, une centrale de mesure chez un autre, une sonde de température chez un troisième, et les trois vivent sur le même réseau sans passerelle d’adaptation. Aucun de ces fabricants n’a besoin de savoir sur quel serveur ses produits finiront.
Ce que la norme ne dit pas, en revanche, c’est si le produit est bon. La certification porte sur la conformité au protocole, pas sur l’étanchéité du boîtier, ni sur la tenue en température, ni sur la justesse de la mesure. Ces trois points se vérifient sur la fiche du produit et sur le terrain.
C’est là que se joue notre choix de matériel. Les devices que nous déployons sont des produits industriels : un indice de protection déclaré, une plage de température qui couvre celle du local où ils vont vivre, un décodeur documenté, un fabricant qui répond. Nous ne posons pas sur un point de mesure industriel un montage qu’il faut programmer pour l’occasion. Nous savons le faire, nous le faisons quand rien n’existe au catalogue, mais c’est une capacité mobilisée en dernier recours, pas notre méthode courante. C’est aussi la raison de fond pour laquelle le WiFi ne rentre pas dans nos installations de mesure : ce n’est pas une question d’ondes, c’est une question de matériel disponible, et nous l’avons développée dans l’article consacré à cette comparaison.
Les familles de devices que nous déployons
Le mot device couvre des objets très différents. Il vaut la peine de les distinguer, parce que les contraintes d’installation ne sont pas les mêmes.
Le comptage. La plupart des compteurs d’eau, de gaz et d’air comprimé disposent d’une sortie impulsion. Le device compte ces impulsions et remonte un index. Point important, déjà signalé dans l’article sur la gateway : l’index vit dans le device. Une liaison coupée ne perd pas la consommation, elle retarde sa remontée.
Les centrales de mesure électriques et les pinces ampèremétriques. Sur un départ de TGBT, la pince se referme autour du câble sans couper l’alimentation, ce qui change tout quand l’atelier ne s’arrête pas. Le device remonte les puissances et les énergies, souvent avec le détail par phase.
La température et l’humidité. Le besoin le plus banal et le plus fréquent. Sonde intégrée au boîtier pour un local, sonde déportée sur câble dès qu’il faut mesurer dans une enceinte, un four ou une chambre froide et laisser l’électronique dehors.
Les entrées analogiques. Certains devices exposent une entrée 4-20 mA ou 0-10 V, sur laquelle se raccorde un capteur d’instrumentation du commerce. Cela ouvre tout le catalogue classique : pression, débit, niveau. Le cas qui revient le plus souvent chez nous est la pression d’un réseau d’eau. Des installations ont besoin d’une pression minimale pour fonctionner correctement, et quand la pression du réseau chute, rien ne le dit. La machine travaille mal, personne ne fait le lien, et on cherche le défaut sur la machine. C’est exactement ce qui s’est produit chez un client avant qu’on instrumente le point : un capteur de pression sur entrée analogique, un seuil, une alerte, et le doute est levé en quelques secondes au lieu d’une demi-journée passée à chercher au mauvais endroit.
Les entrées série. Un device qui parle Modbus RTU sur RS485 interroge un équipement déjà en place, lit ses registres et les remonte. C’est le seul moyen de rendre exploitable un compteur communicant ou un automate existant sans le remplacer, et c’est souvent le device qui fait la différence entre un projet raisonnable et une dépose complète.
Les entrées et sorties tout ou rien. Un contact sec de défaut, un état de marche, un retour de position. Et dans l’autre sens, une sortie relais, ce qui nous amène au point suivant.
Le device alimenté, et le coffret que nous assemblons
La batterie est une réponse à l’absence d’alimentation, pas un objectif. Dès qu’il y a du 230 V à portée de main, c’est ce qu’on utilise. Un device alimenté n’a pas de fin de vie programmée, n’impose aucune contrainte de cadence, et peut écouter en permanence.
Cette écoute permanente est justement ce qui permet de commander quelque chose. Un device qui doit recevoir un ordre à tout moment fonctionne en classe C, et la classe C sur batterie n’a pas de sens : le mécanisme et ses conséquences sont posés dans l’article sur le fonctionnement du LoRaWAN. Autrement dit, un device sur batterie mesure, il ne pilote pas.
Ces coffrets, nous les assemblons dans nos ateliers, selon le type d’environnement où ils vont vivre. Un coffret reçoit un device, ou plusieurs quand les points à piloter sont proches, et tous partagent la même alimentation. L’avantage est double : plus aucune gestion de batterie à prévoir, et la possibilité de commander des relais. C’est le cas typique de l’armoire électrique d’une station de pompage ou d’un local technique, où l’énergie se trouve à quelques centimètres et où il serait absurde d’installer du matériel sur batterie. En sortie, les relais commandent une pompe ou une électrovanne, ce que nous avons détaillé dans l’article sur le pilotage de l’eau, de l’air et de l’électricité.
Un coffret n’est pas qu’une boîte avec des devices dedans. Nous y installons l’alimentation, un transformateur dimensionné pour ce qu’il doit tenir, avec ses protections. C’est un équipement électrique, assemblé comme tel, conforme au RGIE. Un boîtier posé dans une armoire de production engage la responsabilité de celui qui l’a monté, et c’est un point sur lequel un intégrateur ou un bureau d’études nous attend, à juste titre.
La règle de décision est simple. Un point de mesure isolé, sans alimentation à proximité et sans commande à passer, part sur batterie. Un point situé dans ou contre une armoire, ou qui doit agir sur le process, part sur alimentation et en coffret.
Ce qui use une batterie
Commençons par un cas qui contredit ce qu’on entend le plus souvent. Un compteur d’eau posé dans une cavette, sous une trappe, à l’autre bout d’un site. Le signal qui en sort est très faible, et son rapport signal sur bruit est négatif une bonne partie du temps. Il envoie un message tous les quarts d’heure depuis le début de l’année 2024. Sa tension de batterie, aujourd’hui, est celle qu’il avait le jour de la pose. Ni la cadence rapide ni l’emplacement ingrat ne l’ont usé.
Ce n’est pas de la chance, et l’explication tient en une phrase : ce qui consomme, c’est le temps passé à émettre, pas la distance que le signal doit parcourir.
La cadence. C’est le premier levier, et le seul qui se règle par un paramètre. Un compteur relevé tous les quarts d’heure envoie 96 fois plus de messages que le même compteur relevé une fois par jour. Autant d’émissions, autant de données transmises, autant de points à stocker. Sur la seule batterie, l’exemple ci-dessus montre que cela se tient des années. Le problème est ailleurs.
Alors pourquoi ne pas tout mettre au quart d’heure. Parce que la batterie n’est pas la seule à payer. Chaque message devient un point transmis, stocké, puis conservé pendant des années. Sur beaucoup d’installations que nous reprenons, ces données arrivent à un rythme que personne ne consulte : la courbe au quart d’heure existe, elle n’est jamais ouverte, et elle encombre la lecture de celles qui comptent. Une donnée inutile n’est pourtant pas neutre : elle occupe du disque, elle se sauvegarde, elle se réplique, et tout cela consomme de l’électricité pour un usage qui n’existe pas. Mesurer plus fin n’est pas mesurer mieux, sauf quand la finesse sert à quelque chose : un talon nocturne, une alarme, la recherche d’une fuite. La cadence se décide sur l’usage de la donnée, pas sur le confort du dashboard.
Le temps d’émission, et donc l’étalement. Ce qui coûte vraiment n’est pas l’éloignement mais la durée de chaque message. Un device éloigné qui conserve un étalement bas, parce qu’il lui reste de la marge, émet aussi court qu’un device posé à côté de la gateway. Celui qui coûte cher est celui que le réseau a dû faire passer en étalement élevé, où le même message dure des dizaines de fois plus longtemps. C’est l’objet de la section suivante, et c’est la vraie raison pour laquelle un emplacement se réfléchit.
La configuration d’usine. Un device sorti du carton émet à la cadence de démonstration du fabricant, de quelques minutes à quelques dizaines de minutes selon les modèles. Mis en service sans que ce paramètre soit revu, il consommera sa batterie à faire la démonstration qu’il fonctionne.
Le froid. Une batterie au lithium en local non chauffé ou en extérieur ne restitue pas l’hiver ce qu’elle restitue à 20 degrés. Sur le compteur en cavette, le seul accident visible en deux ans et demi de relevés est un léger creux au mois de janvier. Un device en cavette, en toiture ou dans un hall non chauffé se prévoit à la baisse.
Ce que le device dit de sa batterie
L’information remonte par deux chemins qu’il faut distinguer.
Le premier est le payload applicatif du fabricant. La plupart des devices y placent un pourcentage ou une tension à côté de la mesure, c’est décodé comme le reste et c’est ce qui alimente nos suivis.
Le second est prévu par la norme elle-même. Le serveur peut demander son état au device, qui répond avec un niveau de batterie et une marge de démodulation. Dans ce champ normalisé, une subtilité mérite d’être connue : la valeur 0 ne signifie pas batterie vide, elle signifie que le device est sur alimentation externe, et la valeur haute de l’échelle signifie qu’il n’a pas pu mesurer son niveau. Un seuil d’alerte posé naïvement sur ce champ déclenche une alarme de batterie sur tout un coffret alimenté.
La limite à garder en tête vaut pour les deux chemins. Ces batteries au lithium de 3,6 volts ne perdent presque pas de tension en fonctionnement, et c’est exactement ce que montre le compteur en cavette : deux ans et demi de relevés, une ligne plate. Le fabricant fixe le remplacement à 2,7 volts, soit près d’un volt plus bas, et précise lui-même dans ses notices que la courbe de décharge n’est pas linéaire et qu’il ne faut pas la traduire en pourcentage. L’indicateur n’est donc pas une jauge d’essence. Il se lit comme une tendance sur des années, et il ne prévient pas longtemps à l’avance. Le remplacement se planifie sur l’âge du parc et sur la cadence, pas sur cette seule valeur.
Spreading factor et ADR
Le spreading factor est le degré d’étalement du signal. Plus il est élevé, plus le message résiste au bruit et à la distance, et plus il occupe l’air longtemps. Le même message peut prendre des dizaines de fois plus de temps à passer selon ce réglage. Cela se paie deux fois : en énergie côté device, et en temps d’antenne consommé sur la bande, dont les règles sont expliquées dans l’article sur le fonctionnement du LoRaWAN.
L’ADR est le mécanisme qui règle cela tout seul. Le serveur observe la qualité des messages reçus d’un device et lui propose de réduire son étalement quand la marge le permet. Le device applique, émet plus court, consomme moins.
La mise en service, et ce qui bloque un join
Nous mettons les devices en service en OTAA. Le device ne détient pas ses clés de session, il les obtient au moment où il rejoint le réseau. Cela demande de renseigner trois éléments : le DevEUI, qui identifie le device, le JoinEUI, qui identifie l’application, et l’AppKey, la clé racine dont dériveront les clés de session. Le JoinEUI s’appelait AppEUI dans les versions antérieures de la norme, ce qui explique que l’étiquette du fabricant et le champ du serveur ne portent pas toujours le même intitulé : c’est le même paramètre.
Ce que nous faisons ensuite tient en une phrase : rien. Ces trois éléments saisis, le reste est automatique, et le reste fonctionne. Il n’y a aucun réglage fin à opérer device par device pour qu’une installation tienne dans le temps.
Quand un device ne rejoint pas le réseau, la cause est presque toujours dans ces trois champs. Un caractère de trop ou un caractère manquant sur une clé. Un identifiant recopié dans le mauvais sens, parce que le fabricant l’imprime dans un ordre et que le serveur l’attend dans l’autre. Un device déjà déclaré ailleurs, sur un autre profil ou un autre réseau. Ce sont des erreurs de saisie, pas des problèmes de sans fil, et c’est par là qu’il faut commencer.
La distinction avec un vrai problème de couverture est immédiate. Sur une erreur de clé ou d’identifiant, la tentative de raccordement arrive bien au serveur et échoue. Sur un device hors de portée, rien n’arrive du tout. Un coup d’œil suffit à trancher, et il évite de partir déplacer une antenne pour une clé mal recopiée.
Lire le RSSI et le SNR
Une fois le device en service, deux valeurs accompagnent chaque message reçu, et elles ne disent pas la même chose.
Le RSSI est le niveau du signal reçu. Le SNR est l’écart entre ce signal et le bruit ambiant. La grille de lecture tient en deux cas.
Signal faible mais propre, RSSI bas et SNR correct : c’est de la distance ou de l’atténuation. Le réseau s’y adapte, l’étalement augmente, les messages passent. Si cela ne suffit pas, la correction est du côté de l’antenne ou du placement.
Signal fort mais sale, RSSI correct et SNR dégradé : c’est du bruit, donc une source qui émet à proximité. La correction consiste à trouver ce qui émet, pas à déplacer quoi que ce soit.
Confondre les deux fait déplacer une gateway pour rien, et c’est l’erreur la plus courante quand on ne regarde qu’une seule des deux valeurs.
Un point surprend souvent les nouveaux venus : en LoRa, le SNR est fréquemment négatif. Un message reste décodable alors que le signal se trouve sous le niveau de bruit, ce qui est une conséquence directe de l’étalement de spectre. La fiche technique du transceiver SX1276 de Semtech, largement utilisé dans les devices du marché, donne pour une bande de 125 kHz une limite de démodulation à -7,5 dB de SNR au plus faible étalement, et à -20 dB au plus fort, pour des sensibilités respectives de -123 et -136 dBm. Autrement dit, un SNR de -15 dB relevé sur un device en étalement élevé n’est pas une anomalie, c’est le régime normal de fonctionnement.
Ce que nous en faisons est moins normatif qu’on pourrait le croire. Un device peut rester en place avec des niveaux médiocres si la nature de la mesure le supporte : c’est le cas du compteur d’eau en cavette décrit dans l’article sur le fonctionnement du réseau, où l’on compense un signal médiocre par la cadence plutôt que par du matériel. À l’inverse, une mesure qui déclenche une alarme ne tolère pas la même perte de messages.
Le vrai intérêt de ces deux valeurs est dans la durée. Un connecteur d’antenne extérieure qui prend l’eau ne coupe rien du jour au lendemain : il fait baisser le niveau reçu de tout le parc, lentement, sur des mois. Sans relevé de ces valeurs, personne ne le voit, et c’est exactement le suivi que nous mettons en place au niveau de la gateway. Ce qui suppose une chose : noter les niveaux à la mise en service. Sans point de départ, une dérive n’existe pas.
Ce qu’on peut faire à distance, et ce qu’on ne peut pas
Un device LoRaWAN n’est pas un objet muet qu’on visite avec un tournevis. Deux natures d’ordres descendants coexistent, et les confondre mène à des attentes fausses.
Les premiers sont normalisés. Le serveur ajuste l’étalement et la puissance d’émission, active ou retire des canaux, demande son état au device. Cela fonctionne de la même façon sur tous les devices conformes, sans rien connaître du produit.
Les seconds sont propres au fabricant. Redémarrer un device, changer sa cadence de relevé, relire sa configuration, revenir aux paramètres d’usine, forcer un envoi immédiat, basculer une sortie relais : tout cela existe sur les produits industriels que nous déployons, mais la norme ne dit rien de la façon de l’écrire. La syntaxe se lit dans la documentation du produit, et deux devices de deux fabricants ne se redémarrent pas avec le même message. C’est un point à vérifier au moment du choix du matériel, au même titre que l’indice de protection : un produit dont la configuration ne se change qu’en ouvrant le boîtier vous fera revenir sur site.
La limite est structurelle, et elle tient au rythme. Un ordre descendant n’est pas instantané. Un device sur batterie n’écoute qu’après avoir parlé, donc une commande envoyée à un device qui remonte une fois par jour attend son tour. Reconfigurer un parc à distance se fait, mais cela se planifie sur le rythme des devices, pas sur celui de l’opérateur.
Cette contrainte a un effet secondaire qu’on apprécie. Un device sur batterie n’ouvre que deux très courtes fenêtres d’écoute après chacune de ses émissions, et sa réception est éteinte le reste du temps. Rien ne peut donc lui être adressé en dehors de ces quelques instants. Il n’a ni adresse joignable, ni port ouvert, ni interface d’administration, contrairement à n’importe quel équipement raccordé au réseau informatique du site. Cela ne le rend pas invulnérable, ses messages circulent et c’est le chiffrement qui les protège, sujet traité dans l’article sur le fonctionnement du LoRaWAN. Mais la prise qu’il offre à quelqu’un qui chercherait à en prendre le contrôle est sans commune mesure.
Ce que le choix du device ne résout pas
Un device bien choisi, bien placé et bien réglé ne produit encore aucune information utilisable. Il faut un décodeur juste pour transformer ses octets en mesure, et sans décodeur la mesure n’existe pas. Un device impeccable derrière un décodeur approximatif donne des valeurs fausses avec une belle qualité de signal.
Et il reste la question qui précède toutes les autres : est-ce que ça passe, à cet endroit précis, dans ce bâtiment. Aucune fiche technique ne répond à cette question. Un relevé sur site y répond, et c’est par là que commencent nos installations.
Si vous avez un parc de compteurs, une armoire à instrumenter ou un équipement en Modbus dont vous voudriez sortir les données, parlons-en. Nous regardons d’abord ce qui existe déjà chez vous, avant de proposer quoi que ce soit à installer.