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 liaisons montantes à travers cette passerelle. Ganter Lab intègre un serveur de réseau qui parle le protocole LoRa Basics Station de Semtech, si bien que toute passerelle qui exécute le micrologiciel Basics Station peut employer cette station comme LNS.

Le serveur intégré démarre quand le premier équipement LoRaWAN activé est chargé dans le connector en service, pas 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 le pilote est l'une de deux inscriptions, choisie dans son volet :

• Un capteur, identifié par son DevEUI et admis avec sa clé d'application. Ses tags décodent la charge utile de la liaison montante.
• Un concentrateur radio (la passerelle), identifié par son EUI de station et inscrit dans une région radio choisie dans une liste. Il ne porte aucun tag propre : 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 strictement rien tant qu'on ne lui a pas répondu, si bien qu'une station qui n'a jamais vu son EUI de station laisse chaque capteur derrière lui sans valeur alors que la connexion elle-même semble saine. La réponse est construite ici depuis 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 saisir 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'écoute est toujours en TLS. Aucun réglage ne coupe le chiffrement : une écoute en HTTP simple est refusée partout sauf sur la boucle locale, qui est injoignable depuis le réseau de l'installation et n'existe que pour les essais internes au 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 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 que ce n'est pas fait, 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é. Une vérification en échec refuse la connexion, et le journal enregistre quelle vérification 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 propres : un capteur est joint à travers le concentrateur qui porte son trafic radio, et un concentrateur joint 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é d'application est un secret, et la station la traite comme tel. Le volet la cache derrière des points, avec une case Afficher le mot de passe qui la dévoile le temps de vérifier ce que vous avez saisi ; la base de configuration la conserve protégée sous le compte Windows qui l'a saisie ; et elle n'apparaît ni dans le journal ni dans l'adresse que lit le pilote, laquelle ne porte que le DevEUI. Ouvrez la même configuration sous un autre compte Windows et la clé ne s'ouvre pas avec elle : 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 cesse de se rattacher tant que vous n'avez pas saisi la clé de nouveau. Une configuration emportée dans une sauvegarde la conserve, parce que la sauvegarde est scellée avec le mot de passe que vous lui donnez.

Le rattachement est OTAA seulement : le capteur effectue un rattachement par les airs à travers le concentrateur, et le serveur de réseau lui répond avec l'AppKey configurée. Une demande de rattachement venant 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é son rattachement : avec plus d'un concentrateur à portée, ses liaisons montantes arrivent par celui qui les entend, 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 son prochain rattachement est refusé. 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 EUI de station qui est saisi et ne compte pas 16 chiffres hexadécimaux, une clé d'application absente ou qui ne compte pas 32 chiffres hexadécimaux, ou une région que cette station ne sait pas configurer. L'équipement reste en état 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 technique 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 ne servent qu'à la descente, et le plan de canaux par défaut de la région. Si l'EUI de station 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 de période de scrutation. LoRaWAN est fondé sur la poussée : le capteur décide quand il émet une 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 rapporte 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 résout rien dans une charge utile que le capteur a bien envoyée est une autre affaire et est rapportée comme la lecture en échec qu'elle est.

Quand un capteur devient muet

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é à lui-même, un capteur dont la pile est morte continuerait de publier le même nombre en lecture correcte aussi longtemps que la station tourne, en nourrissant graphiques, historiques et alarmes d'une valeur qui a cessé d'être vraie.

Chaque capteur porte donc une durée maximale sans transmission, 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 élè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 indique quand le capteur a transmis pour la dernière fois, pour que vous voyiez depuis combien de temps il est muet.

Régler le champ sur 0 coupe la péremption pour ce capteur : sa dernière liaison montante continue de se lire comme correcte indéfiniment. Rien d'autre ne change, et aucune charge utile conservée n'est jetée.

Adressage des tags

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 propose des champs typés dans deux modes, commutés par la case Adresser par canal/type Cayenne LPP :

L'ordre des opérations à la 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).

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 : voie/décalage 2, longueur de lecture 2, octet de poids fort en premier coché.
• Mode LPP, même capteur parlant Cayenne LPP sur la voie 1 avec le type 103 : cochez la case LPP, voie 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 ne propose aucun choix inscriptible, et le runtime refuse une écriture au lieu de feindre le succès. Les liaisons descendantes existent dans le protocole en tant que trafic réseau (acceptations de rattachement, commandes MAC), jamais en tant qu'écritures de valeur de tag.

Le pilote n'a pas de balayage de découverte. Ajoutez le concentrateur à la main avec son EUI de station 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.