mapa wrote:

Добрый день, Bakhtiyar_KZ!

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

Кроме того, напомню, что в системе Wialon есть возможность регистрировать свободные события, в том числе как бы оставлять комментарии в свободном виде - совершать "Запись в журнале объекта". То есть в момент срабатывания уведомления можно сразу оставить такую запись. Подробнее про этот функционал можно прочесть по ссылке https://wialon-help.link/866b01ac
Если это решение не подходит, пожалуйста, объясните почему и приведите детали, ответив на вопросы выше. Спасибо!

Извините за вмешательство в беседу, но хотел бы сказать, что я сталкивался с таким кейсом. Мониторили стационарные объекты типа пунктов видеофиксации на трассах. Задача больше походила на охрану и реагирование. В обычном ПО для мониторинга недвижимости обычно есть возможность не только получать "сработки", но и протоколировать ход их отработки в самом ПО, выбирая действия типа "вызов экипажа", "прибытие экипажа", "вызов ответственного" с комментариями о том, что реально стряслось на объекте и автоматической фиксацией времени выполнения этих действий дежурным. Конечно, Wialon не воспроизведет подобный функционал в плане того, что нет классификации возможных действий дежурного, но прокомментировать уведомление возможность, получается, все-таки есть.

Здравствуйте, Бахтияр. Я не представитель Gurtam (к сожалению smile ), но, как правильно заметила Мария, есть возможность писать комментарии при срабатывании уведомления в интерфейсе диспетчера. Дополню лишь ответ скриншотами: при сработке уведомления необходимо нажать ссылку "произвольное событие", после чего в открывшемся окне написать все, что вздумается. Думаю, не надо упоминать о том, что впоследствии есть возможность построить соответствующий отчет по сработавшим уведомлениям, используя журнал объекта smile

24Glonass wrote:

Как надо сделать:

- При экспорте должна сохранятся группа, откуда экспортировалось устройство-транспорт;

- При импорте надо убрать нагрузку по созданию пустого объекта, это лишает смысла сам импорт, получается делаешь объект вручную, смысл импорта не выполняется;

-  при Импорте объект-транспорт должен попадать в свою группу а не проваливаться в "Вне групп". Если группы нет то она должна создаваться из поля "Группа" экспортированного объекта.

Полагаю, что проблема в том, что объекты прав пользователя (объекты, группы, ресурсы и т.д.) имеют свои идентификаторы в Wialon. И если делать экспорт, например, в другой Wialon, то возникнет неоднозначная ситуация.

Приветствую, коллеги!

Вчера обращался в техподдержку по запросу - есть ли возможность отображать в таблице "Поездки между геозонами" только те поездки, в которых по прибытию в конечную геозону, объект провел в ней не менее N количества времени, а не просто по факту остановки в конечной геозоне? Столкнулся с такой проблемой: объект выезжает из точки А в точку B (и эта поездка должна быть зафиксирована), но у него на пути возникает геозона C, захватывающая часть улицы, по которой проезжает транспорт.

Соответственно, если на этой улице ТС произведет остановку по причине дорожной ситуации (светофор, пробка и т.д.), то в таблице будут зафиксированы поездки A -> C, C -> B, а в отчет надо выводить только одну: из A в B (т.е. так, как было по факту). Есть ли в перспективе возможность избавиться от этой ситуации? В текущем функционале, мне ответили, что такой возможности нет.

ansolg wrote:

День добрый.
Удалось кому-то считать поездки (рейсы) между геозонами и объектами (и наоборот) в штатном функционале? Например, рейсы самосвала от экскаватора (объект) на отвал (геозона)? Или, например, бензовоза от АЗС (геозона)  к погрузчику (объект)?

День добрый! В шаблоне отчета есть возможность завести таблицу "Поездки между геозонами", в настройках которой можно выставить, между какими геозонами учитывать поездки, включая использование объектов мониторинга как геозон.

24Glonass wrote:

Прошу рассмотреть предложение по улучшению функции перехода на аккаунт Пользователя из аккаунта Администратора.

