WARNING: [modbus] failed to read 1 input(s) @ 1 of device modbus:: Serial protocol error: malformed response: invalid crc

1

Добрый день!
Столкнулся с такой проблемой.

image
image1920×1404 1.11 MB

выходят вот такие предупреждения при считывании регистров с устройств и параметры в карточках устройств становятся красными.

image
image1570×1418 314 KB

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

Турков я пробовал взять параметры опроса как в выложенном на github шаблоне
“poll_interval”: 1000,
“frame_timeout_ms”: 3,
“guard_interval_us”: 5000,
но при таких параметрах вообще со временем становятся все регистры опроса красными. сейчас у меня стоят вот такие параметры в шаблоне
“poll_interval”: 1000,
“frame_timeout_ms”: 15,
“guard_interval_us”: 50000,
с такими параметрами какое-то время данные приходят нормально но потом начинаются ошибки.
почему сделал “frame_timeout_ms”: 15, - попробовал включить debug сервиса wb-mqtt-serial и в нем увидел пакет приходит поделенный и вторая часть приходит чуть с запозданием и чтобы избежать такой ошибки как invalid crc решил увеличить frame_timeout_ms до 15 стало значительно лучше но все равно invalid crc приходит причем не только по устройствам других производителей на первом скриншоте видно.
также прилагаю диагностический архив. Уже не знаю что и где еще можно посмотреть. Для ПУ Туркова сделана отдельная шина и используется отдельный порт на конце добавлен терминирующий резистор. UTP используется экранированная и в гофре + рядом нет силовых проводов которые могли бы создавать помехи на шине. Единственное подключены только контакты A B без ГНД но у пульта Турков и нет GND на контактах RS485.
Но так как проблема и предупреждения встречаются не только на устройствах Турков я думаю что проблема в чем то другом.

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

4

Добрый день!

Посмотрел диагностический архив, проблема с Turkov и M1W2 не связаны между собой, т.к. ошибки ivalid crc по Turkov и таймауты не совпадают по времени с другими шинами и подавляющее большинство ошибок в логе именно у Турков.

Проблема наверняка кроется в отсутствии земли у Turkov, в рекомендациях к прокладке шины указано, что при разных блоках питаниях общий провод (GND) обязателен. Можно без него, если у устройства изолированный порт RS-485 (что станет как раз таки решением проблем на шине).

По поводу M1W2 - не нашел в архиве ошибок по этим модулям, скорее всего проблема в самих датчиках, проверьте на корректность их физическое подключение, соответствуют ли рекомендациям?

5

вот за последнее время Туркова нет в списке но зато ошибки по другим устройствам

image
image1998×340 130 KB

6

Спасибо за скриншот. Разберу его построчно — здесь фактически две разные истории.

Адрес 2 (modbus:2) — это по-прежнему Turkov, а не другое устройство. Так что Turkov из списка не ушёл — просто теперь виден только второй пульт. По нему всё остаётся как в прошлом сообщении: причина в отсутствии опорной земли на линии, и решением будет изолированная шина RS-485 (модуль/повторитель WBE2-I-RS485-ISO) либо общий провод, если его удастся организовать. За ~20 часов, что охватывает архив, на этом адресе больше 110 ошибок — это и есть основной источник, всё остальное на его фоне единично.

Адреса 54, 55, 56, 57 — шлюзы ONOKOM («AC 101…103»). За те же ~20 часов в архиве по ним 3–7 ошибок на каждый, и все — только invalid crc, без таймаутов. Важный момент: на этой же шине (порт ttyMOD3) вместе с ONOKOM работают модули WB-MIR и WB-M1W2, и у них за тот же период 0–1 ошибка. Если бы дело было в качестве самой шины, ошибки шли бы и по ним. Раз соседние устройства на той же линии чистые — сама линия исправна, а редкие сбои приходят со стороны шлюза (он периодически отдаёт кадр, который контроллер не может проверить по контрольной сумме). Это доли процента от числа опросов.

Адреса 7 (WB-MAO4), 38 (WB-MSW), 9 (WB-MWAC). По ним в архиве по 1–2 ошибки за ~20 часов. На основной шине так же — по одной ошибке размазано по полутора десяткам устройств, без концентрации на каком-то одном. Это фон, а не деградация конкретного прибора.

