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 attribué 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 dans l’interface utilisateur de ThingPark. Le nom du capteur est transmis aux applications tierces dans les métadonnées des trames, avec le DevEUI et le 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 sur chaque modèle : Un ensemble de paramètres de protocole : comme la version et la classe LoRaWAN® prises en charge, les commandes MAC supportées, etc. Les capacités du capteur : comme la plage de TxPower supportée, etc. Les métadonnées du driver permettant d’associer chaque modèle au driver de payload approprié. L’image du modèle Les gestionnaires de capteurs peuvent modifier à tout moment le Modèle associé aux capteurs existants sans les reprovisionner dans le système.
Étiquettes	Chaque capteur peut être associé à une ou plusieurs etiquettes. Les étiquettes peuvent avoir plusieurs objectifs : Étiquettes administratives, pour regrouper facilement les objets et les filtrer en conséquence. Traitement segmenté par les Application Servers, puisque les étiquettes de capteur sont rapportées comme métadonnées dans les rapports uplink envoyés aux 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 Application Servers externes. Elle peut être modifiée à tout moment par le gestionnaire de capteur. Un capteur peut être associé à plusieurs Connexions (jusqu’à 5 par défaut). Si le capteur n’est associé à aucune Connexion, son trafic est uniquement visible dans le dashboard du capteur et dans Wireless Logger, sans être routé vers aucun Application Server externe. Pour en savoir plus sur les différents types de Connexion, voir Connecting an 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 : Aucune position, si la position du capteur n’a pas d’importance. Manuel, la position du capteur (latitude et longitude) est définie manuellement par le gestionnaire de capteur, 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 définissant la latitude et la longitude dans le champ de saisie de texte sous la carte. Le bouton de la boussole permet de basculer entre les formats décimal 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, uniquement applicable aux capteurs LoRaWAN®, est particulièrement intéressant pour suivre des capteurs en mouvement, mais il peut aussi être utilisé pour des capteurs statiques. 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.
Chemin de sujet du capteur	Segment(s) de chemin de rubrique MQTT personnalisé utilisé pour résoudre les modèles de rubrique pour ce capteur dans les connexions MQTT de base associées. Ce champ est affiché uniquement si le capteur est associé à au moins une connexion MQTT de base. La valeur peut contenir un ou plusieurs niveaux de sujet séparés par /. Elle peut également représenter le sujet MQTT complet lorsqu’elle est utilisée avec un modèle de sujet contenant uniquement {DeviceTopicPath}. La valeur doit correspondre à l’expression régulière suivante : ^[^#+/](?:/[^#+/])*$.
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 constructeur 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, jouant le rôle d’identifiant court dans le réseau LoRaWAN®. Pour les capteurs OTAA, l’adresse du capteur est allouée par le Network Server pendant la procédure de Join. Pour les capteurs ABP, l’adresse du capteur est personnalisée directement en usine, puis configurée dans ThingPark lorsque le capteur est ajouté au système. Les bits de poids fort de l’adresse du capteur identifient l’ID de réseau LoRaWAN® (NwkID), qui est 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 meilleure passerelle servante pour la transmission downlink doit être basée sur l’historique des dernières trames reçues par le réseau (pertinent pour une indication de mouvement quasi statique) ou doit uniquement se fonder sur la toute dernière trame reçue 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 l’état d’activation des services à valeur ajoutée, comme l’itinérance et la géolocalisation réseau les objectifs de QoS devant être atteints par ThingPark ADR, tels que le taux d’erreur de paquets (PER) uplink cible, défini par défaut à 10 %. Chaque abonnement ThingPark Enterprise est associé à 4 Connectivity Plans unicast système par défaut, définissant les 4 combinaisons d’activation des fonctionnalités d’itinérance et de géolocalisation. Les abonnements TPE-SaaS supportent 2 modes : Mode implicite (basique) : il s’agit du mode par défaut, dans lequel les Connectivity Plans sont masqués et remplacés par les indicateurs d’activation Roaming et Network Geolocation. Mode explicite (avancé) : ce mode est disponible uniquement pour les abonnements configurés pour utiliser des forfaits de connectivité personnalisés en plus de ceux 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 réglage fin des paramètres techniques LoRaWAN inclus dans le Connectivity Plan. Les TPE auto-hébergé utilisent exclusivement le mode CP implicite/basique, de ce fait les Connectivity Plans 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 de modèle est une chaîne identifiant le modèle de capteur L’Identifiant de Protocole est un bloc d’informations désignant le protocole utilisé pour l’encodage/décodage. Pour en savoir plus, voir Payload drivers
Chiffrement de la payload	Désigne la politique de chiffrement du payload applicatif : Radio encrypted signifie que le payload est uniquement chiffré sur l’interface radio, puis qu’il est déchiffré par ThingPark et transmis 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 d’associer le capteur à une Application Server Transport Key (ASTK) et nécessite un Hardware security module (HSM) soit colocalisé avec le Join Server local, soit intégré au service ThingPark Activation.
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 de capteur). Les capteurs compatibles classe B ont leur classe définie sur class B uniquement lorsqu’ils rapportent ce drapeau dans l’entête MAC LoRaWAN de leurs trames 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 est composée de 32 chiffres hexadécimaux (0 à 9, et A à F) et sert à dériver les clés de session qui permettent à LoRaWAN® de sécuriser la communication avec le Network Server et l’Application Server. 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 constructeur du capteur lors de l’achat du 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 de manière sécurisée. Les propriétaires de capteurs n’ont pas besoin de provisionner l’AppKey dans ThingPark Enterprise, ils doivent uniquement fournir la preuve de propriété (appelée Owner Token) lors de l’ajout de 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 dans le traitement de la procédure de Join et 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 constructeur du capteur. Dans les premiers temps de LoRaWAN, cet ID s’appelait "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 revendiquer la propriété du capteur dans le JS au nom du propriétaire du capteur, à l’aide de l’Owner Token.
Owner Token	Fait office de preuve de propriété pour les capteurs OTAA activés sur un Join Server externe. Ce jeton est fourni par le constructeur du capteur après la pré-commissioning du capteur sur le Join Server externe, par exemple ThingPark Activation. Il est généralement inclus dans le QR code standard LoRaWAN imprimé sur l’étiquette du capteur. Pour en savoir plus, voir Activation QR codes. Grâce au 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 Seamless integration with ThingPark Activation.
NwkSKey	Network Session Key, uniquement pertinent 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 constructeur du capteur en usine et doit être fournie au propriétaire du capteur afin de la provisionner lors de l’ajout du capteur ABP dans ThingPark.
AppSKey	Application Session Key, pertinente pour tous les capteurs LoRaWAN. Composée de 32 chiffres hexadécimaux (0 à 9 et A à F). Elle est utilisée pour chiffrer le payload applicatif sur l’interface radio. 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 constructeur du capteur en usine et doit être fournie au propriétaire du capteur afin de la provisionner lors de l’ajout du capteur ABP dans ThingPark.
NwkKey	Network Key, uniquement pertinente pour les capteurs LoRaWAN 1.1 OTAA. Clé AES-128 spécifique à chaque capteur LoRaWAN 1.1 OTAA, programmée en usine par le constructeur du capteur en même temps que l’AppKey. Elle est composée de 32 chiffres hexadécimaux (0 à 9, et A à F) et est fournie par le constructeur 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	Forwarding Network Session Integrity Key, uniquement pertinente 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 constructeur du capteur en usine et doit être fournie au propriétaire du capteur afin de la provisionner lors de l’ajout du capteur ABP dans ThingPark.
SNwkSIntKey	Serving Network Session Integrity Key, uniquement pertinente 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 constructeur du capteur en usine et doit être fournie au propriétaire du capteur afin de la provisionner lors de l’ajout du capteur ABP dans ThingPark.
NwkSEncKey	Network Session Encryption Key, uniquement pertinente 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 constructeur du capteur en usine et doit être fournie au propriétaire du capteur afin de la provisionner lors de l’ajout du capteur ABP dans ThingPark.

