После обновления прошивки устройства модуса зависли в режиме загрузчика

Добрый день! Столкнулся с такой проблемой: вайренборд проработал на объекте почти год без обновлений прошивки (самого контроллера и всех модбас устройств). В один прекрасный момент один из датчиков wb-msw-v3 полностью отвалился (в дебаге это: failed to read 2 holding(s) @ 97 of device modbus:17: Serial protocol error: request timed out) а у нескольких других появились какие-то аномальные значения VOC (более 100000) и появилась ошибка чтения этого регистра.

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

В итоге вместо того чтобы те датчики начали работать, отвалилось еще несколько датчиков и других утройсв (вошли в режим загрузчика и не выходят). При чем абсолютно рандомно (например один WB-MAO4 обновился без проблем, а второй завис в загрузке).

Пытался починить все командой “wb-mcu-fw-updater recover-all”, но это не помогло, устройства зависают на половине прошивки.

Пробовал восстанавливать каждое устройство отдельно, но результат тот же(

При попытке обновить загрузчик вообще говорит, что нужно проверить подключение устройсва, хотя с ним вобще ничего не могло произойти, тк датчики точно никто не трогал.

В чем может быть проблема? Ее нужно прямо срочно решить, а как это сделать вообще не представляю…

Здравствуйте! Опишите, пожалуйста, вашу конфигурацию: какая аппаратная версия контроллера, какие устройства, к каким портам подключены, какие параметры обмена используете? Пришлите, пожалуйста, архив с диагностической информацией контроллера.
Еще нужны логи от утилиты обновления. Получить их можно так:

journalctl --since "1 day ago" | grep wb-mcu-fw-updater > /root/updater.log

Файл /root/updater.log пришлите сюда.
Также пришлите, пожалуйста, серийные номера modbus-устройств или фото наклеек с серийным номером.

Проверьте физическое подключение устройств: что провода А и В шины RS-485 не имеют обрывов, замыканий, в клеммниках надежный контакт.
Попробуйте оставить на порту подключенным только одно modbus-устройство, например, модуль MAO4. Перезагрузите его питанием, затем еще раз запустите восстановление прошивки командой

wb-mcu-fw-updater recover /dev/ttyRS485-2 -a23

В общем после ночи мучений все же самому удалось восстановить работу отвалившихся устройств. Вылечил это ручной прошивкой с загрузкой файлов из репозитория.
Вообще у меня есть такое ощущение, что у вас немного сломался инструмент авто-обновления, т.к буквально в этот же день возникла аналогичная проблема на другом контроллере (wb-7). Также обновили его последний версии прошивки и также командой “wb-mcu-fw-updater update-all” обновляли прошивки устройств. Половина из них тоже норм обновилась, а другая зависла в режиме загрузчика. Но там помогли команда авто-восстановления (wb-mcu-fw-updater recover).

Так что если будет возможность, приверти wb-mcu-fw-updater. Ладно на wb-6 проработавшем почти год и с установленным сторонним ПО какой-то косяк получился, но на совсем новом контроллере, буквально в первый раз включившемся - это странно.

P.S пока танцевал с бубнов вокруг терминала возникла мысль, а почему не сделать в веб интерфейсе все вот эти команды? Во вкладке обновления несколько кнопок “Обновить ПО контролера”, “Обновить устройства”, “Обновить определенное устройства” “Востановить все” и т.д. Вроде это не очень сложно сделать, но очень нужно)

Вернемся к изначальной проблеме. Вот схема подключения всех устройств:

Сам контроллер:

Датчики все в полной комплектации (серийные номера):
4269959935 - подключение через wb-mge, проблема с VOC (завис на 82 ppm и горит красным)
4269966524 - подключение через wb-mge, проблема с VOC (завис на 42480 ppm и горит красным)
4269963457 - подключение через wb-mge, проблема со всем (все горит красным)
4269965484 - подключение через wb-mge, проблема с VOC (завис на 320 ppm и горит красным)

Т.к. все эти датчики подключены через wb-mge, удаленно с ними что-то делать возможности нет, wb-mcu-fw-updater не работает через IP. Буду на объекте в ПН, смогу их переподключить и обновить (надеюсь это их спасет).

По поводу настроек подключения, то вот:

