Nouvelles fonctionnalités

Cette page regroupe toutes les nouvelles fonctionnalités de ThingPark Enterprise apportées par les différentes versions logicielles 8.1.x. Consultez le changelog 8.1 pour en savoir plus sur la répartition de ces fonctionnalités par version de maintenance.

Les fonctionnalités décrites sur cette page sont communes aux produits SaaS et TPE auto-hébergé.

Intégrer une sonde de capteur virtuel dans les passerelles RDTP-3399

À partir de la version 8.1, les gestionnaires de passerelles peuvent activer des sondes RF sur leurs passerelles. Une sonde RF agit comme un capteur virtuel intégré à une passerelle, faisant que la passerelle se comporte comme un capteur et envoie des trames uplink périodiques reçues par les passerelles environnantes.

Le but de ces trames uplink est de tester la qualité RF du réseau LoRaWAN et de détecter tout dysfonctionnement RF éventuel sur la passerelle émettrice ou réceptrice. La nature déterministe du trafic des sondes RF facilite l'identification des problèmes radio sans être affecté par l'aléa du trafic LoRaWAN généré par de vrais capteurs.

Pour en savoir plus, consultez Utilisation des sondes RF.

Plus de détails

Principaux avantages pour les clients

Grâce à cette fonctionnalité, les gestionnaires de passerelle peuvent vérifier de manière proactive la qualité de transmission/réception RF de leur réseau LoRaWAN sans déployer de sondes RF physiques :

• Détecter les problèmes RF, que ce soit sur la passerelle émettrice ou réceptrice
• Évaluer et améliorer la précision de la géolocalisation du réseau
• Dépannage approfondi du réseau

Activation de la fonctionnalité

Cette fonctionnalité est désactivée par défaut.

Pour activer la sonde RF sur une passerelle donnée, allez sur la page détaillée de la passerelle, puis l'onglet RF probe puis cliquez sur ACTIVER LA SONDE RF.

Une fois activée, le gestionnaire de la passerelle peut associer la sonde RF à une ou plusieurs Connexions vers lesquelles les paquets Uplink doivent être envoyés vers des serveurs d'application externes.

Limitations de la fonctionnalité

Cette fonctionnalité est supportée uniquement pour les passerelles utilisant le packet forwarder ThingPark LRR (version LRR 2.8.36 ou supérieure). Cette fonctionnalité n'est pas supportée pour les passerelles exécutant le packet forwarder Basics Station.

Journaux d'actions utilisateur (audit trail) RDTP-15326 RDTP-24685

Les journaux d'actions utilisateur (également appelés audit trail) sont générés pour toutes les opérations d'écriture et les opérations de connexion/déconnexion effectuées par les comptes utilisateur et les comptes de service associés à l'abonnement. Ils permettent de suivre les actions suivantes sur l'ensemble des ressources ThingPark concernées :

• Connexion/déconnexion, y compris les erreurs
• Création de ressources, y compris les commandes administratives créées sur des ressources existantes, telles que le redémarrage ou la mise à jour d'une passerelle ou la mise à jour de sa RF Region
• Mise à jour de ressource
• Suppression de ressource

Une ressource peut être un Capteur, une Passerelle, une Connexion, un Groupe Multicast, une Configuration d'abonnement (par exemple un Domaine), un compte utilisateur ou un compte de service. La nature exacte de l'action de création/mise à jour est décrite dans la colonne httpRequestContent du fichier csv exporté.

note

Les comptes utilisateur sont identifiés par leur adresse e-mail, tandis que les comptes de service sont identifiés par leur Client ID.

Les journaux d'actions utilisateur sont accessibles uniquement aux utilisateurs ayant le rôle d'Administrateur. Ils peuvent être téléchargés directement depuis l'interface utilisateur, sous le menu Administration.

Plus de détails

Avantages clés pour les clients

Cette fonctionnalité renforce à la fois la sécurité et l'opérabilité de ThingPark Enterprise.

1. Sécurité et conformité

   • Suivre le comportement des utilisateurs : aide à détecter les accès non autorisés ou les activités suspectes.
   • Soutient la conformité : respecte les exigences réglementaires (par ex. GDPR, HIPAA, ISO 27001).
   • Responsabilité : attribue clairement les actions à des utilisateurs ou à des Capteurs spécifiques.

