Configuration TPE

La configuration TPE est accessible à partir du module Cockpit de configuration TPE.

ID d'installation

L'ID d'installation est en lecture seule. Il s'agit de l'identifiant de l'installation et il dépend du matériel.

Si l'instance TPE doit être réinstallée sur un nouveau matériel, la licence deviendra invalide. De plus, pour l'installation en ligne, le dépôt (utilisé pour yum, les images docker, les catalogues et les images de Passerelle) deviendra également inaccessible sauf si une nouvelle licence est souscrite.

Pour modifier votre abonnement à la licence ou souscrire à une nouvelle licence, rendez-vous au portail central Actility.

Paramètres de fonctionnalités

Pour économiser les ressources du serveur et selon vos besoins, certaines fonctionnalités peuvent être désactivées. Cela inclut :

• DX API : gérez vos capteurs et passerelles via une simple REST API. Cette fonctionnalité est activée par défaut.
• ThingPark X IoT Flow : fournit une large gamme de connecteurs IoT supportés professionnellement vers les principales plateformes IoT (Amazon AWS IoT, Microsoft Azure, IBM Watson, ThingWorx, Yandex, Cumulocity et bien d'autres…). ThingPark X IoT Flow supporte également les connexions MQTT et HTTP génériques. Cette fonctionnalité est activée par défaut.
• Node-RED : un éditeur de flux basé sur le navigateur utilisé pour développer des applications Internet des objets. Il vous propose des blocs de code appelés nœuds, chaque nœud décrivant une tâche. Lorsqu'ils sont liés ensemble, les nœuds forment un flux. Cette fonctionnalité est désactivée par défaut.
• LoRa Basics™ Station : connectez des passerelles exécutant LoRa Basics™ Station, une implémentation d'un packet forwarder LoRa®. Cette fonctionnalité est désactivée par défaut.

Paramètres de messagerie

Un serveur SMTP est requis pour envoyer des emails transactionnels aux utilisateurs pour les événements suivants :

• Activation d'un compte utilisateur,
• Réinitialisation de mot de passe,
• Formulaire de contact,
• Notification d'alarme.

La configuration SMTP est facultative à partir de TPE 6,1. Lorsque les mails sortants sont désactivés, aucun email ne sera envoyé aux utilisateurs. En conséquence, les fonctionnalités suivantes seront désactivées :

• Réinitialisation de mot de passe via le libre-service (i.e. mot de passe perdu),
• Nous contacter,
• Notification d'alarme.

Lorsque les mails sortants sont activés, vous devez définir des entrées valides pour les champs suivants :

• Serveur SMTP : Nom d'hôte ou adresse IP du serveur SMTP utilisé pour envoyer les emails (vous pouvez définir un numéro de port en option).
• Sécurité SMTP : sélectionnez l'une des options disponibles (Aucune, SSL ou TLS) en fonction du serveur SMTP que vous utiliserez.
• Login SMTP et mot de passe SMTP.
• SMTP no reply email : expéditeur des emails "De" de tous les emails envoyés par l'instance TPE.
• Durée de vie des actions initiées par l'utilisateur : Temps maximum avant qu'une demande d'action - notifiée à l'utilisateur par email - n'expire. Ce paramètre concerne la réponse de l'utilisateur à une action initiée par lui-même, par exemple : mot de passe oublié. Par conséquent, il est recommandé que cette durée soit courte car on s'attend à ce que l'utilisateur réagisse rapidement à ses actions auto-initiées. La valeur par défaut est de 15 min.
• Durée de vie des actions initiées par l'administrateur : Temps maximum avant qu'une demande d'action - notifiée à l'utilisateur par email - n'expire. Ce paramètre concerne la réponse de l'utilisateur à une action initiée par l'administrateur, par exemple : création de compte. Par conséquent, il est recommandé que cette durée soit longue pour permettre aux administrateurs d'envoyer des emails aux utilisateurs actuellement hors ligne. La valeur par défaut est de 60 min.

Vous pouvez modifier ces paramètres depuis Cockpit à tout moment.

Certificat TLS pour le trafic HTTP

Ces paramètres (certificat et clé privée) permettent de télécharger le certificat et la clé utilisés pour sécuriser votre connexion HTTP à l'instance TPE.

Le certificat TLS pour le trafic HTTP est également utilisé pour sécuriser les stations LoRa Basics™. Voir la section configuration des stations LoRa Basics™ pour plus de détails.

Le certificat par défaut est délivré pour actility.local et *.actility.local. Le certificat est signé par une racine générée aléatoirement lors de l'initialisation de l'instance.

Le certificat par défaut ne doit pas être conservé, mais remplacé par un certificat délivré pour le nom d'hôte/l'adresse IP de votre instance TPE. Un subjectAltName avec ce nom d'hôte/cette adresse IP doit être configuré pour être compatible avec les navigateurs et les stations Basics ([alt_names] DNS.1 = yourdomain ou [alt_names] IP.1 = yourIPaddress si ce certificat est généré par OpenSSL, voir fichier d'exemple openssl.cnf.cer) et le certificat signé par un certificat racine connu. Ce certificat racine devrait être déployé sur les navigateurs web des utilisateurs de TPE. Le certificat devrait être délivré par une autorité de certification bien connue, par exemple par le PKI d'entreprise. Lorsque la fonctionnalité station LoRa Basics™ est activée, ce certificat racine doit également être fourni dans le champ Certificat racine.

