> 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/es/faq-and-troubleshooting/gps-devices/parking-detection-logic.md).
# Lógica de detección de estacionamiento
### Introducción
La detección de estacionamiento es un ajuste central que define viajes, paradas, ralentí y otros eventos relacionados con el movimiento para una unidad en Navixy. La lógica combina la velocidad, el tiempo mínimo de inactividad y, cuando está disponible, datos adicionales como el estado del encendido o del sensor de movimiento.
Antes de revisar informes o alertas, asegúrese de que el dispositivo envíe datos coherentes y de que la configuración coincida con la operación real de la flota.
Configure esto desde **Detección de estacionamiento**. Esto afecta directamente a:
* Informe de viajes
* Informe de paradas
* Ralentí excesivo
* Paradas dentro o fuera de geocercas
* Reglas que dependen del estado de movimiento o estacionamiento
La plataforma solo interpreta los datos que recibe. La baja frecuencia de reporte, el ruido GPS, un estado de encendido incorrecto o datos de movimiento no confiables afectarán el resultado.
### Configuración principal
En **Detección de estacionamiento**, usted define cuándo la plataforma debe tratar una unidad como estacionada.
* **Detección de inactividad mínima**: El tiempo mínimo que la unidad debe permanecer inactiva antes de que la plataforma la marque como estacionada. Si se establece en 5 minutos, la condición debe mantenerse durante los 5 minutos completos antes de que cambie el estado. Rango permitido: de 1 a 1440 minutos.
* **Velocidad máxima en ralentí**: El umbral de velocidad usado para tratar la unidad como inactiva. Si se establece en 3 km/h, la plataforma trata como inactivos los valores inferiores a 3 km/h. Si se establece en 0, la detección de velocidad en ralentí se deshabilita.
* **Considerar el estado del encendido**: Incluye el estado del motor en **Detección de estacionamiento**. Para que esto funcione correctamente, el sensor de encendido debe estar físicamente conectado y configurado en **Sensores y botones**. Si habilita esto sin un sensor válido, los resultados pueden ser incorrectos.
* **Considerar el sensor de movimiento**: Incluye el movimiento reportado por el dispositivo además de la velocidad y el tiempo. Esto puede ayudar cuando el ruido GPS provoca movimiento falso, pero solo si los datos del sensor son confiables.
### Cómo funciona la lógica sin encendido ni sensor de movimiento
Si estas opciones están deshabilitadas, la plataforma usa solo la velocidad y el tiempo:
1. La velocidad cae por debajo del **Velocidad máxima en ralentí**.
2. La plataforma comienza a contar el tiempo.
3. Si se cumple el **Detección de inactividad mínima** la unidad se marca como estacionada.
4. Si llega un paquete con una velocidad superior al umbral, el conteo se reinicia.
Ejemplo:
Si la inactividad se establece en 5 minutos y la velocidad en 3 km/h, la plataforma debe recibir datos por debajo de 3 km/h durante 5 minutos continuos antes de marcar la unidad como estacionada. Un paquete por encima del umbral reinicia el conteo.
### Cómo cambia la lógica al considerar el encendido
La velocidad por sí sola no siempre puede distinguir entre una parada operativa, tráfico, espera con el motor encendido o el final de un viaje. El encendido añade contexto y ayuda a separar estos escenarios.
Cuando esta opción está habilitada, la plataforma evalúa la velocidad, el tiempo y el estado del motor. Si el estado del encendido está invertido, ausente o es intermitente, la detección puede ser incorrecta.
Ejemplo:
La unidad ha estado a 0 km/h durante varios minutos.
* **Encendido apagado** → la plataforma puede confirmar el estacionamiento con mayor certeza
* **Encendido encendido** → puede estar esperando con el motor en marcha, lo que puede alimentar reglas como el ralentí excesivo
* **Encendido configurado incorrectamente** → la plataforma puede interpretar mal ambos casos
### Cómo cambia la lógica al considerar el sensor de movimiento
Cuando esta opción está habilitada, la plataforma usa el estado de movimiento reportado por el dispositivo para complementar los datos de velocidad y tiempo.
Esto ayuda cuando la unidad está detenida pero el ruido GPS crea pequeños desplazamientos de posición o falsas velocidades bajas. En ese caso, el sensor puede confirmar que la unidad realmente no se está moviendo.
Si el sensor reporta datos incorrectos, el efecto puede ser el contrario: viajes divididos, paradas tardías o movimiento falso mientras la unidad está detenida. Valide el sensor antes de habilitarlo.
### Valores recomendados
Use estos valores como punto de partida para operaciones urbanas:
* **Detección de inactividad mínima**: 3 a 5 minutos
* **Velocidad máxima en ralentí**: 3 a 6 km/h
Estos no son valores universales. Dependen de la operación y de lo que usted considere una parada.
* Para operaciones en las que importan las paradas cortas, se puede usar un tiempo menor.
* Para operaciones con tráfico frecuente o rutas lentas, use un tiempo mayor para reducir el ruido en los informes.
* Valide el umbral de velocidad con datos reales. Si el GPS reporta entre 1 y 4 km/h mientras la unidad está detenida, un umbral demasiado bajo puede impedir una detección correcta.
### Buenas prácticas
* **Configure primero la Detección de estacionamiento**: Antes de revisar alertas como ralentí excesivo o paradas en geocercas, valide que la detección base funcione correctamente.
* **Valide el encendido antes de habilitarlo**: El sensor debe existir en **Sensores y botones** y reportar valores correctos. De lo contrario, puede afectar los viajes, las paradas y las alertas.
* **No habilite el sensor de movimiento sin validar los datos**: Primero confirme que el dispositivo envía este estado correctamente. De lo contrario, puede afectar el registro de viajes y la detección de paradas.
* **Revise la frecuencia de reporte**: Si el dispositivo envía datos cada 60 segundos, un tiempo de inactividad de 1 minuto no es adecuado. El tiempo mínimo debe ser mayor que el intervalo de reporte.
* **Valide con informes reales**: Después de cambiar la configuración, revise los informes del día operativo:
* Informe de viajes
* Informe de paradas
* Informe de estacionamiento, si corresponde
* **Documente los cambios**: Registre el valor anterior, el nuevo valor, la fecha, el motivo y los dispositivos afectados. De lo contrario, luego será difícil explicar los cambios en los informes.
Si observa viajes divididos, paradas fantasma o eventos que no coinciden con la operación, ajuste los valores y valide de nuevo.
### Casos comunes
* **La unidad está detenida pero aparece en movimiento**: El **Velocidad máxima en ralentí** puede ser demasiado bajo, o puede haber ruido GPS. Si el dispositivo reporta entre 1 y 4 km/h mientras la unidad está detenida, aumente el umbral.
* **Aparecen demasiados viajes cortos**: El **Detección de inactividad mínima** es demasiado bajo. La plataforma cierra los viajes debido a semáforos o pausas breves. Aumente el tiempo y revise de nuevo.
* **La unidad aparece estacionada aunque se mueve lentamente**: El **Velocidad máxima en ralentí** es demasiado alto. Si la unidad opera a baja velocidad y el umbral está por encima de ella, la plataforma la interpreta como inactiva.
* **El ralentí excesivo no se activa**: La alerta depende de que primero se confirme el estado de estacionado y de que el estado del encendido llegue correctamente. Si **Detección de estacionamiento** no funciona correctamente, la alerta no se activará aunque el encendido esté encendido. Revise **Detección de estacionamiento** primero y luego la alerta.
* **Diferencia entre ralentí de la plataforma y ralentí del hardware**: El ralentí de la plataforma depende de la lógica de Navixy, la detección de estacionamiento y el estado de encendido recibido. El ralentí del hardware proviene de un evento generado directamente por el dispositivo.
* **El viaje no se registra correctamente al usar el sensor de movimiento**: Si el sensor reporta datos incorrectos, es posible que el viaje no se delimite como se espera. Revise primero los datos del sensor.
* **La detección cambia después de habilitar el encendido**: Antes de asumir que se trata de un problema de la plataforma, revise el estado del encendido que llega desde el dispositivo.
### Recomendación para evitar huecos en la ruta
Revise primero estos elementos:
* Detección de inactividad mínima
* Velocidad máxima en ralentí
* Frecuencia de reporte del dispositivo
* Velocidad reportada durante el período
* Calidad de la señal GPS
* Uso de GPS o LBS
* Estado del encendido, si corresponde, y su configuración en **Sensores y botones**
* Sensor de movimiento, si corresponde, y si reporta correctamente
* Reglas de la plataforma y del hardware activas al mismo tiempo
La plataforma aplica la lógica configurada a los datos que recibe. Si los paquetes llegan con baja frecuencia, ruido o valores incoherentes, el resultado reflejará esas condiciones.
### Nota final
**Detección de estacionamiento** no corrige los datos del dispositivo. Solo interpreta los datos entrantes según los valores configurados. Si el encendido o el sensor de movimiento están habilitados, esos datos también pasan a formar parte de la lógica.
Antes de ajustar reglas o informes, asegúrese de que el dispositivo envíe suficientes datos coherentes para coincidir con la operación real.
---
# 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/es/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.