Из области гипотез. Контроллер был поставлен с корпусом вверх ногами. Т.е. застежка для динрейки была сверху, а не с низу как принято. У боковых модулей как и полагается застежка снизу. При этом отверстие для шины было вырезано именно так что внутренности 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.
В письме укажите:
ссылку на эту тему,
серийный номер устройства, если есть,
ваш действующий телефон, адрес доставки, ФИО получателя.
Добрый вечер, контроллерами обменялись мне пришел уже 6.8 (вам обратно выслал 6.7). Перенес все скрипты, конфиги, вообщем восстановил работу.
Контроллер проработал 2 дня и перезагрузился, вот лог:
Oct 27 08:08:36 wirenboard-A76QND3Y npm[986]: e[32mZigbee2MQTT:info e[39m 2021-10-27 08:08:36: MQTT publish: topic 'zigbee2mqtt/0x04cf8cdf3c8b5021', payload '{"device_temperature":5,"energy":0.01,"last_seen":1635304116874,"linkquality":150,"power":0,"state":"OFF"}'
Oct 27 08:08:46 wirenboard-A76QND3Y npm[986]: e[32mZigbee2MQTT:info e[39m 2021-10-27 08:08:46: MQTT publish: topic 'zigbee2mqtt/0x04cf8cdf3c8b5021', payload '{"device_temperature":7,"energy":0.01,"last_seen":1635304126839,"linkquality":150,"power":0,"state":"OFF"}'
Oct 27 08:09:55 wirenboard-A76QND3Y systemd-modules-load[145]: Module 'sc16is7x2' is builtin
Oct 27 08:09:55 wirenboard-A76QND3Y systemd-fsck[139]: rootfs: clean, 30088/116992 files, 152513/262144 blocks
Oct 27 08:09:55 wirenboard-A76QND3Y systemd[1]: Started File System Check on Root Device.
Oct 27 08:09:55 wirenboard-A76QND3Y systemd[1]: Started Load Kernel Modules.
Oct 27 08:09:55 wirenboard-A76QND3Y systemd[1]: Started Create list of required static device nodes for the current kernel.
Лучше всего подключиться к Debug порту - и настроить запись всего выводимого в файл. Также - весьма неплохо поставить агент мониторинга, тот же Zabbix, чтобы посмотреть - не растут ли линейно ресурсы.
Добрый день! Удалось проанализировать мой контроллер который отправлял ранее?
За прошедшее время контроллер перезагружался 3-4 раза. Какую-то зависимость не нашел. Период перезагрузки составляет от 3 до 4,5 дней.
После обновления на wb2110 перезагружаться контроллер перестал (семь дней пока стабильно), но не отображаются конфигурационные файлы и другие меню в WUI, но это уже совсем другая история и в другая тема.
