ЕЖЕДНЕВНЫе WARNING от устройств WB

1

Обновил WirenBoard 8.5.2 до release wb-2602 и таки имею проблемы с родным модулями WirenBoard:

  • WB-MWAC v.1 крайняя версия прошивки 1.19.2 (actual). Начиная с версии прошивки 1.19.0 устройство поддерживает расширение Быстрый Modbus. Снят с производства, прошивки далее не обновляются.
  • WB-MSW v.3 текущая прошивка 4.35.0. Поддержка быстрого Modbus (Fast Modbus) для датчиков WB-MSW v.3 реализована в прошивке версии 4.16.16 и выше. Снят с производства, прошивки далее не обновляются.
    WB-MRGBW-D fw3 текущая прошивка 3.3.4. Поддержка быстрого Modbus (Fast Modbus) реализована в прошивке версии 3.2.0 и выше. Снят с производства, прошивки далее не обновляются.

Помогите господа производители с ЕЖЕДНЕВНЫМИ WARNING и это только малая часть:

2026-04-18T19:17:02.669Z [wb-mqtt-serial] WARNING: [modbus] failed to read 1 input(s) @ 280 of device modbus:162: Serial protocol error: malformed response: invalid crc
2026-04-18T19:02:10.726Z [wb-mqtt-serial] WARNING: [modbus] failed to read 1 input(s) @ 280 of device modbus:62: Serial protocol error: malformed response: invalid crc
2026-04-18T18:29:01.515Z [wb-mqtt-serial] WARNING: [modbus] failed to read 1 input(s) @ 280 of device modbus:162: Serial protocol error: malformed response: invalid crc
2026-04-18T18:09:03.659Z [wb-mqtt-serial] WARNING: [modbus] failed to read 1 input(s) @ 280 of device modbus:162: Serial protocol error: request timed out
2026-04-18T18:08:42.959Z [wb-mqtt-serial] WARNING: [modbus] failed to read 1 input(s) @ 280 of device modbus:162: Serial protocol error: malformed response: invalid crc
2026-04-18T18:02:26.089Z [wb-mqtt-serial] WARNING: [modbus] failed to read 1 input(s) @ 280 of device modbus:162: Serial protocol error: request timed out
2026-04-18T17:59:15.978Z [wb-mqtt-serial] WARNING: [modbus] failed to read 1 input(s) @ 280 of device modbus:162: Serial protocol error: request timed out
2026-04-18T17:48:31.957Z [wb-mqtt-serial] WARNING: [modbus] failed to read 1 input(s) @ 280 of device modbus:162: Serial protocol error: request timed out
2026-04-18T17:28:38.450Z [wb-mqtt-serial] WARNING: [modbus] failed to read 1 input(s) @ 280 of device modbus:62: Serial protocol error: malformed response: invalid crc
2026-04-18T17:28:12.816Z [wb-mqtt-serial] WARNING: [modbus] failed to read 1 input(s) @ 280 of device modbus:162: Serial protocol error: request timed out
2026-04-18T17:15:32.047Z [wb-mqtt-serial] WARNING: [modbus] failed to read 1 input(s) @ 280 of device modbus:162: Serial protocol error: request timed out
2026-04-18T17:13:32.707Z [wb-mqtt-serial] WARNING: [modbus] failed to read 1 input(s) @ 280 of device modbus:162: Serial protocol error: request timed out

2

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

Вы оборудование описали довольно подробно:

  • Контроллер: WB 8.5.2, обновлён до релиза wb-2602.
  • Модули:
    • WB-MWAC v1, FW 1.19.2, Fast Modbus поддерживается.
    • WB-MSW v3, FW 4.35.0, Fast Modbus поддерживается.
    • WB-MRGBW-D fw3, FW 3.3.4, Fast Modbus поддерживается.
  • Ошибки в логах: malformed response: invalid crc, request timed out, server device failure от wb-mqtt-serial для устройств modbus:62, modbus:162 и modbus-tcp:1.

Сейчас по симптомам есть два возможных слоя проблем:

  1. RS‑485 (modbus:62, 162) — CRC и таймауты.
  2. Modbus TCP (modbus-tcp:1) — ошибки server device failure (код 0x04).

После обновления контроллера и появляющихся регулярных WARN чаще всего причина либо в настройках опроса, либо в изменившемся поведении драйвера wb-mqtt-serial (таймауты, размер запросов, fast modbus), которое «обострило» уже существующую слабость линии/устройств.

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

1. Уточнить, какие именно устройства под адресами 62 и 162

Чтобы говорить предметно, нужно понять, что именно висит на этих адресах:

  1. Выполните на контроллере (по SSH):

    cat /etc/wb-mqtt-serial.conf

  2. Найдите блоки "slave_id": 62 и "slave_id": 162 — пришлите сюда:

    • тип устройства (device_type);
    • порт (port) и скорость (baud_rate);
    • включён ли "fast_baud_rate" или "max_read_registers" / "max_read_bits".

