1

Исправить логику обработки уведомлений

Topic: Исправить логику обработки уведомлений

Добрый день.

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

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

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

Возьмем простой пример: прибор Вега по протоколу Wialon IPS. Или ему подобные. Есть параметр, который связан с датчиком зажигание. Есть потребность - сделать уведомление "Движение без зажигания свыше 2 минут". Логика прибора подразумевает, что значение параметра для этого датчика обязательно придет в момент, когда он меняет свое состояние, а также периодически, когда приходит очередная точка по времени. В других сообщениях этого параметра нет.
Как итог, сделать сие простое уведомление без извращений (иначе не могу назвать) физически можно, но оно никогда не сработает.

Можно сделать так, чтобы при обработке сообщения, если нет параметра, оно просто пропускалось-бы, а не прерывало цепочку проверки?
Настройку какую добавить или еще как...

2

Исправить логику обработки уведомлений

Re: Исправить логику обработки уведомлений

Коллеги! Не поверю, что никто не сталкивался с такой "особенностью" уведомлений Виалон и не хочет ее исправить.
Голосуем, не стесняемся. smile

3

Исправить логику обработки уведомлений

Re: Исправить логику обработки уведомлений

Поддержу. Я занимаюсь разработкой прошивки для устройства, которое работает по протоколу Wialon IPS. Передача параметров не в каждом сообщении сделано намеренно - ради экономии трафика и размера черного ящика на устройстве.
Сейчас приходится искать обходные пути. Получается, чтобы сейчас заработали уведомления, нужно передавать порядка 20-30 параметров в одном сообщении. То есть, если где-то в каком-то параметре поменялось одно значение, то я вынужден передавать еще 29 неизменившихся параметров. Избыточность просто колоссальная. Большинство М2М тарифов имеют ограничение в 20-50 МБ. С этой логикой мы и в 50, и в 100 МБ не уложимся...

4

Исправить логику обработки уведомлений

Re: Исправить логику обработки уведомлений

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

В текущей реализации уведомлений этого не избежать, о чем и subj.

5

Исправить логику обработки уведомлений

Re: Исправить логику обработки уведомлений

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

Tatsiana Kots
Ex-Business Analyst, Gurtam
6

Исправить логику обработки уведомлений

Re: Исправить логику обработки уведомлений

Спасибо, ожидаю с верой в успех.

7

Исправить логику обработки уведомлений

Re: Исправить логику обработки уведомлений

SanderAMC, добрый день!
Попробовали мы приступить к задаче. Не напрасно разработчики ранее не брались за эту дороботку smile
Для проверки измненения состояния рассматриваются N последних соощений из базы + пришедшее. Нам всегда известен последний параметр, но нет информации о предпоследнем, чтобы их сравнить. Если его нет в N сообщениях, то мы только и можем сделать, что сработать на всякий случай о смене состояния. Если есть, то можем сравнить и сделать выводы.
По итогу полноценного выхода из ситуации не можем найти, к сожалению.
Можно попробовать не очень хорошее решение для проверки этих N сообщений.
Тогда уведомление будет работать, как ожидается, в случаях, если трекер не прислал параметр только в одном единичном сообщении, например, одно sos сообщение.
Если отслеживается параметр, который приходит в начале и конце события, например, поездки, то тут не получится.
Если непонятно что-то объяснила, уточняйте.

И вопрос к знатокам: есть ли смысл делать такое полурешение? Сколько процентов случаев мы таким образом закроем? Не слишком ли запутанно и сложно?

Tatsiana Kots
Ex-Business Analyst, Gurtam
8

Исправить логику обработки уведомлений

Re: Исправить логику обработки уведомлений

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

Что мешает сделать так для Wialon? Это очевидно будет быстрее, чем брать n последних сообщений и их анализировать. А вдруг n мало? Тогда надо брать k. smile
В итоге будет получено ровно то, что я вначале темы писал, без полумер и полурешений.

9

Исправить логику обработки уведомлений

Re: Исправить логику обработки уведомлений

SanderAMC wrote:

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

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

Tatsiana Kots
Ex-Business Analyst, Gurtam
10

Исправить логику обработки уведомлений

Re: Исправить логику обработки уведомлений

