Wb-mqtt-gpio.service restart

Коллеги произошел непонятный рестарт wb-mqtt-gpio.service, лог прилагаю ниже. После перезагрузки по ряду дискретных входов появилась логическая единица. Т.к. на WBIO-DI-WD-14 и Модуль ввода-вывода WBIO-DI-HVD-16 заведены импульсные выключатели и работает скрипт на импульсные выключатели, то результатом стало включение по всей квартире света и диспузера, что очень напрягло хозяина.

Архитектура: WB6.7 + WD14 + WD14 + HVD16 + R-10A8 + R-10A8 + R-10A4
К дискретам подключены ипульсные выключатели, импульсы от счетчиков воды/э/э, датчики протечки.

Sep 23 12:44:22 wirenboard-AFMIIQX7 systemd[1]: wb-mqtt-gpio.service: Main process exited, code=killed, status=4/ILL
Sep 23 12:44:22 wirenboard-AFMIIQX7 systemd[1]: wb-mqtt-gpio.service: Unit entered failed state.
Sep 23 12:44:22 wirenboard-AFMIIQX7 systemd[1]: wb-mqtt-gpio.service: Failed with result 'signal'.
Sep 23 12:44:23 wirenboard-AFMIIQX7 systemd[1]: wb-mqtt-gpio.service: Service hold-off time over, scheduling restart.
Sep 23 12:44:23 wirenboard-AFMIIQX7 systemd[1]: Stopped MQTT Driver for GPIO-controlled switches.
Sep 23 12:44:23 wirenboard-AFMIIQX7 systemd[1]: Starting MQTT Driver for GPIO-controlled switches...

messages.txt (119.9 КБ)

Вопросы:

  1. Как понять что стало первопричиной сбоя? В логах нет ничего подозрительно до сбоя. Откуда копать?
  2. При перезагрузки контроллера подобное не наблюдается, т.е. только при рестарте wb-mqtt-gpio.service. Почему? Скорее всего т.к. правила инициализируются с задержкой и ложный импульс на входе не обрабатывается движком правил.

Добрый день.
Какой релиз на контроллере?

Welcome to Wiren Board 6.7.2 (s/n AFMIIQX7), release wb-2108 (as stable)
Linux wirenboard-AFMIIQX7 4.9.22-wb2 #2 SMP Thu Jun 24 14:46:55 UTC 2021 armv7l GNU/Linux

Посмотрел в лог, дайте пожалуйста вывод journalctl c 12 часов может бытть будет больше информации.

Нет, при запуске (перезапуске) сервиса в топики не пишется true. Подпишитесь на топик и проверьте.

В моем случае получается что пишется или скрипт с импульсными кнопками не корректно отрабатывает при перезапуске сервиса gpio?

Прилагаю лог + скрипт.

journalctl.txt (128.7 КБ)
impuls_switch.js (39.3 КБ)

Сейчас проблематично проверить, объект сдан. Заказчик заселился.

Из области гипотез. Контроллер был поставлен с корпусом вверх ногами. Т.е. застежка для динрейки была сверху, а не с низу как принято. У боковых модулей как и полагается застежка снизу. При этом отверстие для шины было вырезано именно так что внутренности WB перевернуть не было возможности. Креативность оценил, но время менять /доробатывать не было.

Соответственно при сборке приходилось WB поднимать вверх, а модули WBIO опускать вниз для защелкивания на DIN. Соостность была примерная, но тем не менее модуль и контроллер состыковались.

Если плохой контакт в шине - это может стать причиной ошибки и перезапуска сервиса?

Файл скрипта не качается.
Но могу предположить что не проверяется состояние на true в правилах.
В логах подозрительного не вижу.
Но так как процесс явно был убит - то посмотрите

dmesg |grep kill

Ну и на количество свободной памяти.

dmesg |grep kill

вывод ничего не дал

то есть стоит иридиум, возможны скачки памяти… Ну, тогда у себя на стенде проверьте - записывает ли (нет) “1” в топики wb-mqtt-gpio при перезапуске.

Иридиум стоит, и не только на этой инсталяции. На других подобного не встречал.
Я бы не сказал что данный объект выбивается по сложности проекта иридиум.
Более того когда произошел рестарт, в квартире никого не было, расписание не запускались, т.е. по сути контроллер работал без какой либо дополнительной нагрузки.

