Неудачное обновление прошивки MR6CUv2

здравствуйте. релиз 2606, на rs485-1 6 устройств в пределах метра, все WB, шина работает на 115200. веб-интерфейс предложил обновить, нажал на первом реле, ошибку не помню, но что-то завершилось неудачно. факт - все делал через браузер. теперь это реле недоступно ни в каком виде. что делал - оставлял одно устройство на линии, искал через веб + в режиме загрузчика (нет результатов), запускал “wb-mcu-fw-flasher -d /dev/ttyRS485-1 -a0 -u” в течение 2 секунд после подачи питания, менял скорость на 9600, сканировал все адреса - нет устройства. зеленый светодиод на реле горит постоянно. что можно еще сделать?

root@wirenboard-AI6XF5NV:~# wb-mcu-fw-updater recover /dev/ttyRS485-1 -a 63
Will find bootloader port settings for (/dev/ttyRS485-1 : 63; response_timeout: 0.20)… (elapsed: 01:52)
2026-08-15 17:14:22,009 Device (63 /dev/ttyRS485-1) is not in bootloader mode! Check connection or slaveid/port

Здравствуйте! Я — автоматический помощник техподдержки Wiren Board.
Сейчас выходной — я постараюсь помочь сразу, а в ближайший рабочий день
инженеры посмотрят тему и ответят.

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

  1. Полностью отключите питание MR6CUv2 на 10–15 секунд, оставьте на RS-485 только это реле и подключите его напрямую коротким кабелем. Проверьте полярность A/B и общий провод.
  2. На контроллере проверьте поиск на стандартной скорости загрузчика и на исходной скорости устройства:
wb-mcu-fw-flasher -d /dev/ttyRS485-1 -s 9600 -a 0 -u
wb-mcu-fw-flasher -d /dev/ttyRS485-1 -s 115200 -a 0 -u

Если ключ -s в установленной версии утилиты не поддерживается, выведите её справку:

wb-mcu-fw-flasher --help
  1. Если известен Modbus-адрес реле, повторите проверку с ним вместо -a 0. Команда recover предназначена именно для устройства, которое уже находится в загрузчике; сообщение Device ... is not in bootloader mode означает, что по адресу 63 загрузчик не отвечает.

  2. Приложите вывод команд и укажите:

    • точную маркировку: WB-MR6CUv2 или WB-MR6C v2 и текущий Modbus-адрес;
    • зелёный светодиод горит постоянно или мигает после включения;
    • результат wb-mcu-fw-flasher --help и команды с параметрами 9600/115200.

В документации Wiren Board описано восстановление через wb-mcu-fw-updater recover, но оно применимо только к устройству, находящемуся в режиме загрузчика: Wb-mcu-fw-updater. Общие параметры загрузчика приведены в Bootloader Changelog. По текущим симптомам похоже, что реле не перешло в загрузчик либо не отвечает по физическому интерфейсу; здесь может понадобиться мнение инженера Wiren Board.

Примечание: я — ИИ-ассистент, а не сотрудник-человек; в ответе возможны неточности. Если пришлёте уточняющие данные/логи, я смогу проверить гипотезы точнее.

я повторил процедуру с одним устройством на отдельной линии и собрал немного больше информации. вот окно с предложение обновить прошивку:

вот ошибка после нажатия кнопки “обновить”:

после чего устройство становится с адресом 1 и поиском не ищется (видимо быстрый модбас в старых прошивках отсутствует), но его можно добавить вручную. вот map3E:

а вот нашлось то пропавшее реле:

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

Добрый день!

Уточните, пожалуйста, один момент: версия прошивки после неудачной попытки ниже той, что была в устройстве до нажатия «Обновить», или совпадает с ней? Режим восстановления заливает обратно ту прошивку, которая в устройстве уже была, поэтому важно понимать, идёт ли речь о реальном понижении версии или о возврате к прежней.

На одном из двух устройств, которые у вас на отдельной линии, выполните обновление из консоли и приложите вывод целиком:

wb-mcu-fw-updater update-fw /dev/ttyRS485-1 -a<адрес> --debug

И заодно версии загрузчика, прошивки и сигнатуру — по ним видно, какой путь обновления выбирает утилита (порт держит драйвер, поэтому его надо остановить):

systemctl stop wb-mqtt-serial
wb-mcu-fw-flasher -d /dev/ttyRS485-1 -b115200 -pN -s2 -a<адрес> --get-device-info
systemctl start wb-mqtt-serial

Рекомендую обновлять на актуальной версии загрузчика: Обновление загрузчика.

Теперь по основному вопросу — как обновлять удалённые устройства.

Обновление прошивки само по себе безопасно: обрыв связи или питания в любой момент не приводит к необратимым последствиям, устройство просто остаётся в режиме загрузчика (индикатор мигает раз в секунду) и лечится повторной заливкой. Необратима только неудачная прошивка загрузчика — там критичны ~100 мс после последнего блока. Подробно: https://wiki.wirenboard.com/wiki/Bootloader#Описание

