Некорректная работа уведомлений

Изложил свое мнение как должны работать уведомления.

Введем 4 состояния объекта:
С0 – начальное состояние, объект в не тревожном состоянии давно (больше времени Т2).
С1 – объект перешел в тревожное состояние, но уведомление еще не сработало
С2 – объект в тревожном состоянии дольше времени Т1 и сработало уведомление
С3 – объект вышел из тревожного состояния со сработавшим уведомлением (С2) на короткий период (меньше Т2).

Граф переходов для состояний будет выглядеть следующим образом:

Т.е. как только пришел тревожный параметр, объект переходит из С0 в С1.

Если тревожный параметр перестает приходить и прошло меньше времени Т1, объект из состояния С1 возвращается в состояние С0. Если тревожный параметр приходит дольше времени Т1, объект переходит из состояния С1 в состояние С2 и посылается уведомление.

Если во время нахождения в состоянии С2, перестает приходить тревожный параметр объект переходит в состояние С3.

Если в состоянии С3 снова начинает приходить тревожный параметр и прошло времени меньше Т2, объект возвращается в состояние С2. Если объект в состоянии С3 находится по времени дольше Т2, он переходит в состояние С0.

Вот как-то так. Т.е. контролировать краткосрочный выход из тревожного состояния необходимо только если уже было создано уведомление.

Мы держимся, спасибо. Приходится приспосабливаться.

На счет остального не согласен. В документации нет ни слова, что при наступлении тревожного состояния уведомление может совсем не сработать. Почитайте внимательно документацию.
"Минимальная продолжительность предыдущего состояния. Этот параметр предназначен для того, чтобы исключить излишние срабатывания. Например, объект может на небольшой промежуток времени попасть в нормальное состояние, после чего вернуться в тревожное. Данный параметр необходим для того, чтобы уведомление в таком случае сработало только один раз. "

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

Такой ответ не мотивирует на ведение диалога. Вам нужна обратная связь или нет? В продукте нашли ошибку, указали на нее и вместо "Спасибо большое, изучим, учтём, исправим" от вас получаем "все нормально", издевательское "но вы держитесь" и "доработка не планируется".

Странное отношение.

Параметр Т2 в моем примере очень даже существует в Виалоне, это "Минимальная продолжительность предыдущего состояния". В настойках уведомления есть такой параметр:

Попробую еще раз. Настройки уведомления на картинке. Контролируемая скорость 100 км/ч. Приходят сообщения со скоростью 90, 105, 95, 103, 130, 170, 200, 200 и далее долго 200 км/ч. Между сообщениями 2 сек. Уведомление не сработает.
Из-за скачка 90,105,95 в вашем алгоритме что-то отключается и когда наступает тревожное состояние уведомление уже не срабатывает.

Еще раз.
Если приходит 90, 95, 103, 130, 170, 200, 200 ... уведомление сработает.
Если приходит 90, 105, 95, 103, 130, 170, 200, 200 ... уведомление  не сработает вообще.

Вы считаете это нормально? Вы считаете это соответствует документации?

P.S. Обратите внимание, где красная линия у вас поля на разных уровнях стоят. Не красиво.

Если не Гуртам зачем в категоричной форме писать, что доработка модуля уведомлений не планируется? Пусть сам Гуртам и пишет планирует доработку или нет. Вы партнер Гуртама и участвуете в обсуждении потенциальной проблемы. Это нормально.

По делу ответа не было. Это и не устроило. Общая фраза "Логика работы уведомления при изменении параметра и состояния ровно такая, как описано вами в "оказывается" и ровно такая, как в документации. Иной нет, но вы держитесь." это не ответ по делу. Вот я в 1-ом и 2-ом сообщении написал по делу, подробно и с примерами.

На публичном форуме я написал, потому что служба поддержки Гуртам на этом настояла.

А вот за это спасибо! Вам тоже удачи!

Тему со сменой логики работы модуля уведомлений плюсанул.