Сейчас это выглядит так, из Админ.учетки нажимаешь нужного пользователя, и твой-же интерфейс перезагружается под Пользователем. Это не очень удобно, т.к. потом все равно приходится возвращаться под Администратора и продолжать работу. Перезагрузка интерфейса занимает длительное время.

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

Так вы щелкайте не по самому имени пользователя, а по синей кнопке справа от его имени - "Открыть в новой вкладке", получите дополнительную вкладку с интерфейсом нужного пользователя, но при этом админская вкладка так и останется функционирующей. Или я чего-то не понял?

SpecTechRU wrote:

Добрый день, предлагаю добавить функцию валидации датчиков по геозонам.
Например актуальна валидация топливного датчика по факту нахождения в геозоне. Условно- пока ТС в геозоне, данные с дут-невалидны.

Конкретно есть ситуации например связанные с погрузчиками которые в ходе работы въезжают на крутой пандус (и могут стоять на нем достаточно продолжительное время), что вызывают ложные-слив заправки по ДУТ не фильтруемые штатными средствами ( сильное сглаживание вызывает искажение фактических заправок и сливов).

Если бы была возможность настроить в системе Wialon Hosting валидацию по геозоне в районе такого пандуса, это решило бы вопрос ложных сообщений в отчетах.

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

А если в момент нахождения на пандусе произойдет реальный слив?

Ringo wrote:

Дмитрий Л предлагается использовать график с произвольным датчиком вида:

+ show spoiler

Тогда есть риск нос к носу столкнуться с ограничениями по количеству датчиков в одном графике ) Из-за "лишнего" датчика )

ForS wrote:

Судя по HH это Цезарь, зп предлагают ~60 что для их требований ни о чем
Цезарь контора не айс я так понял?

Извините, не выдержал... с учетом приведенных требований топикстартера и 60 тысяч? В СПб??? о_О
Куда мир катится...

bekstr wrote:

А чем вас Деактивация не устраивает?

a.s.tsybizov wrote:

mars

Вот подобных просьб к нам приходило гораздо больше, чем на импорт группы объектов с автосозданием соответствующей группы. Можете вкратце рассказать, для чего такая возможность была бы полезной?

Это процесс, взаимосвязанный с приостановлением объектов. Из жизни - есть крупный клиент, у которого транспорт работает только летом. Где-то с сентября по май ежегодно они приостанавливают обслуживание объектов мониторинга. В этом случае мы удаляем объекты, но перед удалением экспортируем каждый из них в wlp и складываем полученные файлы в отдельное хранилище. Но помимо этого мы делаем экспорт истории сообщений. После того, как мы получаем от клиента заявку на возобновление обслуживания этих объектов, происходит обратный процесс - поштучное восстановление объектов и импорт истории каждого из них. Этот пример - один из самых характерных. Также немалую часть составляют клиенты, работающие по срочным контрактам с не очень определенной перспективой перезаключения нового контракта (т.е. контракт может быть перезаключен сразу, либо через три месяца, либо через год), и там объемы объектов куда внушительнее. Я уже молчу про мелких клиентов и периодическую рутину с неплательщиками, которых мы можем отключать не сразу за долги и т. д.

Тем, что у нас "пакетный" тариф, в котором деактивация не предусмотрена smile

Nayn wrote:

Вот вам немного моей визуальной магии HTML smile

Либо мигающая красная точка.
Либо мигающая тачка без красной точки (мигание черная, красная тачка).
Стрелка - - это типа перенос All в окно.
PS > можно плюсиком мигать, вместо точки, еще лучше! smile

Кнопочка клевая, действительно было бы прикольней, а вот в чем прикол переноса кнопки All в рамках данной задачи в окно пополнения списка, я не очень понял. Кстати, на мой взгляд было бы здорово "заглобалить" кнопку "Пополнить список" таким образом, чтобы она была доступна не только в панели мониторинга, но и в панелях треков, сообщений, отчетов. Иногда окно пополнения списка мешает при анализе отчетов, но опять же, если надо тут же построить отчет/трек/массив сообщений по другой машине, то после его закрытия приходится опять лезть в "Мониторинг", чтобы добавить нужную машину. Что не очень удобно, когда в голове нужно удержать то, что ты увидел в предыдущем отчете )))

