Добрый день, удалось ли решить вопрос?
Добрый день! Если это вопрос к пользователям, то других сигналов от команды WirenBoard, кроме того, что вопрос у разработчиков, не поступало 
Недавно был релиз testing, в анонсе которого упоминалось: “В wb-rules: Исправлен баг с lazyInit;”, но относится ли данный фикс к этой проблеме не понятно.
Переключился на ветку testing. Проблема не исправлена, видимо, еще в работе у разработчиков
Пока не исправлено к сожалению.
Видимо, мне как пользователю нужно искать какое-то обходное решение уже. Исходя из сути проблемы, Вы не дадите рекомендацию, что можно попробовать предпринять?
Последнее, на чем мы с Вами остановились в этой ветке - “тут как раз связано с тем что “большое” количество одновременных публикаций переполняют буфер. Даже не буфер а публикация потока топиков просрачивает проверку публикации первого из них.”
В то же время, как я понял, все пользователи заметили, что проблема возникает только в объемных скриптах: где декларируется много виртуальных устройств. При попытке сохранить изменения в таких скриптах проявляется ошибка.
Значит ли это, что можно попробовать разбить скрипты на части, чтобы в каждом декларировалось поменьше виртуальных устройств?
Ведь, вроде бы, Ваш вывод никак не связан с количеством устройств в конкретном скрипте, а будто бы связан с общим количеством устройств в контроллере… или я ошибаюсь? Спасибо!
Не “много” а “много одновременно”.
Я советую контролы виртуальных устройств создвать через обертку типа “makeNewVirtualControl()”.
Вот тут пример.
Что я понял - это воспроизводится имено при создании контролов “разом”, одним запросом. Если создавать по одному - то независимо от количества ошибок не возникает.
Правильно ли я уловил суть: если мы декларируем виртуальные устройства в скрипте, да еще и много их, да еще и с большим количеством топиков, то при сохранении скрипта устройства начинают создаваться “много одновременно”… а если сделать обертку, которая бы создавала их последовательно и с какой-то паузой, то и проблемы не возникает?
Да, верно.
Но я не настоящий разработчик, поэтому могу, конечно, ошибаться в суждениях.
Спасибо! Попробую так и отпишусь. По идее тогда и мой первый вариант - просто как можно сильнее логически разделять скрипты, а не впихивать в один большой, тоже должен сработать - при условии, что и виртуальные устройства будут разнесены и редактироваться/сохранятся эти мелкие скрипты будут в разное время априори.
Можете попробовать фикс? решит ли проблему.
echo "deb http://deb.wirenboard.com/all experimental.rules-token-wait-timeout main" > /etc/apt/sources.list.d/rules.list
apt update; apt upgrade
1 Like
Есть робкая надежда, что помогло. Внес фикс, попробовал на самом “длинном” скрипте, в котором уже полгода точно не было никаких шансов сохранить его без перезагрузки контроллера - изменения сохранились. Попробовал еще раз - снова сохранились.
В отладочном окне видно, как после сохранения изменений правила объявляются поочередно и в моем “длинном” скрипте этот процесс растягивается 4 секунды.
Да, в целом конечно лучше такие большие скрипты разбить на более мелкие, чтобы не было проблем.
Спасибо! Подскажите, этот фикс теперь так и останется на контроллере, или после обновления на очередной релиз он может слететь и нужно за ним следить?
У вас stable или testing? В testing этот фикс будет доступен, в stable соответственно уже в следующем.
временно перешел на testing, как раз для скорейшего применения фиксов. Все понял, значит к следующему релизу уже могу возвращаться на stable. Спасибо!
Такая же проблема. Когда примерно ожидать в stable?
То же самое в stable, в testing вроде работает!!!
Добрый день!
В конце октября
Добрый день.
На 2025.12.01 поставил все обновления stable ветки.
Как проверить, что исправление этой проблемы применилось?
Или в stable еще нет исправления?