Сейчас включаются кнопки, идет активный взаимообмен с панелями и тем не менее система работает стабильно - это и напрягает.

Конечно можно сейчас все списать на иридиум, потратиться на комп и перенести туда сервер, а если не поможет? Хотелось бы причину найти.

При рестарте контроллера состояние gpio бывает отфонарным до первой принудительной записи. Это надо помнить.
Возможно, то же творится и при падении демона, так что его нужно мониторить. Вопрос - как лучше это делать.

GPIO явно определяются ядром еще при инициализации сервисом. А сам сервис, запускаясь (пере)создает MQTT топики. Ну и начальное значение пишет в топики - NULL

К сожалению, практикой это не подтвердилось. Если гпио назначен выходом и записи значения после рестарта не было, он может и в 1 встать, и в 0.
Вб 6.7 из коробки, два экземпляра на стенде, идентично. Позже, после перехода на новый репо, гпио на них не использовались, ничего не скажу; надеюсь, починили.

Ситуация повторилась описанная выше. К этому моменту иридиум сервер был уже перенесен на отдельное устройство, т.е. на WB нет стороннего ПО. Загрузка процессора в пике составляет 55% (!!!).

Прикладываю лог - messages (642.7 КБ)

06:31:51 самостоятельная перезагрузка контроллера
08:19:10 закрытие и старт сервиса GPIO с последующим включением всего освещения дома

Какие ваши предложения? Как смотрите на то что вы направляете контроллер с последними обновлениями может быть даже с конфигами которые я предоставлю, чтоб совсем исключить вероятность что в процессе настройки мы делаем что-то не то. Для изучения я направляю вам свой контроллер.

Могу предоставить SSH на данный контроллер, если хотите посмотреть логи самостоятельно.

Я вижу в логе записи “trying to stop unknown timer:”, более 20 за несколько часов.
Скрипты текут, вызывая переполнение. Ошибок такого типа не должно быть. Если таймер создан - должен быть завершен явно.
Посмотрте, как часто появляются ошибки?

По поводу перезапуска - (возможно) аппаратный WD.
У вас есть система мониторинга контроллеров?

Советую все же провести ревизию скриптов.

Для того чтобы держать ПО в актуальном состоянии - достаточно на нем, на контроллере выполнить apt update && apt upgrade -y
Да, мы можем поменять контроллер.
Курьер привезёт новое оборудование и заберёт старое.
Для возврата напишите, пожалуйста, письмо на info@wirenboard.com.

В письме укажите:

  1. ссылку на эту тему,
  2. серийный номер устройства, AFMIIQX7,
  3. ваш действующий телефон, адрес доставки, ФИО получателя.

Не совсем понял вопроса. Аппаратный - watch dog? Что его включить/выключить?
Сторонней системы мониторинга нет, кроме той что представляете вы.

Проверим, да ошибки такого плана появляются постоянно. Тк объект по факту сдан, то экспериментировать не представляется возможным.

ПО обновлял недавно, как только вышел крайний стабильный релиз

Возьмем пока паузу, проверим скрипты, но даже если есть ошибки они должны как то систематически о себе давать знать. Может все-таки посмотрите по SSH?

Да, конечно, могу посмотреть. Давайте доступ в ЛС.

Скрипты проверил, нашел место в скрипте где не хватает удаление таймера. Вот ссылка на тему где данный скрипт выложен автором и многие его берут себе на вооружение.

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...

ВОПРОСЫ:

  1. где нужно поправить скрипты чтобы убрать в лог публикацию данных от zigbee, 90% это их сообщения, место только забирают
  2. последняя строка перед стартом загрузки, что означает? Это нормально?
1 Like

Добрый день!

Мне что-то не нравятся эти логи, подозреваю аппаратную проблему с контроллером.

Давайте мы поменяем вам оборудование:
Курьер привезёт новое оборудование и заберёт старое.
Для возврата напишите, пожалуйста, письмо на info@wirenboard.com.

В письме укажите:

  1. ссылку на эту тему,
  2. серийный номер устройства, если есть,
  3. ваш действующий телефон, адрес доставки, ФИО получателя.