Симптомы:
Перестают работать выключатели, настроенные через правила на выходы реле. Выполняем перезагрузку (отключаем питание и подаем) - не помогает.
В первый раз решилось отключением от контроллера всех модулей (физически отсоединили) и подключением заново.
Второй раз (сегодня), проверили, что через веб-интерфейс реле переключаются, а через входы - нет. И также, после отсоединения модулей и перезагрузки всё снова запустилось.
Проблему к сожалению наблюдаю не сам, а удаленно. Бываю на объекте в выходные, но подключиться терминально могу.
Что такое может быть? Правила не запускаются? Куда смотреть? Какие логи записать?
Это как замечаете? Можете в этот момент зайти в интерфейс и проверить, правильно ли изменяется состояние входов, и управляются ли вручную выходы? Это поможет отличить проблемы с оборудованием от проблем с движком правил.
Проверить работы сервисов можно так:
service wb-rules status //правила
service wb-mqtt-serial status //подключенное по RS-485
service wb-homa-gpio status //боковые модули, вставленные непосредственно в Wiren Board
Я лично не замечал. Мне звонят и говорят, что “выключатели не работают, нажимаем, а ничего не происходит”.
Оба случая я был далеко от возможности подключиться и посмотреть состояние контроллера, поэтому приходилось действовать оперативно.
По возможности я конечно проверю (хотя очень не хочется чтобы снова возникала такая возможность).
Может есть какие-то готовые скрипты, которые бы запускались и мониторили состояние правил, mqtt, gpio и в случае проблем - выполняли действия для уведомления (это какой-нибудь скрипт)?
2го января снова повторилось “зависание”.
Успел удаленно выполнить команды статуса сервисов.
Сводка
root@wirenboard-ACWRKP6X:/etc/init.d# service wb-rules status
● wb-rules.service - LSB: MQTT Rule Engine for Wiren Board
Loaded: loaded (/etc/init.d/wb-rules; generated; vendor preset: enabled)
Active: active (running) since Thu 2020-01-02 19:42:45 MSK; 8min ago
Docs: man:systemd-sysv-generator(8)
Process: 3684 ExecStop=/etc/init.d/wb-rules stop (code=exited, status=0/SUCCESS)
Process: 3693 ExecStart=/etc/init.d/wb-rules start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/wb-rules.service
└─3700 /usr/bin/wb-rules -syslog -queue-len 2048 -editdir /etc/wb-rules /usr/share/wb-rules-system/rules/ /etc/wb-rules /usr/share/wb-rules/
Jan 02 19:42:44 wirenboard-ACWRKP6X systemd[1]: Starting LSB: MQTT Rule Engine for Wiren Board…
Jan 02 19:42:45 wirenboard-ACWRKP6X systemd[1]: Started LSB: MQTT Rule Engine for Wiren Board.
root@wirenboard-ACWRKP6X:/etc/init.d# service wb-homa-gpio status
● wb-homa-gpio.service - LSB: MQTT Driver for GPIO-controlled switches
Loaded: loaded (/etc/init.d/wb-homa-gpio; generated; vendor preset: enabled)
Active: active (running) since Thu 2020-01-02 19:39:07 MSK; 12min ago
Docs: man:systemd-sysv-generator(8)
Process: 1722 ExecStart=/etc/init.d/wb-homa-gpio start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/wb-homa-gpio.service
└─2928 /usr/bin/wb-homa-gpio -c /tmp/wb-homa-gpio.do-not-edit.conf
Jan 02 19:38:51 wirenboard-ACWRKP6X systemd[1]: Starting LSB: MQTT Driver for GPIO-controlled switches…
Jan 02 19:39:07 wirenboard-ACWRKP6X wb-homa-gpio[1722]: Starting MQTT Driver for GPIO-controlled switches: wb-homa-gpio.
Jan 02 19:39:07 wirenboard-ACWRKP6X systemd[1]: Started LSB: MQTT Driver for GPIO-controlled switches.
root@wirenboard-ACWRKP6X:/etc/init.d# service wb-mqtt-serial status
● wb-mqtt-serial.service - LSB: MQTT Driver for serial devices
Loaded: loaded (/etc/init.d/wb-mqtt-serial; generated; vendor preset: enabled)
Active: active (running) since Thu 2020-01-02 19:38:53 MSK; 13min ago
Docs: man:systemd-sysv-generator(8)
Process: 1739 ExecStart=/etc/init.d/wb-mqtt-serial start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/wb-mqtt-serial.service
├─1812 /bin/bash -c exec /usr/bin/wb-mqtt-serial -c /etc/wb-mqtt-serial.conf 2>&1 | logger -t serial
├─1821 /usr/bin/wb-mqtt-serial -c /etc/wb-mqtt-serial.conf
└─1822 logger -t serial
Jan 02 19:38:51 wirenboard-ACWRKP6X systemd[1]: Starting LSB: MQTT Driver for serial devices…
Jan 02 19:38:53 wirenboard-ACWRKP6X systemd[1]: Started LSB: MQTT Driver for serial devices.
root@wirenboard-ACWRKP6X:/etc/init.d#
В этот раз помогло отключение питания.
Файл messages “спасти” не удалось, когда 5го числа зашел его забрать - за 2е число уже не было данных. Надо где-то настроить ротацию файлов логов, чтобы подольше хранил.
После праздников планирую заменить контроллер на резерв, до выяснения обстоятельств, а то заказчик остался недовольным таким поведением его “умного дома”.
Причем второй контроллер с подобной конфигурацией пока работает стабильно, тьфу-тьфу-тьфу.
настройте логгирование на внешний сервер что бы понять в чем проблема. так же гляньте что по свободному месту на контроллере. по-умолчанию там есть логгирование данных mosquitto в базу данных. возможно хранилище переполнилось
около 3х недель назад поменяли первый контроллер на резервный, обновили wb-rules на версию 2.2
2 недели назад начал “зависать” второй контроллер - там тоже выполнил обновление wb-rules.
Вот сегодня второй контроллер снова “завис” (уже с новыми wb-rules).
Перезапуск сервисов wb-rules не помог. также не помог перезупуск сервиса wb-mqtt-serial.
При перезапуске mosquitto соединение с сервером пропало и пришлось прибегнуть к жесткой перезагрузке.
Прикладываю лог. “Зависание” заметили в 18:00-18:05 по времени лога, т.к. потом уже подключился я и делал перезапуск сервисов.
в 18:06 перезапустили wb-rules и попробовали понажимать на кнопки - в логе видно события из правил, но свет не переключался.
С виду вроде нормально сидят, плотно воткнуты. Я конечно их еще раз перевоткну.
А может быть какое-то зависание этой шины на стороне модулей, а не контроллера? Типа входы (подключены первыми) срабатывают (видно по логам правил), а выходы “отвалились”?
Столкнулся сегодня с аналогичной проблемой:
Свет остался гореть, выключатели и реле на кнопки не реагируют. Реле ничего не переключают. Что не горит (свет) - не включить, а то, что горит - не выключить.
Сначала к контроллеру справа подключен модуль реле 16 контактов, потом 2 модуля по 14 контактов сухих контактов и потом модуль на краны.
В веб интерфейсе никакой реакции ни на подключенные кнопки, ни на нажатия на сами переключатели реле не было. Удаление модулей из конфигурации ни к чему не привело, добавил обратно. Ни перезагрузка через консоль, ни по питанию не разблокировала реле.
Помогло только выключение питания на контроллере с последующим физическим отсоединением всех 4-х доп модулей. В момент отсоединения реле выключились (хотя сам контроллер был выключен). После обратного присоединения и включении питания система вернулась к нормальной работе, наблюдаю за поведением далее
Возможные причины в порядке уменьшения вероятности как мне видится:
Плохой контакт в боковых разъемах модулей. Что можно сделать - проверить, что штырьки не погнуты, модули плотно прижаты друг другу на динрейке.
Непропай одного из боковых разъемов на любом модуле или контроллере. Что можно сделать - снять задние крышки, посмотреть пайку разъемов.
Зависание чипа в модуле (никогда не наблюдали, но все же). Как можно диагностировать - при повторении проблемы сначала перезагрузить контроллер по питанию (кнопкой на корпусе), проверить что не помогло. Потом перезагрузить контроллер, полностью отключив питание, стараясь не трогать модули и контроллер. Если помогло - значит зависал чип.
Почему так - при выключении контроллера кнопкой или его перезагрузке по вотчдогу, питание на боковых модулях остается, как раз с целью сохранения состояния реле.
Т.е. как будто достаточно переинициализацию сделать? Если это так, то значит на программном уровне можно восстановить работу.
Осталось выяснить как это сделать и проверить.