> 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/expert-center/fr/vehicle-telematics-technology/fuel-management/understanding-gray-zones-in-fuel-level-reports.md).
# Comprendre les zones grises dans les rapports de niveau de carburant
Les zones grises dans les rapports de niveau de carburant proviennent de la logique de continuité des données, et non de relevés manquants. Couvre la validité du GPS par rapport à celle du capteur et la manière de réduire les lacunes de reporting.
### Vue d'ensemble
Les clients signalent parfois des zones grises ou des lignes discontinues dans les rapports de niveau de carburant, en supposant que la plateforme ne traite pas correctement les Données du capteur. Ce comportement peut prêter à confusion, car il peut sembler que des relevés de capteur manquent ou sont ignorés.
En réalité, la plateforme continue de traiter correctement les Données du capteur. Les zones grises sont une conséquence de la logique de continuité des données de la plateforme, conçue pour empêcher une interpolation inexacte entre de longues lacunes dans les rapports.
Ce document explique comment la plateforme traite les Données du capteur, pourquoi des intervalles discontinus apparaissent et ce qui peut être fait pour les minimiser.
### Données du capteur valides contre données GPS invalides
Le premier concept à comprendre est que la validité du GPS et celle du capteur sont indépendantes.
Une position est considérée comme invalide lorsque :
* Aucun satellite GPS n'est disponible.
* Moins de trois satellites sont disponibles.
* La latitude ou la longitude est égale à 0.
Bien que la position elle-même soit considérée comme invalide, les valeurs des capteurs contenues dans le même paquet restent valides et sont toujours traitées.
Par exemple :
Bien que la position GPS ne puisse pas être affichée sur la carte en raison de l'absence de satellites, la valeur de avl\_io\_9 (capteur de niveau de carburant) est toujours :
* Reçue
* Stockée
* Traitée
* Affichée dans les Rapports de carburant
* Utilisée par IoT Logic
Autrement dit, des données GPS invalides n'invalident pas les Données du capteur.
### Continuité des Données du capteur
L'une des questions les plus fréquentes concernant les rapports de niveau de carburant est de savoir pourquoi le graphe affiche des segments discontinus, alors que les relevés individuels des capteurs sont présents dans le rapport.
Du point de vue du client, ce comportement peut sembler incorrect, car les valeurs des capteurs sont visibles, mais le graphe n'est pas rendu sous la forme d'une seule ligne continue. Dans de nombreux cas, les clients interprètent ces interruptions comme des données manquantes ou un traitement incorrect, alors qu'en réalité elles résultent de la logique de continuité de la plateforme.
#### Logique de continuité
La plateforme regroupe les relevés des capteurs en intervalles continus en fonction de l'écart de temps entre les enregistrements consécutifs.
Lorsque le temps écoulé entre deux relevés successifs du capteur dépasse 30 minutes, la plateforme considère que l'intervalle précédent est terminé et qu'un nouvel intervalle commence. Par conséquent, le graphe est divisé en segments indépendants au lieu d'être rendu comme une ligne ininterrompue.
Ce comportement est intentionnel et s'applique indépendamment du fait que les valeurs du capteur avant et après la coupure de communication semblent cohérentes. La continuité du graphe est déterminée par l'intervalle de transmission plutôt que par la similarité des valeurs mesurées.
Par conséquent, les relevés individuels des capteurs continuent d'être stockés, traités et inclus dans les rapports, mais ils ne sont pas reliés visuellement lorsqu'ils appartiennent à différents intervalles de continuité.
#### Pourquoi la plateforme ne relie-t-elle pas les segments ?
L'objectif principal du moteur de rapports est de ne représenter que les informations qui ont réellement été transmises par l'appareil.
Si la plateforme reliait automatiquement deux points séparés par une longue coupure de communication, elle supposerait implicitement ce qui s'est produit pendant la période où aucune donnée n'a été reçue. Comme la plateforme ne dispose d'aucune information décrivant le comportement du capteur pendant cet intervalle, toute ligne reliant ces points représenterait une estimation plutôt que des données réellement enregistrées.
Pendant une coupure de communication, de nombreuses situations ont pu se produire.
* La valeur du capteur a pu rester totalement stable pendant toute la lacune de rapport.
* La valeur du capteur a pu augmenter progressivement au fil du temps.
* La valeur du capteur a pu diminuer progressivement pendant l'intervalle.
* Un événement soudain, tel qu'un ravitaillement ou un vol de carburant, a pu se produire mais n'a jamais été signalé en raison de l'absence de données.
* L'appareil lui-même a pu être hors ligne ou temporairement arrêté de transmettre des données pendant cette période.
Cette conception garantit que chaque ligne affichée dans le rapport représente une séquence de mesures réelles au lieu d'hypothèses. Bien que cette approche puisse produire des interruptions visuelles dans le graphe, elle préserve l'intégrité des données et empêche les utilisateurs de tirer des conclusions fondées sur des informations qui n'ont jamais été transmises par l'appareil.
### Réduire les coupures de communication
Dans la plupart des situations, les intervalles discontinus proviennent de la configuration de l'appareil plutôt que du moteur de rapports lui-même.
Le premier aspect à examiner est la stratégie de transmission des capteurs. De nombreux appareils de suivi sont configurés pour transmettre les informations des capteurs uniquement lorsqu'un changement est détecté, au lieu d'envoyer des mises à jour périodiques. Bien que ce comportement réduise le trafic réseau et la consommation de bande passante, il produit naturellement de longues périodes sans relevés de capteurs chaque fois que la valeur mesurée reste inchangée.
Un autre facteur important est la fréquence de transmission de l'appareil. Augmenter la fréquence de transmission conduit généralement à des ensembles de données plus continus et donc à une visualisation des rapports plus fluide.
La gestion de l'alimentation doit également être prise en compte. Selon la configuration de l'appareil, celui-ci peut entrer en mode Sleep, Deep Sleep ou dans un autre mode d'économie d'énergie lorsque le Contact est coupé. Dans ces états, l'appareil peut continuer à communiquer avec le serveur au moyen de paquets de pulsation tout en suspendant temporairement les transmissions des capteurs. Bien que le serveur reconnaisse toujours l'appareil comme connecté, aucune nouvelle valeur de capteur n'est reçue, ce qui crée finalement de nouveaux intervalles de continuité.
Pour cette raison, le moyen le plus efficace de réduire les zones grises est de revoir la configuration de l'appareil, notamment :
* Fréquence de transmission des capteurs.
* Priorité de transmission des capteurs.
* Transmission basée sur les événements par rapport à la transmission périodique.
* Configuration de veille et de veille profonde.
* Source d'alimentation de l'appareil et comportement du Contact.
L'optimisation de ces paramètres permet à la plateforme de recevoir des relevés de capteurs plus fréquemment, ce qui se traduit par des intervalles continus plus longs et une représentation graphique plus complète, tout en préservant la précision et l'intégrité des données enregistré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/expert-center/fr/vehicle-telematics-technology/fuel-management/understanding-gray-zones-in-fuel-level-reports.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.