Configurer avec soin le certificat TLS pour le trafic HTTP est essentiel pour sécuriser l'accès à l'instance TPE. Les utilisateurs de TPE ne doivent pas avoir à contourner la vérification de sécurité du navigateur.

Vous pouvez modifier ces paramètres depuis Cockpit à tout moment.
La taille de la clé RSA doit être d'au moins 2048 bits.

Certificat IPsec/TLS pour le trafic des passerelles

Le certificat racine et la clé privée sont utilisés pour sécuriser vos connexions de Passerelle à l'instance TPE. Le certificat/clé racine est généré aléatoirement par le système lors de l'initialisation de l'instance TPE.

AVERTISSEMENT

Il est fortement recommandé de le conserver. Si vous devez définir votre propre certificat ou clé PKI, voir Génération de certificat IPsec pour le trafic des passerelles.

Si les certificats/clés sont modifiés après le premier démarrage du service TPE, toutes les passerelles seront temporairement déconnectées pour récupérer un nouveau certificat.

Noms d'hôte du network server

astuce

Ces paramètres ne s'appliquent pas à la station LoRa Basics™.

• Pour déploiement autonome
  • Nom d'hôte du network server : définissez le nom d'hôte ou l'adresse IPV4 utilisée par les passerelles pour atteindre le serveur TPE.
• Pour déploiement HA
  • Nom d'hôte principal du network server : définissez le nom d'hôte ou l'adresse IPV4 utilisée par les passerelles pour joindre le nœud 1 du cluster TPE.
  • Nom d'hôte secondaire du network server : définissez le nom d'hôte ou l'adresse IPV4 utilisée par les passerelles pour joindre le nœud 2 du cluster TPE.

AVERTISSEMENT

La modification du/des nom(s) d'hôte du network server ou de l'adresse(s) IPV4 de votre instance TPE a un impact sur toutes les passerelles configurées sur l'instance TPE. Les passerelles déjà connectées continueront d'utiliser l'ancienne configuration jusqu'à :

• la passerelle le certificat est régénéré pour propager le(s) nouveau(x) nom(s) d'hôte(s) ou adresse(s) IPV4 à la passerelle (la régénération de certificat est le seul moyen de pousser une nouvelle configuration à la passerelle),
• les nouveaux nom(s) d'hôte ou adresse(s) IPV4 sont définis dans le menu Suplog.

IPsec/TLS pour connexion de la passerelle au Cœur de réseau TPE

Le paramètre "IPSec (X.509) pour connexion de la passerelle au Cœur de réseau TPE" détermine la politique de sécurité utilisée par les passerelles pour se connecter au cœur de réseau TPE:

• Imposé : Toutes les passerelles doivent utiliser l’IPSec. Seules les connexions chiffrées et authentifiées sont autorisées.
• Optionnel : Les passerelles peuvent utiliser ou non l’IPSec. Dans de tels cas, la configuration est effectuée sur chaque Passerelle, en utilisant Suplog. Les connexions chiffrées et non chiffrées sont autorisées.
• Désactivé : Aucune passerelle ne doit utiliser l’IPSec. Seules les connexions non chiffrées sont autorisées.

AVERTISSEMENT

Lorsque la fonction station LoRa Basics™ est activée, seuls Forcé et Optionnel doivent être utilisés.

