Остановка работы wb-mqtt-serial

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

У нас тут проблема, на ровном месте перестают приходить данные от wb-mqtt-serial. Первый раз всё встало 20 марта, обнаружили только 25 марта, перезагрузили, проработало чуть больше суток, и опять всё встало.

Сейчас заметил, что дело в том, что wb-mqtt-serial остановлен:

root@wirenboard-ATCGNXJQ:~# service wb-mqtt-serial status
● wb-mqtt-serial.service - MQTT Driver for serial devices
     Loaded: loaded (/lib/systemd/system/wb-mqtt-serial.service; enabled; vendor preset: enabled)
     Active: activating (auto-restart) (Result: signal) since Tue 2025-03-25 15:56:54 UTC; 573ms ago
    Process: 32203 ExecStart=/usr/bin/wb-mqtt-serial (code=killed, signal=SEGV)
   Main PID: 32203 (code=killed, signal=SEGV)
        CPU: 3.845s

Причём будто он пытается перезагрузиться:

root@wirenboard-ATCGNXJQ:~# service wb-mqtt-serial status
● wb-mqtt-serial.service - MQTT Driver for serial devices
     Loaded: loaded (/lib/systemd/system/wb-mqtt-serial.service; enabled; vendor preset: enabled)
     Active: activating (auto-restart) (Result: signal) since Tue 2025-03-25 15:56:54 UTC; 573ms ago
    Process: 32203 ExecStart=/usr/bin/wb-mqtt-serial (code=killed, signal=SEGV)
   Main PID: 32203 (code=killed, signal=SEGV)
        CPU: 3.845s
root@wirenboard-ATCGNXJQ:~# systemctl status wb-mqtt-serial
● wb-mqtt-serial.service - MQTT Driver for serial devices
     Loaded: loaded (/lib/systemd/system/wb-mqtt-serial.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2025-03-25 16:03:48 UTC; 2s ago
   Main PID: 4072 (wb-mqtt-serial)
      Tasks: 2 (limit: 2354)
     Memory: 2.1M
        CPU: 1.953s
     CGroup: /system.slice/wb-mqtt-serial.service
             └─4072 /usr/bin/wb-mqtt-serial

Mar 25 16:03:48 wirenboard-ATCGNXJQ systemd[1]: Started MQTT Driver for serial devices.
Mar 25 16:03:50 wirenboard-ATCGNXJQ wb-mqtt-serial[4072]: INFO: [mqtt] Default host and port detected, checking if UNIX socket exists on /var/run/mosquitto/mosquitto.sock
Mar 25 16:03:50 wirenboard-ATCGNXJQ wb-mqtt-serial[4072]: INFO: [mqtt] UNIX socket exists, using it for connection
root@wirenboard-ATCGNXJQ:~# systemctl status wb-mqtt-serial
● wb-mqtt-serial.service - MQTT Driver for serial devices
     Loaded: loaded (/lib/systemd/system/wb-mqtt-serial.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2025-03-25 16:04:16 UTC; 3s ago
   Main PID: 4315 (wb-mqtt-serial)
      Tasks: 6 (limit: 2354)
     Memory: 2.6M
        CPU: 3.027s
     CGroup: /system.slice/wb-mqtt-serial.service
             └─4315 /usr/bin/wb-mqtt-serial

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

Быстрый гуглинг ничем не помог. В чём может быть причина?

3

UPD: ребут контроллера к жизни устройства не вернул.

Поведение очень странное, как я сейчас заметил, устройства на втором порту RS-485 не переставали работать, а проблемы наблюдаются как минимум у map-3e (первый порт). А возможно, проблемы вообще только у него, так как на шине есть устройства, параметры которых не меняются, и нормально отследить их поведение невозможно.

UPD2: вроде как MOD1 тоже не работает

4

Добрый день.
Обратите внимание:

segmentation violation - интересно.

Рекомендую обновить релиз контроллера до актуального, 2501.

6

Обновил, как показывает график показаний в HA, с момента написания поста, счётчик то работал, то не работал.

image
image569×459 16.7 KB

При этом, как-то странно работают устройства на MOD1, но там шторы, постоянной смены данных нет, поэтому определить исправность и историю не получится.

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

8

Судя по логу, в котором есть

Mar 26 11:41:35 wirenboard-ATCGNXJQ wb-mqtt-serial[23215]: WARNING: [backend] Unable to publish, no connection to broker

Хотя понятно, контроллер как раз перезапускался:

Mar 26 11:41:34 wirenboard-ATCGNXJQ systemd[1]: Stopping Mosquitto MQTT Broker...
Mar 26 11:41:34 wirenboard-ATCGNXJQ mosquitto[20246]: 1742989294: mosquitto version 2.0.20 terminating
Mar 26 11:41:34 wirenboard-ATCGNXJQ systemd[1]: mosquitto.service: Succeeded.
Mar 26 11:41:34 wirenboard-ATCGNXJQ systemd[1]: Stopped Mosquitto MQTT Broker.
Mar 26 11:41:34 wirenboard-ATCGNXJQ systemd[1]: mosquitto.service: Consumed 3.898s CPU time.

И после перезапуска проблем (кроме ошибок на шине) не видно.

9

В общем с этим вайреном происходит какая-то магия.

Проблемы в работе wb-mqtt-serial. Мотор штор с ID 0x098000 на порту MOD-2 в UI постоянно краснеет, и показывает рандомные цифры. Полностью отключили шину от вайрена, а оно продложает себя так вести)))

