Перестают работать правила wb-rules при включенном zigbee2mqtt

Некоторое время назад начали сбоить настроенные правила. Симптомы - правила просто не работают, но в логах wb-rules только info, никаких ошибок.

Пример:

Sep 01 19:38:36 wirenboard-AMWQEWLS wb-rules[13160]: Device "ppp0" does not exist.
Sep 01 19:38:36 wirenboard-AMWQEWLS wb-rules[13160]: INFO: network/Wi-Fi 2 IP: failed to convert value '', passing raw
Sep 01 19:38:36 wirenboard-AMWQEWLS wb-rules[13160]: INFO: network/GPRS IP: failed to convert value '', passing raw
Sep 01 19:39:36 wirenboard-AMWQEWLS wb-rules[13160]: INFO: network/Ethernet 2 IP: failed to convert value '', passing ra
Sep 01 19:39:36 wirenboard-AMWQEWLS wb-rules[13160]: INFO: network/Wi-Fi IP: failed to convert value '', passing raw

Разок видел:

Sep 01 19:29:18 wirenboard-AMWQEWLS wb-rules[2720]: WARNING: [wbgo_mqtt] MQTT connection lost: pingresp not received, di
Sep 01 19:29:18 wirenboard-AMWQEWLS wb-rules[2720]: WARNING: [wbgo_mqtt] Cleaning up token queue

Самих правил у меня немного и они просты:

  • если включено какое-то реле, то включить другое
  • если замкнут сухой контакт, то включить реле
  • пара правил расписаний на кроне

Экспериментально выяснил, что проблемы решаются или перезагрузкой, или выключением zigbee2mqtt.
На самом контроллере установлены последние обновления.
Зигби через WBE2R-R-ZIGBEE v.1.
Еще есть датчик WB-MSW-ZIGBEE v.3, сначала думал на него (он шлет огромное количество инфы с высокой частотой), но перенастроил его так, что сообщения стали идти с частотой где-то 1 за 10 с, а проблема осталась

Постараюсь дать больше диагностической информации по запросу

В линуксе и консоли не очень, поэтому буду благодарен за примеры команд, которые нужны, чтобы получить эту информацию

Здравствуйте!
Попробуйте отключить сохранение retained-топиков в базу данных у брокера mosquitto:
в конфигурационном файле /etc/mosquitto/mosquitto.conf
поменять

persistence true

на

persistence false

Затем перезагрузить контроллер. Также после перезагрузки удалить саму базу данных /mnt/data/var/lib/mosquitto/mosquitto.db.

1 лайк

persistence false у меня, оказывается, давно уже, но саму БД я не удалял.
сделал всё, но для проявления проблемы понадобится несколько часов

Нет, это не решило проблему. Задержки снова появились (задержки составляю более 5 секунд, до минуты или правило не срабатывает вообще).

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

По зигби подключен только датчик WB-MSW? Если отключить для теста сам датчик, а сервис zigbee2mqtt оставить в работе проблема остается?

Вот диагностический файл:
diag_output_AMWQEWLS_2022-09-02-17.17.31.zip (66.8 КБ)

Датчик не единственный, но сейчас там остались только движки штор и 1 датчик попроще из совместимых с zigbee2mqtt.
Датчик отключил, отпишусь, если или когда проявятся симптомы проблемы.

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

defineRule("livingroom_blinds_open", {
  whenChanged: "livingroom-motor/open",
    then: function (newValue, devName, cellName) {
    
      if(newValue) {
      	publish('zigbee2mqtt/livingroom_left_motor/set', JSON.stringify({"state": "OPEN"}), 2, false);
      	publish('zigbee2mqtt/livingroom_right_motor/set', JSON.stringify({"state": "OPEN"}), 2, false);
      }
      
  }
});

В логах wb-rules и zigbee2mqtt в момент “зависания” ничего нет необычного нет.

Как это связано с WB-MSW

Исключительно не очень удачным в данных обстоятельствах скриптом:

