1

Нетривиальное уведомление по отслеживанию длительного статуса

Тема: Нетривиальное уведомление по отслеживанию длительного статуса

Добрый день. Нужна помощь зала.

Есть 2 разных дискретных датчика у объекта. Один сообщает о возникновении некого события (кратковременно переключается в 1), второй - об его окончании (аналогично, кратковременно в 1).  Необходимо уведомить, если длительность этого события превысила порог, допустим 12 часов. Т.е. длительность события существенно превышает длительность сработок датчиков.

Использовать в прямую уведомление по значению датчика, параметра и пр. не получится, очевидно, как и их композиции.

Что пришло в голову - можно использовать группу, куда объект попадет при сработке датчика 1 и удалится при сработке датчика 2; уведомление настроить на эту группу.
Но возник другой вопрос - как уведомить, что объект находится в группе эти 12 часов...

Или есть другой способ, без группы? Мне не приходит в голову.
Есть мысли / идеи / советы?

2

Нетривиальное уведомление по отслеживанию длительного статуса

Re: Нетривиальное уведомление по отслеживанию длительного статуса

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

3

Нетривиальное уведомление по отслеживанию длительного статуса

Re: Нетривиальное уведомление по отслеживанию длительного статуса

Any0ne пишет:

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

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

4

Нетривиальное уведомление по отслеживанию длительного статуса

Re: Нетривиальное уведомление по отслеживанию длительного статуса

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

5

Нетривиальное уведомление по отслеживанию длительного статуса

Re: Нетривиальное уведомление по отслеживанию длительного статуса

У меня была идея по скорости, именно для валидных запредельных значений, т.е. любой объект, попавший в группу заведомо нарушает. Но Гуртам скептически оценивает возможность сработки. Жду, пока объект выйдет на связь / поедет ...

6

Нетривиальное уведомление по отслеживанию длительного статуса

(25/06/2021 09:21:06 отредактировано maxev)

Re: Нетривиальное уведомление по отслеживанию длительного статуса

Если  терминал может присылать  сообщение только во время сработки события - можно попробовать контролировать отсутствие параметра в течении нужного времени  через уведомление "параметр в сообщении".

Одно уведомление помещает в группу, а другое срабатывает если не приходил  параметр отмены.

Или одно уведомление срабатывает и помещает в группу, а другое убирает, а третье гарантированно срабатывает на объекты в группе по отсутствию параметра который терминал не присылает.

7

Нетривиальное уведомление по отслеживанию длительного статуса

Re: Нетривиальное уведомление по отслеживанию длительного статуса

SanderAMC пишет:

У меня была идея по скорости, именно для валидных запредельных значений, т.е. любой объект, попавший в группу заведомо нарушает. Но Гуртам скептически оценивает возможность сработки. Жду, пока объект выйдет на связь / поедет ...

Не работает, не возникает событие "смена состояния". А без смены выдает сработку на каждое сообщение.

8

Нетривиальное уведомление по отслеживанию длительного статуса

Re: Нетривиальное уведомление по отслеживанию длительного статуса

Интересно, а  через пассажиров если провернуть.  По документации,  когда приходит код пассажира - он назначается на объект, если повторно приходит тот же код - пассажир снимается. У нас есть уведомление,  если пассажир не снялся в течении какого-то времени.

Создаем пассажира с кодом 1.   

Записываем два датчика в формулу которая дает 1 при событии и 1 при его прекращении.

Вписываем виртуальный датчик как датчик пассажиров. При сработке 1 - пассажир назначен,  при прекращении 1 - пассажир снят.  Правда есть проблема если датчик события может дать нам 1 когда это событие было включено раннее.

9

Нетривиальное уведомление по отслеживанию длительного статуса

Re: Нетривиальное уведомление по отслеживанию длительного статуса

maxev пишет:

Интересно, а  через пассажиров если провернуть.  По документации,  когда приходит код пассажира - он назначается на объект, если повторно приходит тот же код - пассажир снимается. У нас есть уведомление,  если пассажир не снялся в течении какого-то времени.

Хм... Идея годная, оригинальная. Возьму на заметку.

В итоге пока сделал, как выше предложили, через счетчик моточасов; с определенными доработками конечно. В итоге на интервалах 1-2 часа проверил, работает нормально. Ничего не мешает и на длительных интервалах работать.

10

Нетривиальное уведомление по отслеживанию длительного статуса

