Повторное срабатывание whenChanged цифрового входа GPIO

WirenBoard 6.7 используется для мониторинга состояния дизель генератора, при смене уровня входа - отправляется сообщение.

Сейчас, постояно происходит следующее - после перехода уровнеь в 0, через 5-15 минут в mqtt снова приходит сообщение о нулевом уровне, отчего скрипт отправляет сообщение повторно.

Вот - лог состояний аналогового входа, видно что в 13:25 уровень был низкий и ничего не происходило

А вот - лог состояний цифрового входа, видно что в 13:25 был повторный сигнал о нулевом уровне

Такое происходило и ранее, каждый раз после перехода входа в нулевой уровень
photo_2021-03-22_16-06-36

Как избавится от подобного поведения ?

Добрый день.

Так, единственный кто в “нормальных” условиях пишет в топики wb-gpio это wb-mqtt-gpio, покажите версию

dpkg -s wb-mqtt-gpio |grep Version

а в скрипте, который обрабатывает события на входе есть лог срабатываения?
и еще:
Посмотрите в лог

cat /var/log/messages |grep wb-mqtt-gpio

на предмет записей о перезапуске сервиса, вполне возможно повторная установка текущего значения именно при рестарте, это даже можно проверить:

systemctl restart wb-mqtt-gpio

Пакета wb-mqtt-gpio в системе не установлено(прошивка с фабрики не менялась), в системе стоит wb-homa-gpio 1.19.5, я так понимаю он исполняет эти функции. Никаких записей в логах /var/log/messages.* содержащих слово gpio за несколько дней работы пока были эти срабатывания - нету, текущий аптайм системы - около 30 дней.

Интересно… А для прочих входов Ax такое же поведение?

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

Менять и не обязательно, можно так же по испории посмотреть. И да, надо сделать правило, которе пишет в лог изменения. Причем на паре входов.

так ведь и whenChanged не должен срабатывать, если приходит ноль ещё раз. Вообще гарантий на то, что соощение в mqtt придёт один раз при изменении состояния нет. Есть гарантия, что посленее сообщение соответствует текущему состоянию.

Хорошо, тогда буду учитывать это при написании скриптов

Разве QoS = 2 не гарантирует доставку строго один раз?

Подскажите, какое значение QoS используется для

  • публикации значений в драйверах (если значения отличаются в драйверах, то в первую очередь интересуют gpio и serial) и wb-rules
  • при подписке на топики в драйверах и wb-rules?

Это не про QoS, это на логическом уровне. Например, драйвер при старте отправляет текущие значения в MQTT. Или вот wb-mqtt-serial с соответствующей настройкой может публиковать даже неизменные значения раз в N секунд. Т.е. для получателя нет гарантий, что сообщение приходит только об изменениях. Но я не могу представить случаи, где это этого могут быть проблемы.

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

Про логический уровень понял, спасибо.

Для критичных правил, где нужна надёжность, используем свой софт вместо встроенного, и хотелось бы там иметь те же гарантии, что и при использовании софта wb. Отсюда вопрос.
Я сам пытался найти ответ в ваших исходниках.
В wb-rules, насколько я понял, при подписке используется QoS = 2. А вот какой QoS используется в драйверах, в частности, gpio - не смог найти, даже просто в коде ничего не находится по слову “publish”, у вас этот код в приватном репо?

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

И как раз QOS >0 может вызывать “дубль” сообщений, на которые софт реагировать не должен.

Нет, код wb-mqtt-gpio лежит целиком в

Но связь с mqtt реализуются

Повторные срабатывания все еще продолжаются и у меня нет идей как их корректно отбраковывать

photo_2021-04-01_09-45-56

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

var prevValue;

defineRule("diesel_control", {
    whenChanged: "wb-gpio/A1_IN",
    then: function (newValue, devName, cellName) {
    if (newValue != prevValue)
    {
        if ( newValue == 1) {
        runShellCommand('/root/dieselOn.sh')
        }
        else if ( newValue == 0) {
        runShellCommand('/root/dieselOff.sh')
        }
    }
    prevValue = newValue;
    }
});

Ну мне например нужно получить срабатывание скрипта по фронту, то есть по перепаду его с 0 на 1 или с 1 на 0.

А так получается что whenChanged не гарантирует получения изменения значений, а тольно то что в mqtt придет какое то значение, может быть и идентичное предыдущему.

Гарантирует. Пример:

//04_01_test_02.js

defineVirtualDevice("testswitch", {
    title: "testswitch",
    cells: {
        switch0: {
          type: "switch",
          value: false,
          readonly: false,
        },
    }
})
 
defineRule("changeSwitch", {
    whenChanged: "testswitch/switch0",
    then: function (newValue, devName, cellName) {
    	log.info(devName+"/"+cellName+"="+newValue)
    }
});

При переключении вручную - отлично отрабатывает. При

mosquitto_pub -t /devices/testswitch/controls/switch0/on -m 0

Правило срабатывает только на первую установку. И только если предыдущее состояние было “1”.

Мне с трудом представляется контроллер в продакшене, который используется для отладки и редактирования скриптов…