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.

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.

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 du serveur. Généré automatiquement au premier démarrage et enregistré dans le dossier de données de l'application, sous ua\pki\own\private :

• GanterLabOPCUAServer-with-san.pfx : 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.
• GanterLabOPCUAServer-with-san.pem : le certificat public. C'est le fichier que vous installez sur la passerelle pour qu'elle fasse confiance à cette station.

Le certificat est autosigné et n'expire pas. Vous installez sa moitié publique sur chaque concentrateur une fois, à la main, si bien qu'un certificat arrivé à échéance mettrait tout le réseau de capteurs à terre le jour de son anniversaire, refusé au concentrateur là où cette station ne voit rien, et coûterait une visite à chaque concentrateur pour le relever. Il n'y a ni avertissement d'échéance ni commande de renouvellement, parce qu'il n'y a rien à renouveler; la page du pilote montre la date qu'il porte, en lecture.

Il n'est réécrit que dans deux cas, et les deux le disent dans le journal :

• Le fichier enregistré ne peut plus s'ouvrir, par exemple parce qu'il a été écrit par un autre compte Windows.
• Il a été émis par une version antérieure de cette application, qui lui donnait 12 mois.

Dans l'un ou l'autre cas, la page du pilote dit, une fois, que chaque concentrateur doit recevoir le nouveau GanterLabOPCUAServer-with-san.pem. 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. Construire une chaîne valide sur cette machine Windows (les erreurs de chaîne, telle une racine non approuvée, refusent la connexion, et le journal enregistre quel contrôle a échoué).
2. Porter le Station EUI 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é.

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 identifiant laissé vide retombe sur le nom d'équipement assaini, qui n'est presque jamais un EUI valide : remplissez-le.

La clé applicative est un secret, et la station la traite ainsi. Le panneau 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.

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'un concentrateur tenait pour lui est libérée, et sa prochaine jonction est refusée. Une inscription que le serveur n'accepte pas, un DevEUI, une clé applicative, un Station EUI ou une région mal saisis, laissent l'équipement en lecture « non connecté », et le journal nomme le champ qui a été refusé.

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 offre des champs typés en deux modes, basculés par la case Adresser par canal et 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.