alesnichenko wrote:

Есть много объектов, созданных без опознавательных знаков. из идентификации только ID приборов или номера симок.
Хочу из разных источников опознать объекты и дать опознавательные признаки. Например, в произвольные поля записать название пользователя-владельца.

Вопрос - можно ли пакетное преобразование запустить или скрипт какой-то? Объектов несколько сотен, поэтому вручную - не очень.

Вопрос чисто из любопытства - а что это за источники такие внешние, и как они позволят опознать объект по ID?

mars

Вот подобных просьб к нам приходило гораздо больше, чем на импорт группы объектов с автосозданием соответствующей группы. Можете вкратце рассказать, для чего такая возможность была бы полезной?

Это процесс, взаимосвязанный с приостановлением объектов. Из жизни - есть крупный клиент, у которого транспорт работает только летом. Где-то с сентября по май ежегодно они приостанавливают обслуживание объектов мониторинга. В этом случае мы удаляем объекты, но перед удалением экспортируем каждый из них в wlp и складываем полученные файлы в отдельное хранилище. Но помимо этого мы делаем экспорт истории сообщений. После того, как мы получаем от клиента заявку на возобновление обслуживания этих объектов, происходит обратный процесс - поштучное восстановление объектов и импорт истории каждого из них. Этот пример - один из самых характерных. Также немалую часть составляют клиенты, работающие по срочным контрактам с не очень определенной перспективой перезаключения нового контракта (т.е. контракт может быть перезаключен сразу, либо через три месяца, либо через год), и там объемы объектов куда внушительнее. Я уже молчу про мелких клиентов и периодическую рутину с неплательщиками, которых мы можем отключать не сразу за долги и т. д.

mars wrote:

24Glonass
Спасибо за пояснение!

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

У нас сезонной деактивации нет, так как мы на пакетной тарификации, поэтому как только возникает приостановление обслуживания ряда объектов по той или иной причине, возникает много рутинного труда по их удалению с той же целью, что и писал 24Glonass. И если это 25-30 объектов (больше, слава богу, не было), то вешалка полная. Добавлю только к этому, что, возможно, хорошо бы была возможность также группового экспорта и импорта данных, принятых от объектов.

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

1. Настроить произвольный датчик и назвать его, например, "Данные онлайн". В качестве параметра - выражение "regtime - time", получая таким образом отставание времени генерации сообщения от времени регистрации его на сервере в секундах;

2. Настроить градацию показаний для датчика в таблице настройки. Я взял 4 пороговых показания: "1 - Данные онлайн (зеленый цвет)", "300 - Приемлемая задержка (желтый цвет)", "600 - Задержка (оранжевый цвет)", "1800 и более - Критическая задержка (красный цвет)".

3. Настроить раскраску трека по этому датчику.

Таким образом можно отследить наиболее "глухие" участки, как минимум для того оператора, SIM-карта которого установлена в исследуемый прибор. И там уже по результатам - сопоставлять с картой покрытия других операторов.Либо ориентироваться на рассказы местных мужиков, что в каких краях "более лучше" работает ))

Мне, во всяком случае, такой способ помог избавиться от части проблем в деревнях и районах.

Аналогичная тема уже поднималась на форуме, и достаточно давно, но вызвала больше вопросов (в том плане, что ожидается увидеть на выходе) нежели ответов, как среди сообщества, так и разработчиков. Примерно в тех же моментах, что и описал funhrum

avlsmonitoring wrote:

зависть плохое чувство, просто надо продавать клиентам качественное оборудование и проводить семинары на тему как улучшить бизнес с виалоном и все и у вас будет хорошо , и будет время жаловаться на  эргономику виалона ))

a.s.tsybizov wrote:
avlsmonitoring wrote:

60% звонков клиентов это как изменить время в системе виалон.. ну не догадываются они где это можно сделать. предлагаю вынести на самое видно место и громадной стрелкой выделить "МЕНЯТЬ ВРЕМЯ ТУТ"

