Коллеги произошел непонятный рестарт wb-mqtt-gpio.service, лог прилагаю ниже. После перезагрузки по ряду дискретных входов появилась логическая единица. Т.к. на WBIO-DI-WD-14 и Модуль ввода-вывода WBIO-DI-HVD-16 заведены импульсные выключатели и работает скрипт на импульсные выключатели, то результатом стало включение по всей квартире света и диспузера, что очень напрягло хозяина.
Как понять что стало первопричиной сбоя? В логах нет ничего подозрительно до сбоя. Откуда копать?
При перезагрузки контроллера подобное не наблюдается, т.е. только при рестарте wb-mqtt-gpio.service. Почему? Скорее всего т.к. правила инициализируются с задержкой и ложный импульс на входе не обрабатывается движком правил.
Из области гипотез. Контроллер был поставлен с корпусом вверх ногами. Т.е. застежка для динрейки была сверху, а не с низу как принято. У боковых модулей как и полагается застежка снизу. При этом отверстие для шины было вырезано именно так что внутренности WB перевернуть не было возможности. Креативность оценил, но время менять /доробатывать не было.
Соответственно при сборке приходилось WB поднимать вверх, а модули WBIO опускать вниз для защелкивания на DIN. Соостность была примерная, но тем не менее модуль и контроллер состыковались.
Если плохой контакт в шине - это может стать причиной ошибки и перезапуска сервиса?
Файл скрипта не качается.
Но могу предположить что не проверяется состояние на true в правилах.
В логах подозрительного не вижу.
Но так как процесс явно был убит - то посмотрите
Иридиум стоит, и не только на этой инсталяции. На других подобного не встречал.
Я бы не сказал что данный объект выбивается по сложности проекта иридиум.
Более того когда произошел рестарт, в квартире никого не было, расписание не запускались, т.е. по сути контроллер работал без какой либо дополнительной нагрузки.
Сейчас включаются кнопки, идет активный взаимообмен с панелями и тем не менее система работает стабильно - это и напрягает.
Конечно можно сейчас все списать на иридиум, потратиться на комп и перенести туда сервер, а если не поможет? Хотелось бы причину найти.
При рестарте контроллера состояние gpio бывает отфонарным до первой принудительной записи. Это надо помнить.
Возможно, то же творится и при падении демона, так что его нужно мониторить. Вопрос - как лучше это делать.
GPIO явно определяются ядром еще при инициализации сервисом. А сам сервис, запускаясь (пере)создает MQTT топики. Ну и начальное значение пишет в топики - NULL
К сожалению, практикой это не подтвердилось. Если гпио назначен выходом и записи значения после рестарта не было, он может и в 1 встать, и в 0.
Вб 6.7 из коробки, два экземпляра на стенде, идентично. Позже, после перехода на новый репо, гпио на них не использовались, ничего не скажу; надеюсь, починили.
Ситуация повторилась описанная выше. К этому моменту иридиум сервер был уже перенесен на отдельное устройство, т.е. на WB нет стороннего ПО. Загрузка процессора в пике составляет 55% (!!!).
06:31:51 самостоятельная перезагрузка контроллера
08:19:10 закрытие и старт сервиса GPIO с последующим включением всего освещения дома
Какие ваши предложения? Как смотрите на то что вы направляете контроллер с последними обновлениями может быть даже с конфигами которые я предоставлю, чтоб совсем исключить вероятность что в процессе настройки мы делаем что-то не то. Для изучения я направляю вам свой контроллер.
Могу предоставить SSH на данный контроллер, если хотите посмотреть логи самостоятельно.
Я вижу в логе записи “trying to stop unknown timer:”, более 20 за несколько часов.
Скрипты текут, вызывая переполнение. Ошибок такого типа не должно быть. Если таймер создан - должен быть завершен явно.
Посмотрте, как часто появляются ошибки?
По поводу перезапуска - (возможно) аппаратный WD.
У вас есть система мониторинга контроллеров?
Советую все же провести ревизию скриптов.
Для того чтобы держать ПО в актуальном состоянии - достаточно на нем, на контроллере выполнить apt update && apt upgrade -y
Да, мы можем поменять контроллер.
Курьер привезёт новое оборудование и заберёт старое.
Для возврата напишите, пожалуйста, письмо на info@wirenboard.com.
В письме укажите:
ссылку на эту тему,
серийный номер устройства, AFMIIQX7,
ваш действующий телефон, адрес доставки, ФИО получателя.
Скрипты проверил, нашел место в скрипте где не хватает удаление таймера. Вот ссылка на тему где данный скрипт выложен автором и многие его берут себе на вооружение.
timerLongPress = setTimeout(function () {
... // весь код копировать не стал
timerLongPress = null; // ЭТУ СТРОКУ ДОБАВИЛ В ИСХОДНЫЙ КОД
}, timeOfLongPress);
timerWaitNextShortPress = setTimeout(function () {
... // весь код копировать не стал
timerWaitNextShortPress = null; // ЭТУ СТРОКУ ДОБАВИЛ В ИСХОДНЫЙ КОД
}, timeToNextPress);
}
После корректировки скриптов контроллер работал дня три, сегодня обнаружил что был ребут, причина не понятна.
Oct 16 15:32:53 wirenboard-AFMIIQX7 wb-rules[1522]: INFO: [rule info] R04-TS16-3 temp current = 27.6875 setpoint = 31.5 heating command = true
Oct 16 15:32:53 wirenboard-AFMIIQX7 wb-rules[1522]: INFO: [rule info] R06-VL16-8 temp current = 24.8 setpoint = 24.5 cooling command = true
Oct 16 15:32:53 wirenboard-AFMIIQX7 wb-rules[1522]: INFO: [rule info] R10-VL16-10 temp current = 24.6 setpoint = 24.5 cooling command = true
Oct 16 15:32:54 wirenboard-AFMIIQX7 npm[1582]: e[32mZigbee2MQTT:info e[39m 2021-10-16 15:32:54: MQTT publish: topic 'zigbee2mqtt/0x04cf8cdf3c8b5021', payload '{"device_temperature":13,"energy":2.24,"last_seen":1634380374978,"linkquality":140,"power":0,"state":"OFF"}'
Oct 16 15:33:04 wirenboard-AFMIIQX7 npm[1582]: e[32mZigbee2MQTT:info e[39m 2021-10-16 15:33:04: MQTT publish: topic 'zigbee2mqtt/0x04cf8cdf3c8b5021', payload '{"device_temperature":11,"energy":2.24,"last_seen":1634380384954,"linkquality":140,"power":0,"state":"OFF"}'
Oct 16 15:34:13 wirenboard-AFMIIQX7 systemd-modules-load[143]: Module 'sc16is7x2' is builtin
Oct 16 15:34:13 wirenboard-AFMIIQX7 systemd-fsck[140]: rootfs: clean, 30256/118272 files, 154282/262144 blocks
Oct 16 15:34:13 wirenboard-AFMIIQX7 systemd[1]: Started File System Check Daemon to report status.
Oct 16 15:34:13 wirenboard-AFMIIQX7 systemd[1]: Starting Create Static Device Nodes in /dev...
Oct 16 15:34:13 wirenboard-AFMIIQX7 systemd[1]: Starting Apply Kernel Variables...
Oct 16 15:34:13 wirenboard-AFMIIQX7 systemd[1]: Starting Remount Root and Kernel File Systems...
Oct 16 15:34:13 wirenboard-AFMIIQX7 systemd[1]: Started Create Static Device Nodes in /dev.
Oct 16 15:34:13 wirenboard-AFMIIQX7 systemd[1]: Started Apply Kernel Variables.
Oct 16 15:34:13 wirenboard-AFMIIQX7 systemd[1]: Started Remount Root and Kernel File Systems.
Oct 16 15:34:13 wirenboard-AFMIIQX7 systemd[1]: Starting udev Coldplug all Devices...
Oct 16 15:34:13 wirenboard-AFMIIQX7 systemd[1]: Starting prepare partitions at first boot...
Oct 16 15:34:13 wirenboard-AFMIIQX7 systemd[1]: Starting Load/Save Random Seed...
ВОПРОСЫ:
где нужно поправить скрипты чтобы убрать в лог публикацию данных от zigbee, 90% это их сообщения, место только забирают
последняя строка перед стартом загрузки, что означает? Это нормально?
Мне что-то не нравятся эти логи, подозреваю аппаратную проблему с контроллером.
Давайте мы поменяем вам оборудование:
Курьер привезёт новое оборудование и заберёт старое.
Для возврата напишите, пожалуйста, письмо на info@wirenboard.com.
В письме укажите:
ссылку на эту тему,
серийный номер устройства, если есть,
ваш действующий телефон, адрес доставки, ФИО получателя.