Attributs spécifiques cellulaires

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éré par ThingPark et commence par F0-3D-29-00. Pour des raisons de compatibilité ascendante, l’IMEI est utilisé comme DevEUI pour les capteurs cellulaires provisionnés avant ThingPark 8.0. Exemple : F0-3D-29-00-0B-B1-7A-AA
Adresse du capteur	L’adresse du capteur se compose de l’adresse IPv4 du capteur. L’adresse du capteur est allouée conformément à la configuration IPv4 du contexte réseau. Exemple : 192.168.3.130
IMEI imposé	International Mobile Equipment Identity du capteur physique. Un IMEI est composé de 15 chiffres (14 chiffres + 1 chiffre pour la somme de contrôle de Luhn). Lorsqu’il est configuré, l’IMEI est imposé et tout trafic correspondant à un autre IMEI est rejeté pour ce capteur.
Identifiant SIM	IMSI, ICCID ou eID selon le type de SIM. Pour en savoir plus, consultez Types de SIM.
Contexte réseau	Un contexte réseau gère la connectivité IPv4 du capteur et définit les modes de communication. Pour en savoir plus, consultez Gestion des contextes 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 les modes de communication autorisés : mode message et/ou mode IP direct les paramètres de la politique de trafic en mode message : régulateurs à saut de jetons pour les paquets uplink et downlink les paramètres de la politique de trafic en mode IP direct : bande passante uplink et downlink maximale.

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 to Noise Ratio moyen (en décibels, dB), mesuré par chaque passerelle LoRaWAN lors de la réception de trames uplink. Le SNR détermine la qualité de la réception, la plage typique pour LoRaWAN® est [-20, +15 dB]. Pour en savoir plus, voir Signal to Noise Ratio. Pour atténuer les fluctuations de mesure causées par l’évanouissement du signal RF, le SNR associé au statut du capteur dans ThingPark est moyenné sur les 5 dernières trames uplink.
RSSI moyen	Received Signal Strength Indicator (en dBm), mesuré par chaque passerelle LoRaWAN lors de la réception de trames uplink. Le RSSI mesure la puissance RF totale reçue sur un canal RF donné, en sommant le signal LoRaWAN® utile et le bruit de fond. Pour en savoir plus, voir Received Signal Strength Indicator. Pour atténuer les fluctuations de mesure causées par l’évanouissement du signal RF, il est recommandé de calculer un RSSI moyen sur au moins 5 trames uplink.
ESP moyen	Puissance de signal estimée des trames uplink (en dBm). ESP est une estimation de la puissance utile du signal LoRaWAN® calculée à partir des mesures de SNR et de RSSI rapportées par chaque passerelle. Pour en savoir plus, voir Estimated Signal Power. Pour atténuer les fluctuations de mesure causées par l’évanouissement du signal RF, l’ESP associé au statut du capteur dans ThingPark est moyenné sur les 10 dernières trames uplink.
Taux d'erreur de paquets à long terme (PER)	Le Packet Error Rate (PER) à long terme (également appelé "Mean PER") est calculé sur l’historique complet des dernières trames uplink distinctes, comme suit : Long-term PER = 1 - [Distinct_Pkts / (FCntUP(N) - FCntUP(M) + 1)], où : Distinct_Pkts est le nombre de trames uplink distinctes stockées dans l’historique des dernières trames (l’historique peut contenir jusqu’aux 50 dernières trames uplink). FCntUp(N) est le FCntUp de la trame uplink la plus récente dans cette liste d’historique. FCntUp(M) est le FCntUp de la trame uplink la plus ancienne dans cette liste d’historique. Remarque Un reset/rejoin du capteur réinitialise le PER à long terme à 0.
Taux d'erreur de paquets instantané (PER)	Le PER instantané est calculé sur les 2 dernières trames uplink distinctes comme suit : Instant PER = 1 – [ 2 / (FCntUp(N) - FCntUp(N-1) + 1)], où : FCntUp(N) est le FCntUp de la dernière trame uplink FCntUp(N-1) est le FCntUp de la trame uplink précédente (hors répétitions). Exemple Si les deux dernières trames uplink reçues ont un FCntUp de 33 et 36, alors InstantPER = 1 - [2/(36-33+1)] = 0,5 = 50 % (car les trames 34 et 35 manquaient, donc 4 trames étaient attendues mais seulement 2 ont été reçues). 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 data rate utilisé pendant la transmission. La plage SF LoRaWAN® est [7 - 12] : SF7 correspond au data rate le plus rapide (~5,5 kbits/s) tandis que SF12 correspond au data rate le plus lent (~300 bits/s).
Meilleur LRR ID	ID de la passerelle agissant comme meilleure servante pour le capteur. Pour un même capteur, le meilleur serveur peut être différent entre les trames uplink et downlink : Pour les trames uplink : le meilleur serveur désigne la passerelle ayant reçu la dernière trame uplink de ce capteur avec le SNR le plus élevé. Pour les paquets downlink : le meilleur serveur désigne la passerelle offrant le meilleur bilan de liaison RF au capteur. Selon l’indicateur de mouvement de chaque capteur, la dérivation du meilleur serveur DL peut s’appuyer sur l’historique des dernières trames au lieu de se fonder uniquement sur la toute dernière trame.
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. Elle est exprimée par les data 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 de déplacement par rapport au Nord (degrés).

