wirenboard support.zip (2.6 КБ)
Такое ощущение, что проблема вовсе не в правилах. Подобные правила уже писали не раз, на других объектах куда все серъезнее, ничего не отваливается
Да, вполне возможно, эта ошибка может быть всего лишь предупреждением.
Есть ли еще какие-нибудь ошибки в логах этого и других сервисов? Что значит “ложится”? Какой при этом статус у сервиса? Сервис перезапускается сам или остается в нерабочем состоянии?
Можно посмотреть лог сервиса wb-rules так:
journalctl -u wb-rules
Логи всех служб:
journalctl
Также убедитесь, что у контроллера достаточно свободного места на флеш-накопителе и в оперативной памяти.
В файлах правил управления шторами заметил, что после срабатывания идентификатору таймера не присваивается значение null. Добавил комментарии и присвоение:
defineRule("draperyPositionChange", {
whenChanged: "draperyFirst/position",
then: function (newValue) {
if (newValue != 49) {
if (timer) {
clearTimeout(timer);
}
timer = setTimeout(function () {
runShellCommand("perl /usr/bin/akkoFirst.perl.pl " + newValue);
// здесь нужно идентификатору таймера присвоить null, чтобы потом можно было определить, отработал таймер или нет
timer = null;
// после того, как таймер отработал, его ID не сбрасывается в null автоматически. Если впоследствии для ID отработавшего таймера вызвать
// clearTimeout(ID), то как раз и появится сообщение "ERROR: trying to stop unknown timer"
}, 1000);
runShellCommand("perl /usr/bin/akkoFirst.perl.pl " + newValue);
}
dev["draperyFirst"]["position"] = 49;
},
});
Если в ваших файлах правил есть конфиденциальная информация, то тему можно сделать закрытой. Сейчас тему могут просматривать все пользователи.
Из-за этой ошибки: trying to stop unknown timer ложился wb-rules целиком. То есть переставали работать все правила, проблема решалась перезагрузкой контроллера.
Конфиденциальной информации нет, все хорошо.
Нужно попробовать внести изменения.
На друглм объекте похожий скрипт висит, там раьотает уже около полугода, сравню эти скрипты.
Вижу, что используете еще скрипты на Perl. В них не может быть проблемы?
Все же рекомендую при повторении проблемы проверить статус работы сервиса командой:
systemctl status wb-rules
Еще нужно посмотреть лог сервиса wb-rules за период времени, когда возникла проблема (время и дату изменить):
journalctl -u wb-rules --since "2021-12-28 10:00" --until "2021-12-28 11:00"
А также логи всех служб за это же время:
journalctl --since "2021-12-28 10:00" --until "2021-12-28 11:00"
В логах могут быть указаны причины остановки сервиса. Возможно, что сервис не завис, а выполняет, например, бесконечный цикл.
Также убедитесь, что у контроллера достаточно свободного места на флеш-накопителе и в оперативной памяти.
Ок спасибо
Заметил этот же ворнинг на сборке 2110, раньше не было. Была ли сама ситуация - не знаю, всегда проверяю хендл таймера на целоположительность перед гашением.
Есть ощущ, что, действительно, после отработки таймера хендлы перестали инвалидироваться. На скорость не влияет, но неопрятно, конечно.
Вообще тут намного важнее учитывать области видимости переменных. Вот к примеру код
отсюда - он работает без явнго обнуления идентификаторов.
Я был уверен, что по выстрелу таймаута или явному гашению тикера движок это делает сам. Оно было бы логично и понятно, не-се па?
По конкретике - я держу глобальный массив таймеров, часть запущена, часть нет, в изрядном количестве случаев таймер надо прибить до его выстрела (время заранее не известно). Ориентируюсь, согласно доке, на целоположительный хендл, другой-то инфы, кроме него и факта выстрела, нету.
Здравствуйте! Дело в том, что после срабатывания таймера его ID не изменяется. Чтобы понять, было ли срабатывание, надо в функцию-обработчик таймера явно добавить присвоение переменной с ID значения, например, null. Иначе нельзя будет понять, срабатывал таймер или нет.
Здравствуйте! Я и пытаюсь понять, это баг или фича, поскольку уловить логику никак не могу. Хорошо бы объяснить, а не повторять. 
Если таймер срабатывал, колбек должен был быть вызван, это как бы и есть функция таймера, Вы не находите?
Для того же, чтоб изнутри колбека почистить ид таймера, неплохо бы его знать, а параметры в колбек не передаются. Или предлагается для каждого таймера писать свой? У меня десятки таймеров и некоторые надо гасить до срабатывания.
Думаю этот вопрос больше к языку Java Script. Точно такое же поведение наблюдается в node.js и в браузере: после срабатывания таймера или выполнения для него функции clearTimeout(timerID) сам timerID не изменяется. Отличие только в том, что в wb-rules появляется пугающее предупреждение “ERROR: Trying to stop unknown timer”.
При чем тут язык-то? Конкретно дуктейп? Тык поправить можно же.
Я просто не представляю, кому может потребоваться хендл отработавшего таймера.
wb-rules будет рефакториться, это тоже учтем.
Добрый день, нашел источник проблем. Оцените пожалуйста
При открывании и закрывании штор появляется Trying to stop unknown timer. На другом котнроллере с теми же правилами javascript подобной проблемы не было.
ПРимерно на 128 ошибке wb-rules отваливается.
Скрипты ниже:
DraperySecond.js (1.1 КБ)
DraperyFirst.js (1.1 КБ)
1 лайк
Здравствуйте! Запакуйте, пожалуйста, файлы правил в архив и пришлите - файлы js нет возможности скачать.
Какой статус у сервиса wb-rules после того, как он “отваливается”? Есть ли еще какие-либо ошибки в логах? Какая версия пакета wb-rules установлена на обоих контроллерах?
Для воспроизведения проблемы опишите, пожалуйста, какими сигналами и в какой последовательности управляете шторами? Какие модули подключены к контроллеру (внутренние, боковые и внешние)? Пришлите, пожалуйста, архив с диагностической информацией при возникновении проблемы (используйте кнопку Collect diagnostic data на странице Settings->System)
1 лайк