Это покажет, какие регистры опрашиваются (особенно адрес @ 280 — это может быть конкретный вход WB‑MWAC или MSW) и с какими параметрами.

2. Проверка настроек Fast Modbus и опроса

Так как все три модуля уже поддерживают Fast Modbus, важно, чтобы:

  1. В wb-mqtt-serial.conf:

    • для соответствующих устройств был включён fast Modbus только тем способом, который указан в шаблоне устройства (из коробки — через device_type, без ручного «разгона» max_read_registers);
    • не были вручную слишком завышены:
      • max_read_registers
      • max_read_bits
      • poll_interval
      • response_timeout_ms.

  2. Если вы модифицировали шаблоны в /usr/share/wb-mqtt-serial/templates/ или делали свои — пришлите их сюда (особенно те, где есть адреса 62 и 162).

На практике после обновлений иногда получается, что:

  • старый самодельный шаблон + новый wb-mqtt-serial → слишком большие запросы или слишком частый опрос → часть ответов не успевает / искажается → invalid crc и request timed out.

3. Проверка линии RS‑485

Ошибки invalid crc и request timed out не всегда софтовые — это классика «линия на грани»:

  1. Проверьте, пожалуйста, физику:

    • Длина и тип кабеля, наличие скруток, соединителей.
    • Наличие и расположение терминаторов 120 Ом и резисторов смещения (обычно на контроллере и на одном конце линии).
    • Заземление экрана кабеля.
    • Нет ли новых мощных помех (насосы, частотники, LED‑драйверы), которые могли появиться примерно одновременно с обновлением.

  2. Временно снизьте скорость на проблемном порту (если у вас 115200, попробуйте 38400 или 19200) в wb-mqtt-serial.conf, перезагрузите wb-mqtt-serial:

    service wb-mqtt-serial restart

Если при сниженной скорости объём WARN резко уменьшится или уйдёт, значит физика/настройка шины действительно на пределе.

4. Modbus TCP: server device failure

Для устройства modbus-tcp:1:

  • Ошибка server device failure — это ответ самого Modbus TCP сервера (обычно код исключения 0x04), а не контроллера.
  • Нужно понять:
    • Что за устройство по TCP?
    • Какой запрос ему летит (адрес coil’а, частота опроса)?
    • Нет ли пересечения: несколько клиентов одновременно опрашивают то же устройство (WB + что-то ещё)?

Приложите, пожалуйста:

cat /etc/wb-mqtt-serial.conf | sed -n '1,200p'
# если конфиг большой, достаточно блоков порта, где modbus-tcp:1, 62, 162

5. Диагностика через лог wb-mqtt-serial

Чтобы инженеры могли увидеть, что именно происходит, полезно:

  1. Включить отладочный лог:

    service wb-mqtt-serial stop
wb-mqtt-serial -d -c /etc/wb-mqtt-serial.conf 2>&1 | tee /mnt/data/wb-mqtt-serial-debug.log

  2. Подождать хотя бы 5–10 минут, пока в логе появятся ошибки по 62, 162 и modbus-tcp:1.

  3. Остановить отладочный процесс (Ctrl+C) и выслать сюда начало и несколько фрагментов вокруг ошибок.

По логу будет видно, какие именно запросы формируются (адреса, количество регистров) и каков ответ (или его отсутствие).

6. Что можно сделать уже сейчас, чтобы уменьшить поток WARNING

Пока разбираемся, чтобы не «заливало» логи и не мешало работе:

3

1. Уточнить, какие именно устройства под адресами 62 и 162 - датчики движения см файл

2. Проверка настроек Fast Modbus и опроса - все стандартно без разгона

  1. Проверка линии RS‑485 - жили не тужили 5 лет, не менялись длина до 10 метров от контролера до датчика

4. Modbus TCP: server device failure - можно не обращать внимания на эту проблему

устройства.txt (39,7 КБ)

4

1. Уточнить, какие именно устройства под адресами 62 и 162 - датчики движения см файл

2. Проверка настроек Fast Modbus и опроса - все стандартно без разгона

  1. Проверка линии RS‑485 - жили не тужили 5 лет, не менялись длина до 10 метров от контролера до датчика

4. Modbus TCP: server device failure - можно не обращать внимания на эту проблему

устройства.txt (39,7 КБ)

отладочный лог.log (3,4 МБ)

5

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

Ситуация:

  • Контроллер: Wiren Board 8.5.2, прошивка wb-2602.
  • По вашим словам, устройства с адресами 62 и 162 — это датчики движения (WB-MSW v.3), линия короткая (до ~10 м), работала стабильно годы.
  • Конфиги «стандартные, без разгона», есть отладочный лог и файл устройств.