Re: Нетривиальное уведомление по отслеживанию длительного статуса

В принципе можно и через POST сделать, но насколько удобно будет получать уведомление не в wialon'е

11

Нетривиальное уведомление по отслеживанию длительного статуса

Re: Нетривиальное уведомление по отслеживанию длительного статуса

В рамках этого решения и проекта только Виалон, внешние сервисы и системы не рассматриваются.

12

Нетривиальное уведомление по отслеживанию длительного статуса

Re: Нетривиальное уведомление по отслеживанию длительного статуса

У меня получилось реализовать что-то подобное в рамках отчётов (чаще всего именно они используются для анализа длительных интервалов). Схема простая, но настройки писать здесь будет относительно долго.
Возможно, вы сможете прислать мне доступ, чтобы я проверил работу схемы на реальных данных. А там, возможно, и уведомления получится добавить. На реальном объекте всегда проще такое тестировать.
Прислать данные можно на support@gurtam.com, указав точное имя объекта, а также имена обоих параметров и интервал времени, когда параметры приннимали ненулевые значения. Также приложите ссылку на данную тему на форуме, чтобы было понятно, откуда ноги растут.

@ Oleg Zharkovsky
Customer Service / Quality Control and Training
"Timely is the best. But still better late than never."
13

Нетривиальное уведомление по отслеживанию длительного статуса

Re: Нетривиальное уведомление по отслеживанию длительного статуса

zark В рамках отчетов все просто, там возможностей больше и непосредственно анализ делается все-же человеком. Суть вопроса была именно в уведомлениях, т.е. автоматическом контроле события. И здесь простых схем не просматривается.
По итогу удалось реализовать потребность, но только для одного уведомления. И если надо сделать 2 и более, по разным датчикам и событиям, то уже не получится...

14

Нетривиальное уведомление по отслеживанию длительного статуса

Re: Нетривиальное уведомление по отслеживанию длительного статуса

Если вы уверены, что это невозможно, то тогда не смею настаивать.
Если вы хотите проверить мой альтернативный вариант, то, пожалуйста, обращайтесь. Я доступен для обсуждения!

@ Oleg Zharkovsky
Customer Service / Quality Control and Training
"Timely is the best. But still better late than never."
15

Нетривиальное уведомление по отслеживанию длительного статуса

Re: Нетривиальное уведомление по отслеживанию длительного статуса

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

FFA0-0BBB-8911-15BB

https://www.reg.ru
16

Нетривиальное уведомление по отслеживанию длительного статуса

Re: Нетривиальное уведомление по отслеживанию длительного статуса

RedRock пишет:

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

Увы, напомню что датчика 2: один поднимает тревожное состояние, а другой снимает тревогу.
Поэтому нельзя, поскольку состояние датчика остается аварийным и объект опять будет добавлен в тревожную группу, в очередной раз пройдет таймер и опять будет сработка уведомления. И так все время, пока другой датчик не отключит первый и объект перестанет в группу добавляться.
А должна быть сработка один раз, поскольку тревожное состояние одно длящееся.

PS А если объект оставлять в тревожной группе, то после первой сработки по истечению таймера далее будет сработка на каждое сообщение, еще хуже.

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

17

Нетривиальное уведомление по отслеживанию длительного статуса

(23/07/2021 12:05:09 отредактировано RedRock)

Re: Нетривиальное уведомление по отслеживанию длительного статуса

Т.е. у вас 4 состояния датчика:
! - Штатное -  Ожидание события
2 - Ожидание - Ожидание периода в тревожном состоянии
3 - Тревога - Отправка уведомления о тревоге
4 - Отработано - Ожидания перехода датчика в штатное состояние

Соответственно нужно 4 группы, по которым нужно описать логику.

Да громоздко, но это гибкое и понятное решения вашей задачи.

FFA0-0BBB-8911-15BB

https://www.reg.ru
18

Нетривиальное уведомление по отслеживанию длительного статуса

Re: Нетривиальное уведомление по отслеживанию длительного статуса

Гибкое - это одна единственная группа и уведомление "превышено время нахождения в группе". Но увы.

При отсутствии питания объекта оба моих датчика передают "норма", поскольку их часть схемы не запитана, поэтому и валидация не поможет, и куча групп не спасет.
Поэтому я могу ловить их значение только при наличии питания и состояния всего 2, сработка (по одному датчику) и норма (по второму датчику). Это RS-тригер по сути, на базе Виалон smile