> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/user/fr/guide/account/iot-logic/nodes/data-source-node.md).
# Source de données
Le nœud Source de données est le point d'entrée IoT Logic pour la télémétrie des appareils. Il reçoit des données via TCP, UDP, HTTP ou MQTT, les décode et les transmet aux nœuds en aval. Il peut également enrichir un appareil déjà connecté
## Vue d'ensemble technique et fonctionnalités
{% columns %}
{% column %}
**Source de données** Le nœud est un point d'entrée pour les données télémétriques provenant d'appareils IoT et de plateformes OEM dans le système IoT Logic. Il fait office de traducteur universel, recevant les données via les protocoles TCP/UDP/HTTP sur les interfaces réseau et via les files d'attente MQTT, puis décodant les flux de données entrants selon le protocole sélectionné. Le nœud transforme les messages des appareils en un format standardisé qui peut ensuite être traité dans votre flux.
{% endcolumn %}
{% column %}
{% endcolumn %}
{% endcolumns %}
Au-delà de la simple réception de la télémétrie, un **Source de données** nœud peut aussi enrichir un appareil que vous y avez déjà ajouté. Un système externe, comme une plateforme télématique distincte qui n'envoie pas de données à Navixy par défaut, pousse des attributs supplémentaires vers le flux de l'appareil. Parfois, cette plateforme externe est celle du fabricant de l'appareil. Plutôt que de migrer l'appareil vers la collecte native de Navixy, l' **onglet Logiciel** le conserve enregistré tel quel. Il enrichit en continu le flux de l'appareil avec des données de cette autre plateforme, de sorte que les deux flux fonctionnent en parallèle. Voir [Comment les données envoyées sont gérées](#how-pushed-data-is-handled) pour le fonctionnement, et [Options de configuration](#configuration-options) pour le configurer.
### Intégration de l'architecture du flux
**nœud Source de données** fait office de point d'entrée des données dans un flux IoT Logic. Un seul flux peut contenir plusieurs nœuds sources, chacun avec sa propre configuration. Cette architecture permet :
* Acquisition initiale des données à partir de plusieurs types d'appareils et de formats de protocole
* Transformation standardisée des données de divers fabricants en formats unifiés
* Chemins de traitement parallèles en connectant une source de données à plusieurs nœuds en aval
* Filtrage sélectif des appareils pour n'inclure que les sources de données pertinentes dans votre flux
* Enrichissement du flux pour les appareils déjà connectés, à l'aide d'attributs envoyés depuis un système externe via HTTP
### Capacités du nœud
La **nœud Source de données** Le nœud, à lui seul, offre :
* **Diversité des protocoles** : prend en charge plusieurs fabricants d'appareils, notamment Teltonika, Queclink, Suntech, Jimi et d'autres, grâce aux analyseurs syntaxiques et décodeurs hérités de Navixy
* **Flexibilité du transport** : prend en charge les protocoles TCP, UDP, HTTP et les connexions aux courtiers MQTT
* **Transformation unifiée des données** : convertit les messages spécifiques aux appareils en un format standardisé pour un traitement cohérent
* **Filtrage des appareils** : offre des capacités de filtrage pour sélectionner des modèles ou des protocoles spécifiques
* **Traitement en temps réel** : gère les flux de données télémétriques entrants en temps réel pour un traitement immédiat
* **Enrichissement par push HTTP** : fusionne dans le flux les attributs envoyés par un système externe vers l'appareil déjà sélectionné dans ce nœud. HTTP est actuellement le seul type de push pris en charge, l'architecture étant conçue pour en prendre en charge davantage à l'avenir
## Options de configuration
{% columns %}
{% column width="58.333333333333336%" valign="middle" %}
Configurer un **Source de données** nœud détermine quels appareils envoient des données dans votre flux et, éventuellement, comment un système externe peut enrichir ces appareils avec des données envoyées.
La boîte de dialogue de configuration est organisée en deux onglets :
* **Appareils** : sélectionne les appareils qui envoient la télémétrie dans le flux. Obligatoire, et fonctionne exactement comme auparavant.
* **onglet Logiciel** : configure l'enrichissement par push HTTP pour les appareils que vous avez sélectionnés dans l'onglet Appareils. Facultatif, et dépend de cette sélection.
{% endcolumn %}
{% column width="41.666666666666664%" %}
{% endcolumn %}
{% endcolumns %}
{% hint style="info" %}
La **onglet Logiciel** l'onglet dépend de l' **Appareils** onglet. Son **Appareil source** sélecteur n'affiche que les appareils déjà sélectionnés dans **Appareils** , et n'affiche aucune donnée disponible tant que vous n'en avez pas sélectionné au moins un là.
{% endhint %}
Voyons quels éléments ce nœud utilise et ce que vous pouvez configurer lorsqu'il est utilisé :
### Étapes de configuration
{% stepper %}
{% step %}
#### Spécifiez le nom du nœud
Saisissez un nom descriptif pour cette source de données :
* Utilisez un nom qui vous aide à identifier le fabricant, les modèles ou toute autre information pertinente.
* Ce nom sera affiché dans le schéma du flux pour une identification facile.
{% endstep %}
{% step %}
#### Sélectionnez les sources
Dans la liste filtrée, sélectionnez les appareils à inclure. Seuls les appareils enregistrés dans votre compte utilisateur Navixy sont disponibles à la sélection. Cette sélection est également la condition préalable à l'onglet facultatif **onglet Logiciel** onglet, qui ne peut associer que les appareils sélectionnés ici.
{% endstep %}
{% step %}
#### Enregistrez la configuration du nœud
Cliquez **Appliquer les modifications** pour terminer la création du nœud.
{% endstep %}
{% step %}
#### Configurez l'enrichissement par push HTTP (facultatif)
Passez à l' **onglet Logiciel** onglet pour enrichir les appareils que vous avez sélectionnés dans l'onglet Appareils avec des données envoyées par un système externe. Cette étape est facultative. Voir [Configuration de l'enrichissement par push HTTP](#configuring-http-push-enrichment) pour la configuration complète.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
Si vous modifiez les paramètres du fabricant ou du modèle après avoir sélectionné des appareils, Navixy vous avertit si des appareils sélectionnés ne correspondent pas aux nouveaux paramètres, mais ne les supprime pas automatiquement de votre sélection.
{% endhint %}
### Configuration de l'enrichissement par push HTTP
L'enrichissement par push HTTP permet à un système externe d'ajouter des attributs à un appareil déjà sélectionné dans l'onglet de ce nœud **Appareils** en envoyant des données vers une URL générée. C'est facultatif et nécessite qu'au moins un appareil soit sélectionné sous [Étapes de configuration](#configuration-steps) d'abord.
Cela est utile lorsqu'un appareil rapporte déjà à un système distinct qui n'alimente pas Navixy par défaut, par exemple une plateforme de gestion de batterie suivant le niveau de la batterie du même véhicule. Au lieu de migrer l'appareil vers l'ingestion native de Navixy, vous pouvez le conserver tel quel et laisser cette autre plateforme pousser ici ses relevés. Un push avec `vehicle_id: "truck_12"`, `bms_battery_soc: 76`, et `bms_battery_temp: 34.2` ajoute `bms_battery_soc` et `bms_battery_temp` comme de nouveaux attributs sur l'appareil mappé, en plus de sa télémétrie GPS native.
{% stepper %}
{% step %}
#### Définir le type de connecteur
Passez à l' **onglet Logiciel** onglet et définissez **Type de connecteur** sur **HTTP**, actuellement la seule option.
{% endstep %}
{% step %}
#### Enregistrez le flux et copiez l'URL générée
Enregistrez l'intégralité du flux, pas seulement ce nœud. Le **champ URL** ne génère une valeur que lorsque le flux est enregistré avec **Type de connecteur** défini. Jusqu'à ce moment, il affiche un espace réservé vous invitant à enregistrer le flux. Une fois l'URL affichée, cliquez sur l'icône de copie à côté, désactivée uniquement lorsque le champ est vide.
{% endstep %}
{% step %}
#### Authentifiez le système externe
Attribuez au système externe une [clé API Navixy](/docs/user/fr/guide/account/api-keys.md)et configurez-le pour envoyer `Authorization: NVX ` avec chaque requête de push, en même temps que l'URL. Un push sans cet en-tête échoue, donc l'URL et l'en-tête sont tous deux requis avant que les données puissent arriver.
{% endstep %}
{% step %}
#### Définissez la clé primaire et les correspondances
Saisissez un **Clé primaire**: le nom du champ que le système externe utilise pour identifier à quel appareil appartient un enregistrement poussé. Il accepte jusqu'à 64 caractères, uniquement des lettres, des chiffres et des caractères de soulignement.
Ajoutez-en une **Correspondances** ligne par appareil à enrichir. Pour chaque ligne, sélectionnez le **Appareil source**, limité aux appareils déjà sélectionnés dans Appareils, et saisissez la **valeur de clé** qui identifie cet appareil dans les pushes entrants. Ce champ stocke jusqu'à 255 caractères, mais le point de terminaison du push n'accepte lui-même que jusqu'à 100 caractères par champ, alors gardez la valeur bien en dessous de 100 caractères en pratique.
{% hint style="warning" %}
La Clé primaire et la Valeur de clé n'acceptent que des lettres, des chiffres et des caractères de soulignement, sans tirets ni autre ponctuation. La validation générale des champs du point de terminaison du push est plus permissive et accepte les tirets dans n'importe quel champ sans broncher, mais une valeur contenant des tirets ne peut jamais correspondre à une Valeur de clé stockée, de sorte que les pushes qui l'utilisent sont rejetés silencieusement exactement comme si la valeur ne correspondait pas. Si les identifiants de votre système externe utilisent des tirets (par exemple `truck-12`), traduisez-les, par exemple en `truck_12`, avant l'envoi.
{% endhint %}
{% endstep %}
{% step %}
#### Appliquez et enregistrez
Cliquez **Appliquer les modifications**, puis enregistrez de nouveau le flux si vous avez configuré l'onglet Software après l'enregistrement initial.
{% endstep %}
{% endstepper %}
### Spécificités du traitement des données
**Nœud Source de données** hérite de tous les analyseurs et décodeurs de Navixy, offrant la compatibilité avec un large éventail d'appareils IoT. Lorsque les données arrivent à ce nœud, elles passent par le processus suivant :
1. Le flux de données entrant est reçu via le protocole de transport spécifié
2. Les données sont transmises au décodeur de protocole approprié en fonction de votre configuration
3. Les messages de l’appareil sont transformés en un format standardisé qu’IoT Logic peut traiter
4. Les données unifiées sont transmises au Nœud suivant de votre flux
Ce processus de normalisation vous permet de créer des flux de traitement cohérents, quel que soit le format de données d’origine de différents fabricants d’appareils.
### Comment les données envoyées sont gérées
Navixy fait correspondre chaque push entrant à sa valeur de clé primaire par rapport à la configuration du Nœud **Correspondances**, puis fusionne les champs restants dans le flux de données de l’appareil mappé sous forme d’attributs : nouveau si le nom du champ est nouveau, ou écrit dans l’historique existant de cet attribut si le nom correspond à un nom déjà existant, qu’il soit signalé nativement par l’appareil ou transmis par le connecteur d’un autre flux. Ils n’ont aucun effet sur la localisation ni sur les autres données télémétriques. Le champ nommé dans **Clé primaire**, ainsi que `flux_id` et `id_du_Nœud`, est utilisé pour l’acheminement et ne devient jamais lui-même un attribut. Une requête peut se retrouver dans l’un des trois états :
| Résultat | Réponse HTTP | Données fusionnées ? |
| ---------------------------------------------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| La valeur de la clé primaire correspond à un mappage | 200, `succès : true` | Oui. Les champs restants sont fusionnés en tant qu’attributs, nouveaux si le nom est nouveau, historique existant s’il correspond à un déjà utilisé |
| La valeur de la clé primaire ne correspond à aucun mappage | 200, `succès : true` | Non. Ignoré silencieusement |
| Manquant ou invalide `Autorisation` en-tête | Erreur 400 | N° Rejeté avant que Navixy ne vérifie la clé primaire |
{% hint style="info" %}
Une réponse 200 confirme seulement que Navixy a accepté la requête, et non que les données ont été fusionnées. Une valeur de clé primaire non correspondante est ignorée silencieusement, sans erreur pour le signaler. Si vous n’êtes pas sûr qu’un push ait été associé, vérifiez les attributs de l’appareil mappé dans [Analyseur de données](/docs/user/fr/guide/account/iot-logic/data-stream-analyzer.md) plutôt que de s’appuyer sur la réponse.
{% endhint %}
{% hint style="warning" %}
Le nom d’un champ transmis partage le même espace de noms que les attributs natifs du dispositif, ainsi qu’avec les noms transmis par le connecteur d’un autre flux qui enrichit le même dispositif. Si le nom correspond à un nom déjà utilisé, qu’il soit natif au dispositif ou transmis par un autre flux, la transmission écrase l’historique existant de cet attribut au lieu d’en créer un distinct.
Les capteurs, les rapports et les règles d’alertes lisent la valeur fusionnée comme une lecture réelle, donc un nom en collision peut produire de fausses données en aval. Par exemple, un champ poussé nommé `niveau_de_carburant` qui correspond à l’attribut natif de carburant d’un appareil injecterait une mesure erronée, produisant de faux événements de baisse de carburant ou de ravitaillement dans les Rapports.
Pour éviter cela, préfixez les noms des champs poussés afin qu’ils n’entrent pas en conflit avec les attributs natifs d’un appareil ou avec les noms poussés d’un autre flux, par exemple `bms_battery_soc` au lieu de `battery_soc`.
Les champs du message système tels que `vitesse`, `latitude`, `longitude`, `cap`, `satellites`, et `hdop` ne peut pas être écrasé de cette manière. Les envois ne font que créer ou mettre à jour des attributs, jamais la télémétrie au niveau du message. Un champ envoyé portant l’un de ces noms apparaît toujours sous ce nom dans [Analyseur de données](/docs/user/fr/guide/account/iot-logic/data-stream-analyzer.md) , séparément de la télémétrie réelle de l’appareil.
{% endhint %}
Un attribut fusionné apparaît comme une entrée ponctuelle dans l’historique des attributs de l’appareil, et non comme une valeur courante persistante. Si l’appareil transmet sa propre télémétrie beaucoup plus fréquemment que le système externe n’envoie des mises à jour, les paquets de l’appareil peuvent faire progresser l’historique de l’attribut au-delà de la valeur envoyée en quelques secondes, même si la fusion a réussi.
{% hint style="info" %}
C’est une conséquence attendue de deux flux de données fonctionnant à des vitesses différentes, et non un défaut. Référencez l’attribut en aval comme `value('attribute_name', 0, 'valid')` au lieu de son simple nom. `'valid'` remonte l’historique de l’attribut jusqu’à la dernière valeur non nulle, afin que les nœuds en aval reçoivent la valeur envoyée quelle que soit la synchronisation. Voir [Valeurs manquantes et routage des valeurs nulles](/docs/user/fr/guide/account/iot-logic/nodes/logic-node/logic-node-expressions-and-syntax.md#missing-values-and-null-routing) pour savoir comment `'valid'` compare à `'tout'` dans une condition de nœud Logic.
{% endhint %}
Le point de terminaison d’envoi accepte jusqu’à 1 requête par seconde et par clé d’API, avec une taille de rafale de 1. Adaptez le rythme des requêtes du système externe en conséquence.
## Questions fréquentes
#### Puis-je utiliser plusieurs nœuds Source de données dans un seul flux ?
Oui, vous pouvez utiliser plusieurs **nœuds Source de données** dans un seul espace de travail. Cela est utile lorsque vous devez traiter des données provenant de différents types d’appareils de différentes manières ou lorsque vous souhaitez fusionner plusieurs flux de données après des transformations spécifiques.
#### Que se passe-t-il si un appareil est déjà utilisé dans un autre flux ?
Un appareil peut appartenir à plusieurs flux en même temps. Si vous ajoutez un appareil déjà utilisé dans un autre flux, les deux flux traitent ses données simultanément et les résultats sont fusionnés pour éviter toute perte de données. Le fait d’être affecté à un autre flux n’est pas une restriction. En revanche, si les connecteurs de deux flux poussent le même nom d’attribut vers cet appareil, ils ne fusionnent pas sans conséquence. L’historique de l’un écrase celui de l’autre. Voir [Comment les données envoyées sont gérées](#how-pushed-data-is-handled) pour éviter les noms en conflit.
#### Tous mes appareils Navixy sont-ils automatiquement disponibles dans IoT Logic ?
Oui, tous les appareils de votre compte utilisateur Navixy peuvent être utilisés dans le traitement d’IoT Logic. Cela inclut les appareils GPS, les plateformes OEM, les appareils et passerelles MQTT, ainsi que les connecteurs MQTT/Kafka. Un appareil déjà sélectionné dans un nœud peut aussi être enrichi avec des attributs poussés depuis un système externe via HTTP, par l’intermédiaire du **Source de données** nœud peut aussi être enrichi avec des attributs poussés depuis un système externe via HTTP, par l’intermédiaire du **onglet Logiciel** .
#### Comment savoir quel fabricant sélectionner pour mes appareils ?
Le protocole doit correspondre au protocole de communication utilisé par le fabricant de votre appareil. La plupart des appareils utilisent un protocole associé à leur fabricant (par exemple, les appareils Teltonika utilisent le protocole Teltonika). Consultez la documentation de votre appareil ou votre fournisseur si vous avez un doute.
#### Puis-je connecter un nœud Source de données à plusieurs nœuds en aval ?
Oui, vous pouvez connecter un **nœud Source de données** à plusieurs nœuds de traitement pour créer des chemins de traitement parallèles. Cela vous permet d’appliquer différentes transformations au même flux de données. Voici un exemple :
#### Puis-je importer des données d’un système qui n’est pas un appareil Navixy ?
Oui, via le **onglet Logiciel** onglet, mais uniquement pour enrichir un appareil que vous avez déjà ajouté dans l’ **Appareils** onglet. Ce n’est pas une façon de créer un flux sans appareils.
#### Le système depuis lequel je pousse les données remonte moins souvent que mon appareil : les données poussées vont-elles être perdues ?
Non, mais un attribut poussé peut cesser d’être la valeur actuelle rapidement si l’appareil remonte beaucoup plus souvent, car les deux contributeurs partagent le même historique circulaire. Référez-vous à l’attribut en aval comme `value('attribute_name', 0, 'valid')` au lieu de son nom brut pour obtenir de manière fiable la dernière lecture réelle, quel que soit le moment. C’est une conséquence attendue de deux flux fonctionnant à des vitesses différentes, pas un défaut. Voir [Comment les données envoyées sont gérées](#how-pushed-data-is-handled) et [Valeurs manquantes et routage des valeurs nulles](/docs/user/fr/guide/account/iot-logic/nodes/logic-node/logic-node-expressions-and-syntax.md#missing-values-and-null-routing) pour la `'valid'` vs `'tout'` distinction dans une condition de nœud Logic.
#### J’ai poussé des données, mais elles n’apparaissent pas, qu’est-ce qui ne va pas ?
Vérifiez les points suivants dans cet ordre :
1. Confirmez que la requête incluait un `Authorization: NVX ` en-tête valide. Un en-tête manquant ou invalide génère une erreur HTTP 400 explicite.
2. Confirmez que le nom du champ poussé correspond exactement au paramètre du nœud, et que sa valeur correspond exactement à l’une des **Clé primaire** valeurs Key configurées, en utilisant uniquement des lettres, des chiffres et des tirets bas. Une valeur avec tiret est la cause la plus fréquente : elle passe la validation du point de terminaison d’envoi sans erreur, mais ne peut jamais correspondre à une valeur Key stockée, donc la requête renvoie tout de même un succès alors que rien ne fusionne. **Correspondances** lettres, chiffres et tirets bas uniquement. Une valeur avec tiret est la cause la plus fréquente : elle passe la validation du point de terminaison d’envoi sans erreur, mais ne peut jamais correspondre à une valeur Key stockée, donc la requête renvoie tout de même un succès alors que rien ne fusionne.
3. Vérifiez l’historique de l’attribut dans Analyseur de données, pas seulement sa valeur actuelle. Un appareil qui remonte souvent sa propre télémétrie peut faire sortir une valeur fusionnée de l’emplacement courant en quelques secondes, même si la fusion a réussi.
#### J’ai poussé un champ et les relevés de l’appareil semblent erronés
Le nom du champ poussé correspondait probablement à un attribut natif déjà remonté par l’appareil, ou à un attribut poussé par le connecteur d’un autre flux, et a écrasé son historique au lieu de créer un attribut distinct. Renommez le champ poussé avec un préfixe distinct, puis vérifiez l’historique de l’attribut dans [Analyseur de données](/docs/user/fr/guide/account/iot-logic/data-stream-analyzer.md) pour confirmer que les valeurs poussées et natives ne sont plus mélangées.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://navixy.com/docs/user/fr/guide/account/iot-logic/nodes/data-source-node.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
.png?alt=media)
