Самопроизвольное срабатывание скриптов wb-rules на счетчики нажатий

[Aleksandr_Khlebnikov]

Добрый день,

Пока пробую воспроизвести. Предлагаю настроить MQTT-мост следующим образом:

cleansession false

Затем, если всё будет работать корректно, добавьте параметр, если нужно:

qos 1

Также для корректного запуска скриптов после старта системы попробуйте добавить отложенную активацию:

var systemReady = false;

setTimeout(function() {
  systemReady = true;
  log("Скрипты активированы!");
}, 15000);

В правилах добавьте проверку готовности:

if (!systemReady) return;

// основная логика правила

Это должно решить проблему выполнения скриптов до полной инициализации оборудования.

[Igor_Shcherbak]

Добрый день.

@Aleksandr_Khlebnikov

Пока пробую воспроизвести. Предлагаю настроить MQTT-мост следующим образом:

cleansession false

Затем, если всё будет работать корректно, добавьте параметр, если нужно:

qos 1

Да, это уже сделал в прошлый раз:

connection wb-bridge
address 192.168.88.150:1883
topic /devices/+/controls/+/# both 1 wb ""
try_private true
cleansession false
notifications true

@Aleksandr_Khlebnikov

Также для корректного запуска скриптов после старта системы попробуйте добавить отложенную активацию:

var systemReady = false;

setTimeout(function() {
  systemReady = true;
  log("Скрипты активированы!");
}, 15000);

В правилах добавьте проверку готовности:

if (!systemReady) return;

// основная логика правила

Это должно решить проблему выполнения скриптов до полной инициализации оборудования.

В моем случае скрипты правил вообще не перезапускались, они продолжали работать, пока не было света (контроллер жил на встроенной батарейке). т.е. этот код с задержкой бы не отработал.

То же самое и при перезапуске wb-mqtt-serial, этот код с отложенной инициализацией правил не вызовется, а оборудование будет какое-то время недоступно для правил.

[Aleksandr_Khlebnikov]

Добрый день,

Обсудили с коллегами — можно экранировать поведение через флаг готовности: если устройства (bridges) недоступны, скрипты не выполняются.

Также прошу уточнить:
— почему используется питание от разных БП?
— есть ли схема подключения и обмена данными?

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

[Igor_Shcherbak]

@Aleksandr_Khlebnikov

Обсудили с коллегами — можно экранировать поведение через флаг готовности: если устройства (bridges) недоступны, скрипты не выполняются.

Не совсем понял что это значит. что за устройства bridges.

@Aleksandr_Khlebnikov

— почему используется питание от разных БП?

Такого я вроде не писал. Используется один БП для питания всех модулей и контроллера. Отдельный БП только в щите, где стоят модули за WB-MIO-E шлюзом, подключенным чрез ethernet.

@Aleksandr_Khlebnikov

— есть ли схема подключения и обмена данными?

Оборудование подключено на три шины контроллера RS485-1 все щитовое оборудование (реле, диммеры, леды и т.д) на скорости 115200, и две шины с датчиками на каждый этаж (изолированные порты MOD1 и MOD2).

В отдельном щите висят 8 шт. WB-LED, подключенные через WB-MIO-E

[Aleksandr_Khlebnikov]

Добрый день,

С учётом столь сложной схемы подключений, моих компетенций недостаточно для точных рекомендаций по разработке правила.

Рекомендую обратиться к интеграторам — они смогут реализовать решение с учётом всех особенностей вашей системы.
Техническая поддержка не является интегратором и не разрабатывает код

[Igor_Shcherbak]

@Aleksandr_Khlebnikov

С учётом столь сложной схемы подключений

Поясните пожалуйста, что именно в схеме выходит за рамки штатного подключения?

@Aleksandr_Khlebnikov

Рекомендую обратиться к интеграторам — они смогут реализовать решение с учётом всех особенностей вашей системы.

В чем, по вашему, тут нужна помощь интегратора? Я не корректно использую базовые механизмы правил?

Мы же говорим про использование простейших скриптов на счетчики, рекомендованных документацией.

defineRule({
  whenChanged: "wb-mr6c_95/Input 3 counter",
  then: function (newValue, devName, cellName) {
    dev["wb-mdm3_58/K1"] = true;
  }
});

Ситуация, в которой происходит некорректное поведение должна легко воспроизводиться. При пропадании питания на модулях, при включенном контроллере (отрабатывает внутренняя батарейка), и последующем восстановлении питания, срабатывают счетчики с нулевым значением. А в каких-то случаях потом еще и с не нулевым. Вы пробовали такое проделать? Удалось повторить это поведение?

@Aleksandr_Khlebnikov

Техническая поддержка не является интегратором и не разрабатывает код

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

