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

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

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

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

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

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

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

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

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

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

Добрый день!

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