defineRule("WB-MSW-v3_badroom_rules_CO2", {
    whenChanged: "WB-MSW-v3_badroom/co2",
    then: function(newValue, devName, cellName) {
      
      var co2_good = newValue <= 1000;
      var co2_okay = newValue > 1000 && newValue <= 2500;
      var co2_bad = newValue > 2500;
      
      if(co2_good) {
        // no lights
        publish('zigbee2mqtt/WB-MSW-v3_badroom/set', JSON.stringify({"state_l1": "OFF"}), 2, false);
        publish('zigbee2mqtt/WB-MSW-v3_badroom/set', JSON.stringify({"state_l2": "OFF"}), 2, false);        
      }      
      else if(co2_okay) {
        // green
        publish('zigbee2mqtt/WB-MSW-v3_badroom/set', JSON.stringify({"state_l1": "OFF"}), 2, false);
        publish('zigbee2mqtt/WB-MSW-v3_badroom/set', JSON.stringify({"state_l2": "ON"}), 2, false);        
      }
      else if(co2_okay) {
        // red
        publish('zigbee2mqtt/WB-MSW-v3_badroom/set', JSON.stringify({"state_l1": "ON"}), 2, false);
        publish('zigbee2mqtt/WB-MSW-v3_badroom/set', JSON.stringify({"state_l2": "OFF"}), 2, false);        
      }
      
    }
});

Будь здесь проверка перехода через границу, publish в zigbee2mqtt происходил бы не при каждом изменении, а только при переходе.

Возможно, что это не правила отрабатывают с задержкой, а zigbee2mqtt отправляет команды с задрежкой. Проверьте, изменяется ли топик zigbee2mqtt/WB-MSW-v3_badroom/set на новое значение или нет.

А если не управлять шторами, то задержек нет?
Посмотрите загрузку контроллера командой top во время возникновении проблемы.

Возможно, что это не правила отрабатывают с задержкой, а zigbee2mqtt отправляет команды с задрежкой

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

Проверьте, изменяется ли топик zigbee2mqtt/WB-MSW-v3_badroom/set на новое значение или нет.

Как-то у меня в списке каналов mqtt ни одного канала с /set нет. Так и должно быть?

А если не управлять шторами, то задержек нет?

Если не запускать правила, в которых идет отправка через zigbee - задержек нет.

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

В момент возникновения проблемы:


После исчезновения проблемы:
image

Я вижу, что по какой-то причине резко начинает потреблять ЦПУ процесс wb-rules.

В веб-интерфейсе отображаются только топики, соответствующие конвенции: conventions/README.md at main · wirenboard/conventions · GitHub.
Топик, которые создает сам zigbee2mqtt этой конвенции не отвечают, поэтому не отображаются. Чтобы их посмотреть нужно в консоли на них подписаться:

mosquitto_sub -v -t zigbee2mqtt/#

Любое из правил с публикацией в топики зигби вызывает такое поведение wb-rules или какое-то одно правило?

Пока не получается воспроизвести такое поведение…
Попробуйте локализовать место, где возникает проблема. Например, попробуйте оставить только одно правило “livingroom_blinds_open”, где отправляются команды зигби. А правило
“WB-MSW-v3_badroom_rules_CO2” пока удалите, сделав резервную копию.
Попробуйте отправлять команды не сразу две подряд, а, например, с некоторой задержкой.

Выяснил, топики с /set меняются на новое значение.

Я попробовал тут разное, все-таки дело не в отправке в зигби, а в приеме. Заметил случайно. Обычно не пользуемся физическими кнопками на движках для штор, а тут нажал и пошёл выключатель жать (он в WBIO заведен и триггерит правило), а правило-то и не сработало.
Поэксперементировал, убрал (удалил или закомментировал) всю отправку в зигби, вернул WB-MSW-v3 - с этого момента и начался тупняк правил и загрузка wb-rules:
image

Сейчас WB-MSW-v3 шлёт примерно 1 сообщение в 2-3 секунды. Штора, когда закрывается, за 15 секунд шлёт около 8.
По идее это не нагрузка даже для процессора WB6, а чего тогда так тупит?

А в какой конфигурации пытаетесь воспроизводить?

Тестирую с датчиком WB-MSWv3.

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

Как вариант попробовать определить устройства, которые вызывают такое поведение (например, выключив их питанием). Для датчика WB-MSW можно уменьшить период обновления данных по zigbee: Универсальный настенный датчик WB-MSW-ZIGBEE v.3 — Wiren Board

Какие устройства - уже понятно:

  • Движки штор при движении (отправляют текущее состояние)
  • WB-MSW

Сейчас WB-MSW шлет примерно 1 сообщение в секунду, иногда с паузами до 10 с. Изначально было несколько сообщений в секунду. Насколько еще его необходимо замедлить?

Ну и сама проблема этим не решается. Если проблема в парсинге их скриптом wb-zigbee2mqtt, почему top показывает нагрузку именно на wb-rules?

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

В документации в табличке указаны значения.

Скрипт - это правило, написанное на wb-rules. То есть для парсинга топиков используются тоже wb-rules.