Опыт позволяет мне написать скрипты без использования счетчиков, но я полагал, что WB будет интересно разобраться в таком сайд-эфекте базового функционала. Я с ним получил только включение света ночью. У кого-то может быть более серьезные последствия.

[Igor_Shcherbak]

Путем экспериментов выяснил некую закономерность в поведении счетчиков.

1. Счетчики замыканий (например wb-mr6c_95/Input 3 counter) и счетчики разных типов нажатий (например wb-mr6c_95/Input 3 Long Press Counter или wb-mr6c_95/Input 3 Single Press Counter) при пропадании питания работают по-разному. А именно, счетчик замыканий обнуляется и вызывает срабатывание правила с нулевым счетчиком.
   Cчетчики разных типов нажатий mqtt остаются неизменными и не вызывают сработку правил.

Это легко повторить, просто скинув клемму с устройства и вернув на место.

Работа счетчиков при потере питания

Значения счетчиков до отключения питания

Значения счетчиков при отключенном питании

Значения счетчиков после восстановления питания


Видно, что обнулился только счетчик wb-mr6c_95/Input 3 counter и сработало правило

Apr 04 22:37:14 wirenboard-AC6A3GB6 wb-rules[5389]: INFO: [rule info] switchAction triggered for 'wb-mr6c_95/Input 3 counter'(counter=0)
Apr 04 22:37:14 wirenboard-AC6A3GB6 wb-rules[5389]: WARNING: [rule warning] !!! Switching action on 'wb-mr6c_95/Input 3 counter'(counter=0) is skipped!!! (possible wrong triggered)

2. Вторую часть проблемы (самопроизвольный срабатывание скриптов на счетчики с ненулевыми значениями) тоже смог локализовать. Это связано с работой mqtt-моста с брокером HomeAssistant. Выяснил, что при восстановлении моста, если топики на WB и HA отличаются, то значения топиков WB и HA меняются местами, вместо синхронизации. Что приводит к срабатыванию правил на счетчики.

Напомню, у меня поднят мост на стороне HA c таким конфигом:

connection wb-bridge
address 192.168.88.150:1883
topic /devices/+/controls/+/# both 1 wb ""
try_private true
cleansession false
notifications true

Получается, что при пропадании электричества в НA остается не нулевой счетчик, при восстановлении в WB счетчик обнуляется (правило срабатывает первый раз с нулем), а потом, при поднятии моста в WB записывается ненулевое значение счетчика (и снова срабатывает правило уже с ненулевым значением).

Восстановление моста

Восстановление устройства при отключенном bridge

До отключения:

После восстановления питания счетчик Input 3 Counter сбросился в 0 и сработал скрипт на 0

Apr 04 22:55:28 wirenboard-AC6A3GB6 wb-mqtt-serial[26661]: INFO: [serial client] Events are disabled for <modbus:95:input: 499>
Apr 04 22:55:28 wirenboard-AC6A3GB6 wb-mqtt-serial[26661]: INFO: [serial client] Events are disabled for <modbus:95:input: 500>
Apr 04 22:55:28 wirenboard-AC6A3GB6 wb-mqtt-serial[26661]: INFO: [serial client] Events are enabled for <modbus:95:input: 501>
Apr 04 22:55:28 wirenboard-AC6A3GB6 wb-mqtt-serial[26661]: INFO: [serial client] Events are enabled for <modbus:95:input: 517>
Apr 04 22:55:28 wirenboard-AC6A3GB6 wb-mqtt-serial[26661]: INFO: [serial client] Events are disabled for <modbus:95: reboot>
Apr 04 22:55:28 wirenboard-AC6A3GB6 wb-rules[5389]: INFO: [rule info] switchAction triggered for 'wb-mr6c_95/Input 3 counter'(counter=0)
Apr 04 22:55:28 wirenboard-AC6A3GB6 wb-rules[5389]: WARNING: [rule warning] !!! Switching action on 'wb-mr6c_95/Input 3 counter'(counter=0) is skipped!!! (possible wrong triggered)
Apr 04 22:56:06 wirenboard-AC6A3GB6 wb-rules[5389]: INFO: [rule info] _update_git_status started!
Apr 04 22:56:10 wirenboard-AC6A3GB6 mosquitto[3818]: 1743800170: Client core-mosquitto.wb-bridge has exceeded timeout, disconnecting.

После восстановления mqtt-моста

значения mqtt топика счетчика Input 3 Counter на WB и на HA поменялись местами (0<->17)

И сразу сработало правило на счетчик со значением 17

