Более того, я открыл файл /etc/wb-hardware.conf - там все поля module пустые!
Каким-то образом этот конфиг может очищаться сам?
p.s. потратил полдня на это, удаленно не удалось восстановить работу боковых модулей
если я прописываю их в конфиг, то не работает serial, каждая перезагрузка занимает около 10-15 минут, но в итоге ВБ загружается…
я такое встречал только при обновлении пакетов. Если вы обновляете wb-hwconf-manager, то apt может спросить, что делать с конфигом. Пользователь может выбрать вариант с заменой на стандартный.
Нужно почитать /var/log/messages, там будет написано, в чём дело. Можно нам тоже выложить - посмотрим.
Продолжают воевать с контроллерами. Заказчик в изоляции стал чаще пользоваться устройствами и “зависания” стали чаще.
Но меня уже в курс не вводили, т.к. надежды что я починю это быстро - не было. Сами применяли “на семь бед один ресет”.
Лишь вчера с утра сообщили об очередном случае и что это теперь у них регулярно, а вечером мне удалось присутствовать при таком “зависании”.
Прикладываю логи.
messages_170_20200410.txt (1.1 МБ)
Утренняя перезагрузка была в “Apr 9 06:59:36”.
К вечеру я переписал все правила, чтобы добавить больше логирования, и применил их “Apr 9 17:47:30”.
После некоторых проверок, нажатий на кнопки, я дошел до закрытия штор “Apr 9 17:48:50”.
Закрыть я ее закрыл, а вот открыть не получилось. И дальнейшие нажатия на кнопки хоть и отображались в логе (сперва с задержкой, затем перестали),
но никакие действия не выполнялись. Из интерфейса тоже никак не переключались реле.
Перезапуск служб wb-rules, wb-mqtt-serial, wb-homa-gpio не помог. А при перезапуске mosqitto контроллер завис и ушел в перезагрузку.
Но загрузиться нормально не смог (либо я не дождался). Вырубил питание с контроллера и всей периферии. После этого всё запустилось.
Даже не знаю за что зацепиться в поиске причин. Из наблюдений:
какую версию wb-rules вы используете?
да, это плохой знак. Плохой контакт между боковыми модулями и контроллером или брак в разъёме у контроллера, например может быть.
Попробуйте ещё отключить один из модулей R1G-16 от контроллера, если есть возможность.
Около месяца назад обновил до 2.2
root@wirenboard-AC7VKWIO:~#dpkg -s wb-rules
Package: wb-rules
Status: install ok installed
Priority: optional
Section: misc
Installed-Size: 15280
Maintainer: Nikita webconn Maslov n.maslov@contactless.ru
Architecture: armhf
Version: 2.2.1
Depends: libc6 (>= 2.13)
Breaks: wb-mqtt-confed (<< 1.0.2)
Conffiles:
/etc/init.d/wb-rules 1579ece52285107cde1482052f47615d
/etc/wb-configs.d/13wb-rules 1236e2e4343d949e0a21de865706c00b
/etc/wb-rules/alarms.conf 2051dd214a6232c5e778c50e52d5fb6a
/etc/wb-rules/rules.js 926c30d0fd63e272f6f9ad370dffb1b0
Description: Wiren Board Rule Engine
Боюсь, что оперативно отключить один модуль не получится - нужно будет куда-то перецеплять контакты. Если только в течении нескольких дней или даже недель.
А можно его перенести на MIO? что-то даст?
Ситуация усугубляется еще тем, что таких контроллеров два (с одинаковым набором модулей) и у обоих похожие проблемы.
Подскажите ещё пожалуйста, воспроизводится ли у вас зависание, связанное именно с включением штор?
Т.е. можете ли вы перезагрузить контроллер, получить работающий без проблем контроллер, включить/выключить шторы, получить неработающий контроллер?
Попытались повторить в “Apr 10 18:25:42”, но не удалось. Раз на раз не приходится.
messages_170_20200410-1.txt (463.7 КБ)
Сегодня днем отключили по одному модулю R1G-16 на каждом контроллере.
Но результат неудачный. На одном из контроллеров всё работает (именно на нем были переписаны правила в прошлый раз). А на втором (правила остались прежними) произошло “зависание” (еще до отключения модуля ) и перезагрузка в “Apr 15 17:32:02”, затем отсоединили модуль и удалили настройку для одного R1G-16 в “Apr 15 17:53:36” и неожиданно отключились все реле, но потом заработало.
Затем, снова зависло и я попытался рестартануть службы в “Apr 15 18:52:16”, но не вышло и перезагрузил в “Apr 15 18:57:39”. Потом немного настраивал правила… Всё это проработало до перезагрузки в “Apr 15 21:51:09”.
messages_137_20200415.txt (937.0 КБ)
Завтра перепишу правила по аналогии с первым контроллером, но надежды у меня уже нет…
Текущая версия: где-то снаружи есть сильно индуктивная нагрузка, например привод шторы или контактор. Когда она включается или выключается, на линии шины i2c наводится помеха. У вас это проявляется или из-за особо плохой нагрузки, или, что вероятнее, из-за неудачно проложенных проводов и длинной линейки модулей WBIO. Теоретически, помехи могут вызывать и сами промежуточные реле. Это очень нестандартный подход - использовать внешние промежуточные реле вместе с нашим оборудованием, и это может объяснить, почему с проблемой столкнулись именно вы.
В самых свежих модулях WD-14 мы предпринимали меры против такого, но у вас более старые модули.
Как проверить:
после “зависания” в top будут висеть процессы с irq, в /proc/interrupts будет с большой скоростью увеличиваться счётчик напротив прерывания одного из gpio. После зависания нужно остановить wb-homa-gpio, выгрузить модуль mcp23s08. Потом загрузить его обратно и запустить wb-homa-gpio. После этого всё должно работать как работало раньше.
Вместо этого можно организовать нам удалённый доступ по ssh и отправить реквизиты мне на boger@wirenboard.com - все нужные действия проделаем сами.
Если проблема подтвердится, то лечение - это избавиться от помех. Если виноваты внешние по отношению к щиту потребители, то нужно поставить снабберы (конденсатор+резистор) на отходящие линии к таким потребителям. Например такие: https://www.meandr.ru/sb-2-1
Если виноваты промежуточные реле, то поможет управлять ими не через WBIO-DO-R1G-16, а через, например, HS-8. Ещё лучше избавиться и от промежуточных реле, и от R1G-16 и поставить много модулей WB-MR6C или WB-MRPS6. Места на это должно хватить, потому что промежуточные реле занимают целую рейку.
Промежуточные реле использовались в первую очередь для возможности замены и для возможности организации управления без контроллера и модулей. Реле управляются 24в, а сами коммутируют 220в, либо тоже 24в. Вся силовая часть (автоматы, некоторые блоки питания освещения и прочее) вынесено в соседний шкаф. С этими промежуточными реле работали и ранее. Поэтому удивительно что это могут быть наводки.
Вот фото щитка 1го контроллера (который зависал вчера несколько раз).
Вот 2ой контроллер.
Переписал правила на 1ом контроллере. Наблюдаю удаленно.
Попробую организовать вам терминальный доступ.
Решилось переносом выходных модулей WBIO-DO-R1G-16 на отдельный адаптер WB-MIO-E.
Т.е. на контроллере остались 4 модуля WBIO-DI-DR-16, а остальные модули по 4 штуки на адаптерах WB-MIO-E.
Считаю что победил свою проблему. За последние пару месяцем не было описываемых произвольных “зависаний” (правда, пока непрерывный uptime не превышал 2х недель, т.к. контроллеры выключались по необходимости).
