> 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/ru/faq-and-troubleshooting/gps-devices/parking-detection-logic.md).

# Логика обнаружения парковки

### Введение

Определение парковки — это основная настройка, которая определяет поездки, остановки, холостой ход и другие события, связанные с движением, для объекта в Navixy. Логика объединяет скорость, минимальное время бездействия и, при наличии, дополнительные данные, такие как зажигание или состояние датчика движения.

Перед просмотром отчетов или оповещений убедитесь, что устройство отправляет согласованные данные, а конфигурация соответствует реальной работе автопарка.

<img src="/files/7edaeba6bdfc0cd000fee0cd24ba660b47bb0c56" alt="" height="336" width="624">

Настройте это в **Определение парковки**. Это напрямую влияет на:

* Отчет по поездкам
* Отчет по остановкам
* Чрезмерный холостой ход
* Остановки внутри или вне геозон
* Правила, зависящие от движения или статуса парковки

<img src="/files/41fb1e4d5839f65dc111c93b752c70110a4135aa" alt="" height="519" width="624">

Платформа интерпретирует только получаемые данные. Низкая частота передачи, шум GPS, некорректный статус зажигания или ненадежные данные датчика движения повлияют на результат.

### Основная конфигурация

В **Определение парковки**, вы определяете, когда платформа должна считать объект припаркованным.

<img src="/files/4c3a81c44a255d205ee9e1e4148355e2345cd71b" alt="" height="404" width="624">

* **Минимальное обнаружение бездействия**: Минимальное время, в течение которого объект должен оставаться без движения, прежде чем платформа отметит его как припаркованный. Если установлено 5 минут, условие должно выполняться в течение полных 5 минут, прежде чем статус изменится. Допустимый диапазон: от 1 до 1440 минут.
* **Максимальная скорость простоя**: Порог скорости, используемый для того, чтобы считать объект находящимся в простое. Если установлено 3 км/ч, платформа будет считать скорости ниже 3 км/ч простоями. Если установлено 0, определение скорости простоя отключается.
* **Учитывать статус зажигания**: Включает состояние двигателя в **Определение парковки**. Чтобы это работало корректно, датчик зажигания должен быть физически подключен и настроен в разделе **Датчики и кнопки**. Если включить эту опцию без валидного датчика, результаты могут быть некорректными.
* **Учитывать датчик движения**: Добавляет к скорости и времени информацию о движении, получаемую от устройства. Это может помочь, когда шум GPS вызывает ложное движение, но только если данные датчика надежны.

### Как работает логика без зажигания или датчика движения

<img src="/files/c7728e9e1b4fab3cc94941e576030ae10f88b137" alt="" height="405" width="624">

Если эти опции отключены, платформа использует только скорость и время:

1. Скорость падает ниже **Максимальная скорость простоя**.
2. Платформа начинает отсчет времени.
3. Если **Минимальное обнаружение бездействия** выполняется, объект отмечается как припаркованный.
4. Если поступает пакет со скоростью выше порога, отсчет сбрасывается.

Пример:

Если бездействие установлено на 5 минут, а скорость — на 3 км/ч, платформа должна получить данные со скоростью ниже 3 км/ч в течение 5 непрерывных минут, прежде чем отметит объект как припаркованный. Один пакет выше порога сбрасывает отсчет.

### Как меняется логика при учете зажигания

Одной только скорости не всегда достаточно, чтобы отличить рабочую остановку, пробку, ожидание с работающим двигателем или окончание поездки. Зажигание добавляет контекст и помогает разделить эти сценарии.

Когда эта опция включена, платформа оценивает скорость, время и состояние двигателя. Если статус зажигания инвертирован, отсутствует или передается с перебоями, определение может быть неверным.

Пример:

Объект находился на скорости 0 км/ч в течение нескольких минут.

* **Зажигание выключено** → платформа может с большей уверенностью подтвердить парковку
* **Зажигание включено** → это может быть ожидание с работающим двигателем, что может запускать такие правила, как чрезмерный холостой ход
* **Зажигание настроено некорректно** → платформа может неверно интерпретировать оба случая

### Как меняется логика при учете датчика движения

Когда эта опция включена, платформа использует статус движения, передаваемый устройством, чтобы дополнить данные о скорости и времени.

Это помогает, когда объект остановлен, но шум GPS создает небольшие смещения позиции или ложные низкие скорости. В этом случае датчик может подтвердить, что объект фактически не движется.

Если датчик передает некорректные данные, эффект может быть обратным: разбиение поездок, задержка остановок или ложное движение, когда объект стоит. Прежде чем включать его, проверьте датчик.

### Рекомендуемые значения