Ошибка invalid crc говорит лишь о том, что один ответный кадр пришёл искажённым или неполным. На общей шине RS-485 с несколькими десятками устройств единичные такие события в час — это норма: контроллер просто перечитывает значение на следующем цикле опроса, данные не теряются. Тревожным признаком это становится только если у конкретного устройства ошибки идут потоком/устойчиво.

Если хотите, чтобы мы посмотрели предметно по байтам (например, окончательно подтвердить причину по Turkov или разобрать конкретный шлюз ONOKOM), можно снять отладочный лог:

  1. В веб-интерфейсе: Настройки → Конфигурационные файлы → «Настройка драйвера serial-устройств (wb-mqtt-serial)». Вверху включите параметр отладочных сообщений и сохраните — драйвер перезапустится и начнёт писать в журнал полный обмен по шине (каждый запрос и ответ побайтно).

  2. Оставьте так на некоторое время, чтобы в лог попали ошибки.

  3. Соберите свежий диагностический архив и приложите в тему — в нём будет журнал с побайтовым обменом.

  4. После сбора обязательно выключите отладочные сообщения обратно — с ними журнал быстро растёт и занимает место на диске.

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

Если по каким-то строкам остались вопросы — пишите, разберём.

И еще вопрос, ошибки беспокоили всегда или после каких-то событий появились? Какое-то оборудование работает не так, как ожидается?

7

Вот, кстати. У меня похожая беда с Turkov. При первом включении и подключении работает нормально, а потом понемногу начинает сыпать ошибками: тайм-ауты и crc. Будто накапливается у неё там буфер какой-то и после него начинает сбоить.
Правда, всё это пока ПВУ выключена. Т.е. в сети, но не в рабочем режиме. Три месяца маялся, что с ошибками этими делать и как лечить.
А сейчас приточка два дня работает без остановок - ни одной ошибки в modbus.

И в копилку - при подключении Turkov у меня начинали “сбоить” остальные устройства. Т.е. он как-то умудряется гадить в modbus. Вплоть до того, что я с консоли перепрошивал MSW с modbus device id =22 и этот процесс прервался по ошибке “crc error” от device id = 101 (turkov).

В целом симптомы те же

image
image2248×612 252 KB

8

Я не из команды WB, но поверхностно похоже на Wiren Board 8: Errata ERRWB84009.

9

Причина все та же, отсутствие общей земли с контроллером и остальными модулями. Из-за того что нет единой земли с контроллером и остальными устройствами шины, которые питаются низким напряжением, потенциал относительно шины «плавает» и выходит за рабочий диапазон приёмника — контроллер периодически не получает ответ, отсюда ошибки чтения и таймауты в журнале.

10

Добрый день, прошу уточнить, ошибки беспокоили всегда или после каких-то событий появились? Какое-то оборудование работает не так, как ожидается?

11

Добрый день!
Нет в целом все работает. С M1W2 разобрались, проблема был поврежден датчик температуры при монтаже поэтому он то работал то нет.
Но вот с Turkov проблема остается.
У меня вопрос такой wb-mqtt-serial при опросе регистров если ответы приходят не корректными то он их помечает как нерабочими и я как понимаю реже опрашивает или совсем перестает опрашивать?
Эксперементальным образом я выявил что ошибки переодически приходят от пульта Turkov но потом эти же регистры считываются нормально. А в интерфейсе Wirenboard они все равно продолжают оставаться как не работающие.
Вот мой лог и в нем видно что ошибки приходят достаточно с большим интервалом и я логировал только ответы с ошибками

2026-07-06 05:16:22,407 - ERROR - Slave 2 | holding 1 (count: 4) | FAIL | REQ: 02030001000415FA | RESP: (NO RESPONSE) | Err: Request timed out (no response received)

2026-07-06 05:16:22,749 - WARNING - Poll cycle took longer than poll_interval: 1223.1 ms

2026-07-06 05:27:55,708 - ERROR - Slave 1 | input 276 (count: 2) | FAIL | REQ: 0104011400023033 | RESP: 20418200000000FB84 | Err: Invalid slave ID: expected 1, got 32

2026-07-06 05:27:56,128 - WARNING - Poll cycle took longer than poll_interval: 1234.3 ms