AVERTISSEMENT

• La configuration PKI de la passerelle (dans l'image BS ou via les menus de configuration Suplog) doit être définie conformément à la stratégie de sécurité définie dans Cockpit et l'interface utilisateur du TPE.
• Changer le niveau de sécurité à Optionnel est autorisé à tout moment.
• Le changement du niveau de sécurité dans tout autre cas peut entraîner l'arrêt du fonctionnement des passerelles existantes.
• Si la sécurité par défaut de la passerelle est passée de Désactivée à Imposée, toutes les passerelles existantes cesseront de fonctionner car l'accès non chiffré est fermé.
• Si la sécurité par défaut de la passerelle est passée de Optionnelle à Imposée, seules les passerelles existantes configurées pour se connecter sans chiffrement cesseront de fonctionner car l'accès non chiffré est fermé.
• Si la sécurité par défaut de la passerelle est passée à Désactivée, le service PKI (Infrastructure de Clé Publique) sera terminé. Cette action entraîne deux conséquences majeures :
  • Perturbation des connexions chiffrées : Toutes les passerelles actuellement configurées pour fonctionner avec le chiffrement cesseront de fonctionner.
  • Perte de la gestion des certificats : Pour les passerelles concernées, il ne sera plus possible de révoquer les certificats existants, ni de supprimer les passerelles.

Niveau de sécurité AS

Par défaut, la connexion HTTPS de TPE aux serveurs d'applications doit passer la validation SSL, c'est-à-dire que le certificat exposé par le serveur d'application doit être signé par une autorité de certification de confiance et doit correspondre au nom d'hôte.

Si vos serveurs d'application utilisent des certificats auto-signés ou des certificats signés par des autorités de certification non dignes de confiance, le niveau de sécurité AS doit être défini sur Liberal. Notez que ce paramètre s'applique à tous les serveurs d'applications. Étant donné que Liberal est non sécuritaire, il doit être utilisé exceptionnellement.

Ce paramètre de configuration peut être modifié à tout moment.

Nom d'hôte ou adresse IP HTTP

Définit le nom d'hôte/adresse IP de l'instance TPE et définit l'URL utilisée pour accéder à l'interface utilisateur du portail TPE.

• Pour déploiement autonome, définissez l'adresse IP du serveur TPE ou un nom d'hôte résolu dessus.
• Pour déploiement HA, définissez l'adresse IP flottante ou le répartiteur de charge du cluster TPE ou un nom d'hôte résolu dessus.

Ce paramètre de configuration peut être modifié à tout moment.

AVERTISSEMENT

Assurez-vous que le certificat TLS pour le trafic HTTP est délivré pour le nom d'hôte ou l'adresse IP fournis.

Logo

Permet de changer le logo affiché dans la page de connexion et le menu supérieur du portail TPE GUI.

L'image doit être au format PNG et faire moins de 50 kB. La taille recommandée est de 300 x 100 px.

Vous pouvez le changer à tout moment.

Paramètres IP virtuels

Cette configuration, disponible uniquement dans le déploiement TPE HA, est utilisée pour définir l'adresse IP virtuelle de l'instance TPE. Cela permet de supporter des mécanismes de basculement de nœud de cluster, particulièrement pour l'accès GUI et API de TPE.

Cela doit être désactivé lors de l'utilisation d'un répartiteur de charge externe.

• Virtual IP : activez Enabled si vous souhaitez utiliser une adresse IP flottante pour supporter un basculement de nœud de cluster, notamment pour l'accès GUI et API de TPE.
• Adresse IP : définir l'adresse IP flottante (doit être différente de celle déjà configurée sur chaque nœud).
• Interface réseau : définir avec le nom de l'interface réseau où vous souhaitez lier l'IP virtuelle (par exemple: bound0, eth2). Le nom de l'interface doit être celui où l'adresse IP des nœuds TPE est configurée et le même nom d'interface doit être configuré sur chaque nœud TPE.

Vous pouvez modifier les paramètres du VIP à tout moment.

Paramètres des cartes

Définit le service de carte utilisé par l'instance TPE.

Les services de cartographie supportés sont les suivants :

• Google Maps Pour le paramétrage Google Maps, vous devez entrer votre clé API.
• Cartes Baidu Pour la configuration de la carte Baidu, vous devez saisir votre clé API.
• OpenStreetMap Pour la configuration OpenStreetMap, vous devez fournir les URLs de votre serveur de tuiles et du serveur Nominatim.
• Pas de carte : Service désactivé.

AVERTISSEMENT

Si "Aucune carte" est sélectionnée, tous les widgets de carte dans l'interface graphique du portail TPE sont désactivés et l'application Network Survey est inutilisable.

Ce paramètre de configuration peut être modifié à tout moment.

Notification d'alarme de capteur et de passerelle

Cette configuration est utilisée pour définir le récepteur de serveur SNMP des alarmes comme des pièges SNMP. Un serveur SNMP acceptant le piège est nécessaire pour utiliser cette fonction.

Vous pouvez régler :

• Serveur de destination du piège SNMP : Nom d'hôte ou adresse IPV4 du serveur de destination du piège SNMP.
• Communauté de pièges SNMP : régler à public par défaut.

You can change the device and base station alarm notification configuration at any time.

Surveillance des services

Adresses sources

Adresses sources autorisées à accéder aux services de surveillance SNMP : liste d'adresses réseau (adresse IP/Masque, valeurs séparées par des virgules) qui sont autorisées à se connecter. Voir surveillance SNMP pour plus d'informations.

Exemple : 10.100.30.0/23,192.168.1.0/23

Vous pouvez modifier la configuration de la surveillance des services à tout moment.

Version SNMP

Le protocole simple de gestion de réseau (SNMP) v2 offre des fonctionnalités de surveillance et de gestion de réseau basiques. Simple Network Management Protocol (SNMP) v3 offre des fonctionnalités avancées de sécurité avec authentification et chiffrement.

Utilisateurs SNMP v3

Si le SNMP V3 est sélectionné, jusqu'à trois utilisateurs peuvent être configurés. Pour chaque utilisateur, le niveau de sécurité est configurable. Voir surveillance SNMP.

Paramètres avancés

Connexions maximales de IoT Flow

Permet de configurer le nombre maximum de connexions de IoT Flow autorisées simultanément. Comme chaque connexion consomme des ressources matérielles (CPU, RAM), cette valeur doit être définie avec soin.

La valeur minimale est 1, et la valeur maximale est 30.

Ce paramètre est affiché uniquement lorsque la fonction de IoT Flow est activée.

Suivant le profil de dimensionnement matériel, vous ne pouvez pas dépasser les limites suivantes :

• segment S : 5
• segment L et M : 10
• segment XL ou supérieur : 20

Peut être changé à tout moment.

Période de rétention de l'historique du trafic

Permet de configurer la durée de vie des trames uplink et downlink LoRaWAN™. La valeur par défaut de 15 jours est suffisante pour une utilisation normale de ThingPark Enterprise. Augmenter la valeur par défaut consomme des ressources matérielles (RAM, espace disque) ; contactez votre support avant tout changement.

Valeur possible : 15 à 90 jours (15 jours par défaut).

Ce paramètre peut être modifié à tout moment.

Hôtes supplémentaires

Permet de configurer des mappages de nom d'hôte supplémentaires, à utiliser dans la configuration des connexions.

Les hôtes supplémentaires doivent être définis comme NOM D'HÔTE:IP. Une valeur par ligne.

Ce paramètre peut être modifié à tout moment

Configuration des sous-réseaux

Le sous-réseau interne TPE peut être modifié après l'installation. C'est une tâche de maintenance avancée décrite ici. La configuration actuelle du sous-réseau interne TPE est disponible sur le module Cockpit des Services TPE (Opérations du cluster TPE -> Afficher la configuration de l'infrastructure). Ce sous-réseau n'inclut pas les sous-réseaux IPsec.

Lorsque vous changez les sous-réseaux IPsec, assurez-vous qu'ils ne chevauchent pas les sous-réseaux utilisés par le réseau privé dans lequel les passerelles sont déployées et avec le sous-réseau interne TPE configuré lors de la création du cluster.

• Sous-réseau IPsec principal : Sous-réseau IPV4 utilisé par les passerelles utilisant la sécurité IPsec. Chaque sous-réseau doit contenir une adresse pour chaque passerelle. Si IPsec n'est pas utilisé, cette configuration peut être ignorée. Ce paramètre peut être modifié à tout moment. Notez que les passerelles utilisant l'IPsec seront déconnectées pendant le redémarrage des services IPsec.

• Sous-réseau IPsec secondaire : Sous-réseau IPV4 utilisé par les passerelles utilisant la sécurité IPsec. Chaque sous-réseau doit contenir une adresse pour chaque passerelle. Si IPsec n'est pas utilisé ou le TPE est déployé en mode autonome, cette configuration peut être ignorée.
  Ce paramètre peut être modifié à tout moment. Notez que les passerelles utilisant l'IPsec seront déconnectées pendant le redémarrage des services IPsec.

Autorité de Certification (CA) d'entreprise ou privée

Certificat d'Autorité de Certification (CA) qui signe le certificat TLS pour SMTP ou un IDP externe en format PEM encodé en ASCII Base64 lorsque qu'une Autorité de Certification (CA) d'entreprise ou privée est utilisée. Peut être changé à tout moment.

Fédération d'authentification

Cette configuration est utilisée pour activer la délégation d'authentification d'utilisateur à un fournisseur d'identité externe.

Pour activer la fédération d'authentification, les paramètres ci-dessous doivent être correctement définis :

• ID client : ID client utilisé pour authentifier les utilisateurs sur l'IDP fédéré
• Secret client : Secret client utilisé pour authentifier les utilisateurs sur l'IDP fédéré
• Fournisseur OpenID Connect : URL de l'IDP OpenID Connect

Le bouton Vérifier le fournisseur peut être utilisé pour valider le fournisseur OpenID Connect.

Voir fédération d'authentification pour plus de détails.

Configuration LoRa

Itinérance / Activation

Permet de configurer l'activation LoRaWAN™ et l'itinérance passive. Les valeurs possibles sont :

• Aucun : valeur par défaut.
• Activation: permet l'activation de capteurs pré-commissionnés sur des join servers externes convenus.
• Itinérance Entrante : permet aux capteurs des réseaux étrangers convenus d'utiliser les passerelles locales pour les communications Uplink et Downlink (en plus de l'Activation LoRaWAN™).
• Itinérance Sortante : permet aux capteurs locaux d'utiliser les passerelles des réseaux étrangers convenus pour les communications Uplink et Downlink (en plus de l'Activation LoRaWAN™).