Извините за оффтоп, но выдержка у вас, конечно, самая что ни на есть "клиентоориентированная", не хотел бы я с таким обслуживанием столкнуться. И вообще, как же я вам завидую, что 60% ваших звонков - это вот такие "невыносимые" вопросы.

По существу дела же, правильно вам тут написали - вопросы возникают даже по кнопке "Пополнить список", хотя она куда уж видней. И возникают не по одному разу у одного и того же клиента. И касается это многих других элементов системы, которые куда уж очевиднее. А если напихать на главную страницу часовых поясов, базовых городов, составов подсказок и прочего, наболевшего со всех краев СНГ, так про сам мониторинг и забыть можно.

Да где уж мне уж. Удивляет только одно - как при таком размахе с семинарами-медведями-балалайками вам настолько не удается решить такой элементарный вопрос с этими 60%, что аж до кучи восклицательных знаков вас довели люди, которые вам деньги платят smile Ну, и понятия об эргономике у вас весьма занятные, конечно. "Громадная стрелка", "время менять тут!"... Встречное предложение - измените в пользовательском меню название пункта "Справка/Техподдержка", а также содержимое контактов вашего саппорта на "УШЛА НА БАЗУ!!!!". Убежден, что это будет вашим очередным прорывом в стиле вашей работы с клиентами.

avlsmonitoring wrote:

60% звонков клиентов это как изменить время в системе виалон.. ну не догадываются они где это можно сделать. предлагаю вынести на самое видно место и громадной стрелкой выделить "МЕНЯТЬ ВРЕМЯ ТУТ"

Извините за оффтоп, но выдержка у вас, конечно, самая что ни на есть "клиентоориентированная", не хотел бы я с таким обслуживанием столкнуться. И вообще, как же я вам завидую, что 60% ваших звонков - это вот такие "невыносимые" вопросы.

По существу дела же, правильно вам тут написали - вопросы возникают даже по кнопке "Пополнить список", хотя она куда уж видней. И возникают не по одному разу у одного и того же клиента. И касается это многих других элементов системы, которые куда уж очевиднее. А если напихать на главную страницу часовых поясов, базовых городов, составов подсказок и прочего, наболевшего со всех краев СНГ, так про сам мониторинг и забыть можно.

24Glonass wrote:

Прошу перенести (или задублировать) раздел где вносится текущий километраж, часы и тд., из раздела "Основное" автомобиля, в раздел "Техобслуживание",

ни один абонент из тех что начинают использовать раздел "Техобслуживание" не справился с самостоятельной настройкой и согласований этих разделов из-за их разнесённости. Ну и это в принципе нелогично что они в разных местах.

Очередной новый абонент считавший себя "продвинутым" задал в "Техобслуживании" интервалы на весь автопарк и сидел ждал у моря погоды. Не зная что  в "Основном" надо еще вносить настройки, так как это совершенно НЕ очевидно.

Не очень понял, а какие супер-настройки нужно вносить на закладке "Основное"? Галочку автоувеличения счетчика пробега поставить и текущие показания одометра внести, что ли?

Diana wrote:

Добрый день, Александр!

Вы можете ориентироваться на параметр flags  (settings.personal.flags) , чтобы понять используется ли какая-то блокировка (по дням, по балансу) или нет.
см значение тут - https://sdk.s-watcher.com/wiki/ru/sidebar/ … noj_zapisi

К примеру, если блокировка никакая не установлена, flags: 0,  если по дням - то flags: 32  (десятичный формат)

Что касается самого времени (момент блокировки)  - сервер проверяет баланс/дни каждую ночь  в 03:00 (UTC+3), и если условия блокировки наступают, то учетная запись блокируется.

К примеру, Блокировка по дням : 0 дней ,  сегодня у учетной записи  3 дня (daysCounter: 3),  значит в воскрес 28 мая  будет 0 дней, и учетная запись должна будет заблокирована. Тогда ночью 28го в 03:00 учетная запись будет заблокирована.

Диана, огромное Вам спасибо за разъяснения! Действительно, Ваши рекомендации помогли, всё встало на свои места, отчеты адекватные, менеджеры больше за голову не хватаются, всё четко и прозрачно )))

Добрый день!

