Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
22polyak, спасио за помощь в нахождении проблемы. Заголовки столбцов постараемся исправить в самое ближайшее время. А данные во времени регистрации, как писала выше, будут в начале следующей недели.
22polyak, спасио за помощь в нахождении проблемы. Заголовки столбцов постараемся исправить в самое ближайшее время. А данные во времени регистрации, как писала выше, будут в начале следующей недели.
За время регистрации Я читал.
Написал за столбцы, чтобы вместе с проблемой регистрации разбирали. 
Также идет отображение датчиков в сообщениях которые не должно быть видно.
22polyak, спасио за помощь в нахождении проблемы. Заголовки столбцов постараемся исправить в самое ближайшее время. А данные во времени регистрации, как писала выше, будут в начале следующей недели.
Большое спасибо за добавление функционала. Хотя в данный момент каких-то вопиющих моментов не удалось выявить. но и глубоко в анализ не погружался )
У меня другой вопрос - а визуализировать в отчетах или на треках разницу между временем генерации сообщения и временем его регистрации на сервере планируется? Ну, так скажем, дабы не перекапывать большие массивы данных.
a.s.tsybizov, предложение закономерное . В текущий период мы собираем случаи использования и предложения по работе с временем регистрации сообщений. Развитие этого функционала продолжим, когда будет более четкая картина, как время регистрации используется и какие проблемы остались.
a.s.tsybizov, предложение закономерное
Поделюсь немного опытом - видел подобное в решении для дорожно-эксплуатационных организаций. Ввиду того, что ремонтировались трассы, очень актуально было понимать, где объект не на связи по причине плохого покрытия GSM, а где - по причине проблем с конкретно взятыми приборами. Кроме того, бывает и так, что клиент жалуется на то, что "машина часто со связи пропадает", а по факту - это проблемы с покрытием. Часто помогает замена SIM-карт (использование SIM другого оператора). Впредь буду более тщательно обращать внимание на подобные ситуации и чем могу - помогу в части статистики.
Развитие этого функционала продолжим, когда будет более четкая картина, как время регистрации используется и какие проблемы остались.
Основная проблема понятна: неонлайновость. Отсюда лезут следствия. Наиболее частый вопрос озвучил выше a.s.tsybizov . Следующий - "почему утром отчёт по машине за вчера давал такие цифры, а сейчас - другие". Без времени прихода сообщений на сервер сложно ответить на этот вопрос.
Глубинного смысла в графике разницы между регистрацией события и приходом его на сервер не вижу. Пока. Интересен только факт, что сообщение пришло совсем не тогда, когда зарегистрировалось.
Если эту информацию можно будит использовать в отчетах, то и аналитику будит проще производить. Может стоит добавить в виде виртуального параметра к объекту мониторинга? Тогда и такой мощный инструмент как калькуляция тоже будит доступен, более тога можно раскрашивать трек по разнице между временем сообщение и временем получения сообщения.
Отслеживал уровень сигнала через датчик уровня GSM сигнала, по этому датчику раскрашивал трек, на примере галилео, до 2 красный, 2 и выше синий, правда не все терминалы передают эту информацию...
П.С, По раскраске трек, вы не думали сделать автоматический расчет цвета при раскраски трека, например задаешь скорость 0 бледно красный, а 180 насыщено красны, и при скорости 90 мы получаем просто красны. Или стоит составить отдельную тему, а может это уже реализовано, а я из лесу?
П.С, По раскраске трек, вы не думали сделать автоматический расчет цвета при раскраски трека, например задаешь скорость 0 бледно красный, а 180 насыщено красны, и при скорости 90 мы получаем просто красны. Или стоит составить отдельную тему, а может это уже реализовано, а я из лесу?
Добрый день. Это реализовано.
Свойство объекта, дополнительно,Цвет трека по скорости раскрасить можно как Вам угодно.:)
Наверно, vmtp имеет ввиду сделать автоматически градиентное распределение цвета между заданными минимумом и максимумом.
BoolAB вы совершенно правы, а 22polyak тоже прав, но не в моем вопросе.
Градиент в треке по скорости в целом и сейчас можно настроить. Настройка экспортом переносится на большое количество объектов при необходимости.
Делать автоматический градиент идеи не было ренее. Но первая вопрос, на который пока нет ответа, какая от него будет польза?
В теории по треку по скорости должны быть видны участки, на которых водитель нарушал скоростной режим. При плавном переходе разницы между 50 и 70 практически не будет, т.е. определить участки с нарушениями будет труднее. Также потенциально некоторые цвета могут быть плохо различаемы на картооснове, как предложенный бледно-красный на OSM.
Тему каким то чУдным образом пропустил.)
Есть потребность делать отчет по пробегам по сообщениям ,пришедшим за последние календарные сутки.
Такое будет возможно сделать с данным функционалом?
tata, я не имел ввиду градиент по скорости, я имею ввиду градиент трека по произвольному датчику и разница тут как разница между овалом и кругом - круг это частный случай овала.
В целом не хотелось бы уводить данную тему в сторону и офтопить.
Добрый день. Чтобы сделать градиент трека по произвольному датчику, нужно сначала в самом датчике указать интервалы цвета, потом через дополнительно,цвет трека по датчику задать.
keeper
Есть в статистике когда делаете отчет, просто включите Пробег по всем сообщениям.
Или же Я не правильно понял вопрос? smile
keeper, нет, возможности строить отчеты и треки по времени регистрации не будет.
В случаях, когда сообщения идут без сбоев и значительного черного ящика, разницы между временными промежутками регистрации собщений и их фиксации фактически не будет. Если же у объекта черный ящик за длительный период или он приходит непоследовательно, то посчитанная информация не будет соответствовать действительности.
В Wialon по моему есть возможность настроить датчик по разности параметров сообщений. И по моему есть разные варианты использования датчика в отчётах. Таблицы там всякие и графики. Даже раскрашивать трек, если мне не изменяет память можно)
то посчитанная информация не будет соответствовать действительности.
Это можно указать в примечании мааааленькими буковками. Как мне кажется, замысел не в поиске полных данных, а в аналитике хронологии поступления данных. В принципе, было бы интересно иногда показать клиенту (или для себя сделать выводы) - когда пришли сообщения, и это может быть для клиента важно.
Даже раскрашивать трек, если мне не изменяет память можно)
Дадада, именно это всем и не хватало: раскрасочку сделать. Вы там после отпуска или новогодних каникул? Иногда на практике бесит произвольный цвет трека без наглядности и информативности. Но если кому-то нравится - пусть имеют трек то зеленый, то жёлтый, то голубой. Нам же иногда хочется показать клиенту побольше информации, нежели красоты.
И добрый день! В локал когда появится данный функционал?
tata пишет:то посчитанная информация не будет соответствовать действительности.
Это можно указать в примечании мааааленькими буковками. Как мне кажется, замысел не в поиске полных данных, а в аналитике хронологии поступления данных. В принципе, было бы интересно иногда показать клиенту (или для себя сделать выводы) - когда пришли сообщения, и это может быть для клиента важно.
Нет,дело не в аналитике.
В 1с грузится отчет за предыдущий день,в котором у ТС есть пробег,ног эти данные не были переданы на Виалон (например сети нет). Причем этот отчет в Виалоне может постфактум правиться менеджерами при помощи DrivingLogBook назначением и снятием водителей.
И если это сильно северные места,то данных таких может быть очень много.
При импорте сообщений нет времени регистрации. Это так задумано, если да то очень здорово!
Хотелось бы, что бы так и осталось.
Есть-ли внутренняя переменная для времени прихода сообщения, аналогичная time для времени самого сообщения? Чтобы не городить огород из time-#time...
SanderAMC Поддерживаю и полностью согласен, как писал выше - стоит ввести такую переменную!