Ce paramètre ne doit pas être modifié une fois que les passerelles et capteurs sont déployés.

Lorsqu'Itinérance et/ou Activation est activée, la configuration TEX doit être définie à travers les paramètres suivants :

• NSID : identifiant 64 bits du network server LoRaWAN™. Cette information fait partie de l'abonnement ThingPark Exchange (TEX). Peut être changé à tout moment.
• URL TEX : URL de ThingPark Exchange (TEX). Peut être changé à tout moment.
• HubID TEX : HubID de ThingPark Exchange (TEX). Peut être changé à tout moment.
• Nom d'utilisateur pour l'authentification TEX : Nom d'utilisateur du compte ThingPark Exchange (TEX). Peut être changé à tout moment.
• Mot de passe pour l'authentification TEX : Mot de passe du compte ThingPark Exchange (TEX). Peut être changé à tout moment.

Le statut de synchronisation TEX avec LRC peut être surveillé dans "TPE Services" sous le menu "Opérations TEX -> Synchronisation TEX" (voir ThingPark Enterprise Administration and Troubleshooting Guide pour plus de détails).

NetID

Ce paramètre permet de configurer l'identifiant réseau LoRaWAN™ 24 bits. Un NetID dédié assigné par la LoRa Alliance® est requis lorsque l'itinérance sortante est activée. Les valeurs possibles sont de 6 chiffres hexadécimaux (insensibles à la casse) restreintes à la liste suivante :

