Добрый день, пишем скрипты на js в веб интерфейсе вайрена. Недавно столкнулись с проблемой ERROR: trying to stop unknown timer: 1006
После чего ложится wb-rules целиком
Мы используем таймеры, допускаем что проблема 100% с нашей стороны, но не можем понять как отследить и решить проблему. Ее не так то просто воспроизвести, wb-rules ложится через месяц, может еще реже.
Могу поделиться скриптами, может так будет проще отследить
Добрый день. Таймер, после того как он отработал - нужно явно зарыть, то есть вот так:
https://wirenboard.com/wiki/Rule_Examples#.D0.94.D0.B5.D1.82.D0.B5.D0.BA.D1.82.D0.BE.D1.80_.D0.B4.D0.B2.D0.B8.D0.B6.D0.B5.D0.BD.D0.B8.D1.8F_c_.D1.82.D0.B0.D0.B9.D0.BC.D0.B0.D1.83.D1.82.D0.BE.D0.BC
И да, покажите скрипт.
UPD: в сообщении о ошибке, “1006” - это как раз timer_id.
DraperyFirst.js (1.1 КБ)
DraperySecond.js (1.1 КБ)
EmergencyLighting.js (1.1 КБ)
lighting.js (850 Байт)
TelegramNotifications.js (739 Байт)
Скорее завтра займусь, не успеваю сегодня.
есть информация?
Здравствуйте! Не получается скачать файлы с правилами. Пришлите, пожалуйста, их в виде архива.
Ошибка “ERROR: trying to stop unknown timer” обычно связана с закрытием уже отработавшего таймера (вызовом функции clearTimeout() для id таймера, который уже отработал). Функция clearTimeout() используется для останавливает работающего таймера. Если таймер отработал, то специально вызывать clearTimeout() не нужно.
Попробуйте определить, какой именно файл правил является источником ошибок? То есть сделать резервную копию всех правил и проверить работу каждого из файлов правил отдельно. Также можно выводить в лог id таймера после создания, чтобы потом определить, с каким таймером проблемы:
motion_timer_1_id = setTimeout(function () {
dev["wb-gpio"]["EXT1_R3A2"] = false;
motion_timer_1_id = null;
}, motion_timer_1_timeout_ms);
log("Motion Timer ID = " + motion_timer_1_id);
Сейчас пришлю все архивом. Нет возможности проверить по отдельности правила, ошибка вылезает не очень часто. А wb-rules может лечь толькотчерез месяц работы
Такое ощущение, что проблема вовсе не в правилах. Подобные правила уже писали не раз, на других объектах куда все серъезнее, ничего не отваливается
Да, вполне возможно, эта ошибка может быть всего лишь предупреждением.
Есть ли еще какие-нибудь ошибки в логах этого и других сервисов? Что значит “ложится”? Какой при этом статус у сервиса? Сервис перезапускается сам или остается в нерабочем состоянии?
Можно посмотреть лог сервиса 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, раньше не было. Была ли сама ситуация - не знаю, всегда проверяю хендл таймера на целоположительность перед гашением.
Есть ощущ, что, действительно, после отработки таймера хендлы перестали инвалидироваться. На скорость не влияет, но неопрятно, конечно.
Вообще тут намного важнее учитывать области видимости переменных. Вот к примеру код
отсюда - он работает без явнго обнуления идентификаторов.