LoRaWAN

Référence du pilote LoRaWAN : le serveur de réseau Basics Station intégré, les certificats de passerelle, les inscriptions de capteur et de concentrateur, et l'adressage dans la charge utile.

Le pilote LoRaWAN fait de Ganter Lab un petit serveur de réseau LoRaWAN. Le sens de la relation est inversé par rapport à la plupart des pilotes : la station ne va pas chercher un capteur, c'est la passerelle qui se connecte à Ganter Lab, et les capteurs livrent leurs relevés en liaison montante par cette passerelle. Ganter Lab embarque un serveur de réseau qui parle le protocole LoRa Basics Station de Semtech : toute passerelle dont le micrologiciel est Basics Station peut donc employer cette station comme LNS.

Le serveur intégré démarre quand le premier équipement LoRaWAN activé est chargé dans le connecteur en fonctionnement, non au démarrage de l'application, et s'arrête quand le dernier est retiré ou désactivé : sans capteur ni concentrateur configuré, rien n'écoute sur le port. En ajouter un le fait revenir, sans redémarrer l'application.

Chaque équipement sous ce pilote est l'une de deux inscriptions, choisie dans son volet :

• Un capteur, identifié par son DevEUI et admis avec sa clé applicative. Ses tags décodent la charge utile de la liaison montante.
• Un concentrateur radio (la passerelle), identifié par son Station EUI et inscrit dans une région radio choisie dans une liste. Il ne porte aucun tag à lui : sa page garde Ajouter un tag grisé, avec la raison, tant que l'équipement n'est pas enregistré comme capteur.

Inscrivez le concentrateur autant que les capteurs. Un concentrateur Basics Station demande sa configuration radio dès qu'il se connecte et ne relaie rien du tout tant qu'on ne lui a pas répondu : une station qui n'a jamais vu son Station EUI laisse donc chaque capteur derrière lui sans valeur, alors que la connexion elle-même paraît saine. La réponse est bâtie ici à partir de la région que vous avez choisie; il n'y a aucun texte de configuration à coller.

Préparer la passerelle

C'est la passerelle qui appelle cette station, par LoRa Basics Station, et en sortie d'usine elle ne sait pas où la station se trouve. La page de chaque équipement enregistré comme concentrateur radio porte la carte Préparer la passerelle, avec ce qu'il faut entrer dans les réglages Basics Station de la passerelle, écrit pour cette station :

La carte est ouverte tant que la passerelle ne s'est pas connectée depuis l'ouverture de la station, et se replie une fois qu'elle s'est connectée : elle reste sur la page pour la prochaine fois que la passerelle sera configurée. Une passerelle dont aucune racine installée dans Windows ne garantit le certificat est refusée à sa première connexion et attend dans Accès des équipements. Une passerelle qui ne parle que le protocole Semtech UDP packet forwarder ne peut pas se connecter : il lui faut un micrologiciel Basics Station.

Le fichier est le même pour toutes les passerelles de cette station, et il ne change pas quand le nom ou les adresses de la station changent. Une passerelle avec les réglages par défaut de Basics Station accepte la station : rien n'est à désactiver dans sa configuration.

Toute passerelle qui a reçu un fichier d'une version antérieure a besoin de celui-ci, installé une fois comme tc.trust. Au premier démarrage de cette version, une station dont les passerelles peuvent détenir un fichier antérieur affiche sur la carte un avis, Le fichier de cette station a changé, dans cette exécution seulement. L'avis est un rappel, pas la consigne : installez le nouveau fichier une fois sur chaque passerelle d'une station qui avait déjà des passerelles, que la carte affiche l'avis ou non.

Serveur de réseau et ports

L'écouteur est toujours en TLS. Aucun réglage ne désactive le chiffrement : un écouteur en HTTP simple est refusé partout sauf sur la boucle locale, injoignable depuis le réseau de l'usine et qui n'existe que pour les essais en processus.

Certificats

L'admission se fait par TLS mutuel : le serveur prouve qui il est avec son propre certificat, et chaque passerelle doit prouver qui elle est avec un certificat client.

Certificat serveur. Le serveur de réseau présente un certificat signé par la racine propre à cette station, la même que celle dont dépend le système central OCPP. La racine est créée une fois par profil, au premier démarrage de l'un des deux serveurs, et conservée dans le dossier de données de l'application :