• Valeur par défaut : 000001
• 000000 (NetID partagé 0) – interdit si l'itinérance sortante est activée
• 000001 (NetID partagé 1) – interdit si l'itinérance sortante est activée
• 000002-00003F (NetID dédié type 0) - Assigné aux membres Sponsor
• 600000-7FFFFF (NetID dédié type 3) - Assigné aux membres Contributeur
• C00000-DFFFFF (NetID dédié type 6) - Assigné aux membres Adopter et Institutionnel
• E00000-FFFFFF (NetID dédié type 7) - Peut être assigné sans être membre de LoRa-Alliance

Pour les NetID de type 7, le premier NetID du bloc doit être configuré.

Taille du bloc de NetIDs

Ce paramètre est affiché uniquement lorsque le type de NetID 7 est configuré et permet de configurer le nombre de NetIDs type 7 adjacents assignés.

Peut être changé à tout moment.

Sous-réseau DevAddr

Ce paramètre permet d'afficher/configurer le sous-réseau DevAddr (et donc la plage de DevAddr) à utiliser pour les capteurs OTAA. Le sous-réseau DevAddr est exprimé comme un préfixe DevAddr hexadécimal suivi d'un slash (/) et de la taille du masque :

• Lorsque le type de NetID 7 est configuré : ce paramètre affiche la valeur du sous-réseau DevAddr basé sur la configuration de taille de bloc de NetIDs.
• Lorsque le type de NetID est 0, 3 ou 6 est configuré : ce paramètre permet de configurer le sous-réseau DevAddr. Ce sous-réseau doit correspondre au NetID configuré. Peut être modifié à tout moment.