Используйте эти значения как отправную точку для городских перевозок:

* **Минимальное обнаружение бездействия**: от 3 до 5 минут
* **Максимальная скорость простоя**: от 3 до 6 км/ч

Это не универсальные значения. Они зависят от типа работы и от того, что вы считаете остановкой.

* Для операций, где важны короткие остановки, можно использовать меньшее время.
* Для операций с частыми пробками или медленными маршрутами используйте большее время, чтобы уменьшить шум в отчетах.
* Проверьте порог скорости на реальных данных. Если GPS сообщает значения от 1 до 4 км/ч, когда объект стоит, слишком низкий порог может помешать корректному определению.

### Рекомендации по лучшим практикам

* **Сначала настройте определение парковки**: Перед просмотром таких оповещений, как чрезмерный холостой ход или остановки в геозонах, проверьте, что базовое определение работает корректно.
* **Проверьте зажигание перед включением**: Датчик должен существовать в разделе **Датчики и кнопки** и передавать корректные значения. В противном случае это может повлиять на поездки, остановки и оповещения.
* **Не включайте датчик движения без проверки данных**: Сначала убедитесь, что устройство корректно передает этот статус. В противном случае это может повлиять на запись поездок и определение остановок.
* **Проверьте частоту передачи данных**: Если устройство отправляет данные каждые 60 секунд, время бездействия в 1 минуту не подходит. Минимальное время должно быть больше интервала передачи.
* **Проверяйте по реальным отчетам**: После изменения конфигурации просмотрите отчеты за рабочий день:
  * Отчет по поездкам
  * Отчет по остановкам
  * Отчет по парковке, если применимо
* **Документируйте изменения**: Записывайте предыдущее значение, новое значение, дату, причину и затронутые устройства. Иначе позже будет сложно объяснить изменения в отчетах.

Если вы видите разбиение поездок, ложные остановки или события, которые не соответствуют работе, скорректируйте значения и проверьте снова.

### Распространенные случаи

* **Объект стоит, но отображается как движущийся**: **Максимальная скорость простоя** может быть слишком низким, либо может присутствовать шум GPS. Если устройство сообщает значения от 1 до 4 км/ч, когда объект неподвижен, увеличьте порог.
* **Появляется слишком много коротких поездок**: **Минимальное обнаружение бездействия** слишком мало. Платформа завершает поездки из-за светофоров или коротких пауз. Увеличьте время и проверьте снова.
* **Объект отображается как припаркованный, хотя движется медленно**: **Максимальная скорость простоя** слишком высоко. Если объект работает на низкой скорости, а порог выше нее, платформа интерпретирует это как простой.
* **Чрезмерный холостой ход не срабатывает**: Оповещение зависит от того, подтвержден ли сначала статус парковки и корректно ли поступает статус зажигания. Если **Определение парковки** работает некорректно, оповещение не сработает, даже если зажигание включено. Сначала проверьте **Определение парковки** , затем оповещение.
* **Разница между простоями платформы и аппаратными простоями**: Простой платформы зависит от логики Navixy, определения парковки и полученного статуса зажигания. Аппаратный простой поступает из события, создаваемого непосредственно устройством.
* **Поездка некорректно записывается при использовании датчика движения**: Если датчик передает некорректные данные, поездка может быть ограничена не так, как ожидается. Сначала проверьте данные датчика.
* **Определение меняется после включения зажигания**: Прежде чем считать это проблемой платформы, проверьте статус зажигания, поступающий от устройства.

### Рекомендация для предотвращения разрывов маршрута

Сначала проверьте следующие пункты:

* Минимальное обнаружение бездействия
* Максимальная скорость простоя
* Частота передачи данных устройством
* Скорость, отображаемая в этот период
* Качество сигнала GPS
* Использование GPS или LBS
* Статус зажигания, если применимо, и его настройку в разделе **Датчики и кнопки**
* Датчик движения, если применимо, и корректность его передачи
* Правила платформы и оборудования, активные одновременно

Платформа применяет настроенную логику к получаемым данным. Если пакеты поступают с низкой частотой, шумом или несогласованными значениями, результат будет отражать эти условия.

### Заключительное замечание

**Определение парковки** не исправляет данные устройства. Она только интерпретирует входящие данные на основе настроенных значений. Если включены зажигание или датчик движения, эти данные также становятся частью логики.

Прежде чем настраивать правила или отчеты, убедитесь, что устройство передает достаточно согласованных данных, соответствующих реальной работе.


---

# 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/ru/faq-and-troubleshooting/gps-devices/parking-detection-logic.md?ask=<question>&goal=<endgoal>
```

`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.
