Заметил неприятную вещь.
У меня в правилах настроена реакция на отпускание кнопки-выключателя. Кнопка подключена ко входу DI-DR. Если командой рестартую mosquitto (service mosquitto restart), в консоли брокера ничего не происходит, но WB откуда-то ловит появление ноля на этих входах и отрабатывает, как будто я кнопку отпустил. Иногда у меня каналы включались произвольно, редко, но бывало такое. Сейчас связываю те события с этой же проблемой.
В чем дело? почему появляется 0, его не видно в консоли. Что еще так может прилететь?
Тут загрубить временем старта обработчиков не получается, это ведь не после ребута происходит.
С кнопкой, я, допустим, могу теоретически решить вопрос, нагрузив обработчик еще и анализом нажатия. Мол если было нажатие, а потом отпускание, то обрабатывай. Но как быть с другими ситуациями? У меня будут подключены другие входы от АВР (доп контакты с контаторов) другие устройства… А я, получается, не застрахован от таких “паразитных” сообщений?
То есть фактически две проблемы:
- из mqtt-очереди при рестарте брокера прилетает 0, хотя вход замкнут;
- Иногда на постоянно замкнутом входе появляется 0, а потом 1
Верно?
Если 0 при постоянно замкнутом входе появляется из-за помехи, то в web-консоли вы его не увидите, он тут же изменится на 1. Такое можно отловить, только подписавшись на соответствующий топик.
не так. Вход - не замкнут. На нем - 0. Но изменения нет. Как будто при рестарте правила как бы заново видят этот 0 и отрабатывают. Морда на это не всегда реагирует, и в консоли ноль не пролетает. Но иногда морда реагирует) Под реакцией я имею в виду что у меня два канала включаются, а морда не показывает, что они включились, а иногда показывает) В общем, вы мне написали в другой теме, может я пойму алгоритм этих своих обновления скриптов и их изменений и все станет прозрачнее.
Да, на всякий случай, хотел написать:
следить за тем, что происходит в очереди сообщений, удобно в отдельной консоли командой mosquitto_sub, тут https://wirenboard.com/wiki/index.php/MQTT описано, как ей пользоваться.
Ну и в правилах больше log(); вставляйте на этапе отладки.
использую, логи пишу везде. вопрос не в программе, а в том что то виснет, то ведет себя не понятно. Нет понимания алгоритмов работы операционки, похоже, вот вы мне сейчас кое что прояснили, но чувствую - это капля в море(
и пожалуйста, еще раз проясните. Если у меня этот 0 прилетает при перезагрузке или рестарте, как его отфильтровать? Дело не в ноле, а во фронте. Ноль там должен висеть, но, видимо при перезаписи с ноля на ноль все-равно отрабатывает мое правило.
Я использую конструкцию:
defineRule(self.RN,
{
whenChanged: self.IDN + “/” + self.ICN,
then: function (newValue,devName,cellName)
{
if (newValue == 0)
{
получается, что факт изменения подлавливается (что не верно, т.к. 0 поменялся на 0), и правило, конечно, его отрабатывает. Кнопку еще можно отследить, и то это не верно, не должно быть паразитных фронтов. Подскажите, пожалуйста, конструкцию, которая позволит избавиться от этого.
Я не смог даже воспроизвести такую ситуацию у себя, нужен фрагмент вашего кода. Но, например, если новое значение еще раз стало таким же, как и было то правило, по логике вещей, не должно ничего изменить в системе?
я поставил контроль первого прохода по инициализации, чтобы в первый прогон правило не отрабатывалось и проблему отодвинул.
Не совсем так. Логика в том, что меня волнует не 0 как таковой, а фронт, появление этого ноля. В этом контексте получается, что система после рестарта думает, что кнопку нажали и отрабатывает все это со всеми вытекающими. Но, я думаю, этот вопрос можно закрыть, я нашел обход, пусть так и останется, есть более серьезные проблемы, из-за которых все никак не могу выпустить релиз( Мы их с вашей помощью разбираем в других ветках.