Время прихода сообщений

Гарик, спасибо!

И в самом деле не для всех типов оборудования этот ключик активен. Для Галилео 5.0 галочка "Register server time" отсутствует.

Можно увидеть в логах каждого оборудования.

Эта информация есть на серверах .
Если вы пользуетесь  wialon hosting,то вам следует обратиться   в нашу службу  техподдержки , запросите  время прихода сообщений от
интересующего  вас объекта.

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

Присоединяюсь! И таки непонятно, по каким критериям выбиралось оборудование, для которого реализовано время получения сообщения?  Для Телтоники, скажем, не реализовано , хотя не последний по массовости производитель

Я раньше поискал такую возможность, не нашел, да и плюнул, решил - нет возможности у виалона. а анализировать иногда приходится.

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

Недавно была такая ситуация: случайно заблокировали сим-карту на 6 дней, всё это время объект собирал информацию в буфер, затем при разблокировке сеть gsm появилась и он выложил всё на сервер. При этом в сообщениях недоставало информации по первым 2-м суткам с начала блокировки, буфера хватило на 4 дня. Смотря на сообщения по объекту я никак не мог понять причину отсутствия данных, если бы я видел что сообщения последних 4-х дней пришли в одно время на сервер, то это сразу бы выявило неисправность. Поддерживаю. Хотя бы как дополнительный столбец в сообщениях.
Идея про отчет с разницей по времени сообщения на сервере и меткой времени в самом сообщении от трекера очень нравится.

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

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

В этой ситуации я б рекомендовала настроить уведомление по порете связи. 6 дней, вероятно, можно было бы сократить.
А добавление времени прихода сообщения - задача непростая.
Сейчас действующее решение - по необходимости писать на support@gurtam.com, они вам пришлют необходимый кусок сырых данных, в которых будет время регистрации сообщения на сервере.

tata,  Не из пушки ли по воробьям - запросы в ТП?  И как быть с LOCAL - тоже в ТП?
И какой темп запросов выдержит Ваша ТП, в каких объемах, как часто, если интегратор - 'ищущая" натура ? ))
Масса БД в разных предметных областях кроме времени появления события еще и содержат время создания записи.
При гибкости Вашей БД с добавлением произвольных параметров от приборов добавить такое поле не представляет труда - вроде бы...
Не думаю,что вы хотите спрятать какие-то Ваши внутренние тайминги.
А вот для аналитики мониторинга это был бы большой плюс. Вы же не отрицаете возможности аналитики у интеграторов?
Гораздо проще будет понять и показать проблемы задержки доставки данных клиентам, желающим видеть всё онлайн.

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

Существует. На сайте gurtam.com выделена для описания гарантий страница.

На текущий момент мы не готовы изменить формат сообщения, чтобы он передавал еще и время прихода сообщения на сервер. В первую очередь, потому что необходимо будет предусмотреть совместимость со всеми приложениями, связанными с Wialon, в т.ч. написанными не Gurtam, а партнерами. Также каждое сообщение вырастет на 4 байта, т.е. вырастет трафик для клиентов, количество обрабатываемых данных для web, количества данных для хранения для серверов. Прямо сейчас в Wialon поступает 1250586 сообщений в минуту. Одна небольшая доработка множится на повторяемость и места, где используется, в итоге получается совсем не маленькая доработка.

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

К слову, некоторое оборудование помечает сообщения, которые идут из черного ящика.

tata это уже ближе к сути проблемы. если ситуация такая как вы описываете то вижу 4 варианта:
1. партнер  может опционально для себя включать отображение этих сообщений
2. партнер может нажать кнопку, которая повторяет действия ТП за уазываемый период и выгружает данные
3. Создать в свойствах объекта или еще где-то кнопку "Проверить качество передачи данных", при нажатии на которую для данного объекта (или группы объектов) будет проводится анализ на указываемую в настройках разницу между снятием данных и приходом на сервер
4. Сделать отчет, который анализирует данные не только в сообщениях, но и там где ТП берет данные о получении данных, ведь они все равно на сервере существуют и для администратора системы все равно откуда отчет берет данные.

Изучил правила по Вашей ссылке:

Т.е. создал запрос  в ТП по 1 объекту за один временной интервал
- "При создании запроса в службу технической поддержки компании Gurtam клиентом (пользователем) должны быть указаны следующие данные:...    указаны конкретные элементы, по которым возник вопрос (объект, шаблон отчета, временной интервал и т.д.);"
Создал для сравнения еще 3-4 аналогичных запроса по тому же или другим объектам
Подождал от 4 до 8 часов. -"Время реакции на запрос    8 часов 4 часа    4 часа" (в зависимости от Start -Unlimited)
и вуаля - можно запускать следующую итерацию?.

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

Наверное, даже такие умные трекеры в своих пометках не делают разницы межу 30 секундным и 1,5 часовых запозданием )

Подскажите, какова максимальная глубина хранения логов сообщений (по времени и количеству) для 1 объекта? Можно ли получить логи 2-х-4-х недельной давности по желаемым объектам?  Хранятся ли логи сообщений для каждого объекта в отдельном файле, или все сообщения  для каждого типа прибора хранятся  в одном файле?

