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.

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.

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 du serveur. Généré automatiquement au premier démarrage et conservé 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 accorde sa confiance à cette station.

Le certificat est auto-signé 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 rétablir. Il n'y a pas d'avertissement d'échéance ni de commande de renouvellement, parce qu'il n'y a rien à renouveler ; la page du pilote montre la date qu'il porte en simple afficheur.

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

• Le fichier conservé ne peut plus être ouvert, 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 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. Construire une chaîne valide sur cette machine Windows (les erreurs de chaîne comme une racine non accordée refusent la connexion, et le journal enregistre quelle vérification a échoué).
2. Porter l'EUI de 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é.

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

La clé d'application est un secret, et la station la traite comme tel. Le panneau 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.

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 son prochain rattachement est refusé. Une inscription que le serveur n'accepte pas, un DevEUI, une clé d'application, un EUI de station ou une région mal saisis, laissent l'équipement en état 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 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 propose des champs typés dans deux modes, commutés par la case Adresser par voie/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.