Ошибка загрузки файла

1

Постоянно появляется Ошибка загрузки файла: MQTT RPC request timed out MqttTimeoutError

после выключения и включения системы два модуля перешли в режим загрузчика один получилось восстановить с помощью команды wb-mcu-fw-updater recover /dev/ttyRS485-1 -a 10

а второй на нее выдавал ошибку Can’t connect to и адрес восстановил с помощью команды wb-mcu-fw-updater recover wb-mcu-fw-updater recover -a178

В чем причина появления ошибки, появляется частенько когда менял скорость модулей, теперь когда пытаюсь зайти в wb-engine.

2

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

Судя по описанию, у вас:

  • контроллер Wiren Board (скорее всего WB7/WB8),
  • модули на RS‑485 (адреса 10 и 178), вероятно, из серии WB-Mxxx,
  • при работе через веб-интерфейс (wb-engine / панель управления) периодически возникает ошибка:

«Ошибка загрузки файла: MQTT RPC request timed out MqttTimeoutError»

И после перезагрузки системы два модуля перешли в режим загрузчика (bootloader), один удалось восстановить через wb-mcu-fw-updater recover /dev/ttyRS485-1 -a 10, второй — через wb-mcu-fw-updater recover -a 178.

1. Что означает ошибка MQTT RPC request timed out

Такое сообщение обычно говорит не о файле как таковом, а о том, что:

  • веб-интерфейс делает RPC-запрос через MQTT к wb-rules / wb-mqtt-* сервисам,
  • ответ от сервиса не приходит вовремя (таймаут),
  • в итоге UI показывает “Ошибка загрузки файла”.

Частые причины:

  1. Сервис wb-rules или wb-mqtt- зависает или перезапускается* (например, из‑за перегрузки процессора/памяти или ошибок в правилах).
  2. MQTT-брокер (mosquitto) перегружен или периодически перезапускается.
  3. Слишком долгий или “зависший” обработчик RPC-запроса (например, при обращении к проблемному устройству по RS‑485).

Полезно сразу проверить логи:

journalctl -u wb-mqtt-serial -u wb-rules -u mosquitto -n 200 -f

И повторить операцию, которая вызывает ошибку — посмотреть, не появляются ли ошибки времени ответа, зависания, перезапуски сервисов.

2. Переход модулей в загрузчик после перезагрузки

То, что два модуля одновременно ушли в загрузчик, типично для:

  • нарушения параметров RS‑485 (скорость, чётность, стоп‑биты),
  • конфликтов адресов,
  • некорректной работы линии (питание / помехи / “горячее” подключение),
  • прерывания питания во время обновления прошивки.

По Recover-командам видно:

  • wb-mcu-fw-updater recover /dev/ttyRS485-1 -a 10 — стандартное восстановление по шине RS‑485[^1];
  • wb-mcu-fw-updater recover -a 178 — похоже, использовалась автонаходка порта или другая шина.

Режим загрузчика модулей Wiren Board обычно включается, если:

  • не удаётся корректно запуститься основная прошивка (например, сильно “битая” конфигурация порта или ошибки при старте),
  • или если модуль “поймал” последовательность линий/сигналов, похожую на вход в bootloader (на зашумлённой/нестабильной линии).

3. Связь с изменением скорости модулей

Вы сами отметили:

«появляется частенько когда менял скорость модулей»

Тут возможны варианты:

  1. Несоответствие настроек скорости и формата порта

    • В модуле вы выставили одну скорость (например, 115200), а в конфиге /etc/wb-mqtt-serial.conf осталась другая (9600).
    • Или разные модули на одной линии шины с разными скоростями.
      Это может приводить к “мусору” в линии и временами к зависаниям/ошибкам parsed пакетов и, в редких случаях, к уходу модулей в bootloader.

  2. Частое изменение параметров через веб-интерфейс
    При каждом изменении скорости/параметров wb-mqtt-serial перезапускается и может посылать на шину “обрывки” данных. Если линия “на пределе” по помехам/землям/терминации — модуль может принять это за команду загрузчика.

  3. Несоответствие параметров: четность / стоп‑биты
    Нужно убедиться, что и в модуле, и в контроллере выставлены одинаковые:

    • скорость (baud),
    • чётность (N/E/O),
    • количество стоп-битов.

4. Что сделать сейчас

  1. Проверить текущие настройки RS‑485 и модулей

    • Откройте /etc/wb-mqtt-serial.conf и убедитесь, что:
      • все устройства на одном порту /dev/ttyRS485-* на одной скорости и с одинаковыми параметрами;
      • скорость реально поддерживается всеми модулями (больше надёжности — 9600 или 19200, если линия длинная/шумная).
    • На самих модулях (через Modbus/регистры или DIP-переключатели, если есть) проверьте те же параметры.

    Документация по wb-mqtt-serial и конфигурации устройств Modbus есть здесь[^2][^3].

  2. Уменьшить скорость и стабилизировать линию

    На время отладки:

    • поставьте 9600 бод, N,8,1 для всех модулей на этой линии;
    • убедитесь в наличии:
      • терминаторов 120 Ом на концах линии,
      • общей земли между контроллером и модулями,
      • правильной полярности A/B.

    При проблемах на длинной линии лучше остаться на 9600–19200.

  3. Проверить, что модули стабильно опрашиваются

    Можно временно включить отладку wb-mqtt-serial:

    nano /etc/default/wb-mqtt-serial

    Добавить/изменить строку:

    DAEMON_OPTS="--debug"

    Затем:

    systemctl restart wb-mqtt-serial
journalctl -u wb-mqtt-serial -n 200 -f

    Посмотрите, нет ли множества ошибок CRC, timeouts, “device not responding”, захода в bootloader и т.п.

  4. **Разобраться с ошибкой MQTT RPC при входе

4

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

6

А вот сейчас контроллер написал нет связи адрес/mqtt и контроллер завис, зайти без перезагрузки не получилось. Такое и раньше было.

7

Добрый день,
Появлялись ли еще проблемы?