> 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/analytics/fr/iot-query/schema-overview/transformation-layer/common-transformations/sensor-data-aggregation.md). # Agrégation des Données du capteur Traitez les relevés bruts des capteurs IoT en enregistrements regroupés par heure avec calibration décodée, calculs de carburant et agrégation au niveau de l'appareil La transformation d'agrégation des Données du capteur rééchantillonne les relevés bruts des capteurs en enregistrements récapitulatifs regroupés par intervalles de temps. Chaque ligne dans `données_communes_traitées.données_des_capteurs_par_heures` représente un capteur sur un appareil pour une tranche : la valeur décodée moyenne, minimale et maximale, et, pour les capteurs de Carburant, le volume calibré à chacun de ces points. La transformation intégrée s'exécute toutes les heures et agrège la dernière heure de Données du capteur brutes provenant de `raw_telematics_data.inputs` en tranches d'une heure. Chaque exécution ajoute un nouvel ensemble d'enregistrements horaires à la table. {% hint style="info" %} Les données de cette table peuvent avoir jusqu'à 1 heure de retard, reflétant la dernière exécution terminée.\ Tous les horodatages sont stockés en UTC.\ Seules les valeurs numériques des capteurs participent à l'agrégation. Les états textuels, les nombres négatifs et la notation scientifique sont filtrés à la source. {% endhint %} ### Table de sortie : processed\_common\_data.sensors\_data\_by\_hours Chaque ligne représente une tranche de relevés agrégés pour un capteur sur un appareil. Dans la transformation intégrée, chaque tranche couvre une heure. La clé naturelle est `hour_bucket`, `ID de l'appareil`, `sensor_name`, et `event_id`.
ChampTypeDescription
hour_buckethorodatageDébut du créneau temporel que la ligne agrège. Dans la transformation intégrée, toujours aligné sur la limite de l’heure en UTC. Dans les transformations personnalisées avec une taille de créneau différente, il s’agit du début du créneau à la granularité choisie (par exemple, le début d’une fenêtre de 5 minutes).
ID de l'appareilentierIdentifiant de l’appareil. Pour obtenir le libellé de l’objet sans multiplication des lignes, joindre à données_métier_brutes.objets sur ID de l'appareil où is_deleted = false.
sensor_nametexteIdentifiant d’entrée brute provenant de raw_telematics_data.inputs. Correspond à sensor_description.input_label lorsqu’un capteur est configuré.
event_identierIdentifiant du type d’événement pour la lecture du capteur.
identifiant_capteurentierIdentifiant d’entité du capteur provenant de raw_business_data.sensor_description. NULL si le capteur n’est pas configuré.
libellé_d'entréetexteLibellé d’entrée configuré provenant de description_du_capteur. Correspond à sensor_name lorsqu'il est présent.
libellé_du_capteurtexteNom du capteur lisible par l'humain défini par l'utilisateur.
type_de_capteurtexteType de capteur, par exemple niveau_de_Carburant, température, Contact.
unités_du_capteurtexteChaîne d'unité saisie par l'utilisateur lorsque type_d'unités est défini sur personnalisé. Vide sinon.
type_d'unitésentierCode numérique de la catégorie d’unité. Résolu en une chaîne lisible par un humain dans type_d’unités_description_capteur.
Groupe_typeentierCode de règle d’agrégation pour les capteurs regroupés : 0 pour la somme, 1 pour la moyenne. Résolu dans type_de_Groupe_description_capteur.
valeur_moyenneflottantMoyenne de la valeur décodée du capteur sur l’ensemble des relevés du compartiment.
value_minflottantValeur décodée minimale dans le bucket.
value_maxflottantValeur décodée maximale dans le bucket.
val_low_avg, val_high_avg, vol_low_avg, vol_high_avgnumériquePoints de calibration utilisés lors de l'interpolation calibrated_volume_avg. Uniquement pour les capteurs de Carburant ; null sinon.
calibrated_volume_avgnumériqueVolume calibré correspondant à valeur_moyenne, calculé par interpolation linéaire entre les points de rupture. Pour les capteurs qui ne sont pas de type Carburant, cela équivaut à valeur_moyenne.
val_low_min, val_high_min, vol_low_min, vol_high_min, calibrated_volume_minnumériquePoints de calibration et volume interpolé pour value_min.
val_low_max, val_high_max, vol_low_max, vol_high_max, calibrated_volume_maxnumériquePoints de calibration et volume interpolé pour value_max.
traceur_labeltexteLibellé du Traceur provenant de données_métier_brutes.objets. Peut apparaître plusieurs fois pour le même bucket si un appareil a été réaffecté entre des Traceurs au cours de l'historique.
type_d’unités_description_capteurtexteCatégorie d'unité lisible résolue à partir de type_d'unités.
type_de_Groupe_description_capteurtexteRègle de regroupement lisible résolue à partir de Groupe_type.
sensor_units_finaltexteLa chaîne d'unité à afficher. Vaut unités_du_capteur lorsqu'elle est définie, sinon revient à type_d’unités_description_capteur.
value_titletexteLibellé lisible pour les capteurs discrets, recherché dans parameters.value_titles en utilisant value_max comme clé. Null pour les Capteurs de mesure.
Les exemples ci-dessous montrent des modèles de requêtes courants. Le premier renvoie des agrégats horaires pour les 7 derniers jours. Le second effectue une jointure avec `données_métier_brutes.objets` pour inclure le libellé du Traceur sans multiplication des lignes. Le troisième se concentre sur les capteurs de Carburant et utilise les colonnes de volume calibré. {% tabs %} {% tab title="Requête horaire de base" %} {% code overflow="wrap" expandable="true" %} ```sql Sélectionner device_id, hour_bucket, sensor_label, sensor_type, value_avg, value_min, value_max, sensor_units_final FROM processed_common_data.sensors_data_by_hours WHERE hour_bucket >= CURRENT_DATE - INTERVAL '7 days' ORDER BY device_id, hour_bucket, sensor_label; ``` {% endcode %} {% endtab %} {% tab title="Avec libellé du Traceur" %} {% code overflow="wrap" expandable="true" %} ```sql Sélectionner s.device_id, o.traceur_label, s.hour_bucket, s.sensor_label, s.value_avg, s.sensor_units_final FROM processed_common_data.sensors_data_by_hours s LEFT JOIN raw_business_data.objects o ON o.device_id = s.device_id AND o.is_deleted = false WHERE s.hour_bucket >= CURRENT_DATE - INTERVAL '7 days' ORDER BY s.device_id, s.hour_bucket, s.sensor_label; ``` {% endcode %} {% endtab %} {% tab title="Capteurs de Carburant avec volume calibré" %} {% code overflow="wrap" expandable="true" %} ```sql Sélectionner device_id, hour_bucket, sensor_label, value_avg AS raw_avg, calibrated_volume_avg AS volume_avg_litres, calibrated_volume_min AS volume_min_litres, calibrated_volume_max AS volume_max_litres FROM processed_common_data.sensors_data_by_hours WHERE sensor_type = 'niveau_Carburant' AND hour_bucket >= CURRENT_DATE - INTERVAL '24 hours' ORDER BY device_id, hour_bucket; ``` {% endcode %} {% endtab %} {% endtabs %} ### Comment sont construits les agrégats des capteurs Une ligne de cette table n’est pas une lecture brute de l’appareil, c’est une entité dérivée assemblée à partir de nombreuses lectures de capteurs individuelles. La transformation fonctionne à travers les Données brutes par étapes : déterminer quelles lectures sont utilisables, associer la configuration du capteur, décoder la valeur, regrouper par fenêtres temporelles, agréger, appliquer l’étalonnage du Carburant, puis enrichir avec des libellés lisibles par l’humain. Comprendre ce processus vous aide à interpréter correctement les résultats et à reconnaître quand le comportement par défaut doit être ajusté pour votre cas d’usage. Voici les étapes de l’algorithme qui forme une ligne agrégée de capteur : {% stepper %} {% step %} #### **Lecture et filtrage des entrées brutes** La transformation lit la tranche de données la plus récente à partir de `raw_telematics_data.inputs`. La longueur de la tranche correspond à l’intervalle configuré : l’exécution intégrée lit la dernière heure ; une exécution personnalisée avec un intervalle de 5 minutes lit les 5 dernières minutes. Les relevés sont filtrés avant tout autre traitement : * Seules les valeurs correspondant à l’expression régulière `^[0-9]+\.?[0-9]*$` sont conservées. Cela accepte les entiers non négatifs et les décimaux. * Les chaînes de texte, les nombres négatifs, la notation scientifique et les valeurs nulles sont exclus. * Les capteurs qui émettent uniquement des données non numériques n’apparaissent pas dans le tableau de sortie. Le filtre s’applique aux données brutes `valeur` colonne dans `entrées`, avant toute application de décodage. {% endstep %} {% step %} #### **Configuration de jonction du capteur** Chaque mesure restante est mise en correspondance avec `raw_business_data.sensor_description` à l'aide d'un `jointure gauche` sur `ID de l'appareil` et `input_label = sensor_name`. La jointure inclut `identifiant_capteur`, `libellé_du_capteur`, `type_de_capteur`, `type_d'unités`, `Groupe_type`, `diviseur`, `multiplicateur`, `données_d'étalonnage`, et `paramètres`. Parce que la jointure est à gauche, les relevés provenant de capteurs non configurés passent quand même, avec les métadonnées du capteur à null. {% endstep %} {% step %} #### **Décodage de la valeur brute** Chaque relevé est converti de sa représentation stockée en une valeur numérique exploitable. La règle de décodage provient de `sensor_description.parameters.calc_method`: * `indice_de_bit` extrait un seul bit de la valeur entière à l'aide d'un décalage de bits et d'un masque : `((raw_value::bigint >> bit_index) & 1)`. Utilisé pour des indicateurs d'état empaquetés dans des entiers. * `identité` utilise la valeur numérique brute sans modification. * Sinon, la fonction applique `(raw_value / divider) * multiplier`, qui est la formule standard pour les Capteurs de mesure. Un diviseur nul déclenche un `COALESCE` repli sur la valeur brute. {% endstep %} {% step %} #### **Regroupement par buckets et agrégation** Les valeurs décodées sont regroupées en intervalles temporels en tronquant `device_time` à la limite de l'intervalle. Dans chaque intervalle, la fonction calcule `AVG`, `MIN`, et `MAX` de la valeur décodée. Le regroupement inclut également les colonnes de métadonnées des capteurs, de sorte que les agrégats sont calculés par capteur, par appareil et par intervalle. Dans la transformation intégrée, l'intervalle est d'une heure. Les transformations personnalisées peuvent utiliser n'importe quel intervalle positif. Voir [Personnalisation de la transformation](https://claude.ai/chat/32cacafe-fe34-476d-b7d0-c93b4ce82da6#customizing-the-transformation) ci-dessous. {% endstep %} {% step %} #### **Étalonnage des capteurs de Carburant** Les capteurs dotés d’un `données_d'étalonnage` tableau rempli (généralement des capteurs de niveau de Carburant) se voient appliquer une interpolation linéaire à chaque agrégat. Pour `valeur_moyenne`, `value_min`, et `value_max` séparément, la fonction trouve les points de calibration juste en dessous et juste au-dessus de la valeur, puis interpole linéairement pour produire `calibrated_volume_avg`, `calibrated_volume_min`, et `calibrated_volume_max`. Pour les capteurs sans données d’étalonnage, les volumes étalonnés sont égaux aux agrégats bruts. Les colonnes de points de rupture (`val_low_*`, `val_high_*`, `vol_low_*`, `vol_high_*`) sont conservées dans la sortie par souci de transparence. {% endstep %} {% step %} #### **Enrichissement avec des libellés** Les lignes agrégées sont jointes avec `données_métier_brutes.objets` sur `ID de l'appareil` pour ajouter `traceur_label`, et avec `raw_business_data.description_parameters` deux fois pour résoudre `type_d'unités` et `Groupe_type` en chaînes de description lisibles par l’humain. La fonction calcule également `sensor_units_final`, qui privilégie le `unités_du_capteur` saisi par l’utilisateur et revient à la chaîne de description. Pour les capteurs discrets dotés d’un `parameters.value_titles` mappage, la fonction recherche le titre lisible correspondant à `value_max` et le renvoie sous forme de `value_title`. Les Capteurs de mesure ont `value_title` défini à null. {% endstep %} {% endstepper %} Les deux sections de référence suivantes contiennent le paramètre d’intervalle configurable et les règles de décodage que la transformation applique en interne.
Paramètre d’intervalle La transformation est pilotée par un seul paramètre, `p_interval`, qui contrôle à la fois la taille de l’intervalle et la fenêtre de retour. Les deux sont toujours égales : une exécution avec `p_interval = '5 minutes'` lit les 5 dernières minutes de Données brutes et produit des intervalles de 5 minutes. | Paramètre | Transformation intégrée | Transformation personnalisée | | ------------------------ | ------------------------------------------------ | ---------------------------------------------------------------------------------- | | Taille du bucket | 1 heure | Tout intervalle positif défini dans le Nœud SQL personnalisé | | Fenêtre d'historique | 1 heure | Égal à la taille du bucket | | Cadence de planification | Toutes les heures (adapté à la taille du bucket) | Correspond à la taille du bucket choisie pour une couverture continue sans lacunes | Voir [Personnalisation de la transformation](#customizing-the-transformation) pour savoir comment modifier l'intervalle.
Règles de décodage des valeurs Les valeurs brutes des Données du capteur arrivent sous forme de texte dans `raw_telematics_data.inputs.value`. La transformation applique une règle de décodage basée sur la configuration de chaque capteur avant l'agrégation. | `calc_method` | Comportement de décodage | | -------------------- | ----------------------------------------------------------------------------------------------------------------- | | `indice_de_bit` | Extrait un seul bit : `((value::bigint >> bit_index) & 1)`. Le `indice_de_bit` est lu à partir de `paramètres`. | | `identité` | Utilise la valeur brute comme un flottant, inchangée. | | (par défaut / aucun) | Applique `(raw_value / divider) * multiplier`. Un diviseur nul déclenche un `COALESCE` repli sur la valeur brute. | L'interpolation de calibration, appliquée après l'agrégation pour les capteurs disposant de données de calibration, fonctionne en trouvant les points de rupture dans `données_d'étalonnage` (un tableau JSONB de `{in, out}` entrées) les plus proches de la valeur agrégée et en interpolant linéairement entre elles. Le résultat est stocké dans les `calibrated_volume_*` colonnes.
### Personnalisation de la transformation L'agrégation par défaut des Données du capteur reflète l'agrégation horaire polyvalente de Navixy. Si votre scénario opérationnel nécessite une granularité différente, comme une résolution plus fine pour des tableaux de bord de diagnostic ou des intervalles plus grossiers pour des rapports à long terme, vous pouvez créer une transformation personnalisée qui appelle `select_timeperiod_sensor_data` avec un intervalle différent et écrit le résultat dans votre propre table dans `données_personnalisées_traitées`. La personnalisation ne nécessite qu'une modification d'une ligne dans un Nœud SQL personnalisé : ```sql SELECT * FROM processed_common_data.select_timeperiod_sensor_data('5 minutes') ``` Modifiez le littéral de l'intervalle pour contrôler à la fois la taille du bucket et la fenêtre d'historique. La fonction renvoie la même structure de colonnes quel que soit l'intervalle, de sorte que la configuration du Nœud de sortie en aval reste simple. {% hint style="warning" %} La valeur de l'intervalle contrôle ensemble la taille du bucket et la fenêtre d'historique. Elles ne peuvent pas être définies indépendamment. La planification du workflow doit s'exécuter au moins aussi fréquemment que l'intervalle, sinon certaines mesures ne seront pas agrégées. {% endhint %} #### Structure du workflow Le workflow minimal comporte deux Nœuds :
Aucun `Données brutes : Télématique` Nœud source n'est nécessaire. La fonction lit à partir de `raw_telematics_data.inputs` et `raw_business_data` tables en interne. Le Nœud SQL personnalisé contient l'intégralité du pipeline, et le Nœud de sortie matérialise le résultat dans votre table cible. #### Exemples de personnalisation Développez les sections ci-dessous pour voir des exemples de personnalisation par cas d'usage.
Modification de la taille du bucket Utilisez ceci lorsque la granularité horaire est trop grossière pour vos besoins de reporting. Les cas courants incluent les tableaux de bord qui affichent les tendances du Carburant à une résolution de 5 minutes, les diagnostics seconde par seconde pour de courts essais sur route et les consolidations quotidiennes pour les rapports à long terme. Pour modifier la taille du bucket, modifiez le littéral de l'intervalle dans le Nœud SQL personnalisé et mettez à jour la planification en conséquence. * **buckets de 5 minutes**, avec planification `*/5 * * * *` (toutes les 5 minutes) : ```sql SELECT * FROM processed_common_data.select_timeperiod_sensor_data('5 minutes') ``` * **tranches de 15 minutes**, avec planification `*/15 * * * *` (toutes les 15 minutes) : ```sql SELECT * FROM processed_common_data.select_timeperiod_sensor_data('15 minutes') ``` * **tranches journalières**, avec planification `5 0 * * *` (chaque jour à 00:05 UTC) : ```sql SELECT * FROM processed_common_data.select_timeperiod_sensor_data('1 day') ``` La colonne de sortie s'appelle toujours `hour_bucket` quel que soit l'intervalle. Si vous voulez un nom plus clair dans votre table personnalisée, donnez-lui un alias dans le SQL personnalisé : ```sql Sélectionner hour_bucket AS bucket_time, device_id, sensor_name, event_id, sensor_id, input_label, sensor_label, sensor_type, sensor_units, units_type, Groupe_type, value_avg, value_min, value_max, Traceur_label, sensor_units_final FROM processed_common_data.select_timeperiod_sensor_data('5 minutes') ``` Définissez les paramètres du Nœud de sortie **Colonne de temps** à `bucket_time` si vous créez un alias, ou `hour_bucket` si vous conservez le nom d'origine.
Restriction à des capteurs spécifiques Utilisez ceci lorsque vous n'avez besoin d'agrégats que pour un sous-ensemble de capteurs, par exemple uniquement le niveau de Carburant et la température du moteur, afin de réduire la taille de la table et le coût des requêtes. Encapsulez l'appel de fonction dans un filtrage `Sélectionner` à l'intérieur du nœud SQL personnalisé : ```sql SELECT * FROM processed_common_data.select_timeperiod_sensor_data('15 minutes') WHERE sensor_type IN ('Carburant_level', 'temperature') ``` Vous pouvez filtrer sur n'importe quelle colonne que la fonction renvoie, y compris `libellé_du_capteur`, `sensor_name`, ou `identifiant_capteur`. Pour trouver les valeurs disponibles dans vos données, interrogez la table source : ```sql SELECT DISTINCT sensor_name FROM raw_telematics_data.inputs LIMIT 100; ```
Réduire la sortie aux colonnes essentielles Utilisez ceci lorsque vous n'avez pas besoin des points de rupture de calibration ou de la colonne du capteur discret `value_title` et que vous souhaitez une table de sortie plus légère. C'est particulièrement utile lorsque votre Flotte n'a pas de capteurs de Carburant, auquel cas les 15 colonnes liées à la calibration sont toutes nulles ou des doublons des agrégats bruts. Ne projetez que les colonnes dont vous avez besoin : ```sql Sélectionner hour_bucket, device_id, sensor_name, event_id, sensor_label, sensor_type, value_avg, value_min, value_max, Traceur_label, sensor_units_final FROM processed_common_data.select_timeperiod_sensor_data('15 minutes') ``` La configuration du Nœud de sortie reste la même ; la table cible aura simplement moins de colonnes.
#### Configuration du Nœud de sortie Une fois le Nœud SQL personnalisé configuré, connectez-le à un Nœud de sortie et configurez la table cible.
ParamètreValeur
Nom de la tableUn nom descriptif, par exemple sensors_data_by_5min
Colonne de tempshour_bucket (ou votre alias si vous l'avez renommé)
Clé primaireID de l'appareil, hour_bucket, sensor_name, event_id
Partitionner parDATE(hour_bucket)
Mode d'écritureajout
La clé primaire doit inclure les quatre colonnes de la clé naturelle de la fonction. Utiliser uniquement `ID de l'appareil` et `hour_bucket` provoquera des violations de clé primaire, car chaque appareil possède plusieurs capteurs émettant dans le même bucket. `ajout` est le mode d'écriture correct lorsque l'ordonnancement correspond à la taille du bucket, car chaque exécution produit de nouveaux buckets qui n'ont jamais été écrits auparavant. Utilisez `upsert` uniquement si vos exécutions se chevauchent (par exemple, un intervalle de 15 minutes planifié toutes les 5 minutes). #### Ordonnancement Le rythme de planification doit être égal à la valeur de l'intervalle. Chaque exécution lit alors exactement la quantité de données d'un bucket, sans chevauchement ni lacune. | Taille du bucket | Expression de planification | Signification | | ---------------- | --------------------------- | -------------------------------- | | 1 minute | `* * * * *` | Toutes les minutes | | 5 minutes | `*/5 * * * *` | Toutes les 5 minutes | | 15 minutes | `*/15 * * * *` | Toutes les 15 minutes | | 1 heure | `0 * * * *` | Toutes les heures à la minute 00 | | 1 jour | `5 0 * * *` | Tous les jours à 00:05 UTC | Les heures sont en UTC. Faites correspondre la cadence cron à votre intervalle ; une exécution moins fréquente que l'intervalle laissera des lacunes dans la table de sortie, et une exécution plus fréquente provoquera des conflits de clé primaire en `ajout` mode. #### Utilisation du modèle de workflow Navixy fournit un modèle de workflow prêt à l'emploi que vous pouvez charger dans Transformation Builder comme point de départ. Le modèle est fourni avec le Nœud Custom SQL préconfiguré pour des buckets de 5 minutes. Voir la [Modèles](/docs/analytics/fr/iot-query/schema-overview/transformation-layer/transformation-builder/templates.md) page pour le téléchargement, les instructions d'importation et la configuration du Nœud de sortie pour cette transformation. ### Étapes suivantes * [**Transformations courantes**](/docs/analytics/fr/iot-query/schema-overview/transformation-layer/common-transformations.md): Retour à l'index des transformations. * [**Modèles**](/docs/analytics/fr/iot-query/schema-overview/transformation-layer/transformation-builder/templates.md): Téléchargez le modèle de workflow d'agrégation des Données du capteur et importez-le dans Transformation Builder. * [**Transformation Builder**](/docs/analytics/fr/iot-query/schema-overview/transformation-layer/transformation-builder.md): Découvrez comment travailler avec l'éditeur visuel de workflow, ajouter des Nœuds et prévisualiser les résultats. * [**Couche de Données brutes**](/docs/analytics/fr/iot-query/schema-overview/bronze-layer.md): Explorez les tables sources qui alimentent l'agrégation des Données du capteur : `raw_telematics_data.inputs`, `raw_business_data.sensor_description`, et `données_métier_brutes.objets`. * [**Trajets**](/docs/analytics/fr/iot-query/schema-overview/transformation-layer/common-transformations/trips.md): Une transformation sœur qui produit des enregistrements de Voyage des Véhicules à partir de données télématiques brutes. --- # 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/analytics/fr/iot-query/schema-overview/transformation-layer/common-transformations/sensor-data-aggregation.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.