Самый простой способ решения на данный момент - игнорировать в правилах значения счетчиков со значением 0.
defineRule({
whenChanged: "wb-mr6c_104/Input 1 Single Press Counter",
then: function (newValue, devName, cellName) {
if (newValue > 0){
//выполнить нужное действие.
}
}
Это решит все проблемы с ложными срабатываниями.
Единственный минус - будет пропускаться нажатия при переполнении счетчиков (при достижении 65535). Но для режима выключателя это скорее всего произойдет лет через 15-20.
Да, конечно. Первый признак - с ним не будет связи. То есть в /meta/error топике будет “r”.
Такое (точнее, очистку топика ошибки) проверяю с для того чтобы обработать (или игнорировать) события которые произошли на модуле когда с ним не было связи.
Второй - (тоже хорошо проверять) - это uptime модуля. Он читается из решгистров и если внезапно стал менее 10 (например) секунд - модель был выключен.
То есть два возможных события: потеря связи но модель работает (маловероятно, но возможно) и перезапуск модуля.
Спасибо за предложение. Это все костыли , такие же как и тот, что в начале темы. На нем уже год сижу. Хотя, с проверкой на ноль, думаю самый простой. Вы же написали в соседней теме, что вопрос решен в прошивке 2501 тестовой версии? Или тоже есть вопросы? И еще момент, о использовании счетчиков нажатий в правилах, эта проблема ни где не описана. По этому год назад здесь была куча сообщений: у кого ворота ночью открывались, у кого свет во всем доме загорался. Их правда потом разнесли по разным темам, пообещав разобраться и сообщить в каждой теме о решении. А воз и ныне там. Использование счетчиков нажатий не возможно без костылей, так и надо писать в документации. Извините.
Вы почему-то называете нормальную, полноценную, обработку событий костылями.
Да, с публикацией событий счетчиков нажатий. И для вечсьма ограниченных ситуаций.
Просто потому что это логичное поведение.
Я видел эти темы. Ну и помню - про них. Там как раз “свет загорался” из-за того что при разработке проекта не были предусмотрены все возможные ситуации.
Не “костылей”. А полноценной, нормальной обработки всех возможных состояний.
Это логичное поведение с точки зрения обработки абстрактных событий mqtt-брокера (топик изменился, сработало правило).
Возможно логичное, с точки зрения обработки абстрактных счетчиков.
Но оно не логичное с точки зрения обработки событий счетчиков НАЖАТИЙ. Нажатий не было, событие было. Ведь события, маппинг-матрицы не срабатывают при восстановлении питания устройства. А это по сути их аналог на скриптах для связи разных устройств.
Соглашусь с ТС, даже если считать поведение логичным, оно должно быть описано в документации.
Перезагрузка wb-mqtt-serial (например при изменении serial-config) . Текущая “улучшенная” логика (в последнем стейбле) сводится к тому, что при перезагрузке счетчики нажатий c 0 значениями не публикуются в mqtt-топики. Это все. Но если перегрузить wb-mqtt-serial, 0 значения опубликуются и сработают правила.
Да, пусть будет так, не буду спорить. Просто совсем не понятно, для чего эти счетчики, и где их можно использовать кроме выключателей. Большинству ( опять же на истину не претендую), нужно просто отрабатывание типа нажатий в реле и безошибочнуое его передача в контроллер. С ваших слов, если описать все логики вокруг этих счетчиков, чтоб ничего странного не происходило, то проще отключить эти счетчик и использовать правило для трех типов нажатий ( по-моему вами написанное, здесь есть на форуме, оно у меня отлично работает на одном из входов контроллера), наверно оно будет короче по размеру. Я конечно не разработчик, но может можно создать какие то виртуальные входы в самом реле, которые будут срабатывать от типа нажатий( есть события длинного нажатия, сработал виртуальный вход в реле). Зачем их считать? Если есть необходимость их считать, можно это делать в контроллере простым правилом. В общем все ясно. Напишу пока проверку на ноль, мне не принципиален пропуск срабатывания. Домаю дальше это обсуждать нет смысла. И еще момент, если передать топик счетчика в НА, то как его там обрабатывать, какими «костылями»? Счетчик должен считать что то одно, а не 2 события в перемешку, тогда и отделять их друг от друга не нужно.
Почему-то год назад это была проблема, которую собирались решать и оповестить о решении. А теперь, (когда решали и не решили) проблема превратилась в штатное поведение, требующее условно 20 строк логики вокруг трех строчек скрипта на нажатие. Что б можно было безопасно использовать счетчики.