Не думаю, что с этим может быть связано.

В документации в табличке указаны значения.

В данный момент настройки соответствуют указанным в таблице, поэтому я и спрашиваю, насколько нужно замедлить?

В данный момент единственное устройство, которое я оставил - датчик WB-MSWv3. К сожалению, нагрузку на процессор или хотя бы потребление конкретного процесса я вывести в виде графика не могу, но визуально наблюдаю скачки нагрузки у процесса wb-rules, то есть проблема сохраняется.

Я верно понимаю, что на стенде подобное поведение получить не удалось?

Я не знаю точно насколько. Попробуйте для теста увеличить минимальный интервал в 2 раза, в 5 раз.
Чего-то явно проблемного с зависанием правил на некоторое время получить пока не получается.

Переделал на 1 раз в минуту. Данные приходят 6 раз, судя по всему, по каждому из показателей.
Вот пример (пэйлод я обрезал):

Sep 08 17:08:07 wirenboard-AMWQEWLS npm[29934]: Zigbee2MQTT:info  2022-09-08 17:08:07: MQTT publish: topic 'zigbee2mqtt/WB-MSW-v3_badroom', payload '{"co2":1031,...
Sep 08 17:08:09 wirenboard-AMWQEWLS npm[29934]: Zigbee2MQTT:info  2022-09-08 17:08:09: MQTT publish: topic 'zigbee2mqtt/WB-MSW-v3_badroom', payload '{"co2":1031,...
Sep 08 17:08:09 wirenboard-AMWQEWLS npm[29934]: Zigbee2MQTT:info  2022-09-08 17:08:09: MQTT publish: topic 'zigbee2mqtt/WB-MSW-v3_badroom', payload '{"co2":1031,...
Sep 08 17:08:09 wirenboard-AMWQEWLS npm[29934]: Zigbee2MQTT:info  2022-09-08 17:08:09: MQTT publish: topic 'zigbee2mqtt/WB-MSW-v3_badroom', payload '{"co2":1031,...
Sep 08 17:08:09 wirenboard-AMWQEWLS npm[29934]: Zigbee2MQTT:info  2022-09-08 17:08:09: MQTT publish: topic 'zigbee2mqtt/WB-MSW-v3_badroom', payload '{"co2":1031,...
Sep 08 17:08:16 wirenboard-AMWQEWLS npm[29934]: Zigbee2MQTT:info  2022-09-08 17:08:16: MQTT publish: topic 'zigbee2mqtt/WB-MSW-v3_badroom', payload '{"co2":1031,...

Соответственно top в момент, когда приходят данные, показывает высокую нагрузку на wb-rules (>50%), потом примерно 40 секунд низкой нагрузки (<10%). Пока идёт нагрузка - правила работают с задержкой (зависают).

Да, наблюдаю похожее поведение. После отправки команды на включение светодиодов начинают приходить данные с датчика WB-MSW Zigbee v3. В это время наблюдается относительно большая загрузка правил. Но выполняться правила совсем не перестают (тестирую правда на контроллере Wirenboard 7). Думаю, что с этим пока ничего не сделать. Попробуйте отправлять команды датчику не одновременно, а через интервал времени:

publish('zigbee2mqtt/0x04cd15fffea0b238/set', JSON.stringify({"state_l2": "OFF"}), 2, false);
setTimeout( function () {
 publish('zigbee2mqtt/0x04cd15fffea0b238/set', JSON.stringify({"state_l1": "OFF"}), 2, false); 
}, 2000);

“Относительно большая нагрузка правил” на WB7 превращается в “тормозят правила” на WB6.
Причем правила тормозят не только при отправке команд, а, как я писал выше, каждый раз, когда мне приходят данные от датчика.

Подведу предварительный итог.
Симптомы: при активной обработке сообщений от зигби-устройств резко растет загрузка процесса wb-rules. Когда нагрузка заканчивается - правила, которые должны были сработать во время “зависания”, отрабатывают.
Решение: отсутствует.

Я нашёл еще одну тему, кажется, со сходными симптомами: Большая задержка при обработке событий от zigbee2mqtt

Очень не хочется к этому апеллировать, но как так получается, я купил устройства с заявленной поддержкой от производителя (датчик, плата и контроллер - все производство WirenBoard) на ощутимую сумму, но от поддержки я получаю ответ: “Думаю, что с этим пока ничего не сделать”? Что мне теперь с этим датчиком делать, отключить, убрать в коробку и радоваться, что дополнительные кнопки, включающие свет, или вытяжка в санузле работают без задержек?

1 лайк