То что постил последнее - да, это еще раз. Последние пару дней все ок.
Тогда подождем еще, у меня, к сожалению, не воспроизводится, пробовал публиковать большое количество сообщений в топик z2m.
В принципе такая же проблема, которая так и осталась без ответа
https://support.wirenboard.com/t/zaderzhka-obrabotki-sobytij-zigbee2mqtt
Так похоже и не воспроизведется - я показываю что одни и те же сообщения от z2m то приводят к зависанию, то нет (несколько дней после рестарта). Может быть написать вам и дать доступ на контроллер когда “начнется”? Просто я сам вижу что в логах особо ничего не отличается, кроме того что процесс вб-рулез начинает жрать очень много ресурсов.
Да я уже несколько топиков видел где эта проблема всплывала но не решилась
Да, для того чтобы решить - нужно воспроизвести (научиться гарантированно воспроизводить).
Реально полезным для этого была бы запись сообщений z2m в топики.
Например mosquitto_sub -v -t zigbee2mqtt/# >>/root/zigbee.log - и сам файл.
Я бы его воспроизводил, публикуя - и получал бы эффект.
Если запустите в screen, например и дадите файл (пусть хоть несколько гигабайт) - то естественно попробую.
Почему бесполезно иметь доступ к контроллеру в котором уже wb-ruls потек - прото он нужен собранный в отладочном варианте.
То есть шаг первый - воспризвести.
Окей, я вас понял, но еще раз повторюсь - подозреваю что лог zigbee2mqtt не поможет - данные идут одни и те же, и в период когда все ок, и когда начинаются лаги. Ну или надо правда выгрузку за несколько суток.
А рулез поставить у меня в отладочном варианте - не вариант?
Да, это, как мне кажется - оптимально.
Не особо поможет, отладку надо будет добавлять уже в процессе. То есть - хочется научиться воспроизводить сиснтетически все ж.
Поймал тормоза. Специально сделал “тяжелую” нагрузку - в нескольких устройствах (floor-termostat-2.x) публиковались значения типа структура, и создавался флуд - много дублирующихся сообщений. /В нормальной эксплуатации структуры отфильтрованы, со флудом борюсь debounce 1/
- Перезапущен wb-rules & zigbee2mqtt
- Через примерно 4-5 часов появились заметные лаги в работе по датчикам, но пропадающие
- Еще через час (~17:00) лаги стали постоянными.
- Включил фильтры и debounce для всех устройств
- Постоянные лаги ушли, стали редкими
- Выключил фильтры и debounce
- Постоянные лаги появились сразу
- Перезагрузил wb-rules, лаги при тяжелой нагрузке исчезли, в течении минут 20 не появлялись.
Весь период в выгрузке mosquito_sub
zigbee_mqtt_messages_09_12_2023.log.gz (673,8 КБ)
Так же есть в варианте лога сервиса
z2m_system_log_09_12_2023.gz (224,3 КБ)
1 лайк
И так… результаты есть? такая же проблема после добавления BHT-002-GCLZB Правила стали зависать или не выполняться совсем…
Да, воспроизводится. Отдал разработчикам, пока решения нет но работа идет.
Добрый, кроме плавающего глюка в контроллере, эти термостаты имеют проблему и сами - они заваливают очередь сообщениями, на их странице на zigbee2mqtt указано решение - параметр debounce 1. Рекомендую даже не 1 а 5 (раз в 5 секунд присылать). Насколько я понимаю даже если контроллер починят то этот костыль останется актуальным для них
1 лайк
Да. Спасибо. Это я видел и сразу сделал. Но пока удалил их, потому что виснет все. Ждём решения…
Странно, у меня вполне себе живет - лаги появляются через несколько дней. Я еще вырезал все атрибута типа структура (расписание итд)
От количества зависит.
Достаточно, например, воспроизвести команды из сообщения - и воспроизводится.
Да, сейчас чиним. Но скорее всего починка сведется к переписываию wb-zigbee2mqtt с нуля.
Андрей, яйца куриц не учат 
но как идея - если переписываете, рассмотрите вариант обрабатывать сообщения от zigbee2mqtt не в json, а в виде атрибутов (есть в настройках у него возможность отдавать так). Насколько я помню по какой то из смежных тем, там в момент преобразования json много ресурсов потреблялось, так зачем кушать кактус
Да, как вариант. Но это уже “настоящие” программисты решат.
Возможно - форкнут GitHub - fullhouse-lab/wirenboard-module-zigbee например или аналогичное.
подтверждаю. Добавление термостата с его расписанием и вот этим вот всем - пренеприятнейшим образом сказывается на быстродействии конструкции в целом.
Причем не сразу. А через несколько часов.
Наблюдения:
- загрузка процессора зависит от качества связи с термостатом. Ничего удивительного.
- похоже, что растет очередь сообщений zigbee. Основания для таких предположений:
термостат люто спамит, присылая каждую секунду полный набор своих параметров. В системе у меня два термостата и датчик VOC (Tuya). Последний тоже спамер тот еще.
С этими тремя устройствами (если ничего не делать, а просто их добавить) у меня LA постепенно, за несколько часов, возрастает до значений 6-7, wb-rules при этом потребляет 150-240% процессора. Как это все работает - очень несложно догадаться: никак.
Мне помогло поставить спамящим устройствам запрет на частую передачу данных.
Датчику VOC debounce = 5, а термостатам и вовсе 10. Никаких данных, которые мне нужны были бы немедленно эти устройства не генерят.
Этот совет тут уже был год назад: Управление Zigbee розетками и реле из node-RED - #8 от пользователя BrainRoot
Прошли сутки, полет нормальный.
в качестве бонуса температура процессора снизилась на 14 градусов
2 лайка
Здравствуйте. Внесли изменения в тестинге. Пожалуйста, обновите пакет wb-zigbee2mqtt, протестируйте. Изменится ли что нибудь в вашем случае.
чтобы не создавать новую тему.
в тестинге обновился. стало лучше, но все равно тормоза при считывании данных Зигби.
в числе указанных 5 датчиков движения которые прямо сорят данными раз в секунду минимум.
на контроллере установлен НА.
он читает данные замечательно и быстро по сравнению с с WB
прикладываю видео отражения в НА и в SVG WB одного и того же датчика освещенности.
перед экспериментом ребутнул.
любые самописные правила отстутствуют. (убрал с контроллера совсем для эксперимента)
через WB включаю свет в правом углу видео и жду отображения данных об освещенности.
как видим WB читает данные в десятки раз медленее. За минуту видео данные до показываемых 96 люмен НА так и не прочитались. они прочитаются секунд за 100.