• GanterLabConnector.pfx, sous ua\pki\own\private : la clé privée, chiffrée sous un mot de passe aléatoire lui-même protégé par utilisateur Windows (DPAPI), si bien que la paire de fichiers ne s'ouvre pour personne une fois copiée ailleurs.
• GanterLabConnector-<station>.pem, sous ua\pki\station : le certificat racine public. C'est le fichier que vous installez sur la passerelle comme tc.trust pour qu'elle fasse confiance à cette station.

Le sujet de la racine est Ganter Lab Connector (<station>), où <station> est le nom réseau le jour où elle a été créée, et elle n'expire pas. Vous en installez la moitié publique sur chaque concentrateur une fois, à la main : une racine qui arriverait à échéance mettrait donc tout le réseau de capteurs à terre le jour de son anniversaire, refusée au concentrateur où cette station ne voit rien, et il faudrait passer voir chaque concentrateur pour le remettre en marche. Il n'y a ni avertissement d'expiration ni commande de renouvellement, parce qu'il n'y a rien à renouveler; la carte Certificat racine de la station, sur la page du pilote, affiche la date qu'elle porte en simple lecture (Valide jusqu'au), avec le chemin complet du fichier public et un bouton Ouvrir le dossier qui le montre dans l'explorateur de fichiers de Windows (dans la fenêtre de la station elle-même; dans un navigateur sur un autre appareil, le bouton reste grisé et dit pourquoi).

Le certificat que le serveur de réseau présente sous cette racine nomme le nom réseau de la station (le « Nom de réseau » de la configuration du serveur OPC UA intégré; le nom de l'ordinateur tant qu'il est vide), localhost et chaque adresse IPv4 de la station : une passerelle qui vérifie le nom du serveur l'accepte donc. Renommer l'ordinateur, changer le nom réseau ou changer les adresses de la station ne remplace pas la racine : seul le certificat placé dessous est émis de nouveau, de lui-même, sans rien à faire sur les concentrateurs.

La racine n'est créée de nouveau que lorsque celle qui est enregistrée ne peut plus être ouverte, par exemple parce qu'elle a été écrite par un autre compte Windows. Dans ce cas, et au premier démarrage de cette version sur une station qui a pu donner un fichier antérieur à des concentrateurs, la page du pilote dit, une fois, sous Les concentrateurs ont besoin du nouveau fichier de certificat, que chaque concentrateur doit recevoir le nouveau GanterLabConnector-<station>.pem comme tc.trust. Tant qu'ils ne l'ont pas, ils ne peuvent pas se connecter.

Certificat client de la passerelle. Chaque passerelle doit présenter un certificat client pendant la poignée de main TLS; une poignée de main sans certificat est abandonnée avant qu'aucune donnée ne circule. Le certificat doit :

1. Être digne de confiance de l'une de deux façons : il construit une chaîne valide sur cette machine Windows, jusqu'à une racine qui y est installée; ou vous avez approuvé ce certificat précis sous Accès des équipements sur la page de ce pilote (plus bas). Dans les deux cas, il doit être dans ses dates de validité. Un contrôle en échec refuse la connexion, et le journal enregistre quel contrôle a échoué.
2. Porter l'EUI de la station de la passerelle dans son nom commun de sujet ou dans un autre nom de sujet DNS. L'identifiant est lu comme une valeur, si bien que AABBCCDDEEFF0011, AA-BB-CC-DD-EE-FF-00-11 et AA:BB:CC:DD:EE:FF:00:11 nomment tous la même station.
3. Nommer la même station que celle que la connexion de données prétend être : un certificat qui nomme une autre passerelle que celle de l'adresse de connexion est refusé.

Accès des équipements

Une passerelle dont aucune racine installée dans Windows ne garantit le certificat, parce qu'il est auto-signé ou émis par l'autorité du fabricant lui-même, n'a pas besoin que cette racine soit installée sur cet ordinateur. Sa première connexion est refusée, et son certificat attend sous Accès des équipements, à la fin de la page du pilote LoRaWAN, la même carte que celle de la page du pilote OPC UA, jusqu'à ce que vous décidiez :

Chaque certificat est approuvé pour lui-même, jamais l'autorité qui l'a signé : une deuxième passerelle du même fabricant attend donc sa propre approbation. Comparez l'empreinte avec celle qu'indique la passerelle avant de l'approuver. L'approbation ne change pas la passerelle que le certificat désigne : il reste admis uniquement sous l'EUI de la station qu'il porte, et uniquement dans ses dates de validité. Un certificat auquel Windows fait déjà confiance est admis comme avant et n'apparaît jamais ici; rien n'est approuvé automatiquement.

Les décisions sont gardées dans le dossier de données de la station, sous ua\pki\lorawan, et survivent à un redémarrage. Seul un rôle qui peut configurer le Connector reçoit les commandes, et elles n'agissent que dans la fenêtre de la station elle-même : un navigateur sur un autre appareil lit la carte sans la modifier, et aucun outil d'agent n'approuve un certificat. La liste garde jusqu'à 100 certificats en attente d'approbation; une fois pleine, un nouveau certificat reste refusé mais n'est pas listé, et la carte le dit.

Champs de connexion

Un équipement LoRaWAN n'a ni hôte ni port à lui : un capteur est atteint par le concentrateur qui porte son trafic radio, et un concentrateur atteint cette station. Le volet montre d'abord le sélecteur d'inscription, puis les champs dont cette inscription a besoin.

Un équipement dont le DevEUI (capteur) ou l'EUI de la station (concentrateur) est encore vide, comme un équipement qu'on vient d'ajouter, l'attend. La station ne l'inscrit pas sur le serveur de réseau et aucune connexion n'est tentée, sa ligne dans l'arborescence et l'avis en haut de sa page disent « DevEUI pas encore saisi » ou « EUI de la station pas encore saisi » au lieu d'afficher une erreur, Reconnecter n'a rien à rouvrir, et son état de santé reste Pas encore connu. Saisissez l'identifiant dans la carte Connexion et la station inscrit l'équipement. Un équipement enregistré avec l'identifiant vide et nommé d'après son EUI (seize chiffres hexadécimaux, sans séparateurs) n'attend pas : il s'inscrit sous son nom, comme il l'a toujours fait.

La clé applicative est un secret, et la station la traite ainsi. Le volet la masque derrière des points, avec une case Afficher le mot de passe qui la montre pendant que vous vérifiez ce que vous avez tapé; la base de configuration la garde protégée sous le compte Windows qui l'a tapée; et elle ne paraît ni dans le journal ni dans l'adresse que lit le pilote, qui ne porte que le DevEUI. Ouvrez la même configuration sous un autre compte Windows et la clé ne s'ouvre pas avec: le champ revient vide, en disant "Illisible sur ce compte Windows : il ne s'ouvre que sur la machine et le compte Windows qui l'ont saisi. Saisissez-le de nouveau ici.", et le capteur arrête de faire sa jonction tant que vous n'avez pas retapé la clé. Une configuration transportée dans une sauvegarde la garde, car la sauvegarde est scellée avec le mot de passe que vous lui donnez.

La jonction est OTAA seulement : le capteur effectue une jonction par les ondes à travers le concentrateur, et le serveur de réseau y répond avec l'AppKey configurée. Une demande de jonction venue d'un DevEUI qu'aucun équipement configuré ne porte est refusée et journalisée. L'activation par personnalisation (ABP, clés de session préprovisionnées) n'est pas prise en charge. La session d'un capteur appartient à cette station, et non au concentrateur qui a relayé sa jonction : avec plus d'un concentrateur à portée, ses liaisons montantes arrivent par celui qui les capte, et un concentrateur qui tombe ou qu'on retire n'emporte aucun capteur avec lui.

Désactiver ou supprimer un équipement le retire du serveur de réseau immédiatement, sans attendre un redémarrage : sa clé quitte le registre, la session qu'il tenait sur cette station est libérée, et sa prochaine jonction est refusée. Désactiver ou supprimer un concentrateur ferme aussi sa connexion sur-le-champ, et les capteurs qu'il relayait gardent leur session.

Une inscription que le serveur n'accepte pas n'est pas faite du tout : un DevEUI ou un Station EUI qui est saisi et ne compte pas 16 chiffres hexadécimaux, une clé applicative absente ou qui ne compte pas 32 chiffres hexadécimaux, ou une région que cette station ne sait pas configurer. L'équipement se lit « non connecté », sa ligne dans l'arborescence et le texte rouge sous l'en-tête de sa page nomment le champ refusé et ce qu'il doit contenir, et le journal garde la même ligne. Le serveur de réseau n'est pas démarré pour lui, et la station ne retente pas la même inscription : c'est la correction du champ qui ramène l'équipement, et Reconnecter répond par le même refus.

L'état de santé du concentrateur

Un concentrateur ne porte aucun tag, donc aucune lecture ne peut dire s'il est là. Son état de santé, le point sur sa ligne dans l'arborescence et la colonne État de santé sur la page du pilote, dit si sa passerelle est connectée à cette station :

Pendant au plus dix secondes après l'enregistrement d'une modification du concentrateur, ou le démarrage du Connector, il se lit Pas encore connu : l'inscrire à nouveau ferme la connexion de la passerelle, et la passerelle met un moment à se reconnecter. Les capteurs gardent leur propre état de santé, d'après leurs lectures, quel que soit celui du concentrateur : avec plus d'un concentrateur à portée, celui qui tombe laisse les autres livrer.

Ce qui est envoyé au concentrateur

Quand un concentrateur inscrit termine sa poignée de main de version, cette station répond avec la configuration radio de sa région : la plage de fréquences, les débits et lesquels d'entre eux sont réservés à la liaison descendante, et le plan de canaux par défaut de la région. Si le Station EUI n'est pas inscrit ici, rien n'est envoyé, et le journal dit quelle station a demandé et qu'elle n'est pas inscrite. C'est l'entrée à chercher quand un concentrateur se connecte et qu'aucun capteur derrière lui ne rapporte jamais de valeur.

Il n'y a pas de champ d'intervalle de scrutation. LoRaWAN fonctionne par poussée : le capteur décide quand il émet en liaison montante, le serveur garde les charges utiles décodées les plus récentes par équipement, et les valeurs des tags se rafraîchissent depuis ce cache sur un cycle fixe d'une seconde.

Un capteur qui n'a pas encore émis n'a donc aucune lecture, et non une lecture en échec. Les tags restent vides, l'équipement signale que rien n'a été observé plutôt que de passer hors ligne, et aucun échec n'est journalisé : attendre la première liaison montante, c'est le protocole qui fonctionne. Une adresse qui ne se résout vers rien dans une charge utile que le capteur a bel et bien envoyée est une autre affaire, et elle est rapportée comme l'échec de lecture qu'elle est.

Quand un capteur se tait

Comme rien ne scrute un capteur, la charge utile qu'il a envoyée en dernier reste dans ce cache jusqu'à ce qu'il en envoie une autre. Laissé seul, un capteur dont la pile est morte continuerait de publier le même nombre comme une bonne lecture aussi longtemps que la station fonctionne, nourrissant les courbes, l'historique et les alarmes d'une valeur qui a cessé d'être vraie.

Chaque capteur porte donc un temps maximal sans émission, en secondes, dans son propre volet. La valeur par défaut est de 3600 secondes, une heure, ce qui couvre largement la cadence de dix à trente minutes d'un capteur courant; un capteur qui rapporte plus rarement relève la sienne. Passé ce délai :

• Ses tags cessent de porter une valeur et publient une mauvaise qualité, au lieu de répéter la dernière liaison montante.
• Le volet de l'équipement dit quand le capteur a émis pour la dernière fois, pour que vous voyiez depuis combien de temps il se tait.

Poser le champ à 0 désactive la péremption pour ce capteur : sa dernière liaison montante continue de se lire comme bonne indéfiniment. Rien d'autre ne change, et aucune charge utile enregistrée n'est abandonnée.

Adressage d'un tag

Un tag LoRaWAN adresse des octets à l'intérieur de la charge utile décodée. Il n'y a pas d'adresse en texte libre; la carte Source de la valeur offre des champs typés en deux modes, basculés par la case Adresser par canal/type Cayenne LPP :

L'ordre des opérations d'une lecture est : prendre les octets adressés → appliquer le masque binaire → inverser si l'octet de poids fort est en premier → convertir vers le type de donnée du tag → appliquer le multiplicateur (types numériques).

Des exemples, pour un capteur dont la charge utile de 11 octets porte une température Int16 en gros-boutiste au décalage 2 :

• Mode décalage : canal ou décalage 2, longueur de lecture 2, octet de poids fort en premier activé.
• Mode LPP, le même capteur parlant Cayenne LPP sur le canal 1 avec le type 103 : cochez la case LPP, canal 1, code de type 103, longueur de lecture 2.

Types de donnée pris en charge

Écritures et découverte

Les tags LoRaWAN sont en lecture seule : les valeurs ne viennent que des liaisons montantes des capteurs, le champ d'accès n'offre aucun choix inscriptible, et le runtime refuse une écriture au lieu de feindre un succès. Les liaisons descendantes existent dans le protocole comme trafic réseau (acceptations de jonction, commandes MAC), jamais comme écritures de valeur sur un tag.

Le pilote n'a pas de balayage de découverte. Ajoutez le concentrateur à la main avec son Station EUI et sa région, et chaque capteur à la main avec son DevEUI et son AppKey; l'ajout général d'un équipement est décrit sur la page Connector.