Вот видео экрана, извиняюсь за такой формат съёмки.

То же самое происходит с устройством ID 14 на порту RS-485-2. Устройство обесточено, а UI делает вид, что оно работает с ошибками.

Вот видео экрана, извиняюсь за такой формат съёмки.

Что с ним происходит? Я даже не понимаю, куда копать.

приложен диагностический архив, доступен только сотрудникам поддержки
(229,8 КБ)
wb-mqtt-serial_20250409T130714.log (347,1 КБ)

11

Для него я вижу в логе:

Apr 09 10:09:04 wirenboard-ATCGNXJQ wb-mqtt-serial[11183]: DEBUG: [port] /dev/ttyMOD2: ReadFrame: ff ff ff ff ff ff 75
Apr 09 10:09:04 wirenboard-ATCGNXJQ wb-mqtt-serial[11183]: DEBUG: [register] new val for <</dev/ttyMOD2 2400 8 N 1> a_ok:0x098000:position: 0>: 0
Apr 09 10:09:04 wirenboard-ATCGNXJQ wb-mqtt-serial[11183]: INFO: [serial device] device </dev/ttyMOD2 2400 8 N 1> a_ok:0x098000 is connected

И многократно:

Apr 09 10:09:05 wirenboard-ATCGNXJQ wb-mqtt-serial[11183]: DEBUG: [port] /dev/ttyMOD2: ReadFrame: db ed ff ff ef ff ff
Apr 09 10:09:05 wirenboard-ATCGNXJQ wb-mqtt-serial[11183]: DEBUG: [serial client] </dev/ttyMOD2 2400 8 N 1>7461128: Wait until 7461128

На неподключенной шине - наличие 0xff как правило говорит от наводках.
Как организован Gnd для нее и, соответственно какой терминатор установлен?

Не вижу в логе примеров удачного чтения с него.
В какой момент времени смотреть? Ну или - отключите опрос всех устройств кром него и загрузите логи.

12

Шину отключили со стороны WB, вынув клеммник. Там могут быть наводки? GND на шинах, подключенных к MOD1 и MOD2 не подключены, так как на моторах A-OK нет GND.

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

Их там и не должно быть, так как устройство обесточено с прошлой недели. Вопрос в том, что в UI он тоже периодически чернеет, будто успешно читается, чего быть не может.

ЗЫ: эта инсталляция несколько месяцев работала весьма стабильно. Началось довольно внезапно.

13

Видел такое, при наличии чего-то (источника помех) мощного неподалеку. Да и сам получал, при поступлении вызова на телефон, лежащий рядом с контроллером.

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

Нет, драйвер по истечению таймаута пытается начать снова чтение.

14

Два файла, в одном включено только одно устройство, во втором только другое. Будто во втором файле даже с отключенным MOD2, в логах он всё равно есть

only_aok.log (277,7 КБ)

only_carel.log (151,6 КБ)

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

16

Сейчас выяснили, что с коллегой произошла путаница, и в MOD2 сидит KNX модуль, а второй модуль RS-485-ISO сидит в MOD3. Сейчас ещё тесты проведём и отпишусь.

Вообще конечно было бы классно иметь защиту от дурака в виде невозможности настраивать в serial конфиге MOD, если он не настроен как RS-485-ISO.