Нет приема групповых сообщений в wb-mqtt-knx

Добрый день! Однажды, совсем недавно мы испытывали проблемы с knx…

Тогда всё решилось заменой контроллера. Неделю всё работало хорошо, потом сервис перестал принимать данные от одного мотора штор. Я предположил проблемы с подключением, и проверил физику, всё было на месте. После замены в " [Настройка Групповых объектов KNX] " адресов групп, которые возвращают статусы, статус мотора стал виден и всё заработало как надо - на одном из трех моторов. Статусы от двух других перестали отображаться. Сегодня очистил файл “/etc/wb-mqtt-knx.conf” и написал конфигурацию заново, что бы проверить, не тут ли проблема, теперь статусов нет со всех трех моторов.

Я вижу телеграммы от моторов, если использую контроллер как шлюз в ETS5. Я смог загрузить один из моторов, используя контроллер как шлюз в ETS5. Проблема не та же самая, что в прошлый раз, это что то еще.

Диагностику прилагаю, доступ в облаке есть, реквизиты те же

diag_output_A7ACJFF5_2025-08-09-12.56.19.zip (436,9 КБ)

wb-mqtt-knx.conf (5,4 КБ)
wb-knxd-config.conf (475 байтов)
knxd.conf (216 байтов)

Прилагаю файлы конфигурации knx

если слушать шину через

knxtool vbusmonitor1 local:/var/run/knx

то видны только сообщения от сервиса wb-mqtt-knx. Может быть что то с сервисом knxd? С его конфигурацией?

root@wirenboard-A7ACJFF5:~# knxtool vbusmonitor1 local:/var/run/knx
L_Busmon: BC 11 01 09 18 E1 00 81 22 :L_Data low from 1.1.1 to 1/1/24 hops: 06 T_Data_Group A_GroupValue_Write (small) 01
L_Busmon: BC 11 01 09 09 E1 00 80 32 :L_Data low from 1.1.1 to 1/1/9 hops: 06 T_Data_Group A_GroupValue_Write (small) 00
L_Busmon: BC 11 01 09 09 E1 00 81 33 :L_Data low from 1.1.1 to 1/1/9 hops: 06 T_Data_Group A_GroupValue_Write (small) 01
L_Busmon: BC 11 04 09 08 E1 00 00 B6 :L_Data low from 1.1.4 to 1/1/8 hops: 06 T_Data_Group A_GroupValue_Read
L_Busmon: BC 11 04 09 09 E1 00 00 B7 :L_Data low from 1.1.4 to 1/1/9 hops: 06 T_Data_Group A_GroupValue_Read
L_Busmon: BC 11 04 09 0A E1 00 00 B4 :L_Data low from 1.1.4 to 1/1/10 hops: 06 T_Data_Group A_GroupValue_Read
L_Busmon: BC 11 04 09 0B E1 00 00 B5 :L_Data low from 1.1.4 to 1/1/11 hops: 06 T_Data_Group A_GroupValue_Read
L_Busmon: BC 11 04 09 0C E1 00 00 B2 :L_Data low from 1.1.4 to 1/1/12 hops: 06 T_Data_Group A_GroupValue_Read
L_Busmon: BC 11 04 09 14 E1 00 00 AA :L_Data low from 1.1.4 to 1/1/20 hops: 06 T_Data_Group A_GroupValue_Read
L_Busmon: BC 11 04 09 15 E1 00 00 AB :L_Data low from 1.1.4 to 1/1/21 hops: 06 T_Data_Group A_GroupValue_Read
L_Busmon: BC 11 04 09 17 E1 00 00 A9 :L_Data low from 1.1.4 to 1/1/23 hops: 06 T_Data_Group A_GroupValue_Read
L_Busmon: BC 11 04 09 18 E1 00 00 A6 :L_Data low from 1.1.4 to 1/1/24 hops: 06 T_Data_Group A_GroupValue_Read
L_Busmon: BC 11 04 09 19 E1 00 00 A7 :L_Data low from 1.1.4 to 1/1/25 hops: 06 T_Data_Group A_GroupValue_Read
L_Busmon: BC 11 04 09 1E E1 00 00 A0 :L_Data low from 1.1.4 to 1/1/30 hops: 06 T_Data_Group A_GroupValue_Read
L_Busmon: BC 11 04 09 1F E1 00 00 A1 :L_Data low from 1.1.4 to 1/1/31 hops: 06 T_Data_Group A_GroupValue_Read
L_Busmon: BC 11 04 09 21 E1 00 00 9F :L_Data low from 1.1.4 to 1/1/33 hops: 06 T_Data_Group A_GroupValue_Read
L_Busmon: BC 11 04 09 22 E1 00 00 9C :L_Data low from 1.1.4 to 1/1/34 hops: 06 T_Data_Group A_GroupValue_Read
L_Busmon: BC 11 04 09 23 E1 00 00 9D :L_Data low from 1.1.4 to 1/1/35 hops: 06 T_Data_Group A_GroupValue_Read

Добрый день!

Благодарим за подробное описание проблемы.
Потребуется некоторое время, чтобы проанализировать ситуацию и предложить решение.

Здравствуйте. Благодарю за ожидание.

В мониторинге шины вижу отправку команд и запрос от устройств 1.1.4 и 1.1.1:

Тем временем адрес шлюза 1.1.11 (судя по knxd) и он ничего не шлет в шину.

Какие индивидуальные адреса штор, какой адрес шлюза прописан в ETS?