2026-07-06 05:28:48,372 - ERROR - Slave 2 | input 276 (count: 2) | FAIL | REQ: 0204011400023000 | RESP: 20418200000000C884 | Err: Invalid slave ID: expected 2, got 32

2026-07-06 05:28:48,423 - WARNING - Poll cycle took longer than poll_interval: 1284.7 ms

2026-07-06 05:29:49,315 - ERROR - Slave 2 | holding 1 (count: 4) | FAIL | REQ: 02030001000415FA | RESP: A0B0A07CCC | Err: Invalid slave ID: expected 2, got 160

2026-07-06 05:29:49,659 - WARNING - Poll cycle took longer than poll_interval: 1224.1 ms

2026-07-06 05:31:16,492 - ERROR - Slave 1 | input 276 (count: 2) | FAIL | REQ: 0104011400023033 | RESP: 10101020408000FB84 | Err: Invalid slave ID: expected 1, got 16

2026-07-06 05:31:16,914 - WARNING - Poll cycle took longer than poll_interval: 1236.3 ms

2026-07-06 05:44:43,947 - ERROR - Slave 2 | holding 1 (count: 4) | FAIL | REQ: 02030001000415FA | RESP: (NO RESPONSE) | Err: Request timed out (no response received)

2026-07-06 05:44:44,286 - WARNING - Poll cycle took longer than poll_interval: 1221.4 ms

2026-07-06 05:48:32,718 - ERROR - Slave 2 | holding 1 (count: 4) | FAIL | REQ: 02030001000415FA | RESP: 028303F131 | Err: Illegal Data Value (0x03)

2026-07-06 05:48:40,218 - ERROR - Slave 2 | holding 1 (count: 4) | FAIL | REQ: 02030001000415FA | RESP: 346C50BECC | Err: Invalid slave ID: expected 2, got 52

2026-07-06 05:48:40,561 - WARNING - Poll cycle took longer than poll_interval: 1230.8 ms

2026-07-06 06:15:44,752 - ERROR - Slave 2 | holding 1 (count: 4) | FAIL | REQ: 02030001000415FA | RESP: 83028303F131 | Err: Invalid slave ID: expected 2, got 131

2026-07-06 06:15:45,095 - WARNING - Poll cycle took longer than poll_interval: 1221.6 ms

2026-07-06 06:16:32,007 - ERROR - Slave 2 | holding 1 (count: 4) | FAIL | REQ: 02030001000415FA | RESP: 8A31 | Err: Request timed out (incomplete header: 8A31)

2026-07-06 06:16:32,350 - WARNING - Poll cycle took longer than poll_interval: 1245.3 ms

2026-07-06 06:16:44,244 - ERROR - Slave 2 | holding 1 (count: 4) | FAIL | REQ: 02030001000415FA | RESP: 0202030800010016000100009250 | Err: Invalid function code: expected 3 or 131, got 2

2026-07-06 06:16:44,591 - WARNING - Poll cycle took longer than poll_interval: 1236.8 ms

2026-07-06 06:17:52,499 - ERROR - Slave 2 | holding 1 (count: 4) | FAIL | REQ: 02030001000415FA | RESP: (NO RESPONSE) | Err: Request timed out (no response received)

2026-07-06 06:17:52,841 - WARNING - Poll cycle took longer than poll_interval: 1231.3 ms

2026-07-06 06:19:13,848 - ERROR - Slave 1 | input 276 (count: 2) | FAIL | REQ: 0104011400023033 | RESP: 44881020408000FB84 | Err: Invalid slave ID: expected 1, got 68

2026-07-06 06:19:14,429 - WARNING - Poll cycle took longer than poll_interval: 1571.1 ms

2026-07-06 06:19:18,311 - ERROR - Slave 2 | holding 1 (count: 4) | FAIL | REQ: 02030001000415FA | RESP: 0202030800010016000100009250 | Err: Invalid function code: expected 3 or 131, got 2

2026-07-06 06:19:18,656 - WARNING - Poll cycle took longer than poll_interval: 1222.4 ms

2026-07-06 06:34:49,116 - ERROR - Slave 2 | input 262 (count: 2) | FAIL | REQ: 0204010600029005 | RESP: 448810A02040803884 | Err: Invalid slave ID: expected 2, got 68

2026-07-06 06:34:49,248 - WARNING - Poll cycle took longer than poll_interval: 1400.2 ms