Обращался в техподдержку, если не ошибаюсь, дважды по этому вопросу, но внятного разъяснения сути алгоритма так и не смог получить, решил написать здесь.Задача стояла по API выгружать из Wialon информацию следующего характера по предстоящим блокировкам:

Учетная запись (клиент) - Статус (блокирован/нет) -  Дата блокировки - Порог блокировки, дн.

Поле "Дата блокировки" рассчитывается на основе полученного порога блокировки (settings.personal.minDaysCounter) и текущего счетчика дней (daysCounter). При этом, если порог блокировки и текущий счетчик дней в настоящий момент имеют нулевые значения, мы делаем вывод о том, что ограничения для учетной записи по дням отсутствуют, о чем выводим информацию.

Ранее (где-то года полтора назад) это работало. Но потом что-то изменилось, то есть, если у клиента осталось 0 дней по состоянию на текущую дату, и порог блокировки у него 0 дней, это не значит, что в дату блокировки он в любое время заблокирован, по крайней мере после 4 часов утра в нашем часовом поясе (так и есть, блокировки наступают гораздо позже). Насколько я понял, мой механизм проверки устарел. Теперь вопрос - как все-таки узнать не только дату, но и точное время блокировки, чтобы сделать вывод о том, есть у клиента ограничения по дням или нет?

Потому что, как я понял, нет возможности средствами API подтянуть признак "Блокировка по дням", чтобы сделать вывод о наличии ограничений. Или я не прав? Менеджеров такой отчет стал очень сбивать с толку, так как в день блокировки по клиентам, у которых текущий счетчик дней равен нулю, в отчет выводится информация "Ограничения отсутствуют".

Diana wrote:
gszi wrote:

Все понял )) Ид нужно было смотреть через отчет в 1с, а я искренне хотел его найти в веб панели виалона)) Спасибо

Добрый день!

Если небольшой лайфак smile - подсмотреть на сайте менеджера  https://forum.gurtam.com/viewtopic.php? … 32#p178532

Ахахах ))) Что ж вы скрывали-то? ) Мне и в голову не могло прийти задать вопрос - "можно ли как-то видеть ID через пользовательский интерфейс?" ) Как я увидел, эта штука действует и на сайт мониторинга, в этом случае ID элемента высвечивается в заголовке свойств объекта/пользователя.

maxev wrote:

Добавление  в отчет  второго графика с произвольными датчиками вам не подойдет?

В принципе, пока да, я про это не догадался ))
Но надо еще посмотреть-подумать, чего вылезти может.

Добрый день!

После обновления системы в части настроек топливных датчиков столкнулся с такой ситуацией. Транспортное средство (ТС) - 2 сообщающихся бака. Учет горючего на двухбаковых ТС ведется по принципу:

1. "ДУТ-1", "ДУТ-2" - настраиваются как произвольные датчики.
2. "Общий объем топлива" - это [ДУТ-1]+[ДУТ-2], настроен как датчик уровня топлива.

Таким образом в режиме онлайн клиент видит показания ДУТ как по отдельности, так и суммарный объем топлива, а в отчете - видит расход топлива и графики только по общему объему (во избежание детектирования ложных заправок и сливов при перетекании топлива из одного бака в другой).

В ряде случаев возникает необходимость краткосрочной перенастройки этих датчиков, например, когда клиент обращается с вопросом по показаниям ДУТ, и с целью диагностики необходимо видеть графики каждого ДУТа по отдельности. В этом случае суммирующий датчик мы делаем произвольным, а отдельные ДУТ - датчиками уровня топлива.

Так вот - всякий раз, когда делаешь подобную замену, при смене типа датчика с произвольного на датчик уровня топлива, приходится заново выставлять флаги настроек топливного датчика. Можно ли сделать как-то так, чтобы при установке типа датчика с "ДУТ" на "произвольный" настройки, связанные с топливом, скрывались, но не удалялись и восстанавливались при обратной замене типа?

chdi
Дополнительно хотел бы вас поблагодарить за консультацию - сегодня реализовал запрос, всё отлично получилось, результаты были весьма любопытными ) По крайней мере, получили четкую картину )