Загрузчик у вас по кнопке не обновится: в веб-интерфейсе это появилось в wb-mqtt-homeui 2.237.1 и wb-mqtt-serial 2.258.0 (у вас 2.208.1 и 2.248.1), в update-all — с wb-mcu-fw-updater 1.16.0 (у вас 1.14.4). То есть на удалённых устройствах вы рискуете максимум уронить их в загрузчик, а это обратимо.

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

по вашим инструкциям получилось обновить оба устройства, у которых произошел downgrade (подтверждаю, кнопка “обновить” в веб-интерфейсе повела себя явно нештатно и поставила более старые версии лоадера и прошивки со сбросом адреса на единицу) на последние версии:

root@wirenboard-AI6XF5NV:~# wb-mcu-fw-flasher -d /dev/ttyMOD1 -b115200 -pN -s2 -a63 --get-device-info
/dev/ttyMOD1 opened successfully.
Trying to probe (63 /dev/ttyMOD1) at bootloader params…
Bootloader version: 1.2.0
Firmware version: 1.18.5
Firmware signature (fw-sig): mr6cuG
Download firmwares: S3 Bucket Listing Generator
Component firmware flags read error: Illegal data value
root@wirenboard-AI6XF5NV:~# wb-mcu-fw-updater update-bl /dev/ttyMOD1 -a63
Will find serial port settings for (/dev/ttyMOD1 : 63; response_timeout: 0.20)… (elapsed: 00:00)
2026-08-17 14:59:38,603 Has found serial port settings: SerialSettings(baudrate=9600, parity=‘N’, stopbits=2)
2026-08-17 14:59:40,508 bootloader (mr6cuG 63 on /dev/ttyMOD1):
2026-08-17 14:59:40,510 Update: 1.2.0 → 1.4.9 (mr6cuG 63 /dev/ttyMOD1)
2026-08-17 14:59:42,169 Flashing /var/lib/wb-mcu-fw-updater/bootloader/wb-bootloader-updater_mr6cuG__1.4.9_master_4617288.wbfw (36 data chunks)
100%|##################################################################################################################################################################################################################################################|36/36
2026-08-17 14:59:49,802 Bootloader was successfully flashed. Will flash released firmware for “mr6cuG”
2026-08-17 14:59:56,356 Flashing /var/lib/wb-mcu-fw-updater/mr6cuG__1.26.5_master_f30fea4.wbfw (210 data chunks)
100%|################################################################################################################################################################################################################################################|210/210
2026-08-17 15:00:39,566 Done
root@wirenboard-AI6XF5NV:~# wb-mcu-fw-flasher -d /dev/ttyMOD1 -b115200 -pN -s2 -a63 --get-device-info
/dev/ttyMOD1 opened successfully.
Trying to probe (63 /dev/ttyMOD1) at bootloader params…
Bootloader version: 1.4.9
Firmware version: 1.26.5
Firmware signature (fw-sig): mr6cuG

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

Предварительно похоже, что причина связана со старым загрузчиком: 1.2.0 ниже версии 1.3.0, с которой появился вход в режим загрузчика с сохранением текущих параметров связи. Но это только версия, её надо проверять — понижать версию загрузчика веб-интерфейс не должен ни при каких условиях.

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

Может быть есть какой то еще фактор? Пропадала связь или питание в момент прошивки? Можете описать подробные шаги для воспроизведения?

питание пропадать не могло, 12в идет от 190Ач аккумулятора. шаги - исключительно нажатие кнопок в веб-морде. вероятно, дело в обновлении - была версия 2407 (не помню точно, но примерно 2 года разницы), был вызван apt-get upgrade, successfully, ребут, zigbee2mqtt сам не запустился, пришлось конфиги переносить из бэкапа, после пытался обновить прошивки. что еще можно считать дополнительными факторами, не знаю.

Практический вывод прежний: обновляйте оставшиеся устройства из консоли, командой wb-mcu-fw-updater update-fw. После обновления загрузчик станет свежее 1.3.0 и этот сценарий больше не повторится.

Если всё-таки столкнётесь с тем же ещё раз – соберите, пожалуйста, до любых дальнейших действий:

вывод wb-mcu-fw-flasher -d <порт> -b<скорость> -pN -s2 -a<адрес> --get-device-info до попытки обновления и сразу после неё;
точные дату и время нажатия «Обновить» и полный текст ошибки;
вывод ls -la /var/lib/wb-mcu-fw-updater/ /var/lib/wb-mcu-fw-updater/bootloader/;
диагностический архив, собранный сразу после сбоя, до перезагрузки контроллера и до повторной прошивки.

С таким набором мы сможем точно сказать, какой файл выбирался для заливки, и передать разработчикам воспроизводимый случай.

Здравствуйте!

Вам еще нужна помощь техподдержки?

нет, спасибо, закрывайте тему. я не буду экспериментировать)