Наблюдаю периодические ошибки обмена с модулями Wiren Board на RS485-2. Пока заметны только предупреждения в журнале — явных сбоев или задержек управления не обнаружил. Вероятно, ошибки были с запуска системы, но ранее журнал не проверял.
Версии ПО
Контроллер: Wiren Board 8.
Релиз: wb-2606, stable, wb8/bullseye.
Ядро: 6.8.0-wb161 #1 SMP Wed Aug 12 12:43:50 UTC 2026 aarch64.
wb-mqtt-serial: 2.248.1-wb107.
Подключение и настройки
Проблемный порт: /dev/ttyRS485-2, 115200, 8N2.
Длина шины — до 1,5 м, питание от одного БП.
Кабель — неэкранированная витая пара; A и B идут жилами одной пары.
Контроллер находится на конце шины, встроенный терминатор включён. На другом конце также установлен терминатор.
На порту настроены только модули WB: 2 × WB-MWAC, 11 × WB-MCM8, 5 × WB-MR6CU, 4 × WB-MDM3.
Снижение скорости до 57600 проблему не устранило; в текущей конфигурации снова 115200.
Ошибки
В журнале встречаются invalid crc, invalid data size и request timed out. Ошибки затрагивают разные модели и адреса, в частности:
WB-MWAC — 105 и 193;
WB-MCM8 — 80;
WB-MR6CU — 111, 127, 180, 191;
WB-MDM3 — 109, 121, 156, 196.
В теме «Ошибка invalid crc модуля WB-MCM8» обсуждалась аналогичная проблема на таком же ядре. Поддержка сообщала о неисправленном баге «Ошибки invalid crc на 115200» и планируемых изменениях в ядре 6.15.
Прошу уточнить:
Похож ли мой случай на этот известный баг или по диагностике видна другая причина?
Доступно ли уже исправление и какое обновление рекомендуется для моей системы?
Нужны ли дополнительные проверки для выяснения причин invalid data size и таймаутов?
Диагностический лог прилагаю.
приложен диагностический архив, доступен только сотрудникам поддержки
Похоже на ERRWB84009 «Нестабильная работа портов RS-485» ( https://wiki.wirenboard.com/wiki/WB_8:\_Errata ) — баг во всех WB8. Ошибки у вас идут сразу по 12 из 21 устройства, разных моделей — не похоже на локальную проблему монтажа. В среднем одна ошибка раз в 5 минут.
Исправления пока нет — «запланировано в ближайших обновлениях». Релиз и ядро у вас уже последние стабильные.
Тест на 57600 в логе виден лишь ~1,5 мин с перезапусками службы. Вспомните, пожалуйста, поведение было такое же, и частота ошибок совпадала?
Уточните: какой резистор стоит на дальнем конце шины (номинал, именно между A и B на последнем устройстве)?
Длительно не тестировал на этой скорости - убедился, что ошибки повторились и перешел назад на 115200. Поэтому не могу охарактеризовать их частоту. Если нужно - могу более длительно подержать эту скорость для статистики.
В конце линии: витая пара A и В длинной 5 см от последнего устройства выходит на двойную клемму, с обратной стороны которой резистор 120 Ом 5%.
Я не вижу каких-либо потенциальных проблем в монтаже, шине и т.д. Полагаю это то, что описано в ERRATA (см. выше). Поскольку частота ошибок у вас крайне малая, описанная ситуация на работоспособность не влияет, поэтому я предлагаю дождаться фикса.
Прошу уточнить, есть ли сроки решения ERRWB84009 ?
На данный момент запустил несколько правил, которые в том числе обрабатывают метаданные “/meta/error” для контроля за состоянием выходных реле модулей.
Теперь при ошибках вида “WARNING: [modbus] failed to read 1 coil(s) @ 0 of device modbus:191: Serial protocol error: request timed out”
Правила выполняют защитные выключения выходов, что корректно с точки зрения логики, но приводит к частым отключениям из-за фактического наличия таких ошибок. Т.е. я пришел к ситуации, когда уже нельзя утверждать, что наличие ошибок связи не влияет на работоспособность.
Пока я предполагаю ввести в правила более стойкий алгоритм обработки ошибок (для выключения при устойчивой потере связи) или отказаться от такого контроля вообще, но лучшим решением конечно выглядит стабильность обмена данными. Если бы не предположение о ERRWB84009, то я бы начал смотреть физику, хотя имея опыт работы с RS485 в промке - я не вижу за что можно зацепиться. Несколько модулей рядом в одном шкафу, частотников и контакторов рядом нет, условия “кукольные”.
Здравствуйте! Да, нехорошо получается, ошибки связи влияют на работу системы. Исправление в штатных обновлениях пока не вышло. У меня была святая уверенность, что ваш случай полностью подпадает под эррату, но появилось еще одно предположение. Для этого потребуется ваша небольшая помощь.
Пожалуйста, включите отладочные сообщения в настройках драйвера Serial-устройств и сохраните настройки. Драйвер кратковременно перезапустится, отключать устройства не нужно.
Через 15–20 минут отключите отладку, сохраните настройки и сразу соберите диагностический архив. Пришлите его, пожалуйста, для проверки обмена.
Спасибо за архив. Извините, я не учёл ограничение диагностики: при включённой отладке в архив попали лишь последние несколько секунд обмена, без ошибок.
Пожалуйста, попробуйте выгрузить уже записанный журнал следующей командой через SSH:
Мы подозреваем, что ошибки связаны с тем, что все прерывания порта RS485-2 обрабатывает одно ядро процессора (CPU0), и при его занятости контроллер иногда не успевает вовремя переключить порт на приём. Чтобы проверить, перенесите это прерывание на другое ядро и сравните число ошибок:
Перенесите прерывание на другое ядро. Если в п. 1 значение 1 или f, выполните:
echo 2 > /proc/irq/286/smp_affinity
Если в п. 1 значение 2, то вместо этого выполните echo 4 > /proc/irq/286/smp_affinity и сообщите нам об этом. Если команда выдаёт ошибку, пришлите её текст.
Через 1–2 часа повторите команду из п. 2 и напишите нам оба числа.
Верните значение из п. 1 командой echo <значение> > /proc/irq/286/smp_affinity (или перезагрузите контроллер, настройка сбрасывается).
Предлагаем снизить скорость порта RS485-2 с 115200 до 57600: в вашем журнале за 12–13.09, когда порт работал на 57600, было около 4 ошибок в час против 15 на 115200. Полностью ошибки не исчезнут, но станут заметно реже.
У каждого из 21 устройства в группе General отметьте Baud rate и выберите 57600. Скорость порта пока не меняйте.
Нажмите «Сохранить» и подождите 2–3 минуты, пока устройства перестанут отвечать (на вкладке «Устройства» их каналы станут красными). Это значит, что новая скорость записана.
Выставьте скорость порта 57600 и снова сохраните. Устройства должны начать отвечать.
Через сутки напишите, пожалуйста, сколько ошибок накопилось:
journalctl -u wb-mqtt-serial --since "1 day ago" | grep -c "failed to read"
Спасибо за замер. На 57600 ошибок стало примерно в 2 раза меньше (около 6 в час против 15 на 115200).
Чтобы понять, равномерно ли ошибки распределены по всем устройствам или сосредоточены на нескольких адресах, выполните, пожалуйста, на контроллере и пришлите вывод:
До выяснения оставьте 57600 и поправьте свои правила: выключайте выходы, только если /meta/error держится дольше 10–15 секунд подряд. Единичная ошибка снимается следующим опросом и не означает потерю связи.
Точного срока исправления пока нет: в описании ошибки указано «в ближайших обновлениях». Сейчас в репозитории у всех релизов ядро 6.8.0-wb161, новое не опубликовано.
Заметил важную деталь: 51 из ваших ошибок приходится на DALI-шлюз modbus-tcp:1 (по Ethernet), это другая проблема. Пришлите, пожалуйста, несколько таких строк с метками времени, чтобы понять тип сбоя:
journalctl -u wb-mqtt-serial --since "1 day ago" -o short-precise | grep "failed to read" | grep "modbus-tcp" | tail -20
Я гляжу - все ошибки в одно время, я вчера вечером подключал еще один DALI светильник, это по-всей видимости и объясняет эти записи, сохранял настройки в драйвере (активировал управление этим светильником)