2. Transparence opérationnelle

   • Historique clair des modifications : voir qui a fait quoi, quand et comment — à travers les Capteurs ou les systèmes.
   • Débuggage et dépannage : simplifie l'analyse des causes racines en cas d'incident.
   • Réduit les temps d'arrêt : diagnostic plus rapide des pannes système ou des erreurs de configuration.

3. Amélioration du produit et Support

   • Meilleur support client : les journaux aident à reproduire et résoudre les problèmes signalés par les utilisateurs.
   • Assurance de l'intégrité des données : les journaux peuvent démontrer que le système s'est comporté correctement dans des scénarios clés.

Activation de la fonctionnalité

Cette fonctionnalité est automatiquement disponible dans la version 8.1.

Pour exporter les journaux d'actions utilisateur depuis l'interface, cliquez sur Administration dans le menu de gauche, puis Panneau de contrôle, puis allez au widget JOURNAL D'ACTION UTILISATEUR. Optionnellement, définissez vos filtres pour restreindre les journaux exportés selon vos besoins.

Limitations de la fonctionnalité

Les actions suivantes ne sont pas journalisées dans la version actuelle :

• Opérations d'écriture sur les ressources TPX IoT-Flow
• Création de tokens via l'ancienne API DX-ADMIN

Améliorations UI/UX du widget "Last 10 packets" du Capteur RDTP-19954 RDTP-24390 RDTP-13714

Le widget "Last 10 packets", disponible sur la page détaillée de chaque capteur, est significativement amélioré dans la version 8.1. Il s'appelle désormais Packet History.

• Les 10 dernières commandes MAC deviennent accessibles dans ce widget, même si elles ne font pas partie des 10 paquets les plus récents. Elles sont affichées au format décodé.

  

• L'en-tête MAC de chaque paquet est affiché au format décodé, permettant de vérifier facilement les indicateurs Acquittement (ACK) et ADR (entre autres). Des détails supplémentaires sur chaque paquet sont également disponibles, tels que le canal logique, la fréquence RF et le statut de livraison Downlink.

  

• Mises à jour en direct avec rafraîchissement automatique toutes les 10 secondes, supprimant le besoin de rafraîchissement manuel.

  

• Cliquer sur Show more envoie directement l'utilisateur vers WLogger avec le filtre DevEUI approprié.

Plus de détails

Principaux avantages pour les clients

Expérience utilisateur améliorée pour la surveillance et le dépannage des performances des Capteurs.

Activation de la fonctionnalité

Ces améliorations sont automatiquement disponibles après la mise à niveau vers la version 8.1.

Limitations de la fonctionnalité

Non applicable.

Enrichir la liste des passerelles avec la RF Region de chaque passerelle RDTP-23646

À partir de la version 8.1, la RF Region de chaque passerelle est disponible en tant que nouvelle colonne de la vue liste et est également présente dans le fichier csv exportable.

Plus de détails

Principaux avantages clients

UI/UX améliorée, permettant aux gestionnaires de passerelles d'auditer facilement le paramètre RF Region de leurs passerelles et d'identifier rapidement toute potentielle mauvaise configuration.

Cette fonctionnalité peut être particulièrement intéressante pour des déploiements impliquant plusieurs bandes ISM ou des déploiements ayant un mélange de passerelles 8-canaux et 16-canaux.

Activation de la fonctionnalité

La nouvelle colonne est masquée par défaut pour limiter la taille du tableau. Pour afficher la colonne RF Region, l'utilisateur doit cocher la case RF Region comme illustré ci-dessous :

Le choix des colonnes à afficher est stocké dans le cache du navigateur, de sorte que l'utilisateur n'a pas besoin de définir sa préférence à chaque connexion.

Limitations de la fonctionnalité

Non applicable.

Afficher le nombre de licences restantes pour les Capteurs/Passerelles dans le Dashboard RDTP-21133

Pour permettre aux non-administrateurs de savoir combien de crédits device et/ou passerelle restent dans la licence en cours, le décompte des Capteurs et passerelles restants est désormais affiché dans le Dashboard principal, comme illustré dans l'exemple suivant :

Plus de détails

Avantages clés pour les clients

