> 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 les 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 capacités
{% columns %}
{% column %}
**Source de données** Le Nœud est un point d'entrée pour les données de télémétrie provenant d'appareils IoT et de plates-formes OEM dans le système IoT Logic. Il fonctionne comme un traducteur universel, recevant les données via les protocoles TCP/UDP/HTTP sur les interfaces réseau et via des 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 réception de la télémétrie, un **Source de données** Nœud peut également enrichir un appareil que vous lui avez déjà ajouté. Un système externe, tel qu'une autre plateforme de télématique qui n'envoie pas de données à Navixy par défaut, transmet des attributs supplémentaires au flux de l'appareil. Parfois, cette plateforme externe est celle du fabricant de l'appareil. Plutôt que de migrer l'appareil vers l'ingestion native de Navixy, l' **Logiciel** onglet 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 s'exécutent en parallèle. Voir [Comment les données envoyées sont traitées](#how-pushed-data-is-handled) pour le fonctionnement, et [Options de configuration](#configuration-options) pour le mettre en place.
### Intégration à l'architecture du flux
**nœud Source de données** sert de point d'entrée pour les données dans un flux IoT Logic. Un seul flux peut contenir plusieurs Nœuds sources, chacun avec des configurations indépendantes. Cette architecture permet :
* Acquisition initiale des données à partir de plusieurs types d'appareils et 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
Le **nœud Source de données** à 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 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** : traite les flux de télémétrie entrants en temps réel pour un traitement immédiat
* **Enrichissement par push HTTP** : fusionne les attributs envoyés depuis un système externe dans le flux d'un appareil déjà sélectionné dans ce Nœud. HTTP est aujourd'hui le seul type de push pris en charge, avec une architecture conçue pour en prendre en charge d'autres à l'avenir
## Options de configuration
{% columns %}
{% column width="58.333333333333336%" valign="middle" %}
Configurer un **Source de données** Le 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 :
* **Traceurs** : sélectionne les appareils qui envoient la télémétrie dans le flux. Obligatoire, et fonctionne exactement comme auparavant.
* **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" %}
Le **Logiciel** l'onglet dépend de l' **Traceurs** onglet. Son **Appareil source** sélecteur n'affiche que les appareils déjà sélectionnés dans **Traceurs**, et n'affiche aucune donnée disponible tant que vous n'en avez pas sélectionné au moins un.
{% endhint %}
Voyons quels éléments ce nœud utilise et ce que vous pouvez configurer lorsque vous travaillez avec lui :
### É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 d'autres informations pertinentes.
* Ce nom sera affiché dans le diagramme de flux pour faciliter l'identification.
{% endstep %}
{% step %}
#### Sélectionnez des 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 **Logiciel** onglet, qui ne peut associer que les appareils sélectionnés ici.
{% endstep %}
{% step %}
#### Enregistrez la configuration du nœud
Cliquez sur **Appliquez les modifications** pour terminer la création du nœud.
{% endstep %}
{% step %}
#### Configurez l'enrichissement par push HTTP (facultatif)
Passez à la **Logiciel** onglet pour enrichir les appareils que vous avez sélectionnés dans Appareils avec des données envoyées depuis 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 certains 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 **Traceurs** onglet, 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 communique déjà avec un système distinct qui n'alimente pas Navixy par défaut, par exemple une plateforme de gestion de batterie qui suit 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 enregistré tel quel et faire en sorte que cette autre plateforme envoie ses relevés ici. 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` en tant que nouveaux attributs sur l'appareil mappé, aux côtés de sa télémétrie GPS native.
{% stepper %}
{% step %}
#### Définissez le type de connecteur
Passez à la **Logiciel** onglet et définissez **Type de connecteur** en **HTTP**, actuellement la seule option.
{% endstep %}
{% step %}
#### Enregistrez le flux et copiez l'URL générée
Enregistrez l'ensemble du flux, pas seulement ce nœud. Le **URL** le champ ne génère une valeur que lorsque le flux est enregistré avec **Type de connecteur** défini. Jusque-là, il affiche un texte indicatif vous invitant à enregistrer le flux. Une fois l’URL affichée, cliquez sur l’icône de copie à côté, qui n’est désactivée que lorsque le champ est vide.
{% endstep %}
{% step %}
#### Authentifiez le système externe
Attribuez au système externe une clé valide [clé API Navixy](/docs/user/fr/guide/account/api-keys.md), et configurez-le pour envoyer `Authorization: NVX ` avec chaque requête 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 être reçues.
{% endstep %}
{% step %}
#### Définissez la clé primaire et les mappages
Saisissez un **Clé primaire**: le nom du champ que le système externe utilise pour identifier à quel appareil appartient l’enregistrement envoyé. Il accepte jusqu’à 64 caractères, uniquement des lettres, des chiffres et des traits de soulignement.
Ajoutez-en une **Mappages** ligne par appareil à enrichir. Pour chaque ligne, sélectionnez le **Appareil source**, limitée aux appareils déjà sélectionnés dans Appareils, et saisissez la **Valeur de la clé** qui identifie cet appareil dans les envois entrants. Ce champ stocke jusqu’à 255 caractères, mais le point de terminaison d’envoi n’accepte lui-même que jusqu’à 100 caractères par champ, alors gardez en pratique la valeur bien en dessous de 100 caractères.
{% hint style="warning" %}
La Clé primaire et la Valeur de la clé n’acceptent que des lettres, des chiffres et des traits de soulignement, sans tirets ni autre signe de ponctuation. La validation générale des champs du point de terminaison d’envoi est plus permissive et accepte des tirets dans n’importe quel champ sans émettre d’erreur, mais une valeur comportant des tirets ne peut jamais correspondre à une Valeur de la clé stockée, de sorte que les envois utilisant une telle valeur 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 `camion-12`), traduisez-les, par exemple en `truck_12`, avant de pousser.
{% endhint %}
{% endstep %}
{% step %}
#### Appliquer et enregistrer
Cliquez sur **Appliquez 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 parseurs et décodeurs de Navixy, offrant une compatibilité avec un large éventail d’appareils IoT. Lorsque les données arrivent à ce nœud, elles suivent 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é selon 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 dans votre flux
Ce processus de standardisation vous permet de créer des flux de traitement cohérents, quel que soit le format de données d’origine provenant de différents fabricants d’appareils.
### Comment les données envoyées sont traitées
Navixy associe chaque push entrant à sa valeur de clé primaire par rapport au Nœud configuré **Mappages**, puis fusionne les champs restants dans le flux de données de l’appareil mappé en tant qu’attributs : nouveaux si le nom du champ est nouveau, ou écrits dans l’historique existant de cet attribut si le nom correspond à un attribut déjà existant, qu’il soit signalé nativement par l’appareil ou envoyé par le connecteur d’un autre flux. Ils n’affectent pas la localisation ni les autres données de télémétrie. Le champ nommé dans **Clé primaire**, ainsi que `flux_id` et `id_du_nœud` , est utilisé pour le routage et ne devient jamais un attribut en lui-même. Une requête peut aboutir dans l’un des trois états suivants :
| 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 se fusionnent en tant qu'attributs : nouveau 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 `Authorization` en-tête | erreur 400 | Non. 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, pas 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 envoi a été pris en compte, 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 vous fier à la réponse.
{% endhint %}
{% hint style="warning" %}
Le nom d'un champ poussé partage un même espace de noms avec les attributs natifs de l'appareil, ainsi qu'avec les noms poussés par le connecteur d'un autre flux enrichissant le même appareil. Si le nom correspond à un nom déjà utilisé, qu'il soit natif de l'appareil ou poussé par un autre flux, l'envoi écrase l'historique existant de cet attribut au lieu d'en créer un séparé.
Les capteurs, les Rapports et les Règles d’alertes lisent la valeur fusionnée comme une mesure réelle, si bien qu'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 Carburant d'un appareil injecterait une fausse lecture, 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 ne puissent pas entrer en collision avec les attributs natifs d'un appareil ou les noms poussés par un autre flux, par exemple `bms_battery_soc` au lieu de `battery_soc`.
Les champs de message système tels que `speed`, `latitude`, `longitude`, `heading`, `satellites` et `hdop` ne peuvent pas être écrasés de cette façon. Les envois ne créent ou ne mettent à jour que des attributs, jamais la télémétrie au niveau du message. Un champ poussé utilisant 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 remonte sa propre télémétrie beaucoup plus souvent que le système externe n'envoie des mises à jour, les paquets de l'appareil peuvent faire avancer l'historique de l'attribut au-delà de la valeur poussée en quelques secondes, même si la fusion a réussi.
{% hint style="info" %}
Il s'agit d'une conséquence attendue de deux flux de données fonctionnant à des vitesses différentes, et non d'un défaut. Référez-vous à l'attribut en aval sous la forme `value('attribute_name', 0, 'valid')` au lieu de son nom brut. `'valide'` remonte l'historique de l'attribut jusqu'à la dernière lecture non nulle, afin que les nœuds en aval obtiennent la valeur poussée quelle que soit la synchronisation. Consultez [Valeurs manquantes et routage vers null](/docs/user/fr/guide/account/iot-logic/nodes/logic-node/logic-node-expressions-and-syntax.md#missing-values-and-null-routing) pour savoir comment `'valide'` se compare à `'tous'` dans une condition de Nœud Logic.
{% endhint %}
Le point de terminaison d'envoi accepte jusqu'à 1 requête par seconde et par clé API, avec une rafale de 1. Cadencez les requêtes du système externe en conséquence.
## Foire aux questions
#### Puis-je utiliser plusieurs Nœuds Source de données dans un flux ?
Oui, vous pouvez utiliser plusieurs **nœuds Source de données** dans un même espace de travail. C'est utile lorsque vous devez traiter des données provenant de différents types d'appareils de différentes façons ou 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 afin d'éviter toute perte de données. Être affecté à un autre flux n'est pas une restriction. Si les connecteurs de deux flux poussent le même nom d'attribut vers cet appareil, en revanche, ils ne se fusionnent pas sans conséquence. L'historique d'un envoi écrase celui de l'autre. Voir [Comment les données envoyées sont traitées](#how-pushed-data-is-handled) pour éviter les noms en collision.
#### 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 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 **Source de données** Nœud peut également être enrichi avec des attributs poussés depuis un système externe via HTTP, par le **Logiciel** onglet.
#### 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). Vérifiez la documentation de votre appareil ou consultez 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** 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 depuis un système qui n'est pas un appareil Navixy ?
Oui, via l' **Logiciel** onglet, mais uniquement pour enrichir un appareil que vous avez déjà ajouté dans l' **Traceurs** onglet. Ce n'est pas un moyen de créer un flux sans appareil.
#### Le système depuis lequel je pousse remonte moins souvent que mon appareil, les données poussées seront-elles perdues ?
Non, mais un attribut poussé peut cesser d'être la valeur courante rapidement si l'appareil remonte beaucoup plus souvent, puisque les deux contributeurs partagent le même historique glissant. Référez-vous à l'attribut en aval sous la forme `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 s’exécutant à des vitesses différentes, et non un défaut. Voir [Comment les données envoyées sont traitées](#how-pushed-data-is-handled) et [Valeurs manquantes et routage vers null](/docs/user/fr/guide/account/iot-logic/nodes/logic-node/logic-node-expressions-and-syntax.md#missing-values-and-null-routing) pour la `'valide'` vs `'tous'` la distinction dans une condition de Nœud logique.
#### J’ai poussé des données, mais elles ne s’affichent pas. Qu’est-ce qui ne va pas ?
Vérifiez-les dans cet ordre :
1. Confirmez que la requête incluait un en-tête valide `Authorization: NVX ` en-tête. Un en-tête manquant ou invalide échoue de manière explicite avec une erreur HTTP 400.
2. Confirmez que le nom du champ poussé correspond au réglage du Nœud **Clé primaire** exactement, et que sa valeur correspond à l’une des valeurs configurées **Mappages** lettres, chiffres et tirets bas uniquement. Une valeur comportant des traits d’union est la cause la plus fréquente : elle passe la validation propre du point de terminaison de push sans erreur, mais ne peut jamais correspondre à une valeur Key stockée, si bien que la requête renvoie quand même un succès alors que rien ne se fusionne.
3. Vérifiez l’historique de l’attribut dans Analyseur de données, et pas seulement sa valeur actuelle. Un appareil qui remonte sa propre télémétrie peut souvent faire disparaître une valeur fusionnée de l’emplacement actuel en quelques secondes, même si la fusion a réussi.
#### J’ai poussé un champ et les relevés de l’appareil lui-même semblent erronés
Le nom du champ poussé correspondait probablement à un attribut natif que l’appareil remonte déjà, 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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
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 what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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)
