Отвалилось уже на версии с cron?
ага
У меня та же проблема с остановкой wb-rules из-за:
ERROR: queue handleMessage is almost filled
Как понять вообще из-за чего это. Правил которые тригерятся по таймеру - нет. Только по cron и изменению состояния устройств.
Правильно понимаю, что это может быть связано с недостаточной производительностью WB5 и он тупо не успевает обработать запросы?!
У меня, кстати, и до появления этой ошибки wb-rules падал. Не думаю, что они связаны. И у меня wb6, там с производительностью/памятью все более-менее.
У меня идет перезапуск сервиса, когда queue становится полностью full…
Беда в том, что при перезапуске wb-rules у меня срабатывают все правила и включается свет в 3-и часа ночи в коридоре. Есть правило, которое включает свет в коридоре, когда квартира снимается с сигнализации (сухой контакт)… Как отфильтровать данную ситуацию - понятия не имею 
Проблема с зависанием правил из-за роста очереди сообщений была описана здесь больше года назад. Похоже, это тянется до сих пор.
Ситуация критическая - правила могут перестать работать в любой момент, а новой версии движка с исправлениями до сих пор нет.
Подскажите, как Вы это реализовали?
Никак… Скорее всего watchdog его тушит, т.к. система на время фризится и даже по ssh перестает отвечать.
Странно, как-то мало активности в этой теме.
Я начал самостоятельное изучение причин проблемы. Есть пара вопросов к разработчикам:
- Какие именно сообщения попадают в очередь handleMessage, какие сервисы/библиотеки в неё пишут и читают?
- Драйвер wb-mqtt-serial пишет считанное из порта значение в топик mqtt только когда значение изменилось относительно предыдущего? Или не хранит предыдущих значений каналов и безусловно по каждому чтению пишет в mqtt?
А вы не пробовали, кстати, бету 2.0 ставить? Вдруг там пофиксили. Я зимой экспериментировать боюсь - у меня WB котлом управляет, поэтому все глюки пока подпираю костылями.
Только когда изменилось.
Проблема выглядит сложной.
По предварительным данным, в зоне риска находятся только скрипты, использующие таймер или cron-правила (если в вашем правиле они не используются, но проблемы всё равно появляются, пожалуйста, напишите нам).
Лучшей помощью для нас будет выкладывание полных ваших скриптов (чтобы мы могли их скопировать и воспроизвести проблему), описаний проблемы, логов ошибок. Было бы идеально, если бы всё это, упакованное в архив, вы отправляли на info@contactless.ru с темой “Проблема wb-rules”.
В целях дополнительного изучения, не на критичных объектах, могу посоветовать попробовать:
Тут Экземпляры мигалок на Timer - #16 от пользователя Flagman выяснили, что зависает и без таймеров и cron, даже при использовании простых setTimeout/setInterval (а без них не обходится практически ни один реальный скрипт).
Там же есть конкретные примеры правил, с которыми проблема воспроизводится.
setTimeout/setInterval тоже работают через таймеры.
За ссылку на пример скрипта спасибо.
Чем дело кончилось?
Программист работает над глобальным фиксом wb-rules, так что ждём.
Пользуйтесь startTimer - норм!
Есть ли какие-то продвижения? Тоже столкнулись с этой проблемой.
Может можно как-то сразу определять, что wb-rules не работают и рестартовать? Watchdog перезапустил wb-rules лишь через 5 минут, что довольно долго.
Это попробуйте пожалуйста.