> 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/faq-and-troubleshooting/gps-devices/parking-detection-logic.md).
# Logique de détection de stationnement
La détection de stationnement combine la vitesse, le temps d'inactivité et l'état du contact pour marquer la fin des trajets. Configurez des seuils par appareil pour une détection précise des arrêts.
## Introduction
La détection de stationnement est un paramètre central qui définit les trajets, les arrêts, l’état au ralenti et d’autres événements liés au mouvement pour un objet dans Navixy. La logique combine la vitesse, le temps minimum d’inactivité et, lorsque c’est disponible, des données supplémentaires comme l’état du contact ou du capteur de mouvement.
Avant d’examiner les rapports ou les alertes, assurez-vous que l’appareil envoie des données cohérentes et que la configuration correspond à l’exploitation réelle de la flotte.
Configurez cela dans **Détection de stationnement**. Elle affecte directement :
* Rapport de trajet
* Rapport des arrêts
* Fonctionnement au ralenti excessif
* Arrêts à l’intérieur ou à l’extérieur des géozones
* Règles qui dépendent de l’état de mouvement ou de stationnement
La plateforme n’interprète que les données qu’elle reçoit. Une faible fréquence de remontée, du bruit GPS, un mauvais état du contact ou des données de mouvement peu fiables affecteront le résultat.
## Configuration principale
Dans **Détection de stationnement**, vous définissez quand la plateforme doit considérer un objet comme stationné.
* **Détection d’inactivité minimale**: Le temps minimum pendant lequel l’objet doit rester inactif avant que la plateforme le marque comme stationné. Si cette valeur est définie à 5 minutes, la condition doit être satisfaite pendant les 5 minutes complètes avant que l’état change. Plage autorisée : 1 à 1 440 minutes.
* **Vitesse maximale au ralenti**: Le seuil de vitesse utilisé pour considérer l’objet comme au ralenti. Si cette valeur est définie à 3 km/h, la plateforme considère les vitesses inférieures à 3 km/h comme au ralenti. Si cette valeur est définie à 0, la détection de la vitesse au ralenti est désactivée.
* **Prendre en compte l’état du contact**: Inclut l’état du moteur dans **Détection de stationnement**. Pour que cela fonctionne correctement, le capteur de contact doit être physiquement connecté et configuré dans **Boutons et capteurs**. Si vous activez cette option sans capteur valide, les résultats peuvent être incorrects.
* **Prendre en compte le capteur de mouvement**: Inclut le mouvement signalé par l’appareil en plus de la vitesse et du temps. Cela peut aider lorsque le bruit GPS provoque un faux mouvement, mais seulement si les données du capteur sont fiables.
## Comment la logique fonctionne sans contact ni capteur de mouvement
Si ces options sont désactivées, la plateforme utilise uniquement la vitesse et le temps :
1. La vitesse passe sous le **Vitesse maximale au ralenti**.
2. La plateforme commence à compter le temps.
3. Si le **Détection d’inactivité minimale** est atteint, l’objet est marqué comme stationné.
4. Si un paquet arrive avec une vitesse supérieure au seuil, le compteur se réinitialise.
Exemple :
Si l’inactivité est définie à 5 minutes et la vitesse à 3 km/h, la plateforme doit recevoir des données inférieures à 3 km/h pendant 5 minutes consécutives avant de marquer l’objet comme stationné. Un paquet au-dessus du seuil réinitialise le compteur.
## Comment la logique change lorsque le contact est pris en compte
La vitesse seule ne peut pas toujours distinguer un arrêt opérationnel, un embouteillage, une attente moteur tournant ou la fin d’un trajet. Le contact ajoute du contexte et aide à séparer ces scénarios.
Lorsque cette option est activée, la plateforme évalue la vitesse, le temps et l’état du moteur. Si l’état du contact est inversé, absent ou intermittent, la détection peut être erronée.
Exemple :
L’objet est resté à 0 km/h pendant plusieurs minutes.
* **Contact coupé** → la plateforme peut confirmer le stationnement avec une plus grande certitude
* **Contact mis** → il peut s’agir d’une attente moteur tournant, ce qui peut alimenter des règles telles que le fonctionnement au ralenti excessif
* **Contact mal configuré** → la plateforme peut mal interpréter les deux cas
## Comment la logique change lorsque le capteur de mouvement est pris en compte
Lorsque cette option est activée, la plateforme utilise l’état de mouvement signalé par l’appareil pour compléter les données de vitesse et de temps.
Cela aide lorsque l’objet est à l’arrêt mais que le bruit GPS crée de petits décalages de position ou de fausses faibles vitesses. Dans ce cas, le capteur peut confirmer que l’objet ne bouge pas réellement.
Si le capteur renvoie des données incorrectes, l’effet peut être inverse : trajets scindés, arrêts retardés ou faux mouvement alors que l’objet est à l’arrêt. Validez le capteur avant de l’activer.
## Valeurs recommandées
Utilisez ces valeurs comme point de départ pour des opérations urbaines :
* **Détection d’inactivité minimale** : 3 à 5 minutes
* **Vitesse maximale au ralenti** : 3 à 6 km/h
Ce ne sont pas des valeurs universelles. Elles dépendent de l’exploitation et de ce que vous considérez comme un arrêt.
* Pour les opérations où les arrêts courts sont importants, une durée plus courte peut être utilisée.
* Pour les opérations avec des embouteillages fréquents ou des itinéraires lents, utilisez une durée plus longue pour réduire le bruit dans les rapports.
* Validez le seuil de vitesse avec des données réelles. Si le GPS indique entre 1 et 4 km/h alors que l’objet est à l’arrêt, un seuil trop bas peut empêcher une détection correcte.
## Bonnes pratiques
* **Configurez d’abord Détection de stationnement**: Avant d’examiner des alertes telles que le fonctionnement au ralenti excessif ou les arrêts dans les géozones, validez que la détection de base fonctionne correctement.
* **Validez le contact avant de l’activer**: Le capteur doit exister dans **Boutons et capteurs** et renvoyer des valeurs correctes. Sinon, cela peut affecter les trajets, les arrêts et les alertes.
* **N’activez pas le capteur de mouvement sans valider les données**: Confirmez d’abord que l’appareil envoie correctement cet état. Sinon, cela peut affecter l’enregistrement des trajets et la détection des arrêts.
* **Vérifiez la fréquence de remontée**: Si l’appareil envoie des données toutes les 60 secondes, un temps d’inactivité d’1 minute n’est pas adapté. Le temps minimum doit être supérieur à l’intervalle de remontée.
* **Validez avec des rapports réels**: Après avoir modifié la configuration, consultez les rapports de la journée d’exploitation :
* Rapport de trajet
* Rapport des arrêts
* Rapport de stationnement, le cas échéant
* **Documentez les changements**: Notez la valeur précédente, la nouvelle valeur, la date, la raison et les appareils concernés. Sinon, il devient difficile d’expliquer plus tard les changements dans les rapports.
Si vous voyez des trajets scindés, des arrêts fantômes ou des événements qui ne correspondent pas à l’exploitation, ajustez les valeurs et validez de nouveau.
## Cas courants
* **L’objet est à l’arrêt mais semble bouger** : Le **Vitesse maximale au ralenti** peut être trop faible, ou il peut y avoir du bruit GPS. Si l’appareil indique entre 1 et 4 km/h alors que l’objet est immobile, augmentez le seuil.
* **Trop de courts trajets apparaissent** : Le **Détection d’inactivité minimale** est trop faible. La plateforme clôt les trajets à cause des feux rouges ou des courtes pauses. Augmentez la durée et vérifiez de nouveau.
* **L’objet semble stationné alors qu’il se déplace lentement** : Le **Vitesse maximale au ralenti** est trop élevé. Si l’objet fonctionne à faible vitesse et que le seuil est supérieur, la plateforme l’interprète comme au ralenti.
* **Fonctionnement au ralenti excessif ne se déclenche pas** : L’alerte dépend du fait que l’état stationné soit d’abord confirmé et que l’état du contact arrive correctement. Si **Détection de stationnement** ne fonctionne pas correctement, l’alerte ne se déclenchera pas même si le contact est mis. Vérifiez **Détection de stationnement** d’abord le contact, puis l’alerte.
* **Différence entre le ralenti de la plateforme et le ralenti matériel** : Le ralenti de la plateforme dépend de la logique Navixy, de la détection de stationnement et de l’état du contact reçu. Le ralenti matériel provient d’un événement généré directement par l’appareil.
* **Le trajet n’est pas enregistré correctement lors de l’utilisation du capteur de mouvement** : Si le capteur renvoie des données incorrectes, le trajet peut ne pas être délimité comme prévu. Examinez d’abord les données du capteur.
* **La détection change après l’activation du contact** : Avant de supposer qu’il s’agit d’un problème de plateforme, examinez l’état du contact envoyé par l’appareil.
## Recommandation pour éviter les lacunes d’itinéraire
Examinez d’abord ces éléments :
* Détection d’inactivité minimale
* Vitesse maximale au ralenti
* Fréquence de remontée de l’appareil
* Vitesse signalée pendant la période
* Qualité du signal GPS
* Utilisation du GPS ou du LBS
* État du contact, le cas échéant, et sa configuration dans **Boutons et capteurs**
* Capteur de mouvement, le cas échéant, et s’il remonte correctement
* Règles de la plateforme et du matériel actives en même temps
La plateforme applique la logique configurée aux données qu’elle reçoit. Si les paquets arrivent à faible fréquence, avec du bruit ou des valeurs incohérentes, le résultat reflétera ces conditions.
## Note finale
**Détection de stationnement** ne corrige pas les données de l’appareil. Elle interprète seulement les données entrantes selon les valeurs configurées. Si le contact ou le capteur de mouvement est activé, ces données font également partie de la logique.
Avant d’ajuster les règles ou les rapports, assurez-vous que l’appareil envoie suffisamment de données cohérentes pour correspondre à l’exploitation réelle.
---
# 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/faq-and-troubleshooting/gps-devices/parking-detection-logic.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.