Ce paramètre est optionnel et peut être configuré si vous souhaitez effectuer l'itinérance entre les instances TPE partageant le même NetID. Dans ce cas, vous pouvez définir un sous-réseau DevAddr dédié à chaque instance TPE.

La validation du sous-réseau DevAddr s'effectue comme suit :

1. Le préfixe binaire NetID DevAddr est calculé basé sur le NetID configuré :
   • NetID DevAddr préfixe est Type | NwkID
   • Si le NetID est de type 0 (3 MSB valent 0b000) :
     • Type est 0b0
     • NwkID sont les 6 LSB du NetID
   • Sinon si le NetID est de type 3 (3 MSB valent 0b011) :
     • Type est 0b1110
     • NwkID sont les 11 LSB du NetID
   • Sinon si le NetID est de type 6 (3 MSB valent 0b110) :
     • Type est 0b1111110
     • NwkID sont les 15 LSB du NetID
   • Sinon Si le NetID est de type 7 (3 MSB valent 0b111) :
     • Type est 0b11111110
     • NwkID correspond aux 17 LSB de NetID
2. Le préfixe binaire SubNetID DevAddr est calculé en fonction du sous-réseau DevAddr configuré :
   • La partie gauche est traduite de l'hexadécimal au binaire.
   • Seul le nombre de MSB spécifié dans la partie droite est conservé. Pour le type NetID 7, la partie droite doit être ≥ 20.
3. Le sous-réseau DevAddr est valide si la chaîne binaire d'identification de sous-réseau DevAddr commence par la chaîne binaire d'identification de sous-réseau NetID DevAddr.

Voici quelques configurations de sous-réseaux DevAddr valides et invalides basées sur le NetID configuré :

• Exemple #1 - Type 0 : NetID 000002 / sous-réseau DevAddr 040/12

  1. Préfixe NetID DevAddr : 0b0000010
     • Type est 0b0
     • NwkID est 0b000010
  2. Préfixe SubNetID DevAddr : 0b000001000000
  3. Le sous-réseau DevAddr est valide (0b000001000000 est le préfixe de 0b0000010)

• Exemple #2 - Type 3 : NetID 60000F / sous-réseau DevAddr E01E0/20

  1. Préfixe NetID DevAddr : 0b111000000001111
     • Type est 0b1110
     • NwkID est 0b00000001111
  2. Préfixe SubNetID DevAddr : 0b11100000000111100000
  3. Le sous-réseau DevAddr est valide (0b11100000000111100000 est le préfixe de 0b111000000001111)