Apr 04 23:24:08 wirenboard-AC6A3GB6 mosquitto[3818]: 1743801848: New connection from 192.168.88.100:50472 on port 1883.
Apr 04 23:24:08 wirenboard-AC6A3GB6 mosquitto[3818]: 1743801848: New bridge connected from 192.168.88.100:50472 as core-mosquitto.wb-bridge (p2, c0, k60).
Apr 04 23:24:13 wirenboard-AC6A3GB6 wb-rules[5389]: INFO: [rule info] switchAction triggered for 'wb-mr6c_95/Input 3 counter'(counter=17)
Apr 04 23:24:13 wirenboard-AC6A3GB6 wb-rules[5389]: INFO: [rule info] Switching action on 'wb-mr6c_95/Input 3 counter'(counter=17)
Apr 04 23:24:35 wirenboard-AC6A3GB6 tailscaled[15580]: control: netmap: got new dial plan from control

Это странное поведение пока не знаю как победить.
Пробовал добавлять параметры

cleansession true      # управляет сессией на удалённом брокере (WB)
local_cleansession true # управляет сессией на локальном брокере (HA)

QoS ставил в 0.
Но это не помогло.
Может вы подскажете решение.

[Aleksandr_Khlebnikov]

Добрый день!
А можете уточнить для чего используется бридж вообще? HA же может напрямую работать с брокером на контроллере.

[Igor_Shcherbak]

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

[Aleksandr_Khlebnikov]

Добрый день,

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

Однако, как по мне, установка и настройка MQTT-моста в такой схеме избыточна. Это добавляет ещё одно потенциальное звено отказа, что снижает общую надёжность системы.

[Igor_Shcherbak]

@Aleksandr_Khlebnikov

Однако, как по мне, установка и настройка MQTT-моста в такой схеме избыточна. Это добавляет ещё одно потенциальное звено отказа, что снижает общую надёжность системы.

Добрый день.
Буду признателен, если вы подскажете схему без mqtt-моста, когда HA на отдельном железе крутится.

@Igor_Shcherbak

Счетчики замыканий (например wb-mr6c_95/Input 3 counter) и счетчики разных типов нажатий (например wb-mr6c_95/Input 3 Long Press Counter или wb-mr6c_95/Input 3 Single Press Counter) при пропадании питания работают по-разному. А именно, счетчик замыканий обнуляется и вызывает срабатывание правила с нулевым счетчиком.
Cчетчики разных типов нажатий mqtt остаются неизменными и не вызывают сработку правил.

Поясните по первому пункту? Это баг или фича?

[Aleksandr_Khlebnikov]

Добрый день,

Рекомендую проверить следующие параметры модуля реле:

— Режим работы при возобновлении питания
— Безопасный режим

Они определяют, как реле будет вести себя при потере питания или связи — именно эти настройки отвечают за восстановление состояний.

Для подключения к MQTT без встроенного брокера в сторонней системе , выберите интеграцию “MQTT” и укажите адрес внешнего брокера — в вашем случае это IP-адрес контроллера Wiren Board.

[Igor_Shcherbak]

@Aleksandr_Khlebnikov

Для подключения к MQTT без встроенного брокера в сторонней системе , выберите интеграцию “MQTT” и укажите адрес внешнего брокера — в вашем случае это IP-адрес контроллера Wiren Board.

А, ну это значит использовать брокер контроллера для HA напрямую, это не очень подходит под мои критерии разделения ответственности. HA и все его интеграции (в частности z2m) будут неконтролируемо нагружать брокер контроллера. Я хочу этого избежать.

@Aleksandr_Khlebnikov

Рекомендую проверить следующие параметры модуля реле:

— Режим работы при возобновлении питания
— Безопасный режим

Они определяют, как реле будет вести себя при потере питания или связи — именно эти настройки отвечают за восстановление состояний.

Безопасный режим и Режим работы при возобновлении питания связаны с обработкой входов самим реле при потере связи и установке выходов при возврате питания.

Эти режимы никак не связаны со счетчиками нажатий и замыканий реле, публикуемыми в mqtt-брокер при возобновлении питания, на которые реагируют правила. Cчетчики сбрасываются в 0 на самом устройстве, но публикуется в mqtt только счетчик замыканий. Вы пробовали воспроизвести? Я максимально подробно расписал, с картинками, с порядком действий. Это штатшное поведение или ошибка, что счетчики публикуются поразному?

[Aleksandr_Khlebnikov]

Добрый день,

А, ну это значит использовать брокер контроллера для HA напрямую, это не очень подходит под мои критерии разделения ответственности. HA и все его интеграции (в частности z2m) будут неконтролируемо нагружать брокер контроллера. Я хочу этого избежать.

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

У себя я разделил по назначению: — логика и интеграции вынесены на отдельный сервер (там развернут HA и обычный zigbee);
— жизненно важные правила (например, управление светом и перекрытием воды) прописаны непосредственно на контроллере — чтобы они работали даже при недоступности HA.
Это оправдано, учитывая, что Home Assistant может периодически «падать», особенно при большом количестве интеграций.

