> 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/pt-br/faq-and-troubleshooting/gps-devices/parking-detection-logic.md).
# Lógica de Detecção de estacionamento
A Detecção de estacionamento combina velocidade, tempo de inatividade e status da ignição para marcar os fins de Trajeto. Configure limites por dispositivo para uma detecção precisa de paradas.
## Introdução
A Detecção de estacionamento é uma configuração essencial que define trajetos, paradas, motor ocioso e outros eventos relacionados a movimento para uma unidade no Navixy. A lógica combina velocidade, tempo mínimo de inatividade e, quando disponíveis, dados adicionais como ignição ou status do sensor de movimento.
Antes de revisar relatórios ou alertas, certifique-se de que o dispositivo envia dados consistentes e de que a configuração corresponde à operação real da frota.
Configure isso em **Detecção de estacionamento**. Ela afeta diretamente:
* Relatório de trajeto
* Relatório de paradas
* Em marcha lenta excessiva
* Paradas dentro ou fora de geocercas
* Regras que dependem de movimento ou do status de estacionamento
A plataforma interpreta apenas os dados que recebe. Baixa frequência de envio, ruído de GPS, status de ignição incorreto ou dados de movimento não confiáveis afetarão o resultado.
## Configuração principal
Em **Detecção de estacionamento**, você define quando a plataforma deve tratar uma unidade como estacionada.
* **Detecção mínima de inatividade**: O tempo mínimo que a unidade deve permanecer ociosa antes que a plataforma a marque como estacionada. Se isso for definido como 5 minutos, a condição deve se manter pelos 5 minutos completos antes que o status mude. Intervalo permitido: 1 a 1.440 minutos.
* **Velocidade ociosa máxima**: O limite de velocidade usado para tratar a unidade como ociosa. Se isso for definido como 3 km/h, a plataforma trata velocidades abaixo de 3 km/h como ociosas. Se isso for definido como 0, a detecção de velocidade ociosa é desativada.
* **Considerar o status da ignição**: Inclui o status do motor em **Detecção de estacionamento**. Para isso funcionar corretamente, o sensor de ignição deve estar fisicamente conectado e configurado em **Sensores e botões**. Se você ativar isso sem um sensor válido, os resultados podem estar incorretos.
* **Considerar o sensor de movimento**: Inclui o movimento reportado pelo dispositivo além da velocidade e do tempo. Isso pode ajudar quando o ruído de GPS causa movimento falso, mas somente se os dados do sensor forem confiáveis.
## Como a lógica funciona sem ignição ou sensor de movimento
Se essas opções estiverem desativadas, a plataforma usa apenas velocidade e tempo:
1. A velocidade cai abaixo do **Velocidade ociosa máxima**.
2. A plataforma começa a contar o tempo.
3. Se o **Detecção mínima de inatividade** for atendido, a unidade é marcada como estacionada.
4. Se um pacote chegar com velocidade acima do limite, a contagem é reiniciada.
Exemplo:
Se a inatividade estiver definida como 5 minutos e a velocidade como 3 km/h, a plataforma deve receber dados abaixo de 3 km/h por 5 minutos contínuos antes de marcar a unidade como estacionada. Um pacote acima do limite reinicia a contagem.
## Como a lógica muda ao considerar a ignição
A velocidade por si só nem sempre consegue distinguir entre uma parada operacional, trânsito, espera com o motor ligado ou o fim de um trajeto. A ignição adiciona contexto e ajuda a separar esses cenários.
Quando essa opção está ativada, a plataforma avalia velocidade, tempo e status do motor. Se o status da ignição estiver invertido, ausente ou intermitente, a detecção pode estar errada.
Exemplo:
A unidade esteve a 0 km/h por vários minutos.
* **Ignição desligada** → a plataforma pode confirmar o estacionamento com mais certeza
* **Ignição ligada** → ela pode estar em espera com o motor ligado, o que pode alimentar regras como Em marcha lenta excessiva
* **Ignição configurada incorretamente** → a plataforma pode interpretar incorretamente ambos os casos
## Como a lógica muda ao considerar o sensor de movimento
Quando essa opção está ativada, a plataforma usa o status de movimento reportado pelo dispositivo para complementar os dados de velocidade e tempo.
Isso ajuda quando a unidade está parada, mas o ruído de GPS cria pequenos deslocamentos de posição ou falsas velocidades baixas. Nesse caso, o sensor pode confirmar que a unidade não está realmente em movimento.
Se o sensor reportar dados incorretos, o efeito pode ser o oposto: trajetos divididos, paradas atrasadas ou movimento falso enquanto a unidade está estacionária. Valide o sensor antes de ativá-lo.
## Valores recomendados
Use esses valores como ponto de partida para operações urbanas:
* **Detecção mínima de inatividade**: 3 a 5 minutos
* **Velocidade ociosa máxima**: 3 a 6 km/h
Esses não são valores universais. Eles dependem da operação e do que você considera uma parada.
* Para operações em que paradas curtas importam, pode ser usado um tempo menor.
* Para operações com tráfego frequente ou rotas lentas, use um tempo maior para reduzir ruído nos relatórios.
* Valide o limite de velocidade com dados reais. Se o GPS reportar entre 1 e 4 km/h enquanto a unidade estiver parada, um limite muito baixo pode impedir a detecção correta.
## Boas práticas
* **Configure a Detecção de estacionamento primeiro**: Antes de revisar alertas como Em marcha lenta excessiva ou paradas em geocercas, valide se a detecção base funciona corretamente.
* **Valide a ignição antes de ativá-la**: O sensor deve existir em **Sensores e botões** e reportar valores corretos. Caso contrário, isso pode afetar trajetos, paradas e alertas.
* **Não ative o sensor de movimento sem validar os dados**: Primeiro, confirme se o dispositivo envia esse status corretamente. Caso contrário, isso pode afetar o registro de trajetos e a detecção de paradas.
* **Revise a frequência de envio**: Se o dispositivo enviar dados a cada 60 segundos, um tempo de inatividade de 1 minuto não é adequado. O tempo mínimo deve ser maior que o intervalo de envio.
* **Valide com relatórios reais**: Depois de alterar a configuração, revise os relatórios do dia de operação:
* Relatório de trajeto
* Relatório de paradas
* Relatório de estacionamento, se aplicável
* **Documente as alterações**: Registre o valor anterior, o novo valor, a data, o motivo e os dispositivos afetados. Caso contrário, fica difícil explicar mudanças posteriores nos relatórios.
Se você vir trajetos divididos, paradas fantasmas ou eventos que não correspondem à operação, ajuste os valores e valide novamente.
## Casos comuns
* **A unidade está parada, mas parece estar em movimento**: O **Velocidade ociosa máxima** pode estar muito baixo, ou pode haver ruído de GPS. Se o dispositivo reportar entre 1 e 4 km/h enquanto a unidade estiver estacionária, aumente o limite.
* **Aparecem muitos trajetos curtos**: O **Detecção mínima de inatividade** está muito baixo. A plataforma encerra trajetos por causa de semáforos ou pausas curtas. Aumente o tempo e revise novamente.
* **A unidade parece estacionada mesmo estando em movimento lento**: O **Velocidade ociosa máxima** está muito alto. Se a unidade opera em baixa velocidade e o limite estiver acima disso, a plataforma a interpreta como ociosa.
* **Em marcha lenta excessiva não é acionado**: O alerta depende de que o status de estacionamento seja confirmado primeiro e de que o status da ignição chegue corretamente. Se **Detecção de estacionamento** não estiver funcionando corretamente, o alerta não será acionado mesmo se a ignição estiver ligada. Revise **Detecção de estacionamento** primeiro, depois o alerta.
* **Diferença entre motor ocioso da plataforma e motor ocioso do hardware**: O motor ocioso da plataforma depende da lógica da Navixy, da detecção de estacionamento e do status da ignição recebido. O motor ocioso do hardware vem de um evento gerado diretamente pelo dispositivo.
* **O trajeto não é registrado corretamente ao usar o sensor de movimento**: Se o sensor reportar dados incorretos, o trajeto pode não ser delimitado como esperado. Revise os dados do sensor primeiro.
* **A detecção muda após ativar a ignição**: Antes de assumir que isso é um problema da plataforma, revise o status da ignição que chega do dispositivo.
## Recomendação para evitar lacunas na rota
Revise estes itens primeiro:
* Detecção mínima de inatividade
* Velocidade ociosa máxima
* Frequência de envio do dispositivo
* Velocidade reportada durante o período
* Qualidade do sinal de GPS
* Uso de GPS ou LBS
* Status da ignição, se aplicável, e sua configuração em **Sensores e botões**
* Sensor de movimento, se aplicável, e se reporta corretamente
* Regras da plataforma e do hardware ativas ao mesmo tempo
A plataforma aplica a lógica configurada aos dados que recebe. Se os pacotes chegarem com baixa frequência, ruído ou valores inconsistentes, o resultado refletirá essas condições.
## Observação final
**Detecção de estacionamento** não corrige os dados do dispositivo. Ela apenas interpreta os dados recebidos com base nos valores configurados. Se a ignição ou o sensor de movimento estiver ativado, esses dados também passam a fazer parte da lógica.
Antes de ajustar regras ou relatórios, certifique-se de que o dispositivo envia dados consistentes o suficiente para corresponder à operação 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/pt-br/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.