Множественные ошибки "Serial protocol error"

Контроллеры Wiren Board
1

Добрый день.

Недавно переехал c wb 7.4 на 8.5 и обнаружил две неприятные вещи:

  1. Первая заключается в следующем:

image
image1667×405 60.8 KB

Ошибка спонтанная, возникает очень часто. Чтобы её воспроизвести, мне нужно зайти в настройки serial, и просто начать кликать на устройства, на одном или более (это всегда случайное устройство) рано или поздно она появится. Повторный клик на устройство ошибку не сбрасывает. Только F5 (и то есть шанс, что она появится снова. На wb 7.4 я никогда не видел такой ошибки.

  1. Лог serial просто завален ошибками типа:

29-12-2025 11:13:08.926	WARNING: [modbus] failed to read 1 coil(s) @ 3 of device modbus:1: Serial protocol error: malformed response: invalid crc
29-12-2025 11:12:07.127	WARNING: [modbus] failed to read 1 discrete(s) @ 0 of device modbus:56: Serial protocol error: malformed response: invalid crc
29-12-2025 11:07:45.879	WARNING: [RPC] </dev/ttyRS485-1 9600 8 N 2> modbus:6 unable to read "device_model_ex" register: Serial protocol error: request timed out
29-12-2025 11:07:41.476	INFO: [serial device] device modbus:5 is connected
29-12-2025 11:07:41.454	INFO: [modbus] Continuous read enabled [slave_id is 5]
29-12-2025 10:59:48.591	WARNING: [modbus] failed to read 1 input(s) @ 283 of device modbus:29: Serial protocol error: malformed response: invalid crc
29-12-2025 10:54:40.301	WARNING: [modbus] failed to read 1 coil(s) @ 3 of device modbus:1: Serial protocol error: malformed response: invalid crc
29-12-2025 10:54:40.288	WARNING: [modbus] failed to read 1 coil(s) @ 0 of device modbus:21: Serial protocol error: malformed response: invalid crc
29-12-2025 10:53:38.709	WARNING: [modbus] failed to read 1 coil(s) @ 0 of device modbus:4: Serial protocol error: malformed response: invalid crc
29-12-2025 10:48:28.870	WARNING: [modbus] failed to read 1 input(s) @ 283 of device modbus:61: Serial protocol error: malformed response: invalid crc
29-12-2025 10:45:25.286	WARNING: [modbus] failed to read 11 coil(s) @ 0 of device modbus_io:25:1: Serial protocol error: malformed response: invalid crc
29-12-2025 10:44:22.212	WARNING: [modbus] failed to read 1 input(s) @ 283 of device modbus:10: Serial protocol error: malformed response: invalid crc
29-12-2025 10:41:17.233	WARNING: [modbus] failed to read 1 coil(s) @ 0 of device modbus:50: Serial protocol error: malformed response: invalid crc
29-12-2025 10:40:15.734	WARNING: [modbus] failed to read 1 coil(s) @ 0 of device modbus:21: Serial protocol error: malformed response: invalid crc
29-12-2025 10:40:15.553	WARNING: [modbus] failed to read 1 coil(s) @ 0 of device modbus:4: Serial protocol error: malformed response: invalid crc
29-12-2025 10:38:06.229	WARNING: [modbus] failed to read 1 input(s) @ 283 of device modbus:11: Serial protocol error: request timed out
29-12-2025 10:37:10.646	WARNING: [modbus] failed to read 11 coil(s) @ 0 of device modbus_io:25:1: Serial protocol error: malformed response: invalid crc
29-12-2025 10:31:00.733	WARNING: [modbus] failed to read 2 input(s) @ 9 of device modbus:11: Serial protocol error: malformed response: invalid crc
29-12-2025 10:28:58.902	WARNING: [modbus] failed to read 1 coil(s) @ 10 of device modbus:30: Serial protocol error: malformed response: invalid crc
29-12-2025 10:27:55.787	WARNING: [modbus] failed to read 1 coil(s) @ 0 of device modbus:2: Serial protocol error: malformed response: invalid crc
29-12-2025 10:25:52.520	WARNING: [modbus] failed to read 1 discrete(s) @ 1 of device modbus:55: Serial protocol error: malformed response: invalid data size
29-12-2025 10:22:59.637	WARNING: [modbus] failed to read 1 input(s) @ 283 of device modbus:11: Serial protocol error: request timed out
29-12-2025 10:22:50.193	WARNING: [modbus] failed to read 1 input(s) @ 283 of device modbus:6: Serial protocol error: request timed out

При этом всё вроде бы работает, только иногда проявляются небольшие задержки в пару секунд (например, при открытии двери свет может “тупить”), в интерфейсе устройств время от времени мигают красные контролы. И совсем редко отваливается опрос устройств на всей шине по ощущениям где-то на минуту.
В принципе, всё это не сильно напрягает, но хотелось бы всё равно что-то сделать, если это возможно, понять причину.

У меня 3 шины rs-485, на них висит 9, 15 и 11 устройств соответственно. По распределению ошибок я не обнаружил, что глючит какая-то конкретная шина, ошибки возникают случано примерно поровну на каждой. Физически шины идут в разных направлениях, каждая в свою часть дома.

  • Шины практически всегда идут на удалении минимум 10см от силовых проводов. Кое-где пересекаются под 90 градусов и подходят ближе только в щите. Токи на силовых проводах сейчас незначительные - весь дом бОльшую часть дня потребляет не более 300W.
  • Часть шин проложена проводом SFTP, всё остальное FTP.
  • Оплетки и экраны физически соединены на всём протяжении, и заземлены в одном месте в центральном щите. Я пробовал отключать заземление (наводки на нем точно имеются, т.к. при подключении оно чуть-чуть искрит), но вообще не обнаружил разницы - ошибки идут как с заземлением, так и без него, примерно с такой же частотой.
  • А и B всегда подключены проводом из одной пары - зеленым и бело-зеленым.
  • Протяженность шин я оцениваю где-то по 30-40 метров каждая.
  • Одна шина огранизована без ответвлений. Две других шины имеют ответвления.

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

Я знаю только, что еще месяца 3 назад у меня такие ошибки были крайне редким гостем в логах, хотя с того времени физически мало что поменялось, одна “самая древняя” шина 100% вообще не трогалась, но ошибки теперь возникают и на ней с такой же интенсивностью.

С чего можно хотя бы начать диагностику? Если уже ничего не сделать - fine, тогда как отключить эти логи, чтобы они через пару лет на съели emmc?

приложен диагностический архив, доступен только сотрудникам поддержки
(258,3 КБ)

1 Like
4

Добрый день.

Вот тут обсуждали: Множественные ошибки Can't get firmware info for - #17 от пользователя BrainRoot

На WB7 тоже был актуальный testing?

А стоят ли терминаторы?

5

Вот тут обсуждали

ок, значит, первая проблема - следствие второй. Смущает, правда, само сообщение “request timed out(-32000)”. В скобках - это ведь таймаут запроса на чтение настроек из устройства? Почему значение отрицательное? Это миллисекунды? Если да, то неправдоподобно - от момента клика до момента получения этой ошибки ну максимум пару секунд, никак не 32. Или, если это не таймаут, а код ошибки, то из сообщения это неочевидно. Ну, и самое главное - отсутствие пробела перед открывающей скобкой! :upside_down_face:

Можно ли настроить этот таймаут, чтобы реже сталкиваться с этой ошибкой?

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

Если Вы имеете в виду WB-T120, то нет, такие не стоят.

Когда-то видел вот тут, что контроллер имеет встроенные. У меня они включены в настройках:

image
image271×272 8.86 KB

Этого недостаточно? Если недостаточно, то где устанавливать WB-T120 - в случае с “правильной” последовательной шиной понятно, на конце, а в случае со “звездой” - на каждом конце? Довольно громоздкая штука, я ведь правильно понимаю, что любой резистор на 120 ом подойдет, а то в моем случае концы - это датчики MSW, аккуратненько установленные на стене. Внутрь такого датчика WB-T120 не запихнуть.

6

Нет, код ошибки

Screenshot_20251230_102637
Screenshot_20251230_102637634×185 13 KB

Это да, вот тут оно выводится.

Он и так 10 секунд. если верно понимаю
Хотя тут делится. Ну, у разработчиков узнаю, конечно.

Но вообще эта ошибка не влияет, в общем, на возможность настройки.
Сервис, wb-device-manager, работает параллельно.

Конфиги пакетов те же. Железо - да,

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

Да, верно.

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

7

проверил экспериментально - он и так 10с.

Dec 30 11:14:13 wirenboard-AXI4GNPT wb-device-manager[2097]: [WARNING] Can't get firmware info for slave id: 71, /dev/ttyRS485-1 115200 8N2: rpc call to wb-mqtt-serial/port/Load -> 10.00s: no answer [-33000]: rpc call params: {'slave_id': 71, 'function': 3, 'address': 250, 'count': 16, 'response_timeout': 8, 'total_timeout': 10000, 'protocol': 'modbus', 'format': 'HEX', 'path': '/dev/ttyRS485-1', 'baud_rate': 115200, 'parity': 'N', 'data_bits': 8, 'stop_bits': 2}
Dec 30 11:14:13 wirenboard-AXI4GNPT wb-device-manager[2097]: [WARNING] Can't get firmware info for slave id: 33, /dev/ttyRS485-1 115200 8N2: rpc call to wb-mqtt-serial/port/Load -> 10.00s: no answer [-33000]: rpc call params: {'slave_id': 33, 'function': 3, 'address': 250, 'count': 16, 'response_timeout': 8, 'total_timeout': 10000, 'protocol': 'modbus', 'format': 'HEX', 'path': '/dev/ttyRS485-1', 'baud_rate': 115200, 'parity': 'N', 'data_bits': 8, 'stop_bits': 2}
Dec 30 11:14:13 wirenboard-AXI4GNPT wb-device-manager[2097]: [WARNING] Can't get firmware info for slave id: 23, /dev/ttyRS485-1 115200 8N2: rpc call to wb-mqtt-serial/port/Load -> 10.00s: no answer [-33000]: rpc call params: {'slave_id': 23, 'function': 3, 'address': 250, 'count': 16, 'response_timeout': 8, 'total_timeout': 10000, 'protocol': 'modbus', 'format': 'HEX', 'path': '/dev/ttyRS485-1', 'baud_rate': 115200, 'parity': 'N', 'data_bits': 8, 'stop_bits': 2}
Dec 30 11:14:13 wirenboard-AXI4GNPT wb-device-manager[2097]: [WARNING] Can't get firmware info for slave id: 24, /dev/ttyRS485-1 115200 8N2: rpc call to wb-mqtt-serial/port/Load -> 10.00s: no answer [-33000]: rpc call params: {'slave_id': 24, 'function': 3, 'address': 250, 'count': 16, 'response_timeout': 8, 'total_timeout': 10000, 'protocol': 'modbus', 'format': 'HEX', 'path': '/dev/ttyRS485-1', 'baud_rate': 115200, 'parity': 'N', 'data_bits': 8, 'stop_bits': 2}
Dec 30 11:14:13 wirenboard-AXI4GNPT wb-device-manager[2097]: [WARNING] Can't get firmware info for slave id: 32, /dev/ttyRS485-1 115200 8N2: rpc call to wb-mqtt-serial/port/Load -> 10.00s: no answer [-33000]: rpc call params: {'slave_id': 32, 'function': 3, 'address': 250, 'count': 16, 'response_timeout': 8, 'total_timeout': 10000, 'protocol': 'modbus', 'format': 'HEX', 'path': '/dev/ttyRS485-1', 'baud_rate': 115200, 'parity': 'N', 'data_bits': 8, 'stop_bits': 2}
Dec 30 11:14:13 wirenboard-AXI4GNPT wb-device-manager[2097]: [WARNING] Can't get firmware info for slave id: 31, /dev/ttyRS485-1 115200 8N2: rpc call to wb-mqtt-serial/port/Load -> 10.00s: no answer [-33000]: rpc call params: {'slave_id': 31, 'function': 3, 'address': 250, 'count': 16, 'response_timeout': 8, 'total_timeout': 10000, 'protocol': 'modbus', 'format': 'HEX', 'path': '/dev/ttyRS485-1', 'baud_rate': 115200, 'parity': 'N', 'data_bits': 8, 'stop_bits': 2}
Dec 30 11:14:13 wirenboard-AXI4GNPT wb-device-manager[2097]: [WARNING] Can't get firmware info for slave id: 140, /dev/ttyRS485-2 19200 8E1: rpc call to wb-mqtt-serial/port/Load -> 10.00s: no answer [-33000]: rpc call params: {'slave_id': 140, 'function': 3, 'address': 250, 'count': 16, 'response_timeout': 8, 'total_timeout': 10000, 'protocol': 'modbus', 'format': 'HEX', 'path': '/dev/ttyRS485-2', 'baud_rate': 19200, 'parity': 'E', 'data_bits': 8, 'stop_bits': 1}
Dec 30 11:14:13 wirenboard-AXI4GNPT wb-device-manager[2097]: [WARNING] Can't get firmware info for slave id: 21, /dev/ttyMOD1 115200 8N2: rpc call to wb-mqtt-serial/port/Load -> 10.00s: no answer [-33000]: rpc call params: {'slave_id': 21, 'function': 3, 'address': 250, 'count': 16, 'response_timeout': 8, 'total_timeout': 10000, 'protocol': 'modbus', 'format': 'HEX', 'path': '/dev/ttyMOD1', 'baud_rate': 115200, 'parity': 'N', 'data_bits': 8, 'stop_bits': 2}
8

Хм, визуально это так не выглядит. Могу довольно легко воспроизвести следующую ситуацию: я перехожу в интерфейс настройки (или нажимаю F5) и сразу кликаю на устройство. Сразу ловлю ошибку. Прошло от силы 2 секунды или даже менее.

Такие ошибки я иногда замечал, но в ооочень малом количестве, а не так, чтобы весь лог из них состоял. Но дело в том, что пристально смотрел в логи я месяца 2-3 назад. С тех пор поменялся не только контроллер - были добавлены датчики на двух шинах, и для них сделаны несколько ответвлений. Поэтому нельзя с уверенностью сказать, что проблема в контроллере. Я бы поэкспериментировал, попытался бы “отсечь” все новые участки, или попробовать метод дихотомии, но сейчас неудачное для этого время - работает отопление, много всего, время года темное, поэтому без света во время таких экспериментов не посидишь.

С резисторами я попробую, когда их раздобуду. Отпишусь по результатам.
А пока другой вопрос: что можно сделать, чтобы улучшить ситуацию с задержками из-за таких ошибок? Т.е., если я, например, подниму скорость на шине (ошибок в теории станет больше), но при этом увеличу максимальное число неудачных циклов опроса (чтобы устройство не отваливалось совсем вместе со всей шиной) - то сгладит ли это ситуацию?

9

Я бы все ж начал с того что проверил физику.
Для этого, проще всего, циклом опросить. Например.
То есть

Таймаут уменьшить, можно попробовать.
Если на шине только наши устройства - то вполне можно с 500 до 50 мс уменьшить, смело.