> 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. Логика объединяет скорость, минимальное время бездействия и, при наличии, дополнительные данные, такие как зажигание или статус датчика движения. Прежде чем просматривать отчеты или оповещения, убедитесь, что устройство передает согласованные данные и что конфигурация соответствует реальной работе автопарка. Настройте это в разделе **определение стоянок**. Это напрямую влияет на: * Отчет о поездках * Отчет о стоянках * Длительная работа на холостом ходу * Стоянки внутри геозон или вне их * Правила, зависящие от движения или статуса стоянки Платформа лишь интерпретирует полученные данные. Низкая частота передачи данных, помехи GPS, неверный статус зажигания или ненадежные данные о движении повлияют на результат. ## Основная настройка В **определение стоянок**, вы определяете, когда платформа должна считать устройство стоящим. * **Минимальное время бездействия**: Минимальное время, в течение которого устройство должно оставаться без движения, прежде чем платформа пометит его как стоящее. Если указать 5 минут, условие должно выполняться все 5 минут до смены статуса. Допустимый диапазон: от 1 до 1440 минут. * **Максимальная скорость простоя**: Порог скорости, который используется для определения устройства как стоящего. Если указать 3 км/ч, платформа будет считать скорость ниже 3 км/ч признаком простоя. Если указать 0, определение скорости простоя отключается. * **Учитывать статус зажигания**: Включает состояние двигателя в **определение стоянок**. Для корректной работы датчик зажигания должен быть физически подключен и настроен в **Датчики и кнопки**. Если включить это без исправного датчика, результаты могут быть неверными. * **Учитывать датчик движения**: Включает движение, сообщаемое устройством, в дополнение к скорости и времени. Это может помочь, когда помехи GPS вызывают ложное движение, но только если данные датчика надежны. ## Как работает логика без зажигания или датчика движения Если эти опции отключены, платформа использует только скорость и время: 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 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/ru/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.