Так как вложения на форуме я сейчас «физически» открыть не могу, опираюсь на описание: у вас после обновления появилась регулярная россыпь WARNING’ов по Fast Modbus (invalid crc, request timed out) на WB‑MSW v.3, хотя всё это раньше работало.

По опыту с WB‑8 и быстрым Modbus после обновлений возможны два типичных сценария:

  1. Новый wb-mqtt-serial стал опрашивать датчики более «агрессивно» (группировка регистров, меньше таймауты, чуть иная тактика повторов), и это обнажило пограничное место по MSW.
  2. Шаблон устройства или настройки порта не идеально совпадают с реальными возможностями конкретных MSW (особенно старых ревизий / прошивок), из-за чего периодически получаются «тяжёлые» запросы или слишком плотный опрос.

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

1. Проверить, нет ли дублирующего опроса этих же устройств

После обновления иногда остаётся «старый» конфиг или второй драйвер:

  1. Убедитесь, что wb-mqtt-serial — единственный, кто опрашивает эти MSW:

    • нет ли второго файла конфига, который тоже цепляется (/etc/wb-mqtt-serial.conf.d/...);
    • нет ли параллельного опроса тем же адресам другим сервисом (самописный опросчик, Node-RED, внешнее ПО по RS‑485 через USB‑конвертер и т.п.).

  2. На всякий случай можно вывести список процессов, связанных с wb-mqtt-serial:

    ps aux | grep wb-mqtt-serial

Дублирующий опрос легко даёт периодические invalid crc.

2. Небольшое «смягчение» опроса через настройки порта

Даже если всё «стандартно», для MSW иногда помогает чуть увеличить таймаут и/или уменьшить частоту опроса:

  1. В /etc/wb-mqtt-serial.conf найдите порт, на котором сидят адреса 62 и 162 (например, /dev/ttyRS485-1 или другой).

  2. В секции порта (где "port": "/dev/...") можно аккуратно добавить/изменить:

    "response_timeout_ms": 700,
"poll_interval": 100

    Если уже есть эти поля — чуть увеличьте:

    • response_timeout_ms было 500 → сделать 700–800.
    • poll_interval было 20–50 → сделать 80–100.

  3. После правки перезапустите драйвер:

    service wb-mqtt-serial restart

  4. Посмотрите, уменьшилось ли количество WARN за 10–20 минут.

Это не ломает Fast Modbus, но уменьшает вероятность таймаутов и «рваных» ответов при пиковых нагрузках.

3. Проверить шаблон устройства WB-MSW v.3

Так как у вас прошивка датчиков 4.35.0 (Fast Modbus поддерживается), важно, чтобы использовался родной актуальный шаблон, а не какая-то старая/копированная версия:

  1. Посмотрите, какой device_type указан для устройств 62 и 162 в конфиге wb-mqtt-serial.conf:

    • это должен быть тип из /usr/share/wb-mqtt-serial/templates-configs/ или /usr/share/wb-mqtt-serial/templates/, соответствующий WB-MSW v.3.

  2. Если вы когда-то создавали свою копию шаблона, в которой меняли:

    • max_read_registers,
    • max_read_bits,
    • или какие-то нестандартные блоки регистров,

    — имеет смысл временно вернуть штатный шаблон MSW v.3 и посмотреть, уйдут ли предупреждения.

Если напишете сюда точное название device_type из вашего конфига по 62/162 и кусок соответствующего JSON (можно только блок этих устройств), я смогу предметно подсказать, куда лучше поправить.

4. Небольшой эксперимент: отключить Fast Modbus для MSW

Чисто диагностический шаг (временно):

  1. Если для MSW используются специальные «fast»-шаблоны или явно включён «fast_baud_rate» / «fast_modbus» в настройках порта/устройства — можно попробовать отключить быстрый режим только для этих датчиков:

    • выбрать шаблон без Fast Modbus (если есть отдельный обычный),
    • или убрать из устройства специфический параметр fast, если он прописан.

  2. Перезапустить wb-mqtt-serial и посмотреть:

    • если WARN почти исчезнут — значит, конкретная связка «MSW v.3 + fast modbus + новая версия драйвера» у вас граничная, и инженеры уже будут разбираться, что именно в параметрах опроса их триггерит.

5. Что очень полезно приложить инженерам в рабочий день

Вы уже сделали основную тяжёлую работу (конфиги и отладочный лог есть). Чтобы инженеры быстрее локализовали проблему, желательно выложить в тему текстом (не только в виде вложения):

  1. Фрагменты /etc/wb-mqtt-serial.conf:

    • секцию порта, на котором сидят 62 и 162;
    • полные блоки двух устройств с slave_id: 62 и 162.

  2. Небольшие вырезки из отладочного лога

7

Добрый день!
Вы утверждаете, что данные ошибки стали появляться после перехода на WB-2602?
На каком релизе у вас работало стабильно до обновления?

В любом случае рекомендую провести диагностику: Serial-устройства работают нестабильно.

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

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