Чего-то я не догоняю...
Есть группа сообщений, в части из которых есть нужный параметр, в части нет. Он меняется в процессе. Допустим, в 1-3 сообщениях его не было - в телеметрии его тоже не появилось, в 4 он имеет значение 3, попал в телеметрию. В 5-6 его нет, в телеметрии остается 3. В 7 его значение опять 3, не изменился, в телеметрии остается старое значение. Делаем вывод - не изменился.
В 8-9 его нет, в 10 его значение 5. Смотрим телеметрию, там 3, а пришло 5. Делаем вывод - изменился.

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

11

Исправить логику обработки уведомлений

Re: Исправить логику обработки уведомлений

SanderAMC wrote:

- в телеметрии его тоже не появилось, в 4 он имеет значение 3, попал в телеметрию. В 5-6 его нет, в телеметрии остается 3. В 7 его значение опять 3, не изменился, в телеметрии остается старое значение. Делаем вывод - не изменился.
В 8-9 его нет, в 10 его значение 5. Смотрим телеметрию, там 3, а пришло 5. Делаем вывод - изменился.

Если мы в условно телеметрию не записали последнее значение, т.е. 5 в последнем случае, то у нас можно считать этого значения нет, мы  не можем его с чем-то сравнивать. С тех пор как оно пришло - оно стало последним. Значение 3 - предпоследнее. Оно уже затерлось последним актуальным 5 и его нет в телеметрии, только в сырых данных X сообщений назад.

Tatsiana Kots
Ex-Business Analyst, Gurtam
12

Исправить логику обработки уведомлений

Re: Исправить логику обработки уведомлений

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

FFA0-0BBB-8911-15BB

https://www.reg.ru
13

Исправить логику обработки уведомлений

Re: Исправить логику обработки уведомлений

RedRock wrote:

А если рассмотреть вариант при котором сам пользователь будет выбирать какой параметр будит в каждом сообщении, например во вкладке дополнительно внедрить такой функционал?

Я имею ровно ту потребность, которую изложил в теме. Никаких иных замен, подмен  либо альтернатив я не рассматриваю. Поэтому прошу Вас создать свою тему со своим предложением.
Спасибо.

14

Исправить логику обработки уведомлений

Re: Исправить логику обработки уведомлений

tata wrote:
SanderAMC wrote:

- в телеметрии его тоже не появилось, в 4 он имеет значение 3, попал в телеметрию. В 5-6 его нет, в телеметрии остается 3. В 7 его значение опять 3, не изменился, в телеметрии остается старое значение. Делаем вывод - не изменился.
В 8-9 его нет, в 10 его значение 5. Смотрим телеметрию, там 3, а пришло 5. Делаем вывод - изменился.

Если мы в условно телеметрию не записали последнее значение, т.е. 5 в последнем случае, то у нас можно считать этого значения нет, мы  не можем его с чем-то сравнивать. С тех пор как оно пришло - оно стало последним. Значение 3 - предпоследнее. Оно уже затерлось последним актуальным 5 и его нет в телеметрии, только в сырых данных X сообщений назад.

В чем сложность хранить в телеметрии слепок текущего и прежнего значений параметров?

15

Исправить логику обработки уведомлений

Re: Исправить логику обработки уведомлений

SanderAMC wrote:

В чем сложность хранить в телеметрии слепок текущего и прежнего значений параметров?

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

Tatsiana Kots
Ex-Business Analyst, Gurtam
16

Исправить логику обработки уведомлений

Re: Исправить логику обработки уведомлений

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

А если связаны, прошу описать, что именно и как было сделано, что изменено, максимально подробно. Спасибо.

17

Исправить логику обработки уведомлений

Re: Исправить логику обработки уведомлений

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

Tatsiana Kots
Ex-Business Analyst, Gurtam
18

Исправить логику обработки уведомлений

Re: Исправить логику обработки уведомлений

tata wrote:

То, что было установлено по датчкам, касается темы по ссылке.

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

Так где правда, я уже путаюсь... ?

19

Исправить логику обработки уведомлений

Re: Исправить логику обработки уведомлений

SanderAMC wrote:
tata wrote:

То, что было установлено по датчкам, касается темы по ссылке.

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

Так где правда, я уже путаюсь... ?


Добрый день!

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

Diana Cheley
Wialon Hosting Expert
Gurtam
20

Исправить логику обработки уведомлений

Re: Исправить логику обработки уведомлений

Я понял, жаль. И обновление датчиков поломали (обращался отдельно по этому вопросу), и уведомления остались по старому.
Что остается, ... жду решения по теме.