• Exemple #3 - Type 6 : NetID C0000F / sous-réseau DevAddr FC0038/24

  1. Préfixe NetID DevAddr : 0b1111110000000000001111
     • Type est 0b1111110
     • NwkID est 0b000000000001111
  2. Préfixe SubNetID DevAddr : 0b111111000000000000111000
  3. Le sous-réseau DevAddr est invalide (0b111111000000000000111000 n'est PAS le préfixe de 0b1111110000000000001111)

• Exemple #4 - Type 7 : NetID E00020 (premier de la gamme de 16 NetIDs E00020-E0002F) / sous-réseau DevAddr FE001000/21

  1. Préfixe NetID DevAddr : 0b1111111000000000000100000
     • Type est 0b11111110
     • NwkID est 0b00000000000100000
  2. Préfixe SubNetID DevAddr : 0b111111100000000000010
  3. Le sous-réseau DevAddr est valide (0b111111100000000000010 est le préfixe de 0b1111111000000000000100000)

• Exemple #5 - Type 7 : NetID E00020 (premier de la gamme de 32 NetIDs E00020-E0003F) / sous-réseau DevAddr FE001000/20

  1. Préfixe NetID DevAddr : 0b1111111000000000000100000
     • Type est 0b11111110
     • NwkID est 0b00000000000100000
  2. Préfixe SubNetID DevAddr : 0b11111110000000000001
  3. Le sous-réseau DevAddr est valide (0b11111110000000000001 est le préfixe de 0b1111111000000000000100000)

• Exemple #6 - Type 7 : NetID E00020 (premier de la gamme de 16 NetIDs E00020-E0002F) / sous-réseau DevAddr FE000000/21

  1. Préfixe NetID DevAddr : 0b1111111000000000000100000
     • Type est 0b11111110
     • NwkID est 0b00000000000100000
  2. Préfixe SubNetID DevAddr : 0b111111100000000000000
  3. Le sous-réseau DevAddr est invalide (0b111111100000000000000 n'est PAS le préfixe de 0b1111111000000000000100000)

• Exemple #7 - Type 7 : NetID E00020 (premier de la gamme de 32 NetIDs E00020-E0003F) / sous-réseau DevAddr FE001000/7

  1. Préfixe NetID DevAddr : 0b1111111000000000000100000
     • Type est 0b11111110
     • NwkID est 0b00000000000100000
  2. Préfixe SubNetID DevAddr : 0b1111111
  3. Le sous-réseau DevAddr est invalide (la partie droite du sous-réseau DevAddr est > 20)

Type de NetID

Afficher le type NetID (0, 3, 6 ou 7) basé sur le NetID configuré.

Plage DevAddr

Afficher la plage DevAddr pour les périphériques OTAA basée sur le sous-réseau DevAddr configuré.

Mode de mise à jour des catalogues

Lorsque Repository est défini, les catalogues sont servis par le dépôt configuré ci-dessous. Lorsque le Téléchargement manuel est défini, les catalogues sont téléchargés manuellement dans l'interface utilisateur de ThingPark Enterprise. Cela peut être modifié à tout moment.

Dépôt de catalogues et logiciels LRR

URL du dépôt servant les catalogues et les logiciels LRR. Cette URL doit être accessible des serveurs ThingPark Enterprise. Cela peut être modifié à tout moment. L'URL peut diriger vers le dépôt local.

Pour des déploiements hors connexion sans accès à internet, les mises à jour des catalogues et logiciels LRR peuvent être effectuées via un support local, cliquez ici pour télécharger le dernier package. Dans ce cas, le dépôt doit être défini sur http://localrepository1.actility.local:8089. Pour en savoir plus sur l'utilisation de supports locaux, consultez Installation du dépôt local.

Paramètres du proxy

À partir de ThingPark Enterprise 6.0, il existe deux paramètres de proxy différents :

• Les paramètres de proxy sous Configuration TPE sont utilisés pour l'accès au dépôt de ressources ThingPark Enterprise (voir Catalogues et dépôt de logiciels LRR et Dépôt d'images des passerelles pour plus de détails) :

  • URL du serveur proxy, seul HTTP est supporté.
  • Nom d'utilisateur du compte proxy
  • Mot de passe du compte proxy
  • Activer le proxy pour les uplinks LRC : cochez la case si vous souhaitez utiliser le proxy pour les uplinks LRC sur l'interface de tunnel.

• L'URL du proxy sous Services TPE est utilisée pour l'accès au dépôt d'installation de ThingPark Enterprise, seul HTTP est supporté.

Vous pouvez changer la configuration du proxy à tout moment.

URL de la Marketplace

URL de la Marketplace disponible dans l'interface utilisateur du portail TPE. Vous pouvez le changer à tout moment.

E-mail de contact pour le support

Ce paramètre est utilisé pour modifier la destination des e-mails envoyés sur l'écran "Contactez-nous" du portail TPE.

Vous pouvez changer l'adresse e-mail de contact pour le support depuis Cockpit à n'importe quel moment.

Dépôt d'images des passerelles

URL du dépôt servant les images des passerelles. Cette URL doit être accessible via les navigateurs Web.
Cette URL ne peut pas pointer vers le dépôt local. Peut être changé à tout moment.