И что отображается в мониторинге шины в ETS при управлении из контроллера?

Здесь в мониторинге можно видеть индивидуальный адрес отправителя 1.1.1 и 1.1.4, но это сообщения от контроллера. У устройств адреса 1.1.1, 1.1.2 и 1.1.3. Групповые адреса 1/1/24 и 1/1/9 это команды, вызванные с интерфейса “устройства” контроллера.
В ETS прописан тот же индивидуальный адрес шлюза, что и в конфигурации knxd. В мониторинге шины в ETS видно регулярные (30 сек.) статусы моторов, групповые адреса 1/1/11,20,30, видно сообщения от контроллера с командами и видно статусы, которые мотор отправляет в движении.
То, что в knxtool vbusmonitor1 меняется постоянно индивидуальный адрес контроллера меня еще в прошлый раз смутило, но я не придал этому значения

Какие флаги в ETS стоят в групповых объектах, которые вещают в 1/1/11,20,30?

Также, если вы записываете статус в bldStatus, то назначьте время опроса. Иначе wb-mqtt-knx не будет отправлять GroupValueRead в групповой адрес

C,R,T

image

Я могу поделится проектом, он не секретный

да, пришлите, пожалуйста.

diag_output_-44-4.knxproj (1004,5 КБ)
проект ETS5

Здравствуйте. Благодарю за ожидание.

Попробуйте изменить диапазон назначаемых адресов knxd таким образом, чтобы он не пересекался с индивидуальными адресами в TP шине.

Попробую конечно, но надо сказать, что в предыдущей итерации диапазоны были 1.1.1-11 и 0/0/0-50, и при этом были похожие проблемы. Предположительно сделаю сегодня вечером и отпишусь

Здравствуйте. Попробовали?

Здравствуйте. Изменил вчера групповые адреса на 0/0/n, попутно проверил нет ли физических проблем - один мотор не отвечал, но там просто, не ту пару соединили после диагностики. Но изменений в работе knxd/wb-mqtt-knx нет.

Вот результат группового мониторинга, через USB шлюз и через контроллер. Вот отсюда до сюда - это мониторинг шины через контроллер

30 14.08.2025 22:02:25,399 Остановить Запись была остановлена
31 14.08.2025 22:02:42,697 Событие соединения Соединение установлено
32 14.08.2025 22:02:42,697 Запуск Запись запущена, Host=bpavlov, Connection=Новое соединение, Mode=LinkLayer
33 14.08.2025 22:02:54,529 из шины Низкий 1.1.1 Bingshen blind motor v2.0 0/0/34 детская.кн.открзакр 5 GroupValueWrite $01 | Вкл. 1.001 switch
34 14.08.2025 22:03:14,782 из шины Низкий 1.1.1 Bingshen blind motor v2.0 0/0/35 детская.кн.стоп 5 GroupValueWrite $01 | trigger (1) 1.017 trigger
35 14.08.2025 22:03:20,749 из шины Низкий 1.1.1 Bingshen blind motor v2.0 0/0/34 детская.кн.открзакр 5 GroupValueWrite $00 | Выкл. 1.001 switch
36 14.08.2025 22:04:05,311 к шине Низкий 0.0.0 - 0/0/35 детская.кн.стоп 6 GroupValueWrite $01 | trigger (1) 1.017 trigger
37 14.08.2025 22:04:18,878 к шине Низкий 0.0.0 - 0/0/34 детская.кн.открзакр 6 GroupValueWrite $01 | Вкл. 1.001 switch
38 14.08.2025 22:05:00,813 Остановить Запись была остановлена
39 14.08.2025 22:08:44,076 Событие соединения Соединение установлено
40 14.08.2025 22:08:44,076 Запуск Запись запущена, Host=bpavlov, Connection=HDL USB Interface, Mode=LinkLayer

Можно увидеть, что: 1. Контроллер пишет в шину сообщения с адреса 1.1.1, хотя у него адрес 1.1.11, 2. В шине видны лишь сообщения контроллера (они до моторов доходят нормально, моторы крутятся и отвечают).

До и после этого времени мониторинг шины с USB шлюза, можно наблюдать нормальный обмен, видно и сообщения контроллера, и моторов, и ETS.

ets monitoring 3.xml (25,3 КБ)

Вот долгожданное развитие истории: я починил knx. Плохая новость в том, что я не уверен, как я это сделал. В поисках озарения я читал документацию на knxd на гитхабе, и нашел там

Use -t 0xffc -f 9 if you want to watch in excruciating detail what knxd is doing.

Конечно я вставил это в файл конфигурации knxd и пошел смотреть, что теперь попадает в логи. В логах я ничего интересного не нашел, пишет сервис много, но ничего интересного. Потом я решил перезапустить сервис и выполнил

$systemctl restart knxd.socket

И после этого я по пути в логи краем глаза заметил, что в поле “устройства/шлюз knx” появилось что то отличное от i:0/0/0 g:0/0/0! Маршрутизация knx сообщений заработала, все статусы достигают контроллера, жаль я точно не знаю, перезапуск демона или запуск с ключом уровня лога сработал. Ключ лога я убрал, всё продолжает работать.
Я перезагружал контроллер несколько раз, в процессе поиска причин неисправности, но я не помню, что бы я перезапускал отдельно сервис knxd. Возможно дело тут, и нарушен порядок запуска сервисов при старте контроллера. Если knx снова сломается, я это исследую, а пока - дело закрыто

1 лайк