Сбор данных для диагностики почему-то не доступен(

Вместо него могу логи из системного журнала скинуть:
log_20220623T214319.log (6.5 КБ)

Файл /root/updater.log выводит пустой…

Так же очень странно, что в вебе /etc/wb-mqtt-serial.conf очень долго грузится и открывается примерно 1 раз из 15. Постоянно выдает такую ошибку:

Да и вообще по ощущениям вся система очень сильно подтормаживает. Может есть какая-то команда для оптимизации и отчистки от лишнего? Я понимаю что на нем стоит много всего (спрут-хаб, ред-нод и опен-впн). Но аналогичные сетапы с таким набором ПО есть и на других объектах, и там таких проблем не наблюдается.

У вас включен режим отладки драйвера serial-устройств. Эта диагностика заполнила все логи. Также это вызывает дополнительную нагрузку на контроллер. Отключите диагностические сообщения драйвера и сохраните конфигурацию:

Вижу, что на каждой шине у вас подключены еще и сторонние устройства. Не может ли быть проблема в этом? Иногда сторонние устройства могут не совсем ожидаемо работать, нарушая обмен по шине. Можно попробовать для теста их отключить при обновлении прошивки. После обновления, если снова будут проблемы, сохраните логи, как писал выше.

Через MGE тоже можно обновлять прошивку, хоть это и не очень удобно. Процедура описана здесь: Работа с подключёнными к WB-MGE (WB-MIO-E) устройствами через socat — Wiren Board

Перезагрузите контроллер, затем проверьте работает ли соответствующий сервис командой:

systemctl status wb-diag-collect

Если нет, то выполните команды:

systemctl enable wb-diag-collect
systemctl start wb-diag-collect

Все-таки нужен архив с диагностической информацией для диагностики, и чтобы не просить вас выполнять команды в консоли вручную.
Корректно ли прошло обновление контроллера? Если ПО контроллера давно не обновлялось, то нужно обновлять по инструкции: Новый репозиторий ПО Wiren Board — Wiren Board
Если делали не так, то сделайте еще раз по инструкции.

Это очень похоже на проблемы, описанные в Errata: ERRWB-MS0009 и ERRWB-MS0003

Обновление прошивок должно решить проблему.

Да, согласен с вами, предложение хорошее. Запишу ваш запрос в список предложений для разработки.

Сделал. Контроллер был явно куплен ранее мая 2021 года.

Вот архив:
diag_output_ABKOWYKY_2022-06-24-20.zip (141.7 КБ)

Сделал, запустил сбор логов еще раз, вот что вышло:
updater.log.zip (741 Байт)

Тут уж лучше в пн когда буду на объекте воткну прямо в модбас, а то еще накосячу где-то)

Вот тут есть подозрения на блоки INTESIS ME-AC-MBS-1. Они себя в целом странно ведут, тут некоторые уже писали про них. В целом они работают, но когда в интерфейсе нажимаешь на например вкл/выкл, он включаться и спустя секунду сам отключается, а затем опять включается, на видео видно как он себя ведет.

Вот его натройки:

Вижу, что пакет с новым ядром 5.10 установился, но работает еще старое ядро 4.9. Перезагрузите контроллер, чтобы загрузилось новое ядро Linux и еще раз пришлите диагностический архив, чтобы это подтвердить.

Запустите еще раз обновление прошивок:

wb-mcu-fw-updater recover-all

Затем уже соберите логи утилиты. Старые логи уже переписались логами от драйвера serial-устройств.

Не могу точно сказать. Да, некоторые сторонние устройства могут так себя вести: после команды записи нового значения при чтении какое-то время (пока это значение отправляется другому устройству) еще может отдавать старое значение.

Получилось ли решить проблему?

Теперь даже сборщик не запускается…
Бесконечно грузит что-то. По ходу у него память забита чем то

и такая ошибка в вебе вечно

Обновление без ошибок прошло?
Можете остановить процесс java? Что это за процесс? Судя по скриншоту он создает самую большую нагрузку на процессор. Возможно поэтому наблюдается медленная работа веб-интерфейса.

Ни одна из страниц в интерфейсе не загружается?
Попробуйте сгенерировать диагностический архив вручную командой:

wb-diag-collect wbdiag

Пришлите сгенерированный файл из директории /root/wbdiag_XXXXXXXX_XXXXXXX.zip

Еще, обратите внимание что активен процесс kswapd, это значит что RAM явно недостаточно и используется файл свопа. То есть - медленные операции с флешкой.
Ну и еще - запущен mosquitto_pub, который в нормальном режиме работы не используется, совсем.
Как предлагает коллега - остановите процесс java.

На утройсве паралельно запушен спрутхаб и нод ред, Мб это они используют java? Если да, то боюсь остановить их не выйдет, тк они используются для работы умного дома. Или спрут и нод ред это другие сервисы?

Обновление без проблем поставилось

Да, вполне вероятно. В таком случае поменяйте настройки этого ПО, потербление такого количества RAM со свопом на флеш - довольно быстро израсходуют ее ресурс.

Может есть смысл остановить то, что НЕ используется? Тот же аларм, KNX и тд?

А он за что отвечает?

Да, конечно. Но это капля.

https://wirenboard.com/wiki/MQTT#Работа_из_командной_строки
Но кроме как отладка.разработка не используется.

В общем рекомендация остается прежней - проверить, сохраняются ли ошибки и неожиданное поведение при остановленных сервисях, использующих java/

Можно набор команд для остановки?) а то еще чего лишнего снесу)))

К сожалению, прям все остановить не смогу((( Сейчас нод ред перезапустил, по ощущениям все стало немного быстрее