Bienvenue dans ce guide de prise en main du DataPlug, la nouvelle fonctionnalité de votre contrôleur HAI-P200-4G. Ce tutoriel vous montrera comment utiliser notre configurateur graphique pour collecter, structurer et publier en quelques clics des données issues de vos équipements industriels en OPC-UA, Modbus-TCP ou S7-Com. À la fin de ce guide, vos données seront disponibles sur le broker MQTT interne, prêtes à être utilisées par Node-RED, CODESYS, Grafana ou vos propres applications.
Prérequis
- Le contrôleur HAI-P200-4G
- HAI-OS version 1.2.2 ou ultérieure
Configuration par formulaire (Recommandé)
Paramétrage de l’Agent
Ouvrir la page Data-Plug. La page de paramétrage de l’agent s’affichera directement :

Voici les 5 paramètres clés pour piloter le comportement de l'agent :
- Collection Interval : C'est le rythme de collecte de Telegraf. Il définit la fréquence (par exemple, toutes les 10 secondes) à laquelle l'agent interroge les sources de données. Un intervalle court offre plus de précision mais augmente la charge.
- Round Interval : Une fois activé, il synchronise les horodatages sur des intervalles ronds (ex:
10:00:10
,10:00:20
). L'objectif est de nettoyer les données et de faciliter l'alignement des graphiques, surtout en comparant plusieurs serveurs. - Metric Batch Size : C'est la taille du "colis" de données. Telegraf regroupe les métriques jusqu'à atteindre cette taille avant de tout envoyer en un seul bloc. Augmenter cette valeur optimise le réseau en réduisant le nombre d'envois.
- Metric Buffer Limit : C'est la mémoire tampon de sécurité. Si la destination est injoignable, Telegraf stocke les métriques ici pour éviter de les perdre. Cette limite protège l'agent d'une consommation excessive de RAM. Si le tampon est plein, les plus anciennes métriques sont supprimées.
- Flush Interval : C'est un délai d'envoi maximum. Il force l'expédition des données après une certaine durée, même si le "colis" (
Metric Batch Size
) n'est pas plein. Cela garantit que les données, même peu nombreuses, ne restent pas bloquées trop longtemps dans l'agent.
Paramétrage des Inputs
Modbus
Pour Modbus, il est possible de nommer votre appareil utilisant ce protocole (Input Name), de saisir son URL composée de son port (Controller URL) , de sélectionner l’identifiant de l’esclave (Slave ID), son timeout et l’intervalle de collecte des données (Time lag).
Vous pouvez ensuite ajouter les champs dont vous souhaitez récupérer la valeur. Il existe 4 types de champs :
- Holding Registers (Registres de maintien) : Code
0x03
(Read Holding Registers) - Il s'agit de la lecture de mots de 16 bits en lecture/écriture.
- Input Registers (Registres d'entrée) : Code
0x04
(Read Input Registers) - Correspond à la lecture de mots de 16 bits en lecture seule.
- Coils (Bobines) : Code
0x01
(Read Coils) - Permet la lecture de bits (booléens) en lecture/écriture.
- Discrete Inputs (Entrées TOR) : Code
0x02
(Read Discrete Inputs) - Utilisé pour la lecture de bits (booléens) en lecture seule.
Il est possible de nommer ses champs, de saisir leurs adresses ainsi que de choisir leurs catégories, leurs unités (si elles en ont) et leurs descriptions pour chacun des types. Pour les holdings registers et les input registers, il est également possible de paramétrer l’ordre des octets (Byte Order), le type de donnée (entier, réel …) et de choisir l’échelle.
Concernant l’unité des champs, il est possible que malgré le nombre important d’unités, celle que vous souhaitez ne soit pas proposée. Vous pouvez alors créer votre unité en tapant son nom sur la zone de sélection puis en tapant sur la touche Entrée.
OPC-UA
Pour l’OPC-UA, il est possible de choisir le nom de l’entrée (Input Name) ainsi que son URL avec son port (Endpoint URL) au format opc.tcp://ADRESSE_IP:NUMERO_DE_PORT
.
Vous pouvez également paramétrer les délais d'attente et tentatives. Voici les champs modifiables :
- Time lag (Intervalle de collecte) : Ce paramètre définit la fréquence à laquelle Telegraf interroge le serveur OPC-UA pour récupérer les données. C'est le rythme de base de la collecte. Si ce champ est réglé sur
'10s'
, Telegraf demandera les valeurs de toutes les variables configurées toutes les 10 secondes. - Connect Timeout (Délai de connexion) : Cela correspond au temps maximum que le client attend pour établir la connexion initiale avec le serveur OPC UA. Si le serveur ne répond pas à la tentative de connexion dans ce délai (par exemple,
'10s'
), la connexion est considérée comme échouée. C'est la première porte à franchir. - Request Timeout (Délai de requête) : Une fois connecté, ce délai s'applique à chaque demande individuelle (lecture ou écriture d'une variable). Si le client demande la valeur d'un capteur et que le serveur ne répond pas dans ce délai (par exemple,
'5s'
), la requête échoue, même si la connexion globale est toujours active. Cela évite d'attendre indéfiniment une réponse pour une seule opération. - Session Timeout (Délai de session) : Ce champ définit la durée maximale pendant laquelle une session de communication peut rester inactive. Une session est un "contexte" de communication entre le client et le serveur. Pour éviter que le serveur ne ferme la connexion par manque d'activité, le client envoie périodiquement des messages "keep-alive" (signe de vie). Ce timeout garantit que si le client et le serveur ne communiquent plus pendant cette durée (par exemple,
'20m'
), la session est invalidée et devra être rétablie. - Read Retry Count (Nombre de tentatives de lecture) : Ceci correspond au nombre de fois où le client va réessayer de lire une variable si la première tentative échoue (par exemple, à cause d'un Request Timeout). Si ce champ est réglé sur
3
, en cas d'échec de lecture, le client tentera 3 fois de plus avant d'abandonner et de signaler une erreur. Un réglage à0
signifie qu'il n'y aura aucune nouvelle tentative.
Vous pouvez aussi modifier la section Security & Authentication (Sécurité et Authentification), qui est cruciale en OPC UA, car elle garantit que vos données industrielles sont protégées contre l'interception, la modification et l'accès non autorisé. Elle s'articule autour de trois piliers : la politique, le mode et la méthode d'authentification :
- Security Policy (Politique de sécurité) : Ce paramètre définit quels algorithmes de chiffrement seront utilisés pour sécuriser la communication. C'est le "comment" de la sécurité.
- auto ou None : Aucune sécurité. Les données circulent en clair. À n'utiliser que pour des tests ou sur un réseau totalement isolé.
- Basic128Rsa15, Basic256, Basic256Sha256 : Ce sont des ensembles prédéfinis d'algorithmes de plus en plus robustes. Plus la politique est forte, plus la communication est sécurisée (mais cela peut avoir un impact minime sur les performances).
- Security Mode (Mode de sécurité) : Ce paramètre définit ce qui est protégé en utilisant la politique de sécurité choisie.
- None : Rien n'est sécurisé.
- Sign (Signer) : Chaque message est accompagné d'une signature numérique. Cela garantit l'intégrité (le message n'a pas été modifié en chemin) et l'authenticité (on est sûr de qui l'a envoyé). Cependant, le contenu du message n'est pas chiffré et reste lisible.
- SignAndEncrypt (Signer et Chiffrer) : C'est le niveau le plus élevé. Les messages sont à la fois signés ET chiffrés. Cela garantit l'intégrité, l'authenticité et la confidentialité (personne ne peut lire le contenu des messages).
- Auth Method (Méthode d'authentification) : Ce paramètre définit comment un utilisateur ou une application prouve son identité au serveur.
- Anonymous (Anonyme) : Aucune authentification n'est requise. N'importe quel client peut se connecter, bien que les règles de sécurité (chiffrement) puissent toujours s'appliquer.
- UserName : Le client doit fournir un nom d'utilisateur et un mot de passe valides pour être autorisé à se connecter.
- Certificate (Certificat) : L'authentification se fait via le certificat numérique du client. C'est une méthode très sécurisée.
Le choix d'une politique autre que None nécessite des certificats (.pem) pour le client et le serveur afin d'établir une connexion sécurisée.
Vous pouvez également sélectionner la source du Timestamp que le Data-Plug transmettra.
Puis, vous pouvez ajouter vos différentes variables, avec leur nom, leur Namespace, leur Identifier, leur catégorie, leur unité et leur description.
S7
Pour le protocole S7, il est possible d’entrer l’adresse IP du serveur ainsi que son port (Server Address), avec son rack et son slot. Vous pouvez également saisir le type de communication (Connection Type) à établir avec l'automate. Les options sont :
- PD: Pour les connexions aux "Processing Devices" (CPU). C'est le type le plus courant.
- OP: Pour les connexions aux "Operator Panels" (IHM).
- basic: Pour les connexions basiques avec des modules de communication plus simples.
Vous pouvez ensuite saisir le pdu_size, qui correspond à la taille maximale (en octets) des paquets de données (PDU - Protocol Data Unit) échangés avec l'automate. Une taille plus grande peut améliorer les performances mais doit être supportée par l'automate. La valeur par défaut est 240.
Vous pouvez ensuite paramétrer le Timeout ainsi que le Time lag qui correspond à la fréquence à laquelle Telegraf doit interroger l'automate pour lire les variables. C'est le "Time Lag" (délai) entre chaque collecte. Il est aussi exprimé avec une unité de temps (ex: 5s).
Enfin, vous pouvez choisir le nom de la métrique et ajouter vos variables en dessous.
Lorsque vous ajoutez une variable, vous pouvez paramétrer son nom (Field Name), sa catégorie, son unité et sa description. Vous devrez également indiquer son adresse à l’aide des paramètres suivants :
- Area : La zone mémoire où se trouve la variable (ex: DB1 pour le bloc de données 1, I pour les entrées, Q pour les sorties, M pour les mémentos).
- Data Type : Le type de données de la variable (ex: R pour Real/Flottant, I pour Integer, X pour Bit, S pour String).
- Start Address : L'adresse de départ du mot ou de l'octet dans la zone mémoire.
- Extra (Bit/Length) : Un paramètre supplémentaire qui dépend du type de données :
- Pour le type X (Bit), c'est le numéro du bit (de 0 à 7).
- Pour le type S (String), c'est la longueur de la chaîne de caractères à lire.
- Pour les autres types, ce champ n'est pas utilisé.
Configuration en mode éditeur (Avancé)
Sur la page de Data-Plug, vous pouvez trouver en haut, à droite du formulaire un bouton nommé Editor Mode. Une fois celui-ci activé, vous pourrez éditer facilement le fichier de configuration de Telegraf. Cela peut vous permettre d’être plus flexible en ajoutant plusieurs modes de communications supplémentaires, mais également d’ajouter de nombreuses variables et équipements facilement.
La documentation concernant la syntaxe est disponible sur le site d’InfluxData (l’éditeur de télégraf)
Sauvegarder et redémarrer

Pour sauvegarder, cliquez sur Save And Restart. Cela va automatiquement redémarrer le Data-Plug. Vous pouvez également l’allumer et l’éteindre en cliquant sur Data-Plug Service (On/Off).
N’oubliez pas de sauvegarder quand vous changez de page ou de vue (par exemple entre le formulaire et le mode éditeur).
Logs
Un onglet est disponible sur la page de Data-Plug, pour vous permettre de visualiser les logs de Telegraf. Il vous est possible de choisir le nombre de lignes à afficher et de rafraîchir la page facilement.
Configuration du Data-Plug
En cliquant sur le bouton Configuration en haut de la page du Data-Plug, une nouvelle page va s’ouvrir.
Vous pouvez alors retrouver 3 sections :
- La section Cloud Gateway Configuration : Vous pouvez paramétrer la liaison entre le Data-Plug et le cloud. Ceci est optimisé pour Scorp-IO, et les requêtes qui en résultent sont formatées pour Scorp-IO. La liste déroulante vous permet de choisir le type de sortie (actuellement uniquement MQTT). Vous pouvez ensuite ajouter l’adresse de l’hôte (host), son port, l’identifiant du client, le nom d’utilisateur, son mot de passe, l’identifiant du projet, l’identifiant de nœud de périphérie (Edge Node ID) et l’identifiant de l’appareil. Enfin, vous pouvez choisir d’utiliser TLS ou non.
- La section Cloud Gateway Topic : le champ
DataPlug Topic
vous permet de saisir le topic MQTT qui sera utilisé pour obtenir les valeurs à historiser. - La section Store & Forward Configuration : Le champ
DB path
contient le chemin d’accès à la base de données interne historisant les valeurs reçues sur le Data-Plug. Vous pouvez découper votre base de données en plusieurs tables correspondant à un intervalle de temps, pour éviter d’avoir des tables trop remplies. Vous pouvez alors choisir l’échelle de temps utilisée pour ces partitions. Vous pouvez ensuite modifierRetention Days
pour paramétrer au bout de combien de temps les valeurs historisées sont automatiquement supprimées. Enfin, l’interval de commit permet de régler le temps de sauvegarde avant que la base de données SQLite ne persiste les enregistrements dans le système de fichiers.