Expérience utilisateur améliorée pour les non-administrateurs qui ne peuvent pas accéder aux détails de la licence dans la page Panneau de contrôle.

Activation de la fonctionnalité

Cette fonctionnalité est activée automatiquement dans la version 8.1.

Limitations de la fonction

Non applicable.

Prise en charge de la répétition de paquets Downlink en mode Multicast RDTP-24172

Pour améliorer le taux de réussite de réception des paquets multicast Downlink, le serveur d'application peut avoir besoin d'envoyer une payload multicast donnée plusieurs fois avec le même compteur de trame.

Cette capacité est possible à partir de la version 8.1, par laquelle l'AS peut définir un nouveau paramètre de requête repeated dans l'API downlink de l'interface tunnel LRC-AS. Lorsque repeated =1 dans la requête POST Downlink pour un groupe multicast, le network server envoie le paquet Downlink avec le même compteur de trame qui a été utilisé lors de la transmission précédente à ce groupe multicast.

note

Il appartient à l'AS de répéter les trames multicast via des requêtes POST individuelles, le network server ne déclenche pas automatiquement de telles répétitions.

Plus de détails

Principaux bénéfices pour les clients

Grâce à cette fonctionnalité, les serveurs d'application envoyant des paquets multicast via l'interface tunnel LRC-AS peuvent tirer parti de la répétition de trames pour maximiser les chances de transmettre leur payload aux Capteurs participant à un groupe multicast. Comme les différentes copies d'une même payload multicast sont associées au même compteur de trame LoRaWAN, les Capteurs doivent pouvoir rejeter facilement les trames dupliquées.

Activation de la fonction

Cette fonctionnalité est automatiquement disponible dans la version 8.1, mais les répétitions multicast sont désactivées par défaut. La répétition est explicitement demandée par l'AS en définissant le paramètre de requête repeated à 1 (valeur par défaut = 0).

Pour en savoir plus sur l'utilisation de cette fonctionnalité dans l'API de l'interface tunnel LRC-AS, voir Downlink API V2.

Limitations de la fonction

Cette fonctionnalité n'est prise en charge que via l'API V2 de l'interface tunnel LRC-AS : l'envoi de paquets multicast Downlink depuis l'interface utilisateur ou via des connexions TPX IoT Flow ne prend pas actuellement en charge les répétitions.

[Relais LoRaWAN] Ajout de fonctions de configuration et de supervision RDTP-24198

Cette fonctionnalité apporte les améliorations suivantes aux utilisateurs de ThingPark exploitant des relais LoRaWAN :

• Possibilité d’identifier et de filtrer facilement les capteurs agissant comme relais LoRaWAN
• Possibilité de configurer les relais LoRaWAN : activer/désactiver le mode relais, modifier les paramètres WOR, ajouter des règles de filtrage ou modifier les limites de retransmission du trafic
• Possibilité d’afficher la liste des capteurs de confiance desservis par chaque relais.

Pour plus d’informations, voir Exploitation des relais LoRaWAN.

Plus de détails

Avantages clés pour les clients

• Amélioration de l’opérabilité des relais LoRaWAN : facilement identifiables dans la liste des capteurs et depuis la vue carte, nouveau critère de filtrage, affichage des capteurs desservis par chaque relais, etc.
• Grâce aux options de configuration améliorées du relais, les gestionnaires de capteurs peuvent désormais définir des limites de réacheminement supplémentaires pour optimiser la batterie du relais.
• Conformité aux normes, prenant en charge les commandes MAC suivantes en plus de celles prises en charge dans les versions précédentes : RelayConfReq, FilterListReq et ConfigureFwdLimitReq.

Activation de la fonction

La mise en œuvre de cette fonctionnalité est rétrocompatible avec les relais déployés dans les versions précédentes de ThingPark : ces relais continuent à desservir les capteurs finaux sous-jacents en relayant le trafic LoRaWAN entre ces capteurs et le réseau.

Toutefois, les nouvelles fonctions apportées par cette fonctionnalité (améliorations de configuration, de filtrage et de supervision) ne sont pas disponibles tant que le relais n’est pas associé à un modèle de capteur qui indique explicitement le support de la capacité de relais. Par conséquent, pour débloquer cette nouvelle fonctionnalité, mettez à jour le modèle de capteur de vos relais existants vers un profil permettant la capacité de relais.

