Здравствуйте! Я автоматический помощник техподдержки Wiren Board. Сейчас выходной — я попробую помочь сразу, а в ближайший рабочий день инженеры посмотрят тему и ответят.
Я проанализировал ваш вопрос и постарался найти возможное решение:
Если потребуется дополнителоьное уточнение, приложенную информацию прошу направить нажав ответить на мое крайнее сообщение
По вашим данным:
То есть со стороны контроллера IP‑туннель поднят и сетевые пакеты доходят, проблема, скорее всего, в деталях взаимодействия ETS ↔ knxd.
Ниже — конкретные шаги для проверки.
1. Проверить реакцию knxd на подключение ETS
Сразу после неудачной попытки подключения из ETS выполните:
journalctl -u knxd -n 100 --no-pager
Посмотрите/пришлите, есть ли строки:
- про входящее соединение,
- ошибки вида
no free tunnel, EIBNetIP, T_Connect, и т.п.
Это покажет, видит ли knxd попытку туннеля вообще или молчит.
2. Попробовать явный IP Tunneling в ETS
Раз вы уже указываете вручную IP и порт:
- В ETS:
- Добавьте новый интерфейс → IP Tunneling.
- Укажите:
- IP = адрес WB 6.7
- Порт = 3671
- NAT Mode выключен (если ETS и WB в одной подсети, без NAT/роутеров).
- Сохраните интерфейс и попробуйте:
- Сначала “Test” / “Ping” интерфейса в ETS (если есть).
- Затем “Connect”.
Уточните, пожалуйста:
- Сообщение “The interface not found” появляется сразу при сохранении/тесте,
или
- Интерфейс создаётся, но ошибка только при попытке подключиться?
3. Проверить отсутствие конфликтов адресов KNX
В конфиге у вас:
-e 0.0.1 -E 0.0.2:50
Это означает:
- Индивидуальный адрес IP‑интерфейса: 0.0.1
- Диапазон адресов для туннелей: 0.0.2 – 0.0.51
Типично ETS ожидает группу 1.x.x или 2.x.x; иногда адреса 0.x.x могут вызывать странное поведение.
Ради проверки можно задать более стандартные адреса, например:
sudo nano /etc/knxd.conf
и изменить строку:
KNXD_OPTS=" -e 1.1.1 -E 1.1.2:50 -D -T -R -n WirenboardKNX -S 224.0.23.12:3671 -b ncn5120:/dev/ttyKNX "
Затем:
sudo systemctl restart knxd
sudo systemctl status knxd
После этого:
- В ETS удалите старый интерфейс,
- Добавьте заново IP Tunneling на тот же IP/порт
- Проверьте, исчезнет ли ошибка “The interface not found”.
Если уже есть устройство/проект с этим интерфейсом — проверьте, что в ETS не используются конфликтующие индивидуальные адреса.
4. Временно отключить ограничивающие опции (для теста)
Для диагностики можно упростить параметры knxd, оставив только tunneling и физический интерфейс, например:
KNXD_OPTS=" -e 1.1.1 -E 1.1.2:50 -D -T -n WirenboardKNX -b ncn5120:/dev/ttyKNX "
(без -R -S ..., чтобы не использовать multicast, только туннель).
Далее:
sudo systemctl restart knxd
И снова попробовать подключиться из ETS по IP Tunneling (unicast) на 3671.
5. Проверка с другой утилитой (если есть возможность)
Если у вас есть доступ к дополнительному ПК/Линуксу в той же сети, можно проверить туннели сторонней утилитой, например group.knx / knxtool (из пакета knxd-tools). На самом контроллере можно выполнить:
apt-get update
apt-get install knxd-tools
И попробовать:
knxtool vbusmonitor1 ip:127.0.0.1
Если утилита успешно подключится и начнёт показывать трафик — IP‑туннель работает, а проблема локализуется к ETS/сетевым/адресным нюансам.
6. Что особенно важно прислать дальше
Чтобы инженеры могли прицельно разобраться, пожалуйста, приложите в ответ:
- Вывод:
journalctl -u knxd -n 100 --no-pager
сразу после свежей попытки подключения из ETS.
- Скриншот/описание окна настройки интерфейса в ETS (тип, IP, порт, NAT галка).
- Результат теста с изменёнными адресами
-e и -E (например, 1.1.x).
По текущей картине контроллер и плата WBE2-I-KNX работают штатно: драйвер запущен, порт слушается, UDP‑пакеты приходят. Основные кандидаты сейчас — адреса KNX (0.0.x) и/или тонкости ожиданий ETS по IP‑туннелям в этой связ