Раздел FAQ (часто задаваемые вопросы), Q&A (вопросы и ответы) и ЧаВо (частые вопросы) собран на основе реальных обращений от партнеров, интеграторов и клиентов платформы Waliot. Мы проанализировали историю обращений в техподдержку, общение в чатах, а также звонки по горячей линии, чтобы отразить здесь максимально полный перечень вопросов и ответов, встречающихся при работе с системой.
Вопросы и ответы сгруппированы по тематическим разделам. Рекомендуем:
Информация в этом разделе регулярно обновляется и дополняется новыми кейсами. Если вы не нашли ответ на свой вопрос — обратитесь в техническую поддержку, и мы добавим решение в базу знаний.
Перед тем как обращаться в техподдержку, рекомендуем выполнить несколько простых шагов. В большинстве случаев они помогают устранить проблему без дополнительных действий:
На компьютере, планшете или смартфоне должны быть выставлены правильные дата и часовой пояс. Неверные настройки могут приводить к сбоям при авторизации, отображении треков и формировании отчетов.
Медленный или нестабильный интернет влияет на загрузку карт, отчетов и треков. Рекомендуем:
Если страница «подвисла» или данные не загружаются:
При повторяющихся ошибках или некорректном отображении данных очистите кэш веб-приложения. Подробная инструкция: Очистка кэша браузера.
Устаревший браузер может некорректно работать с современными веб-технологиями. Для WALIOT.Навигатор, WALIOT.Админ и других веб-приложений платформы рекомендуется использовать последнюю версию одного из браузеров:
При использовании других браузеров возможна частичная или некорректная работа отдельных функций.
Расширения вроде AdBlock или AdGuard могут мешать работе веб-приложения и вызывать ошибки. Добавьте Waliot в список исключений.
Раздел о работе с веб-приложением WALIOT.Навигатор: карта и отображение объектов, отчеты, дашборды и уведомления. Здесь собраны ответы на самые частые вопросы диспетчеров и логистов о том, как находить нужные данные, настраивать их отображение и использовать в ежедневной работе.
Чаще всего объект скрыт настройками отображения. Проверьте:
Две вещи на видимость объекта на карте не влияют: поиск по названию в дереве объектов меняет только состав списка, а объект, потерявший связь, остается на карте в последней известной точке и меняет лишь состояние.
Если все указано верно, попробуйте обновить карту или перезапустите приложение.
Если уведомления перестали приходить, убедитесь, что действие привязано к условию и пользователь подписан на канал: отдельного переключателя «включено — выключено» у условия и действия нет — чтобы прекратить доставку, действие отвязывают от условия или удаляют. При доставке на почту письма иногда попадают в «Спам». Если уведомления не приходят в Telegram или MAX — проверьте, что бот не был отключен пользователем. Полный список причин — в Q4.6.
Если уведомления не настроены вовсе: в разделе «Уведомления» создайте условие (тип события, объекты, геозоны), создайте действие с нужным способом доставки и привяжите действие к условию. Поддерживается несколько каналов: уведомление внутри приложения, электронная почта, SMS, Telegram и MAX. Для работы с настройками уведомлений у пользователя должны быть соответствующие права.
Основные причины:
Проверьте трек объекта на карте за тот же период. Если трек отображается, но в отчете нет данных, значит в панели администратора некорректно настроено дополнительное оборудование на данном объекте. Рекомендуется сверить телеметрию в панели администратора и проверить настройки датчиков.
Это действие выполняет администратор в разделе «Объекты» панели администратора. Вся история треков и отчетов при этом сохраняется. Перемещение между группами внутри одной организации доступно самому пользователю через WALIOT.Навигатор при наличии соответствующих прав. Как устроены группы и их вложенность — в разделе «Дерево объектов».
В дереве справа от названия геозоны есть значок «глаз». Включите его, чтобы зона отображалась на карте. В случае создания новой геозоны, если она не отобразилась на карте или в дереве, попробуйте обновить карту или перезапустить приложение.
Если поле отчета пустое — объект не передавал соответствующий параметр (например, обороты двигателя или уровень топлива). Проверить наличие параметров можно в панели администратора через просмотр телеметрии навигационного оборудования.
Подложку меняют кнопкой «Выбор карты» в панели управления картой: на компьютере она в нижней группе кнопок у правого края экрана, на телефоне эта группа смещена вверх вправо. В меню одиннадцать подложек: OSM, OSM Dark, OSM Light, 2ГИС (выбрана по умолчанию), Google, Google Спутник, Google Гибрид, Google Ландшафт, Яндекс, Яндекс Спутник и Яндекс Гибрид. Выбранная подложка сохраняется локально в этом браузере и на другие устройства не переносится.
Ориентир по выбору:
«Пробки» — не подложка, а отдельная кнопка рядом с «Выбором карты»: она накладывает слой дорожной обстановки поверх любой выбранной подложки. Провайдер подбирается автоматически — для подложек Яндекса показываются пробки Яндекса, для остальных пробки Google.
Обычно дело в объеме отображаемых данных или в канале связи. Уменьшите число одновременно показываемых объектов: включите фильтры, воспользуйтесь поиском или группировкой в дереве. Для собственной категоризации парка пригодятся пользовательские метки — цветные текстовые ярлыки на транспортных средствах, по которым удобно отбирать нужные объекты. Полный разбор, включая VPN и различение локальной проблемы от общей, — в Q4.8.
В разделе «Отчетность» откройте «Отчеты по расписанию». Укажите тип отчета, периодичность и адреса рассылки. Система будет формировать отчеты автоматически и отправлять их на указанную почту. Отчеты формируются по часовому поясу браузера того пользователя, который создал настройку: пояс запоминается при создании и при дальнейшем редактировании настройки не пересчитывается. Отдельного поля выбора часового пояса в интерфейсе нет. Раздел доступен только при наличии соответствующих прав.
В WALIOT.Навигатор отчет отправляется на печать средствами самого приложения: пункт «В печать» открывает окно «Подготовка к печати» с настройками ориентации, стиля, шрифта и его размера, а кнопка «Распечатать» вызывает стандартный диалог печати браузера. Само окно «Подготовка к печати» — штатный предпросмотр, а не признак сбоя. Если печать не запускается или страница подвисает:
Если проблема сохраняется — обратитесь в техническую поддержку.
Да. В отчетной подсистеме есть отдельная группа отчетов «Путевые листы» по унифицированным формам с кодами ОКУД:
Отдельно поддерживается интеграция с 1С:УАТ: в этом случае Waliot передает данные мониторинга (пробег, моточасы, расход и остатки топлива, посещение пунктов), а сам бланк путевого листа формируется уже в 1С.
Требования к каналу на рабочем месте невысокие. На практике достаточно стабильных 1–2 Мбит/с; мобильного 4G хватает. Где взять веб-версию и мобильные приложения — на странице «Установка приложений Waliot». Объем обновлений растет пропорционально числу объектов и геозон в организации, поэтому для крупных парков, а также при просмотре видеонаблюдения (видеопоток идет напрямую из вашей системы видеонаблюдения) запас по каналу нужен больше.
⚠️ Не путайте с системными требованиями On-Premise: указанные там 100 Мбит/с относятся к серверу, на котором разворачивается платформа, а не к рабочему месту пользователя.
Тепловая карта — это картографический слой, который цветовой заливкой показывает плотность движения и стоянок объекта за выбранный период: чем чаще техника проезжала или стояла в точке, тем «горячее» цвет. Слой строится по точкам телеметрии за период, прореженным по времени: из идущих подряд точек остается та, что отстоит от предыдущей больше чем на 10 секунд. Все оставшиеся точки весят одинаково, поэтому карта показывает не число приездов, а число точек: час стоянки дает в одном месте сотни точек и «греет» сильнее, чем несколько проездов по одной улице.
Тепловую карту используют, чтобы увидеть, где техника бывает чаще всего, найти нештатные маршруты и места длительных стоянок. Важно: слово «тепловая» здесь про цветовую шкалу плотности, а не про температуру или тепловые нагрузки. Для точного учета посещений конкретных территорий используйте отчеты «Посещение геозон» и «Прохождение геозон».
Верхнего предела на число объектов нет — ни в интерфейсе, ни в API. Длина периода тоже не ограничена: в календаре недоступны только будущие даты. Ограничения, с которыми сталкиваются на практике, лежат в другом.
Тип отчета. Из 41 стандартного отчета 21 строится только по одному объекту: все путевые листы (Форма №3, Форма №3 спец., Форма №4-С, Форма №4-П, Форма №6 спец., Форма №412-АПК, Форма №ЭСМ-2), «Расход топлива», «Детализация по топливу», «Сводный отчет», «Выдача топлива по картам», «Выдача топлива по радиусу», «Трассировка датчиков», «Выдача УСС», «Въезды и выезды», «Температура», «Детализация по температуре», «Напряжение», «Датчик угла наклона», «Обороты двигателя», «Детализация по CAN-шине». Остальные двадцать строятся сразу по нескольким объектам и помечены в списке отчетов звездочкой.
Требуемое оборудование. У части отчетов задан список требуемых системных меток: объекты без такого оборудования в дереве недоступны для выбора.
Минимальная длина периода — одна минута. Считается общий охват от самой ранней даты начала до самой поздней даты окончания, причем будущее время предварительно приводится к текущему моменту. Если охват короче минуты, отчет не строится: в WALIOT.Навигатор появится сообщение «Не удалось построить отчет», а по API вернется ошибка «Некорректные параметры отчета».
На время построения влияют: число объектов, умноженное на длительность периода; плотность точек телеметрии; число выбранных интервалов — при включенном переключателе «Время по дням недели» отчет строится по отдельному интервалу на каждый подходящий день; число геозон и состав дополнительного оборудования на объектах. Разрозненные интервалы за большой промежуток обходятся как весь промежуток целиком: телеметрия загружается одним запросом от самой ранней до самой поздней даты, поэтому пять дней, выбранных за полгода, стоят столько же, сколько полгода подряд. При очень большой выборке отчет может не построиться — в этом случае сузьте период или число объектов.
Ограничение доступа к телеметрии. Если на объекте или на организации задано «Время ограничения доступа к телеметрии», отчет за период раньше этой даты не строится: запрос отклоняется целиком с ошибкой доступа к телеметрии, а не обрезается до разрешенной даты. Проверяется самая ранняя дата начала из всех интервалов (см. Q2.15).
У отчетов по расписанию произвольного периода нет: «Ежедневно» — за предыдущий день, «Еженедельно» — по понедельникам за предыдущую неделю, «Ежемесячно» — первого числа за предыдущий месяц; день недели и первое число определяются по часовому поясу, указанному в настройке отчета. Внутри дня период сужается полями «Интервал от» и «Интервал до», а набор дней задается переключателем «Время по дням недели». Для многообъектных типов отчетов объекты разбиваются на группы, и на каждую группу приходит отдельный файл с номером в имени; для отчетов по одному объекту приходит по файлу на объект — без нумерации, с регистрационным номером в имени. Если файлов набирается слишком много, рассылка делится на несколько писем.
Печать самой карты с треком в WALIOT.Навигатор не предусмотрена: на панели карты есть масштаб, выбор подложки, «Пробки», «Панорама», измерительные инструменты и переключатель графиков трека — печати среди них нет. Данные трека выводят на печать двумя способами.
Через отчет. Постройте отчет по объекту за нужный период и выберите «В печать»: откроется окно «Подготовка к печати» с настройками ориентации, стиля, шрифта и его размера, а кнопка «Распечатать» вызовет стандартный диалог печати браузера (см. Q1.11).
Через график. В правом верхнем углу панели «Графики трека» есть меню: «Полноэкранный режим», «Распечатать», «Скачать CSV» и «Скачать XLS». Печать и выгрузка относятся к самому графику, а не к карте.
Если нужно именно изображение карты, воспользуйтесь снимком экрана средствами операционной системы.
Отметок о доставке платформа не показывает ни для одного канала оповещения, поэтому проверка идет по цепочке — от факта события к настройкам канала.
1. Событие было? Постройте отчет «События» по объекту за нужный период. Он считается по телеметрии и не зависит от того, настроено ли правило уведомления, — поэтому отвечает на вопрос независимо от настроек. Если события в отчете нет, правило ни при чем.
2. Правило сработало? Откройте раздел «Уведомления»: лента разделена на вкладки «Новые» и «Прочитанные». Важная тонкость: запись в ленте появляется, только если к условию привязано действие «Уведомление через нативные приложения». Правило, у которого настроена одна лишь почта, работает, но в ленте не отражается. Лента общая для организации, а не личная: колонки «Пользователь» и «Дата просмотра» показывают, кто и когда прочитал запись, а отметка «прочитано» одним сотрудником убирает ее из «Новых» у всех.
3. Не подавлена ли сработка? У условия есть обязательное поле «Период эскалации» — минимальный интервал в секундах между оповещениями. Пока интервал не истек, повторная сработка не создает ни записи в ленте, ни писем: фильтр применяется до раздачи по каналам, поэтому событие в отчете будет, а оповещения не будет. Интервал считается отдельно для каждой пары «условие — объект», для условий по геозонам — еще и по каждой геозоне, и отсчитывается от последнего оповещения по любому каналу.
4. Есть ли получатели? Адреса почты вводятся в поле «Почтовые ящики» самого действия, и хотя бы один адрес обязателен. Подписчиков Telegram и MAX вручную не вводят — пользователь подписывается сам, перейдя по ссылке бота; их количество видно в таблице действий в колонках «Telegram подписчики» и «Max подписчики». Пустая колонка означает, что на это действие никто не подписан. Подписки можно перепроверить и в самом боте командой /list: он выведет список подписок или ответит «Список пуст».
Самая частая ошибка — про почту. Уведомления уходят только на адреса, вписанные в поле «Почтовые ящики» действия. Электронная почта в профиле пользователя для рассылки уведомлений не используется вовсе.
Исключение — команда трекеру. У действия «Послать команду трекеру» результат виден: в карточке объекта откройте «Команды трекера» — таблица последних команд содержит «Время создания», «Команду» и «Статус» со значениями «Ожидает подключения», «Ожидает ответа», «Выполнена», «Истекло время ожидания», «Неверный протокол» и «Команда не поддерживается». В этом списке видны и команды, отправленные автоматически по условию уведомления, а не только вручную (см. Команды трекера).
Кто и когда менял сами правила, видно в WALIOT.Админ в разделе «Аудит»: создание, изменение и удаление условий и действий фиксируются. Полный список причин, по которым уведомление может не прийти, — см. Q4.6.
В этом разделе объясняется, как формируются и отображаются данные в системе. Почему может не совпадать пробег, пропадать координаты или топливо, как работает фильтрация и откуда берутся различия между отчетами и треками. Все, что связано с телеметрией, ее визуализацией и отчетностью.
В системе события фиксируются по изменениям уровня топлива, которые передает датчик уровня топлива (ДУТ), установленный в баке. Небольшие колебания показаний связаны с погрешностью датчика, температурными изменениями и колебаниями топлива в баке. Чтобы убедиться в достоверности события (слива или заправки), проверьте:
Пользователю:
Администратору:
При использовании нескольких ДУТ (в одном баке или разных баках) необходимо убедиться в корректной работе каждого.
Если после проверки и коррекции проблема сохраняется — вероятна неисправность самого датчика.
Причины:
Какой из двух пробегов попадает в отчеты и в статусы техобслуживания, задается у объекта в оборудовании «Датчик измерительных приборов» (Объекты → «Доп. оборудование»), поле «Расчет значения одометра»: «GPS», «CAN» или «Накопитель» (накопительный счетчик). Если такого оборудования на объекте нет, по умолчанию используется GPS-одометр. Сырые показания CAN-одометра, как их отдает бортовая электроника, видны отдельно — в отчете «Детализация по CAN-шине», колонка «Общий пробег, км».
Если в данных отсутствуют валидные широта и долгота, это значит:
Проверьте время последней активности объекта и качество спутникового сигнала (флаг валидности, число спутников, HDOP).
Чаще всего параметр вообще не доходит до платформы: не активирован CAN-скрипт, модель ТС не отдает нужный параметр или неверно настроен адаптер — полный разбор в Q5.5.
Если данные до платформы доходят, но в интерфейсе их нет, значит параметр не связан с полем объекта в настройках дополнительного оборудования. Проверить, что именно приходит от трекера, можно в просмотре телеметрии.
Такая ситуация возникает при механических помехах (например, крен автомобиля или движение по неровной дороге). Также стоит проверить частоту фиксации уровня топлива: обычно данные приходят с каждым телематическим пакетом от оборудования. Рекомендуется настроить фильтрацию в анализе топлива и проверить тарировочную таблицу.
Возможные причины:
Наиболее частые причины:
Тот же механизм стоит за «рывками» в передаче и обрывами трека — см. Q4.2 и Q5.9.
Причины:
Возможные причины:
Также разрывы могут быть при сбросе буферизованных данных («черного ящика») до их отправки на телематический сервер. Про одиночные «скачки» маркера по карте — см. Q4.3.
Разрыв на карте не означает потерю пробега. Участок без достоверных координат показан желтым пунктиром: расстояние, «намотанное» ложными координатами, в пробег не входит, но сам участок из пробега не выпадает — когда достоверные координаты появляются снова, к пробегу прибавляется расстояние по прямой между последней достоверной точкой до разрыва и первой после него (см. «Треки и история»).
Система считает «программные» моточасы (т.н. машиночасы) по датчику зажигания: суммируется время, пока зажигание было включено. С фактическим временем работы двигателя такой расчет совпадает ровно настолько, насколько точно снят сигнал зажигания.
Расхождения возможны, если:
Отдельно в карточке объекта есть «Коэффициент корректировки моточасов» — множитель со значением 1 по умолчанию. Он позволяет приблизить значение программных моточасов ближе к интегральному показателю нагрузки.
Незначительные расхождения между уровнем топлива на начало и конец дня не всегда означают слив или заправку. Даже при высокой точности оборудования показания могут немного колебаться из-за физических и эксплуатационных факторов. Отдельный случай — событие на стыке суток: если заправка или слив пересекает границу периода, уровень на этой границе вычисляется линейной интерполяцией между соседними точками и не берется ни из одной реальной точки телеметрии (см. «Анализ топлива»). Основные причины:
Такие расхождения считаются нормой и не свидетельствуют о сливе топлива. Чтобы минимизировать погрешность, рекомендуется не отключать питание трекера и датчика уровня топлива — это обеспечивает постоянную фиксацию данных в течение суток.
Платформа фиксирует несколько независимых слоев данных — для разбора спора полезны все:
Для доказательной базы надежнее выгрузить и сохранить файлы отчетов сразу: выгрузка фиксирует состояние данных на момент формирования, и ее можно приложить к ответу на претензию.
Паспортная погрешность относится к самому датчику — линейности его сигнала в лабораторных условиях. В смонтированной системе на итоговую цифру влияет вся цепочка: тарировка бака, монтаж, условия эксплуатации и обработка данных.
Главный источник расхождений — тарировочная таблица. ДУТ передает не литры, а условные единицы уровня; в литры их переводит тарировочная таблица, снятая проливом. Она задается для каждого датчика отдельно, а не для объекта в целом; если в баке стоит несколько ДУТ, их пересчитанные показания усредняются. Между соседними точками таблицы значение вычисляется линейной интерполяцией, поэтому чем меньше точек и чем сложнее геометрия бака, тем больше ошибка на промежуточных уровнях. Если включено продление таблицы за ее пределы, показания ниже первой и выше последней точки экстраполируются — это наименее точная зона.
Условия эксплуатации: волна в баке при движении и на уклоне, температурное расширение топлива (объем меняется, масса — нет). Для второго есть опция температурной компенсации: если датчик передает собственную температуру, объем пересчитывается с поправкой на тепловое расширение по типу топлива. Устойчивую пропорциональную ошибку — когда датчик стабильно занижает или завышает объем на несколько процентов — убирает «Коэффициент корректировки топлива» в настройках анализа топлива: это множитель со значением 1 по умолчанию. Постоянное смещение на фиксированное число литров он не компенсирует.
Что платформа делает, чтобы шум не превращался в «сливы»: отсекает показания вне заданного диапазона валидных значений датчика, усредняет несколько ДУТ одного бака, по настройке игнорирует данные при выключенном зажигании и может округлять результат до литров.
Как измерить фактическую точность своей установки. В отчетах по выдаче топлива есть колонка «Погрешность УСС/ДУТ, %». Это не паспортная характеристика датчика, а расхождение двух независимых измерений на одной и той же заправке: «Выдано по УСС, л» (счетчик на раздаче) против «Получено по ДУТ, л» (прирост уровня в баке), в процентах от показаний ДУТ. По серии заправок она показывает реальную точность конкретного объекта: разовые выбросы объясняются условиями заправки, а устойчивое смещение — повод уточнить тарировку или коэффициент коррекции.
См. также Q2.1 — как проверить достоверность конкретного события, и Q3.5–Q3.6 — как система определяет заправку и слив.
Ускорение показывает изменение скорости, а не саму скорость: при равномерном движении оно равно нулю независимо от того, с какой скоростью едет объект, а заметные значения появляются на разгонах, торможениях и в поворотах. Значение платформа берет из телеметрии в готовом виде и не рассчитывает его по разнице скоростей соседних точек, поэтому у устройств, которые ускорение не передают, этого параметра в телеметрии не будет. Имена параметров ускорения и их соответствие другим системам мониторинга — в таблице соответствия имен параметров.
Данные, пролежавшие в базе достаточно долго, платформа переводит в сжатый вид. На работу с ними это не влияет: треки, отчеты и выгрузки за давние периоды строятся тем же способом и из того же журнала телеметрии, что и за вчерашний день. Отдельных «архивных» разделов и процедур восстановления нет, а длина периода в календаре не ограничена — но чем длиннее период и чем больше в нем объектов, тем дольше строится результат.
Удаление — только вручную. Удалить телеметрию можно исключительно в WALIOT.Админ и только пользователю с расширенными административными правами: либо одну запись из ее карточки, либо все записи за явно выбранный период — из карточки объекта мониторинга или из карточки трекера. Восстановить удаленное нельзя.
Скрыть данные можно, не удаляя их. В карточке объекта мониторинга администратор задает «Время ограничения доступа к телеметрии». Данные остаются в базе, но запросить период, начинающийся раньше указанного момента, не получится: трек, отчет, тепловая карта и выгрузка за такой период не построятся — платформа ответит отказом в доступе. Ограничение снимается или переносится тем же полем, и его можно задать сразу нескольким объектам через массовое редактирование. Аналогичное ограничение может действовать на уровне всей организации — тогда оно перекрывает настройку объекта (см. Объекты).
Перенос истории из другой системы. При импорте файла телеметрии в формате Wialon WLN точки, зафиксированные слишком давно, в загрузку не попадают — переносить имеет смысл недавнюю историю, а глубину переноса лучше согласовать с технической поддержкой заранее (см. переход с Wialon).
Отдельно про ретрансляцию: событие «Данные слишком долго не отправлялись» в журнале означает, что накопленные для внешнего сервера записи так и не удалось передать и они убраны из очереди на отправку. На историю в самой платформе это не влияет — она остается на месте (см. Ретрансляция).
Отдельного расчета исторических данных, которого нужно дождаться, у треков и отчетов нет — они строятся по телеметрии в момент запроса. Причин задержки обычно несколько, и они разные.
1. Объект еще не привязан к трекеру. Пока трекер зарегистрирован, но не привязан ни к одному объекту мониторинга, платформа принимает пакеты и подтверждает их устройству, но точки не сохраняет — истории за этот период не возникает (см. Q4.10). То же происходит, если все объекты трекера находятся в статусах «Блокирован по запросу», «Демонтирован» или «Дубликат»: достаточно одного объекта в любом другом статусе, чтобы данные писались (см. Объекты). Статус только что созданного объекта — «Новый», приему данных он не мешает.
Заводите объект до подключения трекера. Подтверждение приема уходит устройству и на те пакеты, которые платформа отбросила, а часть трекеров по такому подтверждению стирает свой внутренний архив. Данные, пришедшие до привязки объекта, в этом случае теряются безвозвратно.
2. После привязки нужно немного времени. Сервер приема данных обновляет список привязок по расписанию, поэтому первые сохраненные точки появляются в пределах минуты. Задним числом отброшенное не восстанавливается. При этом историю за прошедший период платформа получает не только импортом файла: чаще всего ее присылает сам трекер из внутренней памяти, когда связь восстановится, — так же данные приходят по ретрансляции из другой системы (см. Q2.15).
3. Пустой график — обычно вопрос оборудования, а не ожидания. Панель «Графики трека» открывается под картой после того, как построен трек объекта: на компьютере сразу, на телефоне ее открывают кнопкой «Показать графики трека». По умолчанию берется период текущих суток. Графики топлива, напряжения и зажигания строятся только при заведенных на объекте датчиках, а без дополнительного оборудования строится одна скорость (см. Дополнительное оборудование).
4. Раздел «Аналитика» устроен иначе. Его показатели готовит ночной расчет за предыдущие календарные сутки: текущий день не рассчитывается, и верхняя граница периода в разделе ограничена вчерашним днем. Поэтому по объекту, подключенному сегодня, показатели там появятся на следующий день. Исключение — плитки «Состояние автопарка» и «Техническое обслуживание» на вкладке «Обзор»: они показывают текущее положение дел и учитывают новый объект сразу (см. Бизнес-аналитика).
Это не ошибка расчета и не расхождение CAN с GPS. У отчетов разный смысл суммы.
«Пробег по дням», «Пробег за период» и ряд отчетов вроде «Расход топлива» берут пробег за весь выбранный день (разница одометра от первой до последней точки суток) — по источнику из датчика «Измерительные приборы»: GPS, CAN или накопитель.
Путевые листы (Форма №3 и остальные формы группы) и отчет «Выезды» суммируют пробег только по поездкам: от конца одной стоянки до начала следующей. Участки на стоянке, короткие смещения без зачета в поездку и поездки, отсеянные параметром «Игнорировать выезды менее», в итог путевого листа не входят.
Поэтому итог путевого листа обычно меньше, чем в «Пробеге по дням» за тот же период. Свести их «один в один» нельзя, не ломая смысл путевого листа.
Если одометр настроен на CAN, а скорость осталась по GPS, границы стоянок и метров режутся по разным источникам — разрыв растет. Когда источник скорости совпадает с логикой движения, разрыв обычно сжимается, но полностью не исчезает (см. Q2.2 про источники пробега; страницы Форма №3 и Пробег по дням).
В этом разделе описаны алгоритмы и правила, по которым система определяет поездки, простои, превышения скорости, заправки, сливы топлива и другие события. Здесь собраны ответы на самые частые вопросы пользователей о том, как именно работает логика платформы, почему данные в отчетах могут отличаться и какие настройки влияют на расчеты.
Поездка начинается, когда объект возобновляет движение после стоянки: скорость становится выше порога «отсутствия движения» (по умолчанию 0 км/ч) при валидных навигационных данных. Отдельного порога по пройденному расстоянию для старта поездки нет.
Сам порог в настройках объекта называется «Порог движения» и правится только администраторами. Времена остановки и стоянки и максимальную скорость может менять и расширенный пользователь в Навигаторе.
Поездка завершается, когда объект простоял дольше тайм-аута стоянки — по умолчанию 5 минут. Отсчет начинается с момента, когда скорость перестала превышать порог «отсутствия движения» (по умолчанию 0 км/ч), и продолжается, пока она этот порог не превысит. Временем окончания поездки записывается момент, когда объект встал, а не момент, когда истекли пять минут.
Более короткий простой поездку не прерывает: если объект стоял дольше 30 секунд, но меньше 5 минут, система фиксирует остановку внутри поездки, а сама поездка продолжается. Само по себе изменение или неизменность координат на завершение поездки не влияют: состояние объекта определяется скоростью и временем. На другое координаты влияют — по ним считается пробег, а поездка с нулевым пробегом в отчет не попадает.
Пороги «Время начала остановки» и «Время начала стоянки» задают для каждого объекта в его свойствах — и в WALIOT.Навигатор, и в WALIOT.Админ; время начала остановки должно быть меньше времени начала стоянки. Порог «отсутствия движения» меняют только в WALIOT.Админ.
Длительность поездки — это все время от окончания одной стоянки до начала следующей, включая остановки, которые не дотянули до стоянки. Чистое время хода показывают отдельные колонки отчетов: «Длительность в движении» (в отчетах по пробегу она называется «Время в пути») и «Работа в движении» — время работы двигателя во время движения.
Время работы двигателя учитывает весь период, когда зажигание включено, включая простои на холостом ходу.
Холостой ход фиксируется, когда зажигание включено, а объект не движется (скорость не выше порога отсутствия движения). Кратковременные остановки отсеиваются задержкой регистрации остановки (по умолчанию 30 секунд). Время холостого хода накапливается за периоды остановок и стоянок при включенном зажигании. Датчик оборотов двигателя уточняет расчет; без него холостым ходом считается вся стоянка с заведенным двигателем по датчику зажигания. Стоянка с заглушенным двигателем в холостой ход не попадает.
Заправка фиксируется, когда объем топлива в баке резко увеличивается больше установленного порога. Порог задается в миллилитрах — поле «Минимальный объем топлива для учета заправки». Настраивает его администратор, причем не в самом датчике уровня топлива, а в оборудовании «Анализ топлива». Автоматической связи порога с объемом бака нет: значение подбирают вручную под тип техники и бак. Мелкие колебания уровня и плавные изменения при этом отсеиваются, чтобы исключить ложные события.
Слив фиксируется, когда объем топлива в баке резко уменьшается больше установленного порога — поле «Минимальный объем топлива для учета слива» в настройках «Анализа топлива». Очень малые изменения (доли процента от объема бака) и плавное снижение уровня система трактует как обычный расход, а не слив. Резкие маневры и тряска при движении могут искажать показания, поэтому важны корректная тарировочная таблица и настройка фильтрации в анализе топлива.
Основные причины:
Превышение фиксируется, когда скорость объекта становится выше заданного порога. По умолчанию используется порог 90 км/ч; его можно изменить для конкретного объекта. Если лимитов несколько, нарушением считается превышение самого низкого из применимых: «Макс. скорость» объекта, «Макс. допустимая скорость движения в зоне» для всех геозон, внутри которых объект находится, и пороги датчика «Качество вождения». В условии уведомления есть отдельное поле «Лимит скорости»: если оно заполнено, система сравнивает только с ним и остальные лимиты игнорирует. Отдельная минимальная длительность превышения по умолчанию не задана — событие фиксируется сразу; при построении отчета можно включить фильтр, отсекающий слишком короткие превышения.
Причины:
Это событие фиксируется встроенным акселерометром трекера, если ускорение превышает установленный порог. Порог можно скорректировать в конфигурации оборудования Акселерометр, чтобы уменьшить или увеличить чувствительность.
Как это отражается в системе Waliot:
Пороги времени остановки и стоянки можно изменить в свойствах объекта.
При очень медленном движении навигационные данные могут иметь значительную погрешность, из-за чего система мониторинга иногда воспринимает объект как стоящий. Основные причины:
На практике это означает:
Нет. Складского учета запчастей и прогноза потребности в расходниках на неделю, месяц или сезон в платформе нет: остатки на складе, закупки и списание материалов не ведутся.
Для планирования работ есть раздел Техническое обслуживание — планы ТО с интервалами по пробегу, моточасам и календарю, с напоминаниями о приближении и просрочке, и отчет История прохождения ТО. По ним видно, какие работы предстоят по каждой единице техники и когда, но номенклатуру и количество запчастей платформа не рассчитывает. Состояние по каждому виду работ показано зонами: желтая — пройдено от 40 % до 80 % интервала, красная — остаток 20 % интервала или меньше либо срок уже пропущен.
Справочники сотрудников и оборудования с их реквизитами ведутся в разделе «Ресурсы предприятия».
Нет. Платформа не подбирает места размещения инфраструктуры — ни зарядных станций для электротранспорта, ни стоянок, ни складов. Такой расчет не входит в возможности системы и не заявлен в дорожной карте.
Оценить, где техника фактически проводит время, помогают отчет по стоянкам и тепловая карта: по ним видны реальные точки простоя и его продолжительность. Решение о размещении принимает пользователь.
Нет. Учета зарядных сессий — кто подключал автомобиль, где и когда, сколько энергии получено и сколько это стоило — в платформе нет, интеграций с зарядными станциями тоже нет.
По электропитанию объекта есть датчик «Напряжение АКБ» — ему задают вольтаж батареи (12 или 24 В) и границы допустимых значений. Отдельного типа «напряжение бортовой сети» в платформе нет: его снимают обычным «Аналоговым датчиком», привязав к параметру напряжения питания (см. Доп. оборудование): их показания видны на графике трека, попадают в отчеты и могут использоваться в событиях. По ним видно, что напряжение выросло, но объем и стоимость полученной энергии система не считает.
Да. Объект в платформе — не обязательно транспорт: любой объект заводится с трекером и нужным набором датчиков. Поэтому под мониторинг попадают дизель-генераторы и насосы (моточасы и факт работы — через датчики зажигания и работы оборудования, обороты), холодильные установки и рефрижераторы (датчики температуры, состояние и режим установки), топливные емкости и цистерны (датчики уровня топлива, учет выдачи). Полный перечень датчиков — «Доп. оборудование».
Для фиксации местоположения стационарного объекта рекомендуется использовать «Настройки навигации» в режиме «Стационарный объект».
Нет. Платформа не ведет статус «в ремонте» и не сравнивает длительность ремонта объекта с аналогичными машинами. По телеметрии доступен анализ простоя и стоянок и холостого хода (сколько техника стояла или работала вхолостую), а плановое обслуживание отслеживается по интервалам — моточасы, пробег, календарь (см. «Техническое обслуживание»). Автоматического выявления «слишком долгого ремонта» в системе нет.
Нет. Платформа не хранит гарантийные условия техники и не сверяет их с режимом эксплуатации. Она фиксирует фактическую телеметрию — моточасы, обороты, температуру, нагрузку, режимы работы; эти данные можно выгрузить в отчеты и использовать при разборе спорной ситуации вручную, но автоматической проверки «гарантийный случай или нет» в системе нет.
Нет. Такой сквозной цепочки учета ремонтов в платформе нет: нет модулей заявок, заказ-нарядов, склада запчастей, поставщиков и учета фактической стоимости ремонта (см. также Q3.13). Что есть: плановое техническое обслуживание по интервалам (моточасы, пробег, календарь) с напоминаниями и историей обслуживания, а также учет топливных затрат — но это не управление ремонтами. Операции по топливным картам приходят из процессингов, а по одному из них — и уведомления о штрафах ГИБДД; и то и другое собрано в разделе «Топливные карты и штрафы».
Типовой методики или калькулятора окупаемости в платформе нет. Срок окупаемости зависит от состава парка, задач и текущих потерь (перерасход и сливы топлива, переработки и простои, штрафы), поэтому расчет делается индивидуально под конкретный парк. За ориентирами и детальным расчетом обратитесь к вашему менеджеру Waliot — он поможет оценить экономию по вашим данным.
В этом разделе собраны ответы на самые частые вопросы, связанные с техническими сбоями, потерей связи, некорректными данными и нестандартными ситуациями при работе с системой Waliot. Здесь описаны типичные ошибки, причины их возникновения и способы устранения.
Основные причины:
Если связь с сервером есть, но данные не доходят, причина другая — разбор в Q5.2 и Q5.15.
Причина всегда на стороне устройства или связи: слабый GSM-сигнал и буферизация («черный ящик»), большой интервал отправки пакетов или энергосберегающий режим. Разбор причин и что с ними делать — в Q2.7.
Обычно это связано с временной потерей ГНСС-сигнала (туннель, здания, РЭБ) или с некорректной фильтрацией данных. Рекомендуется:
Про разрывы трека, а не одиночные скачки, — см. Q2.9.
Причины:
Перенос объекта между организациями сам по себе дублей не создает — это перемещение с сохранением идентификатора и всей истории.
Основные причины:
Развернутый разбор всех причин, включая то, кто и как снимает блокировку, — в Q6.2.
Задолженность по абонентской плате вход не закрывает — это пометка о неоплате: войти в систему можно, но интерфейс будет заблокирован. Свяжитесь с бухгалтерий и оплатите счет по абонплате.
Возможные причины:
Нулевые значения означают, что параметр не дошел до отчета: датчик или CAN подключены некорректно, устройство его не передавало либо он не связан с объектом в настройках дополнительного оборудования. Как это проверить — в Q1.7; если пустует именно CAN — в Q2.4.
Причины:
Если ошибки только у одного пользователя — проблема локальная (браузер, интернет), если у всех — это системная нагрузка (возможны временные работы). Что сделать в самом приложении, чтобы разгрузить экран, — см. Q1.9.
Обычно это связано с отсутствием интернет-доступа или блокировкой картографического сервиса.
Рекомендуется:
Проверьте:
Изменения в привязке и статусах подхватываются не мгновенно — данные пойдут в течение минуты.
В этом разделе собраны ответы на вопросы, связанные с установкой, настройкой и работой телематического оборудования: трекеров, датчиков уровня топлива, CAN-адаптеров и других устройств. Здесь рассмотрены типичные проблемы инженеров и интеграторов при подключении оборудования к платформе Waliot.
Для регистрации необходимо:
Каждый идентификатор уникален в пределах платформы: завести два трекера с одинаковым IMEI, серийным номером или номером SIM-карты нельзя.
Основные причины:
Список поддерживаемых моделей доступен в документации и в панели администратора при добавлении трекера. Часть устройств может работать через универсальные протоколы (EGTS, Wialon IPS и другие). Если модель вашего оборудования не отображается, обратитесь в техническую поддержку.
Возможные причины:
После замены бака или ДУТ тарировочную таблицу нужно откалибровать заново.
Причины:
Про то же самое со стороны интерфейса — почему CAN-параметры не видны в карточке и отчетах — см. Q2.4.
Для большинства устройств обновление выполняется через конфигуратор производителя или OTA-механизм. Перед обновлением следует сохранить текущие настройки трекера. Рекомендуется:
Основные причины:
1. Физическое подключение
2. Настройки входа
3. CAN-шина
Подключение выполняется через свободные входы/выходы трекера:
Используйте документацию производителя трекера для правильного подключения и защиты от поломок.
«Рывки» и обрывы трека — это та же буферизация, что и при задержке данных: слабый GSM-сигнал, редкий интервал передачи или энергосберегающий режим трекера. Подробно — в Q2.7; про разрывы именно в треке, включая потерю спутникового сигнала и сбой времени на трекере, — в Q2.9.
После установки рекомендуется провести тест-драйв для проверки корректности всех датчиков и стабильной передачи данных.
Нет. Объект мониторинга связывается только с одним трекером — «второго» или резервного трекера в модели объекта не предусмотрено. Возможен обратный вариант: один физический трекер можно показать в нескольких карточках-объектах через механизм дубликата (например, чтобы объект был виден в разных организациях). Если на одну единицу техники нужно завести несколько устройств, создайте для них отдельные объекты.
Аналитику ИИ-камер (DSM/ADAS: непристегнутый ремень, разговор по телефону, курение, усталость, отвлечение, предупреждение о столкновении) платформа сейчас не принимает и не обрабатывает. Что доступно: видеонаблюдение — подключение внешних видеопотоков с камер и просмотр в реальном времени без ИИ-анализа; и контроль стиля вождения по данным акселерометра и GPS (резкие ускорения, торможения, повороты) — без камеры. Если требуется именно распознавание поведения водителя по видео, уточните возможность в технической поддержке.
Отдельного готового сценария «прицеп уехал без метки — тревога» в платформе нет. RFID применяется для идентификации: водителя (карта или ключ iButton — учет смен, «свой / чужой») и навесного оборудования (у каждого агрегата своя RFID-метка, а считыватель определяет, какой агрегат сцеплен, — для сельскохозяйственных отчетов). Контроль перемещения собирается из штатных средств: геозона с уведомлением по условию «Выезд из геозоны» и оборудование «Реле блокировки». Действие уведомления умеет не только оповестить, но и само замкнуть или разомкнуть реле и отправить команду трекеру.
Ближе всего к задаче — RFID-ворота: ворота заводят отдельным объектом с оборудованием «RFID считыватель», слот карты работает антенной въезда, слот метки — антенной выезда. Проезд машины с меткой дает событие «Въезды и выезды» с направлением «Въезд» или «Выезд», по нему же строится одноименный отчет в группе «Отчеты по доб.оборудованию».
Обратите внимание на терминологию: навесное и прицепное оборудование в платформе — разные вещи. Работу навесного отслеживает «Датчик ВКЛ/ВЫКЛ», а «Прицепное оборудование» — это отдельная карточка в ресурсах предприятия (плуг, сеялка, борона, опрыскиватель) со своим отчетом. Для конкретной задачи обратитесь в техническую поддержку — подберем комбинацию оборудования и правил.
Отдельной функции «камера 360°» со сшивкой единого кругового обзора в платформе нет. Видеонаблюдение устроено так: платформа отображает потоки внешних видеорегистраторов — каждая камера задается именем и ссылкой на видеопоток. Несколько ракурсов (дорога, кабина, борт, грузовой отсек, зад) возможны, если регистратор передает их как отдельные каналы-камеры. Панорамной склейки в единый обзор 360° сама платформа не выполняет. Про аналитику ИИ-камер (DSM/ADAS) — см. Q5.12.
Частая причина — ГНСС-приемник трекера еще не зафиксировал координаты: устройство только что включили, техника стоит в помещении, под металлическим навесом или в зоне помех. Пока фиксации координат нет, многие трекеры отправляют на сервер только служебные пакеты (пинги) без навигационных данных: связь с сервером при этом есть, но точки с координатами не создаются — объект не обновляется на карте и в треках. Как только приемник зафиксирует координаты (обычно достаточно вывести технику под открытое небо), трекер начнет передавать полноценные навигационные данные и точки появятся. Про отсутствие валидных координат в уже приходящих данных — см. Q2.3, про проверку устройства после установки — см. Q4.10.
Возможен и второй вариант: трекер шлет навигационные пакеты, но с нулевыми координатами. Такие записи платформа сохраняет, помечая координаты невалидными, — в разделе «Телеметрия» WALIOT.Админ они видны и обновляют время последней активности объекта, но на карту и в трек не попадают, и объект остается в последней достоверной точке.
Живой трафик на SIM-карте еще не доказывает, что данные доходят до платформы: трафик расходуется и на повторные попытки подключения. Сервер приема данных закрывает соединение при любой ошибке разбора пакета, включая неверную контрольную сумму. Чаще всего это происходит в трех случаях:
Что проверить:
Про общие причины, по которым устройство не подключается, — см. Q5.2, про обрывы и рывки в передаче — см. Q5.9, про подключившийся трекер без точек на карте — см. Q5.15.
В этом разделе собраны ответы на вопросы, связанные с входом в систему Waliot, управлением ролями и правами пользователей, сбросом паролей и настройкой доступа к данным. Здесь рассмотрены типичные ситуации, когда пользователи не могут войти в систему, теряют доступ или сталкиваются с ограничениями прав.
Восстановить пароль может администратор вашей организации или администратор вышестоящей организации — доступ есть у всех администраторов по ветке дерева, при условии что их роль строго выше вашей. Обратитесь к нему для сброса и выдачи нового пароля. Администратор не может узнать старый пароль — он всегда назначает новый. Сотрудники Waliot не имеют доступа к текущим паролям пользователей.
Основные причины:
Заблокированную учетную запись разблокирует администратор вашей организации (см. Q6.12). Блокировку самой организации снимают из вышестоящей организации: собственную организацию в WALIOT.Админ нельзя ни отредактировать, ни заблокировать, а пока блокировка стоит, вход закрыт всем пользователям организации, включая ее администраторов. Если вышестоящей организации у вас нет, обратитесь в техническую поддержку Waliot.
Что такое ключ организации. Это регистрационный ключ доступа к организации — восемь символов из заглавных латинских букв и цифр. Платформа выдает его сама при создании организации; задать свой ключ, изменить или перевыпустить его нельзя. Логины уникальны внутри организации, поэтому ключ определяет, в какую именно организацию выполняется вход. Посмотреть и скопировать ключ можно в WALIOT.Админ, в разделе «Организации».
Все веб-приложения Waliot (в том числе WALIOT.Навигатор и WALIOT.Админ) доступны только по HTTPS.
Администратор в WALIOT.Админ (Панели администратора) может создать пользователя, указав:
Есть два варианта настройки:
1. Ограничение доступа к объектам
2. Ограничение доступа к функциям
Если требуется ограничить доступ не к объектам, а к функциям системы (например, отчеты, уведомления), используйте роли и разрешения. В этом случае создавать отдельные организации не нужно.
Если доступ нужен постороннему — клиенту, подрядчику или партнеру — учетную запись заводить не требуется: WALIOT.Шеринг дает ссылку, по которой видно местоположение только выбранных объектов, с ограничением по сроку действия и с возможностью отозвать доступ в любой момент.
Роль задает верхнюю границу возможностей и старшинство пользователя — кого он может заводить и редактировать. Фактический набор доступов настраивается разрешениями конкретного пользователя в пределах его роли. Сами роли не создаются и не редактируются: это фиксированный список.
Доступ к разделам определяется не ролью, а конкретными разрешениями: если нужного разрешения нет, запрос отклоняется. Роль лишь ограничивает набор разрешений, которые вообще можно назначить. Проверьте права в панели администратора и при необходимости добавьте разрешения.
Администратор может задать пользователю новый пароль в WALIOT.Админ (Панели администратора): ввести пароль вручную или воспользоваться кнопкой автоматической генерации, после чего сообщить новый пароль пользователю. Узнать старый пароль нельзя — он хранится в необратимо зашифрованном виде.
Если сотрудник не может войти в систему, доступ восстанавливается только через администратора:
Основные причины:
Администратор может управлять доступом через панель администратора:
Рекомендуется использовать отключение (блокировку), если нужно временно приостановить доступ (например, на время отпуска или внутренней проверки).
Платформа использует Yandex SmartCaptcha для защиты от перебора паролей. Капча может потребоваться в двух случаях:
После успешного решения капчи можно повторить попытку входа. Пороги задаются на стороне сервера авторизации и по умолчанию соответствуют указанным значениям.
Если логин и ключ организации указаны верно, система считает неудачные попытки авторизации этого пользователя за последний 1 час. При достижении 10 таких попыток учетная запись блокируется автоматически.
Разблокировать аккаунт может только администратор организации в WALIOT.Админ (см. Q6.7, Q6.8). Это дополняет ручную блокировку администратором и не связано с задолженностью по абонентской плате.
Если с одного IP-адреса зафиксировано 10 и более неудачных попыток входа за 1 минуту (по любой причине — неверный логин, пароль и т. п.), этот IP получает временный бан на 1 час. В течение бана новые попытки авторизации с этого адреса отклоняются.
Счетчик накопительный: он обнуляется, только если прошла целая минута без новых неудачных попыток. Час бана тоже отсчитывается от последней попытки, поэтому обращения во время бана продлевают его — чтобы он снялся, нужно перестать пробовать на час. Успешный вход счетчик неудач не обнуляет.
Бан IP не связан со сменой IP при VPN или мобильном интернете (см. Q6.9): бан наступает только при интенсивном переборе.
В этом разделе собраны ответы на вопросы, связанные с использованием Waliot API, обменом данными с внешними системами (1С, ERP, BI), получением API ключей и отладкой интеграций. Раздел предназначен в первую очередь для интеграторов и разработчиков, которые настраивают взаимодействие с платформой.
Необходимо создать специального пользователя, настроить его роль и разрешения и выпустить для этого пользователя API ключ. API-ключ всегда привязан к конкретному пользователю: роль и разрешения берутся у этого пользователя в момент запроса. Доступ к объектам мониторинга дополнительно сужается — платформа пересекает список объектов, доступных пользователю, со списком объектов самой интеграции; переключатель «Все объекты выбраны» это ограничение снимает.
Ключ выдается только из вышестоящей организации: организация, в которой вы работаете, должна отличаться от организации пользователя, а сам пользователь — находиться в дочерней организации любого уровня. На попытку выпустить ключ пользователю своей же организации платформа отвечает ошибкой «Пользователь не может выдать API ключ для пользователя в своей собственной организации». Ограничение касается только выпуска: перевыпустить, изменить или удалить готовый ключ можно и внутри своей организации.
Важно! API ключ нельзя использовать для входа в веб-приложения. Пользователь, для которого выпущен API ключ, не может авторизоваться в веб-приложениях.
Все запросы выполняются с использованием API ключа.
Ключ передается в заголовке:
Authorization: ApiKey ${API_KEY}Выполните запрос получения данных о текущем пользователе:
GET /api/customers/users/userВ ответ должно вернуться 200 OK с данными пользователя в JSON формате.
Ошибку 401 Unauthorized возвращает запрос с неверным или отозванным (заблокированным) API-ключом. Если ключ верный, но у пользователя нет прав на запрашиваемый ресурс, возвращается 403 Forbidden. API-ключи не имеют срока действия — они работают, пока не отключены администратором.
Если речь идет о 1С:УАТ (1С:Управление Автотранспортом):
Для других конфигураций 1С (в том числе ERP, Бухгалтерия) существует отдельный интеграционный модуль 1С-Waliot от компании «Аркис».
Для интеграции с иными ИТ-системами мы предоставляем документацию по API и консультации по методам и данным; саму интеграцию выполняет заказчик или привлеченная сторонняя компания.
Подключение выполняется через API:
GET /api/customers/organizations/${ORG_ID}/tracking-objects
Authorization: ApiKey ${API_KEY}GET /api/tracks/${OBJECT_ID}?from=${FROM_ISO8601}&to=${TO_ISO8601}
Authorization: ApiKey ${API_KEY}Даты указываются в формате ISO 8601 (рекомендуется в UTC). Часовой пояс и границы периода задаются параметрами запроса, поэтому запрос за 1 марта в часовом поясе MSK вернет границу 2026-02-28T21:00:00Z — это не данные за 28 февраля, а полночь 1 марта по Москве (см. Интеграционные возможности).
Правила расчета у API и веб-приложений общие — расходятся параметры запроса:
Рекомендуется:
Для отладки рекомендуется использовать тестовую организацию, чтобы не создавать тестовые данные в рабочей базе.
Классических webhook (мгновенный HTTP-запрос на ваш URL в момент события) в платформе нет. События-уведомления доставляются по фиксированным каналам: всплывающие в приложении, email, SMS, Telegram, MAX.
Для передачи данных во внешние системы есть ретрансляция: платформа пересылает телеметрию выбранных объектов на ваш сервер по телематическим протоколам (EGTS, Wialon IPS и др.). Работает она пакетами по расписанию, а не по каждой точке в момент приема: данные накапливаются 10 секунд, складываются в очередь и раз в 30 секунд уходят порциями до 50 точек в пакете, поэтому на приемной стороне появляются с задержкой в несколько десятков секунд. Изменения в списке ретранслируемых объектов вступают в силу в течение 5 минут.
Историю за прошедший период можно отправить отдельно: в WALIOT.Админ откройте карточку сервера ретрансляции и нажмите «Отправить историю», выбрав период и объекты. Объекты должны быть заранее привязаны к этому серверу, а отправка идет той же очередью.
Ретрансляция — это не «push по событию», а поток телеметрии; для событийной интеграции обычно используют периодический опрос Waliot API (см. Q7.1).
Частоту обращений к API определяйте по сценарию интеграции: опрашивайте API не чаще, чем обновляются сами данные, кешируйте редко меняющиеся справочники (модели, списки объектов, пользователи) и запрашивайте данные за период одним запросом вместо серии точечных.
Технических ограничений частоты обращений в платформе нет: количество запросов не считается и по интенсивности они не отклоняются. Если интеграция создает избыточную нагрузку — например, запрашивает одни и те же данные каждую секунду, — ее доступ отключают вручную, снятием признака активности у ключа. Поэтому планируемую частоту запросов лучше заранее согласовать с технической поддержкой. Ограничения на неудачные попытки входа — отдельный механизм (см. Q6.11–Q6.13).
Под каждую интеграцию рекомендуется создавать отдельного специального пользователя и выпускать API ключ именно для него: на одного пользователя выпускается только один ключ, поэтому несколько интеграций на общем пользователе не смогут работать с раздельными ключами.
Раздельные пользователи позволяют отозвать доступ одной интеграции, не затрагивая остальные, и разделить их следы в аудите. Учтите: журнал «Действия» фиксирует создание, изменение и удаление, а также входы в систему — запросы на чтение в него не попадают, поэтому по аудиту не видно, какие именно выборки делает интеграция.
Построение отчетов учитывается отдельно, на вкладке «Отчеты» того же раздела. Роль и права такому пользователю выдавайте по принципу минимально необходимых: только те разрешения, которые действительно нужны интеграции (например, для выгрузки данных достаточно прав просмотра). Подробнее об API-ключах и правах — в разделе «Пользователи»; как получить доступ к API — см. Q7.1.
Отдельного метода, который вернул бы уровень топлива на заданную дату, в API нет. Текущий уровень отдает GET /api/states/{id}, уровень на конец произвольного периода — GET /api/tracks/{id}, а показатели в разрезе отчета получают, построив сам отчет:
POST /api/reports?type=FUEL_CONSUMPTION&format=JSON&version=VER_3
Authorization: ApiKey ${API_KEY}
{"orgId": ${ORG_ID}, "objects": [${OBJECT_ID}], "intervals": [{"from": ${FROM_ISO8601}, "to": ${TO_ISO8601}}]}Тело запроса описано в спецификации схемой ReportInfo; сервис принимает и сокращенный вариант из трех полей — остальные подставляются из настроек выбранного типа отчета.
В ответе таблица table.rows[]. Уровень топлива на конец периода — поле toFuel в строках с типом DATE_TOTAL (итог за день) и EQUIPMENT_TOTAL (итог по одному датчику за весь период; при нескольких баках таких строк будет несколько). Рядом приходят fromFuel, totalFactFuelConsumption, fuelAddAmount и fuelAddCount, fuelLeakAmount и fuelLeakCount.
Чаще всего нужное поле «не находится» из-за версии формата. При version=VER_3 объемы приходят целым числом в миллилитрах. В более старых форматах VER_1 и VER_2 объемы приходят строкой в литрах, округленной до двух знаков. Если параметр не передать, применяется VER_1: строка таблицы выглядит как {type, trackData, values}, где values — массив значений по позициям, а названия столбцов лежат в отдельном поле отчета columns. Искать в такой строке поле по имени бесполезно.
Соответствие «столбец отчета — имя поля» берите из самого отчета: в поле tableColumns[] у каждого столбца есть field. Эндпоинт GET /api/reports/custom/default-report-column-types описывает столбцы произвольных отчетов, и имена там могут отличаться: «Уровень на конец периода» там называется endFuel, тогда как в «Расходе топлива» поле называется toFuel.
По нескольким объектам сразу строится тип GROUP_FUEL_CONSUMPTION («Расход топлива по группам») — поля те же. Что доступно у каждого отчета, возвращает GET /api/reports/list: тип, группа, форматы, признак многообъектности, использование геозон и список требуемых системных меток (см. Q1.15).
Без отчета уровень на конец периода можно взять из трека:
GET /api/tracks/${OBJECT_ID}?from=${FROM_ISO8601}&to=${TO_ISO8601}&event-types=FUEL_ADD,FUEL_LEAK
Authorization: ApiKey ${API_KEY}В блоке end.fuelValues по каждому баку приходят current (уровень) и total (объем бака) в миллилитрах; суммарный уровень — сумма current по бакам, дополнительные емкости в нее не входят. Параметр event-types обязателен: без него заправки и сливы в ответ не попадут, а расход посчитается как разница уровней на начало и конец периода — после заправки он окажется занижен, после слива завышен.
Нормы расхода объекта отдает GET /api/customers/tracking-objects/{id}: summerFuelConsumption и winterFuelConsumption — в литрах на километр (в интерфейсе те же значения показаны в литрах на 100 км), parkingFuelConsumption и motohourFuelConsumption — в литрах в час. Текущий уровень топлива в GET /api/states/{id} лежит в поле fuelValues — номер бака и уровень в миллилитрах; в отличие от трека, объем бака здесь не передается, и дату метод не принимает.
Готовый пример такого запроса на 1С — в примерах запросов Waliot API. Почему цифры из API могут отличаться от отчета в интерфейсе — см. Q7.9.