Я лично не замечал. Мне звонят и говорят, что “выключатели не работают, нажимаем, а ничего не происходит”.
Оба случая я был далеко от возможности подключиться и посмотреть состояние контроллера, поэтому приходилось действовать оперативно.
По возможности я конечно проверю (хотя очень не хочется чтобы снова возникала такая возможность).
Может есть какие-то готовые скрипты, которые бы запускались и мониторили состояние правил, 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е число уже не было данных. Надо где-то настроить ротацию файлов логов, чтобы подольше хранил.
После праздников планирую заменить контроллер на резерв, до выяснения обстоятельств, а то заказчик остался недовольным таким поведением его “умного дома”.
Причем второй контроллер с подобной конфигурацией пока работает стабильно, тьфу-тьфу-тьфу.
07.01.2020 в 20:48 “полечили зависание” перезагрузкой системы отключив питание.
messages_223.txt (951.8 КБ)
Посмотрел логи. Перед “зависанием” заметил такие события:
Jan 7 19:49:32 wirenboard-ACWRKP6X user.warn wb-mqtt-db[1870]: 2020-01-07 19:49:32.148 WARN: Channel data limit is reached: channel wb-adc/A1, row count 10201, limit 10000
Jan 7 19:49:32 wirenboard-ACWRKP6X user.warn wb-mqtt-db[1870]: 2020-01-07 19:49:32.171 WARN: Channel data limit is reached: channel wb-adc/A2, row count 10201, limit 10000
Jan 7 19:49:32 wirenboard-ACWRKP6X user.warn wb-mqtt-db[1870]: 2020-01-07 19:49:32.193 WARN: Channel data limit is reached: channel wb-adc/A3, row count 10201, limit 10000
Jan 7 19:49:32 wirenboard-ACWRKP6X user.warn wb-mqtt-db[1870]: 2020-01-07 19:49:32.222 WARN: Channel data limit is reached: channel wb-adc/A4, row count 10201, limit 10000
Jan 7 19:49:32 wirenboard-ACWRKP6X user.warn wb-mqtt-db[1870]: 2020-01-07 19:49:32.247 WARN: Channel data limit is reached: channel wb-adc/Vin, row count 10201, limit 10000
Jan 7 19:53:32 wirenboard-ACWRKP6X user.warn wb-mqtt-db[1870]: 2020-01-07 19:53:32.151 WARN: Channel data limit is reached: channel system/Current uptime, row count 10201, limit 10000
Jan 7 19:53:32 wirenboard-ACWRKP6X user.warn wb-mqtt-db[1870]: 2020-01-07 19:53:32.189 WARN: Channel data limit is reached: channel power_status/Vin, row count 10201, limit 10000
Jan 7 20:03:32 wirenboard-ACWRKP6X user.warn wb-mqtt-db[1870]: 2020-01-07 20:03:32.158 WARN: Channel data limit is reached: channel hwmon/CPU Temperature, row count 10201, limit 10000
Могут ли они приводить к “зависанию”?
Могу предположить, что зависает сервис wb-rules. Что стоит попробовать:
- при следующем зависании выполнить
service wb-rules restart
- если поможет, то попробовать вот это Ошибка: wb-rules check failed, reload wb-rules
в прошлый раз перезапуск wb-rules не помогал, также как reboot без отключения питания.
но попробую
Если не поможет, то следующий кандидат на перезапуск - сервис mosquitto.
настройте логгирование на внешний сервер что бы понять в чем проблема. так же гляньте что по свободному месту на контроллере. по-умолчанию там есть логгирование данных 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 и попробовали понажимать на кнопки - в логе видно события из правил, но свет не переключался.
Также прикладываю файл правил, возможно у меня с ними проблема и я там накрутил лишнего.messages_170_20200129.txt (855.0 КБ)
level1.js.txt (24.7 КБ)
Перейти на node-red и забыть о wb-rules! у меня правил на 500кб, более 500 нод используется, ничего не зависает.
что-то мне подсказывает что проблема не в правилах, а в чем-то другом.
т.к. даже перезагрузка служб не дала результата. только обесточивание модулей
Проверьте пожалуйста подключение боковых модулей ввода-вывода. Скорее всего, проблема в них.
С виду вроде нормально сидят, плотно воткнуты. Я конечно их еще раз перевоткну.
А может быть какое-то зависание этой шины на стороне модулей, а не контроллера? Типа входы (подключены первыми) срабатывают (видно по логам правил), а выходы “отвалились”?
Столкнулся сегодня с аналогичной проблемой:
Свет остался гореть, выключатели и реле на кнопки не реагируют. Реле ничего не переключают. Что не горит (свет) - не включить, а то, что горит - не выключить.
Сначала к контроллеру справа подключен модуль реле 16 контактов, потом 2 модуля по 14 контактов сухих контактов и потом модуль на краны.
В веб интерфейсе никакой реакции ни на подключенные кнопки, ни на нажатия на сами переключатели реле не было. Удаление модулей из конфигурации ни к чему не привело, добавил обратно. Ни перезагрузка через консоль, ни по питанию не разблокировала реле.
Помогло только выключение питания на контроллере с последующим физическим отсоединением всех 4-х доп модулей. В момент отсоединения реле выключились (хотя сам контроллер был выключен). После обратного присоединения и включении питания система вернулась к нормальной работе, наблюдаю за поведением далее
2 лайка
Возможные причины в порядке уменьшения вероятности как мне видится:
- Плохой контакт в боковых разъемах модулей. Что можно сделать - проверить, что штырьки не погнуты, модули плотно прижаты друг другу на динрейке.
- Непропай одного из боковых разъемов на любом модуле или контроллере. Что можно сделать - снять задние крышки, посмотреть пайку разъемов.
- Зависание чипа в модуле (никогда не наблюдали, но все же). Как можно диагностировать - при повторении проблемы сначала перезагрузить контроллер по питанию (кнопкой на корпусе), проверить что не помогло. Потом перезагрузить контроллер, полностью отключив питание, стараясь не трогать модули и контроллер. Если помогло - значит зависал чип.
Почему так - при выключении контроллера кнопкой или его перезагрузке по вотчдогу, питание на боковых модулях остается, как раз с целью сохранения состояния реле.
У меня 2 раза такое, боковые модули перестают работать, при этом все сервисы работают
ребут не помогает.
Первый раз вылечил таким образом: в hardware конфиге удалил все боковые устройства, сохранил и передобавил.
Т.е. как будто достаточно переинициализацию сделать? Если это так, то значит на программном уровне можно восстановить работу.
Осталось выяснить как это сделать и проверить.
Более того, я открыл файл /etc/wb-hardware.conf - там все поля module пустые!
Каким-то образом этот конфиг может очищаться сам?
p.s. потратил полдня на это, удаленно не удалось восстановить работу боковых модулей
если я прописываю их в конфиг, то не работает serial, каждая перезагрузка занимает около 10-15 минут, но в итоге ВБ загружается…
я такое встречал только при обновлении пакетов. Если вы обновляете wb-hwconf-manager, то apt может спросить, что делать с конфигом. Пользователь может выбрать вариант с заменой на стандартный.
Нужно почитать /var/log/messages, там будет написано, в чём дело. Можно нам тоже выложить - посмотрим.