2026-07-06 06:35:42,155 - ERROR - Slave 2 | holding 1 (count: 4) | FAIL | REQ: 02030001000415FA | RESP: 68D8A07CCC02030800010016000100009250 | Err: Invalid slave ID: expected 2, got 104

2026-07-06 06:35:42,493 - WARNING - Poll cycle took longer than poll_interval: 1233.3 ms

2026-07-06 06:51:20,559 - ERROR - Slave 2 | holding 1 (count: 4) | FAIL | REQ: 02030001000415FA | RESP: (NO RESPONSE) | Err: Request timed out (no response received)

2026-07-06 06:51:20,902 - WARNING - Poll cycle took longer than poll_interval: 1218.6 ms

12

все верно, драйвер опрашивает реже, но не перестает.

Есть точный механизм: device_timeout_ms и device_max_fail_cycles (по умолчанию 3000 мс и 2 цикла). Если в течение этого времени и более чем N подряд циклов ни один регистр устройства не прочитан успешно — устройство помечается «отсоединённым» и опрашивается в ограниченном режиме: одна попытка за цикл, и если она неудачна, до конца цикла устройство больше не трогается («чтобы тратить меньше времени на отключённые устройства»).

Но первый успешный запрос к устройству будет расценён как переподключение устройства, то есть, восстанавливается с первого удачного чтения.

А по логу, стандартное поведение при отсутствующей общей земли. Как говорил раньше, перенести два Туркова на гальванически изолированный порт, но чтоб на нем не было других девайсов.

13

Понял, спасибо.
Последний лог который я прислал это уже с подключенной общей землей и терминирующим резистором на конце шины.
И да у меня пульты Turkov подключены отдельно от других устройств на порт RS485-2.
Буду пробовать дальше ковырять тайминги и количество регистров за запрос при которых пульт будет отдавать данные стабильно. О результатах напишу может кому-то пригодится.

14

Коллеги, добрый день. Хочу поделиться опытом успешной интеграции вентиляционных установок Turkov с контроллерами Wiren Board. Путем подбора таймингов и размера блоков чтения удалось добиться стабильной работы: устройство корректно отображается в веб-интерфейсе, регистры не «краснеют» и не отваливаются.

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

1. Рабочие параметры опроса (фрагмент шаблона)

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

“poll_interval”: 5000,
“timeout_ms”: 1000,
“frame_timeout_ms”: 50,
“guard_interval_us”: 500000,
“max_read_registers”: 8

Обратите внимание на guard_interval_us: огромная пауза в 0.5 секунды перед каждым запросом дает процессору ПВУ необходимое время на «передышку» и позволяет запрашивать данные блоками до 8 регистров разом без ошибок.

2. Необходимость индивидуального подбора

Из нашей практики: для каждой вентиляционной установки эти параметры, скорее всего, придется подбирать индивидуально. На других наших объектах в шаблонах используются совершенно другие тайминги, и там оборудование безотказно работает уже около года (в данном случаи линия оказалась настолько стабильной, что прощает даже отсутствие общей земли и терминирующих резисторов). Не бойтесь экспериментировать с guard_interval_us и max_read_registers, если установка нестабильна.

3. Топология сети (Изоляция ПВУ)

Рекомендуем заводить оборудование Turkov отдельной шиной на выделенный порт RS-485. Специфика процессора Turkov иногда требует больших задержек и долгих таймаутов. Если повесить ПВУ на общую шину с реле или датчиками, медленный опрос вентиляции неизбежно может привести к “тормозам” всей линии и задержкам в управлении освещением или климатом.

4. Важный нюанс подключения клеммы GND

Нигде в официальной документации этого не написано, но при прямом общении с разработчиками Turkov мы выяснили критически важную деталь: Контакт GND, который на плате пульта визуально выглядит как изолированный, на самом деле не изолирован от интерфейса RS-485 самого пульта.

Поэтому этот контакт можно и нужно подключать к клемме GND на контроллере Wiren Board. Это полностью соответствует базовым рекомендациям по прокладке шин: при использовании разных блоков питания для устройств объединение общего провода (GND) строго обязательно для выравнивания потенциалов.

Надеюсь, этот опыт будет полезен при ваших интеграциях!

15

Дмитрий, спасибо что поделились своим опытом, рад что у вас получилось решить проблему!