> 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 Detectar al estacionarse
La detección de estacionamiento combina la velocidad, el tiempo de inactividad y el estado de la ignición para marcar el final de los recorridos. Configure umbrales por dispositivo para una detección de parada precisa.
## Introducción
La función Detectar al estacionarse es una configuración clave que define recorridos, 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 la ignición o el estado del sensor de movimiento.
Antes de revisar reportes o alertas, asegúrese de que el dispositivo envíe datos consistentes y de que la configuración coincida con la operación real de la flota.
Configure esto desde **Detectar al estacionarse**. Afecta directamente a:
* Reporte de recorridos
* Reporte de paradas
* Tiempo de ralentí excesivo
* Paradas dentro o fuera de geocercas
* Reglas que dependen del movimiento o del estado de estacionamiento
La plataforma solo interpreta los datos que recibe. Una frecuencia de reporte baja, ruido de GPS, un estado de ignición incorrecto o datos de movimiento no confiables afectarán el resultado.
## Configuración principal
En **Detectar al estacionarse**, usted define cuándo la plataforma debe tratar una unidad como aparcada.
* **Tiempo mínimo de inactividad**: El tiempo mínimo que la unidad debe permanecer inactiva antes de que la plataforma la marque como aparcada. Si se configura en 5 minutos, la condición debe mantenerse durante los 5 minutos completos antes de que cambie el estado. Rango permitido: 1 a 1440 minutos.
* **Velocidad máxima de ralentí**: El umbral de velocidad usado para tratar la unidad como en ralentí. Si se configura en 3 km/h, la plataforma considera como ralentí las velocidades inferiores a 3 km/h. Si se configura en 0, la detección de velocidad en ralentí se desactiva.
* **Considerar el estado de la ignición**: Incluye el estado del motor en **Detectar al estacionarse**. Para que esto funcione correctamente, el sensor de ignición debe estar conectado físicamente y configurado en **Sensores y botones**. Si activa 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 de GPS causa movimiento falso, pero solo si los datos del sensor son confiables.
## Cómo funciona la lógica sin ignición o sin sensor de movimiento
Si estas opciones están desactivadas, la plataforma usa solo la velocidad y el tiempo:
1. La velocidad cae por debajo del **Velocidad máxima de ralentí**.
2. La plataforma comienza a contar el tiempo.
3. Si el **Tiempo mínimo de inactividad** se cumple, la unidad se marca como aparcada.
4. Si llega un paquete con velocidad superior al umbral, el conteo se reinicia.
Ejemplo:
Si la inactividad se configura 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 aparcada. Un solo paquete por encima del umbral reinicia el conteo.
## Cómo cambia la lógica al considerar la ignición
La velocidad por sí sola no siempre puede distinguir entre una parada operativa, el tráfico, la espera con el motor encendido o el final de un recorrido. La ignición agrega contexto y ayuda a separar estos escenarios.
Cuando esta opción está activada, la plataforma evalúa la velocidad, el tiempo y el estado del motor. Si el estado de ignición está invertido, faltante o intermitente, la detección puede ser incorrecta.
Ejemplo:
La unidad ha estado a 0 km/h durante varios minutos.
* **Ignición apagada** → la plataforma puede confirmar el estacionamiento con mayor certeza
* **Ignición encendida** → puede estar esperando con el motor encendido, lo cual puede activar reglas como tiempo de ralentí excesivo
* **Ignición configurada 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á activada, 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 de GPS crea pequeños desplazamientos de posición o velocidades bajas falsas. 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: recorridos fragmentados, paradas retrasadas o movimiento falso mientras la unidad está detenida. Valide el sensor antes de activarlo.
## Valores recomendados
Use estos valores como punto de partida para operaciones urbanas:
* **Tiempo mínimo de inactividad**: 3 a 5 minutos
* **Velocidad máxima de 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 breves, 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 reportes.
* 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 la detección correcta.
## Buenas prácticas
* **Configure primero la función Detectar al estacionarse**: Antes de revisar alertas como tiempo de ralentí excesivo o paradas en geocercas, valide que la detección básica funcione correctamente.
* **Valide la ignición antes de activarla**: El sensor debe existir en **Sensores y botones** y reportar valores correctos. De lo contrario, puede afectar los recorridos, las paradas y las alertas.
* **No active 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 recorridos 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 reportes reales**: Después de cambiar la configuración, revise los reportes del día de operación:
* Reporte de recorridos
* Reporte de paradas
* Reporte de estacionamiento, si aplica
* **Documente los cambios**: Registre el valor anterior, el nuevo valor, la fecha, el motivo y los dispositivos afectados. De lo contrario, después será difícil explicar cambios posteriores en los reportes.
Si ve recorridos 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 parece estar en movimiento**: El **Velocidad máxima de ralentí** puede ser demasiado bajo, o puede haber ruido de GPS. Si el dispositivo reporta entre 1 y 4 km/h mientras la unidad está detenida, aumente el umbral.
* **Aparecen demasiados recorridos cortos**: El **Tiempo mínimo de inactividad** es demasiado bajo. La plataforma cierra los recorridos por semáforos o pausas cortas. Aumente el tiempo y revise de nuevo.
* **La unidad parece aparcada aunque se mueve lentamente**: El **Velocidad máxima de ralentí** es demasiado alto. Si la unidad opera a baja velocidad y el umbral está por encima de ella, la plataforma la interpreta como en ralentí.
* **Tiempo de ralentí excesivo no se activa**: La alerta depende de que primero se confirme el estado de estacionamiento y de que el estado de ignición llegue correctamente. Si **Detectar al estacionarse** no funciona correctamente, la alerta no se activará aunque la ignición esté encendida. Revise **Detectar al estacionarse** primero, y luego la alerta.
* **Diferencia entre el ralentí de la plataforma y el ralentí del hardware**: El ralentí de la plataforma depende de la lógica de Navixy, la función Detectar al estacionarse y del estado de ignición recibido. El ralentí del hardware proviene de un evento generado directamente por el dispositivo.
* **El recorrido no se registra correctamente al usar el sensor de movimiento**: Si el sensor reporta datos incorrectos, el recorrido puede no delimitarse como se espera. Revise primero los datos del sensor.
* **Cambios de detección después de activar la ignición**: Antes de asumir que se trata de un problema de la plataforma, revise el estado de ignición que llega desde el dispositivo.
## Recomendación para evitar vacíos en la ruta
Revise primero estos elementos:
* Tiempo mínimo de inactividad
* Velocidad máxima de ralentí
* Frecuencia de reporte del dispositivo
* Velocidad reportada durante el período
* Calidad de la señal GPS
* Uso de GPS o LBS
* Estado de ignición, si aplica, y su configuración en **Sensores y botones**
* Sensor de movimiento, si aplica, 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 inconsistentes, el resultado reflejará esas condiciones.
## Nota final
**Detectar al estacionarse** no corrige los datos del dispositivo. Solo interpreta los datos entrantes en función de los valores configurados. Si la ignición o el sensor de movimiento están activados, esos datos también pasan a formar parte de la lógica.
Antes de ajustar reglas o reportes, asegúrese de que el dispositivo envíe suficientes datos consistentes 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 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/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 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.