> 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
### Introduction
La détection de stationnement est un paramètre essentiel qui définit les trajets, les arrêts, le ralenti et d'autres événements liés au mouvement pour une unité dans Navixy. La logique combine la vitesse, le temps d'inactivité minimal et, lorsqu'ils sont disponibles, des données supplémentaires telles que l'état du contact ou du capteur de mouvement.
Avant de consulter les rapports ou les alertes, assurez-vous que l'appareil envoie des données cohérentes et que la configuration correspond au fonctionnement réel de la flotte.
Configurez cela depuis **Détection de stationnement**. Cela affecte directement :
* Rapport de trajets
* Rapport des arrêts
* Ralenti excessif
* Arrêts à l'intérieur ou à l'extérieur des géofences
* 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 état de contact incorrect 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 une unité comme stationnée.
* **Détection d'inactivité minimale**: Le temps minimum pendant lequel l'unité doit rester inactive avant que la plateforme ne la considère comme stationnée. Si cette valeur est définie à 5 minutes, la condition doit être maintenue pendant les 5 minutes complètes avant que l'état ne change. Plage autorisée : de 1 à 1440 minutes.
* **Vitesse maximale au ralenti**: Le seuil de vitesse utilisé pour considérer l'unité comme inactive. Si cette valeur est définie à 3 km/h, la plateforme considère comme inactives les vitesses inférieures à 3 km/h. 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é sous **Capteurs et boutons**. 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 être utile lorsque le bruit GPS provoque de faux mouvements, mais uniquement 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 descend en dessous du **Vitesse maximale au ralenti**.
2. La plateforme commence à compter le temps.
3. Si le **Détection d'inactivité minimale** est atteint, l'unité est marquée comme stationnée.
4. Si un paquet arrive avec une vitesse supérieure au seuil, le compteur est réinitialisé.
Exemple :
Si l'inactivité est définie sur 5 minutes et la vitesse sur 3 km/h, la plateforme doit recevoir des données inférieures à 3 km/h pendant 5 minutes consécutives avant de marquer l'unité comme stationnée. Un seul paquet au-dessus du seuil réinitialise le compteur.
### Comment la logique change lorsqu'on prend en compte le contact
La vitesse seule ne permet pas toujours de distinguer un arrêt opérationnel, un embouteillage, une attente moteur allumé ou la fin d'un trajet. Le contact apporte 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é, manquant ou intermittent, la détection peut être incorrecte.
Exemple :
L'unité est restée à 0 km/h pendant plusieurs minutes.
* **Contact coupé** → la plateforme peut confirmer le stationnement avec plus de certitude
* **Contact mis** → il peut s'agir d'une attente moteur allumé, ce qui peut alimenter des règles telles que le ralenti excessif
* **Contact mal configuré** → la plateforme peut mal interpréter les deux cas
### Comment la logique change lorsqu'on prend en compte le capteur de mouvement
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'unité est arrêtée mais que le bruit GPS crée de petits déplacements de position ou de fausses faibles vitesses. Dans ce cas, le capteur peut confirmer que l'unité ne se déplace pas réellement.
Si le capteur renvoie des données incorrectes, l'effet peut être inverse : trajets fractionnés, arrêts retardés ou faux mouvements alors que l'unité est à l'arrêt. Validez le capteur avant de l'activer.
### Valeurs recommandées
Utilisez ces valeurs comme point de départ pour les opérations urbaines :
* **Détection d'inactivité minimale**: de 3 à 5 minutes
* **Vitesse maximale au ralenti**: de 3 à 6 km/h
Ce ne sont pas des valeurs universelles. Elles dépendent de l'opération et de ce que vous considérez comme un arrêt.
* Pour les opérations où les arrêts courts comptent, une durée plus faible peut être utilisée.
* Pour les opérations avec un trafic fréquent ou des trajets lents, utilisez une durée plus élevée afin de réduire le bruit dans les rapports.
* Validez le seuil de vitesse avec des données réelles. Si le GPS signale entre 1 et 4 km/h alors que l'unité est à l'arrêt, un seuil trop faible peut empêcher une détection correcte.
### Bonnes pratiques
* **Configurez d'abord la détection de stationnement**: Avant d'examiner des alertes telles que le ralenti excessif ou les arrêts dans les géofences, vérifiez que la détection de base fonctionne correctement.
* **Validez le contact avant de l'activer**: Le capteur doit exister sous **Capteurs et boutons** 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, une durée d'inactivité d'une minute n'est pas adaptée. Le temps minimum doit être supérieur à l'intervalle de remontée.
* **Validez avec de vrais rapports**: Après avoir modifié la configuration, consultez les rapports de la journée d'exploitation :
* Rapport de trajets
* Rapport des arrêts
* Rapport de stationnement, le cas échéant
* **Documentez les modifications**: Enregistrez 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 observez des trajets fractionnés, des arrêts fantômes ou des événements qui ne correspondent pas à l'exploitation, ajustez les valeurs et validez à nouveau.
### Cas courants
* **L'unité est à l'arrêt mais semble se déplacer**: Le **Vitesse maximale au ralenti** peut être trop faible, ou il peut y avoir du bruit GPS. Si l'appareil signale entre 1 et 4 km/h alors que l'unité est immobile, augmentez le seuil.
* **Trop de trajets courts apparaissent**: Le **Détection d'inactivité minimale** est trop faible. La plateforme clôt les trajets à cause des feux rouges ou de courtes pauses. Augmentez le temps et vérifiez à nouveau.
* **L'unité semble stationnée alors qu'elle se déplace lentement**: Le **Vitesse maximale au ralenti** est trop élevé. Si l'unité fonctionne à faible vitesse et que le seuil est supérieur à celle-ci, la plateforme l'interprète comme inactive.
* **Le 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, 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. Consultez 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, vérifiez l'état du contact envoyé par l'appareil.
### Recommandation pour éviter les lacunes de parcours
Vérifiez 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 sous **Capteurs et boutons**
* Capteur de mouvement, le cas échéant, et s'il signale 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 avec une faible fréquence, du bruit ou des valeurs incohérentes, le résultat reflétera ces conditions.
### Note finale
**Détection de stationnement** Navixy n'corrige pas les données de l'appareil. Elle les interprète uniquement en fonction des 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 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/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 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.