Limitations de la fonctionnalité

Les limitations suivantes existent dans la version 8.1 :

• La commande MAC EndDeviceConfReq n’est pas encore supportée dans la version actuelle, mais toutes les autres commandes MAC spécifiées dans TS011 sont supportées.
• Seul le canal WOR par défaut est supporté, car la commande MAC requise pour configurer un second canal WOR sur le capteur n’est pas encore supportée dans cette version.

Activation par défaut de l’alarme de capteur « Aucune activité uplink » RDTP-23893

Dans de nombreux cas, les gestionnaires de capteurs oublient d’activer l’alarme de capteur « Aucune activité uplink », en configurant ses paramètres comme expliqué dans Configuration de l’alarme « Aucune activité uplink ».

• Cette alarme informe le gestionnaire de capteurs de problèmes de connexion inattendus, causés soit par un dysfonctionnement du capteur, des problèmes radio ou des problèmes de configuration.

  note

  L’alarme n’est pas déclenchée si le capteur est suspendu ou n’a jamais communiqué avec le réseau par le passé.

• De plus, le système s’appuie sur ces paramètres d’alarme pour basculer le capteur à l’état « Erreur de connexion ». Si ces seuils d’alarme ne sont pas définis, le capteur peut apparaître actif alors qu’il a cessé de communiquer avec le réseau depuis un certain temps déjà.

Pour réduire ce risque d’état de santé du capteur trompeur et permettre aux gestionnaires de capteurs d’être facilement informés des situations d’inactivité du capteur, les seuils d’alarme sont désormais définis sur les valeurs par défaut suivantes :

Plus de détails

Le gestionnaire de capteurs peut toujours personnaliser ces paramètres par défaut pour chaque capteur, comme décrit dans Configuration de l’alarme « Aucune activité uplink ».

Cette fonctionnalité n’a pas d’impact sur les capteurs pour lesquels les seuils d’alarme ont déjà été définis par le gestionnaire de capteurs dans les versions précédentes. La configuration utilisateur reste applicable.

Principaux bénéfices pour les clients

États de capteur plus complets et notification améliorée en cas de problèmes de connectivité.

Activation de la fonctionnalité

Si l’alarme de capteur 004 « Aucune activité uplink » n’a pas été activée avant la mise à jour vers ThingPark 8.1, elle sera automatiquement activée après la mise à jour, avec la configuration par défaut suivante :

• Déclencher une alarme avec une sévérité « avertissement » en cas de 7 jours d’inactivité
• Déclencher une alarme avec une sévérité « majeure » en cas de 15 jours d’inactivité

En conséquence, des alarmes seront automatiquement déclenchées pour les capteurs inactifs, y compris les anciens capteurs qui ont cessé de communiquer avec le réseau, par exemple en raison d’une batterie à plat, sans être supprimés de ThingPark.
Le déclenchement de cette alarme peut être une bonne occasion de nettoyer votre liste de capteurs et de supprimer les capteurs obsolètes.

Limites des fonctionnalités

Non applicable.

Support de métriques d’affichage supplémentaires pour le marqueur de capteur sur la carte RDTP-19951

Au lieu de représenter uniquement les capteurs sur la carte en fonction de leur état de santé, cette fonctionnalité permet aux utilisateurs de choisir la métrique affichée dans la liste suivante :

Une légende est affichée dans le coin inférieur gauche de la carte pour expliquer la logique des couleurs, en affichant chaque couleur avec son libellé.

Plus de détails

Principaux avantages pour le client

Expérience utilisateur améliorée avec les cartes ThingPark, permettant aux utilisateurs d’identifier rapidement les zones géographiques où la qualité radio est mauvaise : par exemple, taux d’erreur de paquets (PER) élevé ou rapport signal sur bruit (SNR) moyen faible.

Activation de la fonctionnalité

Cette fonctionnalité est automatiquement disponible dans la version 8.1, mais l’affichage est défini sur « État de santé » par défaut.
Les utilisateurs peuvent changer la métrique d’affichage en cliquant sur l’icône de marqueur dans le coin supérieur droit de l’onglet carte du capteur. Une fois modifiée, la préférence de l’utilisateur est stockée dans le cache du navigateur.

Limitations de la fonction

Non applicable.