> 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
## 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 de télémétrie provenant des appareils IoT et des plateformes 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émétrie qui n'envoie pas de données à Navixy par défaut, envoie 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, le **Logiciel** onglet le conserve tel quel. Il enrichit en continu le flux de l'appareil avec les données de cette autre plateforme, de sorte que les deux flux fonctionnent en parallèle. Voir [Comment les données poussé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** 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 :
* L'acquisition initiale de données à partir de plusieurs types d'appareils et formats de protocole
* La transformation standardisée des données de divers fabricants en formats unifiés
* Des chemins de traitement parallèles en connectant une source de données à plusieurs nœuds en aval
* Le filtrage sélectif des appareils afin de n'inclure que les sources de données pertinentes dans votre flux
* L'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** en soi 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 à des brokers 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**: fournit des capacités de filtrage pour sélectionner des modèles ou des protocoles spécifiques
* **Traitement en temps réel**: gère en temps réel les flux de données de télémétrie entrants pour un traitement immédiat
* **Enrichissement par poussée HTTP**: fusionne les attributs poussé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 poussée pris en charge, avec une architecture 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** Le nœud détermine quels appareils envoient des données vers votre flux et, éventuellement, comment un système externe peut enrichir ces appareils avec des données poussées.
La boîte de dialogue de configuration est organisée en deux onglets :
* **Appareils**: sélectionne quels appareils envoient de la télémétrie vers le flux. Obligatoire, et fonctionne exactement comme auparavant.
* **Logiciel**: configure l'enrichissement par poussée 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 du **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 à cet endroit.
{% endhint %}
Voyons quels éléments ce nœud utilise et ce que vous pouvez configurer lors de son utilisation :
### É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 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 **Logiciel** qui ne peut associer que les appareils sélectionnés ici.
{% endstep %}
{% step %}
#### Enregistrez la configuration du nœud
Cliquez sur **Appliquer les modifications** pour terminer la création du nœud.
{% endstep %}
{% step %}
#### Configurer l'enrichissement par poussée HTTP (facultatif)
Passez à l’ **Logiciel** Utilisez l'onglet pour enrichir les appareils que vous avez sélectionnés dans Appareils avec des données poussées depuis un système externe. Cette étape est facultative. Voir [Configuration de l'enrichissement par poussée HTTP](#configuring-http-push-enrichment) pour la configuration complète.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
Si vous modifiez les paramètres de fabricant ou de modèle après la sélection 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 poussée HTTP
L'enrichissement par poussée HTTP permet à un système externe d'ajouter des attributs à un appareil déjà sélectionné dans l'onglet **Appareils** en envoyant des données à une URL générée. C'est facultatif et nécessite qu'au moins un appareil soit d'abord sélectionné sous [Étapes de configuration](#configuration-steps) Appareils d'abord.
C'est utile lorsqu'un appareil communique déjà avec un autre système 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. Plutôt que 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. Une poussée 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éfinir le type de connecteur
Passez à l’ **Logiciel** onglet et définissez **Type de connecteur** à **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 **URL** champ ne génère une valeur qu’une fois que le flux est enregistré avec **Type de connecteur** défini. Jusqu’à ce moment-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é, 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 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 des données puissent être reçues.
{% 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 envoyé. Il accepte jusqu’à 64 caractères, des lettres, des chiffres et des tirets bas uniquement.
Ajoutez-en un **Correspondances** une ligne par appareil à enrichir. Pour chaque ligne, sélectionnez le **Appareil source**, limité aux appareils déjà sélectionnés dans Appareils, puis saisissez le **Valeur de clé** qui identifie cet appareil dans les envois entrants. Ce champ stocke jusqu’à 255 caractères, mais le point de terminaison de push lui-même n’accepte 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 tirets bas, sans tirets ni autre ponctuation. La validation générale des champs du point de terminaison de push est plus permissive et accepte les tirets dans n’importe quel champ sans broncher, mais une valeur contenant un tiret ne peut jamais correspondre à une valeur de clé stockée, de sorte que les envois utilisant une telle valeur sont ignoré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 de les envoyer.
{% endhint %}
{% endstep %}
{% step %}
#### Appliquer et enregistrer
Cliquez sur **Appliquer les modifications**, puis enregistrez de nouveau le flux si vous avez configuré l’onglet Software après la sauvegarde initiale.
{% 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 une large gamme 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 des appareils sont transformés en un format standardisé que 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 des différents fabricants d’appareils.
### Comment les données poussées sont gérées
Navixy fait correspondre chaque push entrant à la valeur de sa clé primaire avec le Nœud configuré **Correspondances**, puis fusionne les autres champs dans le flux de données de l’appareil mappé sous forme d’attributs : nouveau si le nom du champ est nouveau, ou enregistré 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 envoyé par le connecteur d’un autre flux. Ils n’ont aucune incidence 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 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 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 `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 l'indiquer. Si vous n'êtes pas sûr qu'un envoi a é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 vous fier à la réponse.
{% endhint %}
{% hint style="warning" %}
Le nom d'un champ envoyé partage un même espace de noms avec les attributs natifs de l'appareil, ainsi qu'avec les noms envoyés par le connecteur d'un autre flux qui enrichit le même appareil. Si le nom correspond à un nom déjà utilisé, qu'il soit natif à l'appareil ou envoyé par un autre flux, l'envoi é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, de sorte qu'un nom en conflit peut produire de fausses données en aval. Par exemple, un champ envoyé nommé `niveau de carburant` qui correspond à l'attribut Carburant natif de l'appareil injecterait une lecture 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 envoyés afin qu'ils n'entrent pas en conflit avec les attributs natifs d'un appareil ou avec les noms envoyés par un autre flux, par exemple `bms_battery_soc` au lieu de `battery_soc`.
Les champs de message système tels que `vitesse`, `latitude`, `longitude`, `heading`, `satellites`, et `hdop` ne peuvent pas être écrasés de cette manière. Les envois ne créent ou ne mettent à jour que des attributs, jamais de télémétrie au niveau du message. Un champ envoyé 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 véritable télémétrie de l'appareil.
{% endhint %}
Un attribut fusionné s'inscrit 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 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 sous la forme `value('attribute_name', 0, 'valid')` au lieu de son nom brut. `'valid'` remonte dans l'historique de l'attribut jusqu'à la dernière lecture non nulle, de sorte que les nœuds en aval obtiennent la valeur envoyée quelle que soit la synchronisation.
{% endhint %}
Le point de terminaison d'envoi accepte jusqu'à 1 requête par seconde et par clé API, avec une taille de rafale de 1. Cadencez les 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 en utiliser plusieurs **nœuds source de données** dans un même 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 que 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. Être affecté à un autre flux n'est pas une restriction. Si les connecteurs de deux flux envoient toutefois le même nom d'attribut à cet appareil, ils ne fusionnent pas sans conséquence. L'historique d'un envoi écrase celui de l'autre. Voir [Comment les données poussé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 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 envoyés par un système externe via HTTP, à travers le nœud' **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 d'appareils si vous n'êtes pas sûr.
#### 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 l' **Logiciel** onglet, mais uniquement pour enrichir un appareil que vous avez déjà ajouté dans l' **Appareils** onglet. Ce n'est pas un moyen de créer un flux sans appareil.
#### Le système depuis lequel j'envoie remonte moins souvent que mon appareil, les données envoyées seront-elles perdues ?
Non, mais un attribut envoyé peut cesser rapidement d'être la valeur courante si l'appareil remonte beaucoup plus souvent, car les deux sources partagent le même historique glissant. Référencez l'attribut en aval comme `value('attribute_name', 0, 'valid')` au lieu de son simple nom 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 exécutés à des vitesses différentes, pas un défaut.
#### J’ai envoyé des données, mais elles ne s’affichent pas : qu’est-ce qui ne va pas ?
Vérifiez-les dans cet ordre :
1. Vérifiez que la requête incluait un en-tête valide `Authorization: NVX ` en-tête. Un en-tête manquant ou invalide provoque un échec explicite avec une erreur HTTP 400.
2. Vérifiez que le nom du champ envoyé correspond exactement au paramètre du nœud **Clé primaire** du nœud, et que sa valeur correspond exactement à l’une des **Correspondances** valeurs configurées, avec des lettres, des chiffres et des traits de soulignement uniquement. Une valeur avec un trait d’union est la cause la plus courante : elle passe la validation propre du point de terminaison de push sans erreur, mais ne peut jamais correspondre à une valeur Key stockée, de sorte que la requête renvoie tout de même un succès alors que rien ne se fusionne.
3. Vérifiez l’historique de l’attribut dans l’Analyseur de données, et pas seulement sa valeur actuelle. Un appareil qui signale sa propre télémétrie peut souvent faire sortir une valeur fusionnée de l’emplacement actuel en quelques secondes, même si la fusion a réussi.
#### J’ai envoyé un champ et les relevés de l’appareil semblent incorrects
Le nom du champ envoyé correspondait probablement à un attribut natif que l’appareil signale déjà, ou à un attribut envoyé par le connecteur d’un autre flux, et il a écrasé son historique au lieu de créer un attribut distinct. Renommez le champ envoyé 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 envoyé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.