Attributs du capteur
astuce
Dans l'interface utilisateur de ThingPark, les champs modifiables sont affichés avec un fond gris.
Attributs généraux
Attributs communs
| Attribut | Définition |
|---|---|
| Nom | Nom convivial de votre capteur. - Il est donné lors de la déclaration initiale du capteur sur ThingPark, mais peut être modifié à tout moment depuis le dashboard détaillé du capteur. - Vous pouvez rechercher des capteurs par leur nom sur l'interface utilisateur de ThingPark. - Le nom du capteur est communiqué aux applications tierces dans les métadonnées du paquet, aux côtés du DevEUI et du DevAddr. |
| Fabricant | Le fabricant du capteur est défini par le gestionnaire de capteurs dans le système. Si le fabricant est inconnu, il peut être défini sur Générique. |
| Modèle | Le modèle permet d'associer chaque capteur au profil technique adéquat qui définit les informations suivantes concernant chaque modèle : - Un ensemble de paramètres de protocole : tels que la version LoRaWAN® et la classe, les commandes MAC supportées, etc. - Les capacités du capteur : telles que la plage de TxPower supportée, etc. - Les métadonnées du driver permettant d'associer chaque modèle au bon driver de payload. - L'image du modèle Les gestionnaires de capteurs peuvent changer le Modèle associé aux capteurs existants à tout moment sans les réapprovisionner dans le système. |
| Étiquettes | Chaque capteur peut être associé à une ou plusieurs etiquettes. Les etiquettes peuvent servir à divers usages : - Etiquettes administratives, pour regrouper facilement des objets et les filtrer en conséquence. - Traitement ségrégué par les serveurs d'application, puisque les etiquettes de capteur sont rapportées en tant que métadonnées dans les rapports uplink envoyés à l'AS. |
| Domaines | Si la ségrégation basée sur les domaines a été activée par un administrateur, l'attribut Domaines contient la liste des domaines associés au capteur. Si votre compte utilisateur a des restrictions de domaine, les domaines que vous associez à votre capteur doivent correspondre à vos restrictions de domaine, sans aucun préfixe de domaine (seuls les domaines complets peuvent être attribués aux ressources). Voir À propos des domaines pour plus de détails. |
| Connexions | Liste des connexions utilisées pour router le trafic du capteur vers des serveurs d'applications externes. - Elle peut être modifiée à tout moment par le gestionnaire de capteurs. - Un capteur peut être associé à plusieurs Connexions (jusqu'à 5 par défaut). - Si le capteur n'est associé à aucune Connexion, son trafic n'est visible que dans le dashboard du capteur et dans Wireless Logger, sans être routé vers aucun serveur d'application externe. Pour en savoir plus sur les différents types de Connexion, voir Connexion d'une application. |
| Mode de localisation | Technique utilisée pour localiser le capteur. Elle peut être modifiée à tout moment par le gestionnaire de capteurs. Vous pouvez choisir parmi les modes suivants : - Position inconnue, si l'emplacement du capteur n'a pas d'importance. - Manuel, l'emplacement du capteur (latitude et longitude) est défini manuellement par le gestionnaire de capteurs, en utilisant l'une des options suivantes : * Soit via la zone de recherche en haut de la carte, * soit en plaçant directement le marqueur sur la carte, * soit en renseignant la latitude et la longitude dans le champ de saisie sous la carte. Le bouton boussole permet de basculer entre les formats décimaux et degrés/minutes/secondes. - Géolocalisation réseau, le capteur est géolocalisé par le réseau via des techniques de triangulation. Ce mode, applicable uniquement aux capteurs LoRaWAN®, est particulièrement intéressant pour suivre des capteurs mobiles, mais il peut aussi être utilisé pour des capteurs stationnaires. Pour utiliser la géolocalisation réseau, le capteur doit être couvert par au moins trois passerelles. Si ce n'est pas le cas, l'activation de cette fonctionnalité n'est pas recommandée afin d'éviter une consommation excessive de la batterie du capteur. |
| Ajoutée | Date/heure d'ajout du capteur à votre compte ThingPark. |
| Informations supplémentaires | Toute information administrative utile relative au capteur (texte libre). Elle peut être modifiée à tout moment par le gestionnaire de capteurs. |
Attributs spécifiques LoRaWAN
| Attribut | Définition |
|---|---|
| DevEUI | - Identifiant globalement unique du capteur. - Un DevEUI est composé de 32 chiffres hexadécimaux (de 0 à 9, et de A à F). Il est généralement inscrit sur le boîtier du capteur. - Les 6, 7 ou 9 premiers chiffres identifient le fabricant du capteur (tous les fournisseurs de capteurs LoRaWAN® doivent acheter un bloc IEEE OUI auprès de l'IEEE). - Exemple : F0-3D-29-00-0B-B1-7A-AA |
| Adresse du capteur | L'adresse du capteur (DevAddr) se compose de 8 chiffres hexadécimaux, servant d'identifiant court dans le réseau LoRaWAN®. - Pour les capteurs OTAA, l'adresse du capteur est allouée par le network server lors de la procédure de Join. - Pour les capteurs ABP, l'adresse du capteur est personnalisée en usine, puis définie dans ThingPark lorsque le capteur est ajouté au système. - Les bits les plus significatifs de l'adresse du capteur identifient l'identifiant de réseau LoRaWAN® (NwkID), dérivé du NetID de l'opérateur. - Exemple : 00-AB-C4-89 |
| Bande ISM | Définit le profil régional du capteur, tel que EU868 ou US915 ou AS923 etc. Dans le dashboard détaillé de chaque capteur, la bande ISM est affichée à côté du Modèle dans le widget Informations. |
| Indicateur de mouvement | Vitesse de déplacement du capteur, définie lors de l'ajout du capteur au système et modifiable à tout moment par le gestionnaire de capteurs. Exemple Si le capteur suit un colis, vous devez définir « vitesse de voiture ». Par défaut, l'indicateur de mouvement prend la valeur configurée dans le profil technique associé à ce Modèle. L'indicateur de mouvement est utilisé pour : - Déterminer si la sélection de la passerelle la mieux servante pour la transmission downlink doit être basée sur l'historique des derniers paquets reçus par le réseau (pertinent pour une indication de mouvement quasi-statique) ou doit uniquement se baser sur le tout dernier paquet reçu par le réseau (pertinent pour d'autres profils de mobilité). - Améliorer la précision de la géolocalisation réseau. |
| Plan de connectivité | Un Plan de connectivité (CP) définit un ensemble de paramètres associés à chaque capteur et déterminant son profil de service, tels que - le type de communication LoRaWAN : unicast ou multicast - le statut d'activation des services à valeur ajoutée, comme le roaming et la géolocalisation réseau - les objectifs QoS à atteindre par ThingPark ADR, tels que le taux d'erreur de paquets (PER) en uplink, fixé à 10 % par défaut. Chaque abonnement ThingPark Enterprise est associé à 4 Plans de Connectivité unicast système par défaut, définissant les 4 combinaisons d'activation entre les fonctionnalités itinérance et géolocalisation. Les abonnements TPE-SaaS prennent en charge 2 modes : - Mode implicite (de base) : il s'agit du mode par défaut, dans lequel les plans de connectivité sont masqués et remplacés par les indicateurs d'activation du roaming et de la géolocalisation réseau. - Mode explicite (avancé) : ce mode n'est disponible que pour les abonnements configurés pour utiliser des plans de connectivité personnalisés en plus des plans par défaut. Ce mode n'est requis que pour les clients ayant des cas d'usage de déploiement spécifiques nécessitant un ajustement précis des paramètres techniques LoRaWAN inclus dans le Plan de Connectivité. TPE auto-hébergé utilise exclusivement le mode CP implicite/basique, ainsi les Plans de Connectivité sont masqués dans l'interface utilisateur. |
| Driver | Désigne le driver de payload utilisé pour décoder les payloads applicatifs du capteur. Chaque driver est associé à des métadonnées, réparties en 2 parties : - L'identifiant du modèle est une chaîne identifiant le modèle du capteur - L'identifiant du protocole est un bloc d'informations désignant le protocole utilisé pour l'encodage/décodage. Pour en savoir plus, voir Drivers de payload |
| Chiffrement de la payload | Désigne la politique de chiffrement du payload applicatif : - Chiffré par radio signifie que le payload est seulement chiffré sur l'interface radio, puis il est déchiffré par ThingPark et rapporté en clair au serveur d'application. - Chiffré de bout en bout signifie que le payload est chiffré sur l'interface radio et transmis chiffré à l'application sans être déchiffré par ThingPark. Ce mode implique l'association du capteur à une Application Server Transport Key (ASTK) et nécessite un module matériel de sécurité (HSM) soit collocalisé avec le Join Server local soit embarqué avec le service d'activation ThingPark. |
| Application Server Transport Key (ASTK) | Clé de chiffrement de clé utilisée pour chiffrer l'AppSKey entre le Hardware Security Module (HSM) et le serveur d'application lorsqu'un capteur OTAA utilise le mode de chiffrement de bout en bout. À tout moment, associer (ou dissocier) un capteur avec une ASTK active automatiquement (ou désactive respectivement) le mode de chiffrement de bout en bout. Cependant, le changement prend effet uniquement lors du prochain cycle de Join de ce capteur. Associer un capteur avec une ASTK pour fournir un chiffrement de bout en bout n'est possible que pour les capteurs OTAA activés sur un Join Server externe (notamment ThingPark Activation). Dans ce cas, l'association ASTK avec le capteur se fait directement dans ThingPark Activation. |
| NetID | Identifiant réseau sur 24 bits assigné aux réseaux LoRaWAN par la LoRa Alliance. Pour en savoir plus, voir LoRaWAN NetID. |
| Classe LoRaWAN | Classe LoRaWAN® du capteur : A, B ou C. - Elle est récupérée à partir des informations techniques associées au modèle (profil du capteur). - Les capteurs compatibles avec la classe B ont leur classe définie sur class B uniquement lorsqu'ils rapportent ce drapeau dans l'en-tête MAC LoRaWAN de leurs paquets uplink, sinon leur classe est définie sur class A. |
| Mode d'activation | Définit comment le capteur est activé sur le réseau LoRaWAN : soit ABP, soit OTAA avec Join Server local, soit OTAA avec Join Server externe. Pour en savoir plus, voir Modes d'activation. |
| AppKey | Clé racine pour les capteurs OTAA (non pertinente pour les capteurs ABP). La clé d'application est une clé AES-128 spécifique à chaque capteur OTAA, programmée en usine par le fabricant du capteur. Elle se compose de 32 chiffres hexadécimaux (0 à 9 et A à F) et est utilisée pour dériver les clés de session qui permettent à LoRaWAN® de sécuriser la communication avec le network server et le Serveur d'application. - Pour les capteurs OTAA activés avec un Join Server local : l'AppKey doit être provisionnée lors de l'ajout du capteur à ThingPark. Elle est fournie par le fabricant du capteur lorsque vous achetez le capteur. - Pour les capteurs OTAA activés avec un Join Server externe : l'AppKey est directement définie par le fabricant du capteur dans le Join Server, où elle est stockée en toute sécurité. Les propriétaires de capteurs n'ont pas besoin de provisionner l'AppKey dans ThingPark Enterprise, ils doivent seulement fournir la preuve de propriété (connue sous le nom d'Owner Token) lors de l'ajout des capteurs à leur abonnement. |
| JoinEUI (AppEUI) | Identifie le Join Server (JS) pour les capteurs OTAA (non pertinent pour les capteurs ABP). - ID d'application global qui identifie de manière unique le Join Server capable d'assister lors du traitement de la procédure de Join et de la dérivation des clés de session. - Il se compose de 16 chiffres hexadécimaux (0 à 9 et A à F) et est fourni par le fabricant du capteur. - Aux débuts de LoRaWAN, cet ID était appelé "AppEUI". - Le JoinEUI est inclus dans le message Join Request, mais il doit être provisionné dans ThingPark pour les capteurs OTAA activés avec un Join Server externe, car cette information est requise pour réclamer la propriété du capteur dans le JS au nom du propriétaire du capteur, en utilisant l'Owner Token. |
| Owner Token | Fait office de preuve de propriété pour les capteurs OTAA activés sur un Join Server externe. - Ce token est fourni par le fabricant du capteur après le pré-commissioning du capteur sur le Join Server externe, ThingPark Activation par exemple. - Il est typiquement inclus dans le code QR conforme à la norme LoRaWAN imprimé sur l'étiquette du capteur. Pour en savoir plus, voir Codes QR d'activation. - Grâce à l'Owner Token, le network server peut exécuter la procédure de réclamation dans le Join Server au nom du propriétaire du capteur. Pour en savoir plus, voir Intégration transparente avec ThingPark Activation. |
| NwkSKey | Clé de session réseau, pertinente uniquement pour les capteurs LoRaWAN 1.0. - Composée de 32 chiffres hexadécimaux (0 à 9 et A à F). - Elle est utilisée pour l'intégrité des données et le chiffrement des commandes MAC envoyées sur le Fport 0. - Pour les capteurs OTAA, cette clé de session est générée à chaque cycle de Join, elle ne peut pas être préconfigurée dans ThingPark. - Pour les capteurs ABP, cette clé est personnalisée par le fabricant en usine et doit être fournie au propriétaire du capteur pour qu'il la provisionne lors de l'ajout du capteur ABP dans ThingPark. |
| AppSKey | Clé de session d'application, pertinente pour tous les capteurs LoRaWAN. - Composée de 32 chiffres hexadécimaux (0 à 9 et A à F). - Elle est utilisée pour chiffrer la payload applicative sur l'air. - Pour les capteurs OTAA, cette clé de session est générée à chaque cycle de Join, elle ne peut pas être préconfigurée dans ThingPark. - Pour les capteurs ABP, cette clé est personnalisée par le fabricant en usine et doit être fournie au propriétaire du capteur pour qu'il la provisionne lors de l'ajout du capteur ABP dans ThingPark. |
| NwkKey | Clé réseau, pertinente uniquement pour les capteurs OTAA LoRaWAN 1.1. - Clé AES-128 spécifique à chaque capteur OTAA LoRaWAN 1.1, programmée en usine par le fabricant du capteur en même temps que l'AppKey. - Elle se compose de 32 chiffres hexadécimaux (0 à 9 et A à F) et est fournie par le fabricant du capteur. - Utilisée comme clé racine pour chiffrer la communication du capteur avec le network server, en dérivant les clés de session liées au réseau : FNwkSInKey, SNwkSIntKey et NwkSEncKey. |
| FNwkSIntKey | Clé d'intégrité de session réseau de transfert, pertinente uniquement pour les capteurs LoRaWAN 1.1. - Composée de 32 chiffres hexadécimaux (0 à 9 et A à F). - Elle fournit une protection d'intégrité aux capteurs en itinérance. - Pour les capteurs OTAA, cette clé de session est générée à chaque cycle de Join, elle ne peut pas être préconfigurée dans ThingPark. - Pour les capteurs ABP, cette clé est personnalisée par le fabricant en usine et doit être fournie au propriétaire du capteur pour qu'il la provisionne lors de l'ajout du capteur ABP dans ThingPark. |
| SNwkSIntKey | Clé d'intégrité de session du réseau de service, pertinente uniquement pour les capteurs LoRaWAN 1.1. - Composée de 32 chiffres hexadécimaux (0 à 9 et A à F). - Elle fournit une protection d'intégrité via le Message Integrity Code (MIC). - Pour les capteurs OTAA, cette clé de session est générée à chaque cycle de Join, elle ne peut pas être préconfigurée dans ThingPark. - Pour les capteurs ABP, cette clé est personnalisée par le fabricant en usine et doit être fournie au propriétaire du capteur pour qu'il la provisionne lors de l'ajout du capteur ABP dans ThingPark. |
| NwkSEncKey | Clé de chiffrement de session réseau, pertinente uniquement pour les capteurs LoRaWAN 1.1. - Composée de 32 chiffres hexadécimaux (0 à 9 et A à F). - Elle est utilisée pour chiffrer les commandes MAC entre les capteurs LoRaWAN 1.1 et le network server. - Pour les capteurs OTAA, cette clé de session est générée à chaque cycle de Join, elle ne peut pas être préconfigurée dans ThingPark. - Pour les capteurs ABP, cette clé est personnalisée par le fabricant en usine et doit être fournie au propriétaire du capteur pour qu'il la provisionne lors de l'ajout du capteur ABP dans ThingPark. |
Attributs dynamiques (liés à l'activité du capteur)
Attributs communs
| Attribut | Définition |
|---|---|
| État de santé | Cet attribut décrit le statut actuel du capteur. Voir états de santé pour plus de détails. |
| Paquets des dernières 24 heures | Nombre agrégé de paquets uplink + downlink distincts échangés avec le capteur au cours des 24 dernières heures. Remarque Les répétitions uplink ne sont pas comptabilisées. |
| Alarmes actives | Nombre d'alarmes - réparties par gravité - actuellement levées sur ce capteur et non encore acquittées. Pour en savoir plus, voir Alarmes de capteurs. Astuce Cliquez sur un badge d'alarme coloré pour accéder à la liste des alarmes actives et non acquittées correspondantes. |
Attributs spécifiques LoRaWAN
| Attribut | Définition |
|---|---|
| Dernier uplink | Horodatage du dernier paquet uplink reçu du capteur par le réseau (hors doublons de paquets uplink). |
| Dernier downlink | Horodatage du dernier paquet downlink envoyé au capteur. |
| SNR moyen | Signal sur bruit moyen (en décibels, dB), mesuré par chaque passerelle LoRaWAN lors de la réception des paquets uplink. - Le SNR détermine la qualité de la réception, la plage typique pour LoRaWAN® est de [-20, +15 dB]. Pour en savoir plus, voir Signal sur bruit. - Pour atténuer les fluctuations dues à l'affaiblissement du signal RF, le SNR associé au statut du capteur sur ThingPark est calculé en moyenne sur les 5 derniers paquets uplink. |
| RSSI moyen | Indicateur de puissance du signal reçu (en dBm), mesuré par chaque passerelle LoRaWAN lors de la réception de paquets uplink. - Le RSSI mesure la puissance RF totale reçue sur un canal RF donné, en cumulant le signal LoRaWAN® utile et le bruit de fond. Pour en savoir plus, voir Indicateur de puissance du signal reçu. - Pour atténuer les fluctuations dues à l'affaiblissement du signal RF, il est recommandé de calculer un RSSI moyen sur au moins 5 paquets uplink. |
| ESP moyen | Puissance du signal estimée des paquets uplink (en dBm). - L'ESP est une estimation de la puissance du signal utile LoRaWAN®, calculée à partir des mesures SNR et RSSI rapportées par chaque passerelle. Pour en savoir plus, voir Puissance du signal estimée. - Pour atténuer les fluctuations dues à l'affaiblissement du signal RF, l'ESP associée au statut du capteur sur ThingPark est calculée en moyenne sur les 10 derniers paquets uplink. |
| Taux d'erreur de paquets à long terme (PER) | Le taux d'erreur de paquets à long terme (PER) (appelé aussi « PER moyen ») est calculé sur tout l'historique des derniers paquets uplink distincts, comme suit : PER long terme = 1 - [Nb_Paquets_Distincts / (FCntUP(N) - FCntUP(M) + 1)], où : * Nb_Paquets_Distincts est le nombre de paquets uplink distincts stockés dans l'historique des paquets (l'historique peut contenir jusqu'à 50 derniers paquets uplink). * FCntUp(N) est la valeur FCntUp du plus récent paquet uplink de cette liste historique. * FCntUp(M) est la valeur FCntUp du plus ancien paquet uplink de cette liste historique. Remarque Une réinitialisation/ré-join du capteur remet le PER à long terme à 0. |
| Taux d'erreur de paquets instantané (PER) | Le PER instantané est calculé sur les 2 derniers paquets uplink distincts comme suit : PER instantané = 1 – [ 2 / (FCntUp(N) - FCntUp(N-1) + 1)], où : * FCntUp(N) est la valeur FCntUp du dernier paquet uplink * FCntUp(N-1) est la valeur FCntUp du paquet uplink précédent (hors doublons). Exemple Si les deux derniers paquets uplink reçus ont FCntUp 33 et 36, alors InstantPER = 1 - [2/(36-33+1)] = 0,5 = 50% (car les trames 34 et 35 étaient manquantes, donc 4 paquets étaient attendus mais seulement 2 ont été reçus). Remarque Une réinitialisation/ré-join du capteur remet le PER instantané à 0. |
| Dernier Spreading Factor (SF) | Désigne le spreading factor LoRaWAN® utilisé pour le dernier paquet uplink reçu du capteur. Le spreading factor détermine le débit de transmission utilisé lors de la communication. - La plage SF LoRaWAN® est de [7 - 12] : SF7 correspond au débit le plus rapide (~5,5 kbits/sec) tandis que SF12 correspond au débit le plus lent (~300 bits/sec). |
| Meilleur LRR ID | ID de la passerelle agissant comme meilleure servante pour le capteur. Pour un même capteur, la meilleure servante peut différer entre les paquets uplink et downlink : - Pour les paquets uplink : la meilleure servante désigne la passerelle ayant reçu le dernier paquet uplink de ce capteur avec le SNR le plus élevé. - Pour les paquets downlink : la meilleure servante désigne la passerelle offrant le meilleur bilan de liaison RF pour le capteur. En fonction de l'indicateur de mouvement de chaque capteur, la détermination de la meilleure servante DL peut s'appuyer sur l'historique des derniers paquets au lieu de se baser uniquement sur le tout dernier paquet. |
| Meilleur relais | DevEUI du capteur utilisé comme relais LoRaWAN pour servir ce capteur final. Valide uniquement si le capteur utilise le protocole relais. |
| Historique d'emplacement | Désigne tous les détails d'emplacement pour les sept jours précédant le dernier emplacement rapporté. Disponible uniquement si le mode d'emplacement est Géolocalisation Réseau. Il est exprimé par les données suivantes : - Date de la géolocalisation - Latitude et longitude calculées - Précision de la géolocalisation (mètres) - Altitude calculée et sa précision (en mètres) - Vitesse de déplacement calculée (mètres par seconde) et direction du déplacement par rapport au Nord (degrés). |
États de santé du capteur
Un code couleur permet d’identifier l’état de santé de chaque capteur, il est visible sur :
- le dashboard des capteurs,
- la liste des capteurs, sous forme de pastille colorée à côté du logo du capteur,
- la carte des capteurs, sous forme de marqueur coloré.
| État de santé | Couleur | Description |
|---|---|---|
| Actif | Vert | Le capteur est correctement commissionné et échange des paquets avec le network server avec succès. |
| Initialisation | Orange | Le capteur n'a pas terminé son processus d’activation ou de réactivation, ou vient d'être relancé après avoir été suspendu administrativement. |
| Erreur de connexion | Rouge | Le capteur est commissionné et a déjà communiqué dans le passé, mais ne communique plus ou ne correspond plus au schéma de communication attendu. Il nécessite une attention (par exemple, vérifier la batterie du capteur). Si le capteur n'est plus utilisé, vous pouvez le décommissionner. Pour diagnostiquer l'absence d'activité d'uplink, voir Aucune activité d'uplink 004. |
| Suspendu | Bleu clair | Le capteur a été suspendu administrativement et tous ses paquets sont ignorés par le network server. Pour en savoir plus, voir Suspendre un capteur. |
Les transitions possibles pour un capteur LoRaWAN® sont représentées dans la figure suivante :
