Несколько тревожный кнопок

пусть генерируется простое событие?!

Тревожное сообщение содержит такой параметр как SOS, именно его нужно "выдергивать" из сообщений: пишется программа на сервер для реагирования по тревожным сообщениям от объекта. Более точно отпишусь чуть позже.
Суть проблемы в том, чтобы заставить корректно работать несколько датчиков с типом "Тревожная кнопка" у одного объекта.
Или может есть другие варианты?

Добрый день!

В настоящее время мы с Андреем работаем над решением следующей задачи - передача тревожных сообщений с объектов GPS на пульт ПЦН в формате ContactID. Для этого в Wialon'е настроен ретранслятор, который пересылает сообщение на сервер нашей организации. Для этого написан приёмник GPS сообщений по протоколу IPS. Суть этого приёмника - приём сообщения, генерирование сообщения в формате ПЦН и передача его в ПЦН. В ходе разработки, заметили, что если создать для объекта датчик типа "тревожная кнопка", и при сработке этого датчика виалон расценивает это сообщение как тревожное и передаёт в IPS-строке на наш приёмник слово "SOS", по которому происходит передача сгенерированного contactid  ПЦН. Из-за высокой частоты GPS-сообщений, поступающих с ретранслятора на наш приёмник, считаем нецелесообразным производить обработку каждого из них. Поэтому обрабатываются только тревожные сообщения, содержащие в себе "SOS".
Например. Есть трекер, у него два датчика "тревожная кнопка". Первый датчик на низкий заряд  батареи, второй датчик настроен на один из входов трекера. При низком заряде срабатывает датчик заряда батареи и на наш приёмник начинают поступать IPS-сообщения SOS. При этом если сработает датчик одного из входов, IPS-сообщения также будет содержать SOS. Но все последующие сообщения, ретранслируемые к нам не будут содержать SOS, несмотря на то что датчик заряда батареи в системе wialon всё ещё в тревожном состоянии.

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

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

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

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

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

Пока печатал, родилась идея. Возможно ли реализовать в вашей системе следующий функционал - при срабатывании какого-либо уведомления добавить действие "Добавить параметр в ретранслируемое сообщение. ИМЯ ПАРАМЕТРА = ЗНАЧЕНИЕ"?
Имя параметра и передаваемое значение задаются при настройке действия на уведомление. Т.е. при срабатывании, например, уведомления на выход из геозоны, добавить параметр "OUTOFZONE=1".

Это позволило бы интегрировать Wialon практически с любым ПЦН и в разы расширить возможности мониторинговых/охранных компаний по контролю за подвижными объектами.

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

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

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

stolyarchuk
Вопрос, а Вы при получении параметра SOS вне зависимости будь то нажата кнопка паники или это низкий заряд батареи - генеририруете один и тот же Contact ID код или вместе с SOS все же идут еще какие то значения по которым можно понять что это конкретно. И в зависимости от них генерится тот или иной Contact ID код?

GoGPS , разные. Чтобы оператор ПЦН мог по коду определить характер тревоги: удар, наклон (погрузка на эвакуатор) и т.д. Через разбор IPS-строки не совсем удобно контролировать такие параметры как уровень топлива - придётся писать таблицу перерасчёта, при чём для каждого объекта свою. А это уже реализовано в Wialon. И много чего другого - контроль геозон, остановки/стоянки (полезно при сопровождении грузов). Хотелось бы всё же эти "вкуснейшие плюшки" Wialon проинтегрировать в ПЦН.

shal , POST/GET не нашёл в уведомлениях, попробуем с Андреем поискать вместе. Но это лучше чем емейл - как минимум 2 MTA выпадают из канала передачи данных. К тому же наша компания ставить перед собой задачу сделать интерфейс оператора ПЦН единым для обоих типов объектов: подвижных и неподвижных. Считаем этот вариант более рациональным и масштабируемым в плане людских ресурсов, чем содержать штат узконаправленных операторов.