Attributs spécifiques cellulaires

Attribut	Définition
Dernier uplink en mode message	Horodatage du dernier paquet uplink en mode message reçu par le réseau depuis le capteur.
Dernier downlink en mode message	Horodatage du dernier paquet downlink en mode message envoyé au capteur.
Dernier trafic IP direct	Horodatage du dernier événement de microflux signalé pour le trafic IP direct du capteur.
Type d'accès radio	Technologie utilisée par le capteur pour se connecter au réseau cellulaire.
Cell ID	Identifiant globalement unique de la passerelle cellulaire.
Cell MCC MNC	Code pays et opérateur mobile (MCC/MNC) de l'opérateur exploitant la passerelle cellulaire.
Cell TAC	Code de zone de suivi (TAC) de la passerelle cellulaire.
Serving network MCC MNC	Code pays et opérateur mobile (MCC/MNC) de l'opérateur du réseau de service.
IMEI	Identité internationale d'équipement mobile du dernier paquet. Si aucun IMEI imposé n'est configuré, tout IMEI est accepté (la SIM peut être utilisée dans différents capteurs physiques).
IMSI	Identité internationale d'abonné mobile du dernier paquet.
MSISDN	Numéro international d'abonné de la station mobile (MSISDN) du dernier paquet.

É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 :

Les transitions possibles pour un capteur cellulaire sont représentées dans la figure suivante :