Добрый! т.к. предыдущая тема закрылась по сроку давности, прошу помощи
пока модуль не обновляли, т.к. объект не близко, не хочется уронить все
сейчас удалось сгрузить лог после звонка от заказчика про перезагрузку
во вложении лог, мне сложно понять, в чем причина, что за причина . что контроллер пошел на обновление?
user.notice wb-mqtt-db[603]: 2022-06-19 12:54:12.594 NOTICE: Bulk processing took 125ms
только вот эта запись смущает, что после ее появления пошла перезагрузка модуля?
messages.txt (387.7 КБ)
Добрый день. К сожалению, я ничего не понял. Но в вашем тексте есть слово “перезагрузка”, это же есть в еррате на контроллер. Так что обновите пожалуйста ПО контроллера всё-таки.
Добрый !
перезаргузка, судя по логу контроллер выполнил процедуру перезагрузки… раз стал загружаться по новой. т.к. заказчик уверяет, что с электричеством в доме все ок. скачков не было.
Добрый день.
Из лога понятно что релиз ПО (Linux version 4.9.22-wb6) неактуален. Как подсказал коллега выше - обновите ПО.
Здравствуйте! Получилось ли обновить ПО контроллера?
Добрый день! нет ждем удобный момент, что бы нам допустили на объект и мы смогли аккуратно провести обновление.
добрый! обновили вчера , словили проблемы при обновлении, что конфиг файлы и устройства устарели. кроме боковых модулей, еще и на RS-485 от датчиков движения собрали проблем, т.к. там тоже какие то новые правила конфигурирования стали.
ПО контроллера совместимо со старыми версиями конфигураций, старые шаблоны должны работать. Все ли удалось настроить?
возможно, но что есть то есть, пришлось удалять, добавлять по новой
пока работает, наблюдаем. выводы можно будет сделать по прошествии минимум двух недель, т.к. у нас такая частота необоснованной перезагрузки была
Сообщите о результате, пожалуйста. При повторении проблемы нужны будут архив с диагностической информацией контроллера (cоздание архива описано в инструкции) и журнал сообщений за период времени, в котором была перезагрузка. Пример команды получения логов и сохранения их в файл:
journalctl --since "2 hours ago" --until "1 hour ago" > /root/log.txt
добрый!
после обновления появились задержки в работе.
первое что обращает на себя внимание, что при работе с WEB интерфейсом долго приходиться ожидать появление страницы с конфиг файлами (настроечной страницы)
второе - время отработки с модуля сухих контактов (у нас боковые модули в контроллере) до включения выключения канала реле доходит до 6…7 секунд
Сейчас это связано с проверкой шаблонов на корректность при открытии страницы. Задача по ускорению открытия страницы уже есть у разработчиков.
После обновления контроллера необходимо его перезагрузить, чтобы запустилось новое ядро. Если после перезагрузки проблема не пропадет, то пришлите, пожалуйста, архив с диагностической информацией контроллера. Создание архива описано в инструкции.
Также попробуйте удалить боковые модули из конфигурации, перезагрузить контроллер и заново их сконфигурировать.
по второй рекомендации:
конечно после обновления модуль был перезагружен (да и заказчик при проблемах, пытается решить ее перезагрузкой), последняя перезагрузка была 17 часов назад
боковые модули были после обновления удалены и добавлены (т.к. была проблема с настройкой их, ни как не управлял один из них, про это я открывал уже тему, но решили, просто переписали шаблон - на новый чистый из шаблонов образа на контроллере)
еще вот мой коллега, заметил такую странность с ними (боковыми модулями) может ли это иметь к проблеме отношение?
вот его описание проблемы
“При закрытии пластрона в щите на din-рейке, где расположен контроллер wirenboard с модулями расширения, иногда пропадает связь между контроллером и модулями. С дискретных модулей не уходят команды в контроллер. при физическом воздействии (руками прижимаю втычные модули к контроллеру, как бы сжимаю с двух сторон) все команды начинают разом прилетать на контроллер и обрабатываться. На основании этого могу сделать предположение, что данное штыревое соединение работает нестабильно. При этом модули не перекашивает, они расположены на din-рейке ровно и свободно.”
от себя если я правильно понимаю логику работы модулей сухих контактов, то они накапливают у себя изменения состояния сух. контакта (счетчик импульсов по сути), а сам контроллер с заданной периодичностью опрашивает его. т.к. заметили еще такую особенность, что если по нажимать на кнопку выключатель (звонковый тип), то при шевелении модулей и контроллера, команды как бы “кучей прилетают”. т.к. контроллер вкл выкл. подряд релейный канал
На основании этого могу сделать предположение, что данное штыревое соединение работает нестабильно.
Контроллер и боковые модули рекомендуется фиксировать (сжимать) с двух сторон фиксаторами на дин-рейку для надежности контакта. В прижатом состоянии проблема сохраняется? Проверьте и осмотрите разъемы: не повреждены ли сами штыри разъемов, не погнуты ли черные держатели.
Пришлите диагностический архив контроллера.
не много не могу понять, как правильно сформировать диагностический архив?
journalctl --since “2 hours ago” --until “1 hour ago” > /root/log.txt
использовал эту команду? или надо больший диапазон времени охватить?
Создание архива описано в инструкции.
Запустите сервис сбора данных командой в консоли:
systemctl enable wb-diag-collect
systemctl start wb-diag-collect
После этого кнопка должна работать.
Этот пакет должен быть установлен при обновлении на актуальный релиз. Предполагаю, что ПО обновилось не до конца или с ошибками. Каким способом обновляли контроллер?
Сохраните список установленных на контроллере пакетов, а также список работающих сервисов ПО в файлы:
dpkg -l > /root/package_list.txt
systemctl list-units --type=service > /root/service_list.txt
Файлы /root/package_list.txt и /root/service_list.txt пришлите.