Вы пробовали воспроизвести? Я максимально подробно расписал, с картинками, с порядком действий. Это штатное поведение или ошибка, что счётчики публикуются по-разному?

Да, несколько дней потратил на мониторинг и проверки — к сожалению, повторить поведение не удалось.

[Igor_Shcherbak]

@Aleksandr_Khlebnikov

Да, несколько дней потратил на мониторинг и проверки — к сожалению, повторить поведение не удалось.

Попробуйте такую последовательность действий:

• Подключить реле mr6c к контроллеру
• На реле включить опрос счетчиков нажатий первого входа (Input 1 counter, Input 1 Single Press Counter, Input 1 Long Press Counter)
• К реле к первому входу подключить кнопку
• Добавить правила на счетчики нажатий:

defineRule({
  whenChanged: "wb-mr6c_95/Input 1 counter",
  then: function (newValue, devName, cellName) {
	log(">>> Test rule triggered for '{}/{}' with counter = {}", devName, cellName, newValue);
  }
});

defineRule({
  whenChanged: "wb-mr6c_95/Input 1 Single Press Counter",
  then: function (newValue, devName, cellName) {
	log(">>> Test rule triggered for '{}/{}' with counter = {}", devName, cellName, newValue);
  }
});

defineRule({
  whenChanged: "wb-mr6c_95/Input 1 Long Press Counter",
  then: function (newValue, devName, cellName) {
	log(">>> Test rule triggered for '{}/{}' with counter = {}", devName, cellName, newValue);
  }
});

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

В логах должна будет появиться запись о сработке правила на Input 1 counter со значением счетчика 0. И не должно быть сработки на другие виды счетчиков

[BrainRoot]

@Igor_Shcherbak

В логах должна будет появиться запись о сработке правила на Input 1 counter со значением счетчика 0. И не должно быть сработки на другие виды счетчиков

Да, так и есть. Поскольу недавно добавили в движок правил более корректную обработку изменения состояний счемчиков нажатий.

@Igor_Shcherbak

Input 1 counter

Я является счетчиком изменений состояний входа и к нажатиям не относится.

[Genikg]

@BrainRoot

Да, так и есть. Поскольу недавно добавили в движок правил более корректную обработку изменения состояний счемчиков нажатий.

В прошивке 2501 stable это работает?

[BrainRoot]

В testing - да.

[Igor_Shcherbak]

Добрый день, Андрей!

@BrainRoot

является счетчиком изменений состояний входа и к нажатиям не относится.

Спасибо за уточнение.
Вы правы, Input 1 counter не является счетчиком типов нажатий, но все же является счетчиком, и вполне может использоваться для автоматизации. Почему бы к нему не применить такую же логику, как и к счетчиком типов нажатий? Вроде в этом нет каких-то противоречий.

Что касается счетчиков типов нажатий, текущее решение (не публиковать в mqtt 0 (нулевые) значения при восстановлении питания) работает, но до первой перезагрузки wb-mqtt-serial. После перезагрузки 0-е значения все равно публикуются, и срабатывают автоматизации).

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

Суть в том, чтобы для счетчиков типов нажатий или соcтояний считать 0 - невалидным значением и никогда не публиковать его в mqtt. Тогда при потере питания и перезагрузке wb-mqtt-serial никогда не будет ложных срабатываний на 0. А любые замыкания входов уже будут ненулевые и будут успешно опубликованы в mqtt.
Остается решить проблему переполнения счетчиков. Предположу, что это можно сделать в прошивке самих устройств, выставляя 1 а не 0, при переполнении.

[BrainRoot]

@Igor_Shcherbak

Вы правы, Input 1 counter не является счетчиком типов нажатий, но все же является счетчиком, и вполне может использоваться для автоматизации.

Да, совершенно верно.
В “автоматизации” перезагрузка какого-то модуля - это авария.
Соответственно это событие и обрабатывается как аварийное.
Например, на производстве: потеря связи с частотником конвейра - приведет к немедленной остановке связанных с ним в цепочке агрегатов. И ПО контроллера, если оно написано грамотно - не будет запускать до устранения аварии.
В контроллере есть все механизмы для обработки нештатных состояний.

@Igor_Shcherbak

Что касается счетчиков типов нажатий, текущее решение (не публиковать в mqtt 0 (нулевые) значения при восстановлении питания) работает, но до первой перезагрузки wb-mqtt-serial.

wb-mqtt-serial не перезапускается, это тоже аварийное состояние.

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

Какой (реальный) кейс способен выхвать похожее и необрабатываемое программно поведение?

@Igor_Shcherbak

Суть в том, чтобы для счетчиков типов нажатий или соcтояний считать 0 - невалидным значением и никогда не публиковать его в mqtt.

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