> 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
## Introdução
A detecção de estacionamento é uma configuração central que define trajetos, paradas, motor ocioso e outros eventos relacionados ao movimento para uma unidade no Navixy. A lógica combina velocidade, tempo mínimo de inatividade e, quando disponível, dados adicionais como status da ignição ou do sensor de movimento.
Antes de revisar relatórios ou alertas, verifique se o dispositivo envia dados consistentes e se a configuração corresponde à operação real da frota.
Configure isto 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 do status de movimento ou de estacionamento
A plataforma apenas interpreta 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 inativa antes que a plataforma a marque como estacionada. Se isso estiver definido para 5 minutos, a condição deve se manter pelos 5 minutos completos antes que o status mude. Faixa permitida: de 1 a 1440 minutos.
* **Velocidade máxima em marcha lenta**: O limite de velocidade usado para tratar a unidade como inativa. Se isso estiver definido para 3 km/h, a plataforma trata velocidades abaixo de 3 km/h como inativas. Se isso estiver definido para 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 apenas se os dados do sensor forem confiáveis.
## Como a lógica funciona sem ignição ou sensor de movimento
Se estas opções estiverem desativadas, a plataforma usa apenas velocidade e tempo:
1. A velocidade cai abaixo da **Velocidade máxima em marcha lenta**.
2. A plataforma começa a contar o tempo.
3. Se a **Detecção mínima de inatividade** for atendida, a unidade é marcada como estacionada.
4. Se um pacote chegar com velocidade acima do limite, a contagem é reiniciada.
Exemplo:
Se a inatividade estiver definida para 5 minutos e a velocidade estiver definida para 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 sozinha nem sempre consegue distinguir entre uma parada operacional, trânsito, espera com o motor ligado ou o fim de um trajeto. A ignição acrescenta contexto e ajuda a separar esses cenários.
Quando esta 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 está há vários minutos a 0 km/h.
* **Ignição desligada** → a plataforma pode confirmar o estacionamento com maior certeza
* **Ignição ligada** → ela pode estar aguardando com o motor ligado, o que pode alimentar regras como em marcha lenta excessiva
* **Ignição configurada incorretamente** → a plataforma pode interpretar mal ambos os casos
## Como a lógica muda ao considerar o sensor de movimento
Quando esta 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 estes valores como ponto de partida para operações urbanas:
* **Detecção mínima de inatividade**: de 3 a 5 minutos
* **Velocidade máxima em marcha lenta**: de 3 a 6 km/h
Estes 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, um tempo menor pode ser usado.
* Para operações com tráfego frequente ou rotas lentas, use um tempo maior para reduzir o 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 está 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 básica 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, pode afetar viagens, paradas e alertas.
* **Não ative o sensor de movimento sem validar os dados**: Primeiro, confirme que o dispositivo envia este 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 envia 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 operacional:
* 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ê ver 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**: A **Velocidade máxima em marcha lenta** pode estar muito baixa, ou pode haver ruído de GPS. Se o dispositivo reportar entre 1 e 4 km/h enquanto a unidade está estacionária, aumente o limite.
* **Aparecem muitas viagens curtas**: A **Detecção mínima de inatividade** está muito baixo. A plataforma encerra trajetos por causa de semáforos ou pequenas pausas. Aumente o tempo e revise novamente.
* **A unidade parece estacionada, embora esteja se movendo lentamente**: A **Velocidade máxima em marcha lenta** está muito alto. Se a unidade opera em baixa velocidade e o limite fica acima dela, a plataforma a interpreta como ociosa.
* **Em marcha lenta excessiva não é acionado**: O alerta depende de o status de estacionado ser confirmado primeiro e de o status da ignição chegar 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 o motor ocioso da plataforma e o motor ocioso do hardware**: O motor ocioso da plataforma depende da lógica da Navixy, da detecção de estacionamento e do status de 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 primeiro os dados do sensor.
* **A detecção muda depois de 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 primeiro estes itens:
* Detecção mínima de inatividade
* Velocidade máxima em marcha lenta
* 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 ele 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.
## Nota final
**Detecção de estacionamento** A plataforma 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, verifique se o dispositivo envia dados consistentes suficientes 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 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/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 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.