Идея классная.
А если еще время прихода сообщений можно было бы использовать в качестве параметров датчика как time только будет параметр timeserver, то можно очень многое анализировать по потерям связи.
Может у трекера просто не хватило памяти что-бы записать какой-то кусок данных а может он прост завис и ничего не писал в память.
Для интегратора в спорных ситуациях было бы очень полезно.

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

Здравствуйте, STAN
Коль скоро Вы упомянули наличие логов, как какое-то решение, то не могли бы Вы хотя бы предоставить ссылку , по которой можно найти ответы на вышеприведенные вопросы.
Приведенный ответ или сформулирован слишком общо, или является отпиской.
Есть ли у самого Gurtam'а количественная оценка этих данных?

Может быть, в логах все-таки нет искомой информации в разумных и гарантированных объемах ?

Добрый день!

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

tata  Только я обрадовался и тут такое (такое в прикреплении)  если на словах, то колонка пуста

Костыль от меня:
Создали группу не на связи, объекты в которые перемещаются по уведомлению потери связи в течении 8 минут. Если ТС вышла на связь, то объект удаляется из группу не на вязе. Уведомления регистрируют в журнале события. В отчет журнал событий вы увидите всю историю потери связи ТС(не забудьте про 8 минут при перемещении, т.е. если в журнале указано 12:38, то фактически потеря связи произошла в 12:30).

Нет прощения, на колени! (шутка). Для этого требуются отдельные сервера? А на локал будет реализовано?

Спасибо, Tatsiana, понятно всё. Подождём, надеюсь - будет удобно-полезно. Мне более интересно появление данной фишки на локал.

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

Также идет отображение датчиков в сообщениях которые не должно быть видно.

a.s.tsybizov, предложение закономерное . В текущий период мы собираем случаи использования и предложения по работе с временем регистрации сообщений. Развитие этого функционала продолжим, когда будет более четкая картина, как время регистрации используется и какие проблемы остались.

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

Добрый день. Это реализовано.
Свойство объекта, дополнительно,Цвет трека по скорости раскрасить можно как Вам угодно.:)

BoolAB вы совершенно правы, а 22polyak тоже прав, но не в моем вопросе.

Тему каким то чУдным образом пропустил.)
Есть потребность делать отчет по пробегам по сообщениям ,пришедшим за последние календарные сутки.
Такое будет возможно сделать с данным функционалом?

Добрый день. Чтобы сделать градиент трека по произвольному датчику, нужно сначала в самом датчике указать интервалы цвета, потом через дополнительно,цвет трека по датчику задать. 

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

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

И добрый день! В локал когда появится данный функционал?

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

SanderAMC Поддерживаю и полностью согласен, как писал выше - стоит ввести такую переменную!

И повторю этот вопрос. А то хочется же использовать. tata, когда?

Жаль. Прямо сейчас клиент задает вопросы по 2 блокам арнави - там пропадания данных в январе, анализировать сложно.
Спасибо за ответ, Tatsiana. Подождём до весны, что ль.

Дык данное событие надо заранее настроить, задним числом январь не обсчитается. Спасибо, проставлю на будущее в настройках.

Спасибо, попробую.

А статус полноты (нормальности) выгрузки нельзя каким-то образом указывать? Ну, например: выгружены (или нет) все события, прерывистость выгрузки, и т.д. Поскольку, при неустойчивой связи блок может выгружать весь день по 5 событий (записей) полный журнал событий, и недовыгрузить, или же он в это время пустой и нормально скидывает по 5-6 событий. Или же: блок весь день на связи, но событий от него не поступает (проблемы со связью, тарифом сим-карты и тд.). По прошествии времени об этом иногда только гадать приходится.

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

Красиво, молодцы! Только, как мне кажется - цвет "от 2 до 10мин" не очень выделяется, почти не виден на фоне обычных - поярче бы. И вопросик: можно ли будет выбирать цвет трека так же по времени регистрации? Было бы наглядно видно, где лучше выгружается, а где не очень. И ждём в Local, весна уже у нас.

Вот ломаю голову. Хочу вывести в отчет не когда объект был онлайн а когда был на связи.
Пример:
2,04,19 у точки в 17ч40мин время регистрации 03,04,19 1ч57мин
Далее идет выгрузка архива
03,04,19 в 5ч53мин время между regtime и time стала нулевой (объект стал онлайн)

Получается, что кусок данных с 2,04,19  17ч40ми по 03,04,19 в 5ч53мин трекер выгружал с 03,04,19 1ч57мин по 03,04,19 5ч53мин.

Можно ли как то вывести в отчет, что объект был на связи с 03,04,19 1ч57мин по 03,04,19 в 5ч53мин на основании данных time и regtime?

Добрый день,

Для того чтобы понять когда именно объект уже вышел на связь и начал слать данные можно сделать следующее.
Создаем датчик. С формулой (regtime-time)/const60
Строим график по датчику и получаем примерно такую картину:

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

Возможно это как нибудь поможет.

maxgandreevich, можно сейчас раскрашивать трек по датчику, а датчик настроить на разницу между временем получения и регистрации.