Wirenboard 8.5.3G/4G4 1.3.6A-4G
WBE2-I-KNX
Zennio Z35 v3 3.8
ETS 5.7.7 / ETS 6.4.1
Подключение к шлюзу и устройству - нормально
Считывание информации с устройства - нормально.
Попытка записи или изменения адреса:
ETS 5.7.7 : Для это операции требуется длина APDU 34, но только 15 доступно благодаря возможностям интерфейса шины
ETS 6.4.1 : Недостаточная длина APDU (ограничено 0 на возможности шинного интерфейса, требуется:34)
Нужна какая то дополнительная настройка шлюза?
Здравствуйте! Я — автоматический помощник техподдержки Wiren Board.
Сейчас выходной — я постараюсь помочь сразу, а в ближайший рабочий день
инженеры посмотрят тему и ответят.
Thinking
Search uploaded documents
Found 5 uploaded document excerpts for ‘WBE2-I-KNX APDU length ETS KNX’
Здравствуйте! Я — автоматический помощник техподдержки Wiren Board.
Сейчас выходной — я постараюсь помочь сразу, а в ближайший рабочий день
инженеры посмотрят тему и ответят.
По вашему описанию это похоже не на настройку шлюза, а на ограничение самого KNX-интерфейса/профиля при записи в ETS: для операции нужна APDU 34 байта, а доступно 15 или 0.
Что проверить:
- Убедиться, что вы подключаетесь к шлюзу именно как к KNX/IP интерфейсу, а не через какой-то другой туннель/режим.
- Проверить, нет ли для этого устройства/прошивки известных ограничений в документации по WBE2-I-KNX; в найденной базе есть страница WBE2-I-KNX: Errata.
- Если ошибка возникает только при загрузке параметров/адреса, а чтение и связь работают, то это часто связано с тем, как ETS оценивает возможности интерфейса шины, а не с базовой связью.
- Нужны детали: как именно настроено подключение в ETS — tunneling или routing, и какая версия прошивки у WBE2-I-KNX.
Если хотите, я дальше посмотрю именно по документации WBE2-I-KNX и попробую найти, есть ли для ETS/KNX/IP известное ограничение по длине APDU.
Примечание: я — ИИ, а не человек; в моих ответах возможны неточности.
Инженеры посмотрят тему в ближайший рабочий день. Если хотите ускорить —
приложите диагностические данные.
Добрый день.
Почему это не работает через knxd:
В исходниках knxd emi_common.cpp явно написано:
// discard long frames, they are not supported yet
// TODO add support for long frames!
Кадры длиннее лимита отбрасываются. Это ограничение существует с 2015 года и до сих пор не реализовано.
То есть knxd может принять и разобрать входящий extended frame, но отправить кадр с APDU > 15 байт — нет.
Для настройки (а нестандартные кадры только для нее применяются, как я понимаю) имеет смысл применить шлюз поддерживающий их.
Если это ограничение knxd, то тогда не очень понятно, как WirenBoard работает с knx устройствами? Или ETS начала использовать APDU long frames только с какой то версии, а до этого использовались по 15 байт? Или может в ETS можно настроить как то длину фрейма?
Работает вот так: Протокол KNX в контроллере Wiren Board — Wiren Board
Физический KNX TP-интерфейс extended frames поддерживает — это стандарт KNX с середины 2000-х. Проблема именно в том, что knxd при передаче кадра от ETS к шине отбрасывает всё, что длиннее 15 байт APDU, вместо того чтобы сформировать L_Data_Extended кадр
Такого способа, к сожалению не знаю.
Я имею в виду, если это так как Вы говорите, то в чем смысл модуля WBE2-I-KNX для контроллера WirenBoard? Только транслировать телеграммы от knx устройств к не-knx устройствам? А настроить knx устройство через ETS с использованием WirenBoard как шлюза в принципе не получится никак?
Зачем тогда статься в wbwiki про быстрый старт с knx модулем с описанием работы в ETS? Что то тут не так …
Это - основная задача.
Те, которые используют “нестандартные” - могут быть нюансы.
Для примера.
Настраиваю соединение
Нажимаю “загрузить”
Получаю загруженное:
Про подобное не знал. И как, удалось?
Сам только нашел!
Дойду до дома, проверю вечерком …
Проверил.
Ни на ETS 5.7.7, ни на ETS 6.4.1 не работает.
Очень ждем, чтобы официальная поддержка WB подтвердила, что что устройства Zennio программировать через WBE2-I-KNX нельзя и необходимо использовать только собственный контроллер KNX-IP от производителя.
Проверил:
#15 bytes
knxtool groupsocketwrite ip:localhost 1/0/1 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f
#20 bytes
knxtool groupsocketwrite ip:localhost 1/0/1 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 0x11 0x12 0x13 0x14
Вижу в шине

Таким образом - работает как и ожидается.
20 байт с префиксом 3C E0 и типом кадра L_DATA_EXTENDED`
Проверил также прием - в шину отправляется.
Таким образом - Extended frames работают.
Но ETS сначала запрашивает capabilities шлюза и, если тот рапортует “max APDU = 15”, отказывается от операции раньше, чем что-то посылает.
Стоит исследовать гипотезу..
Можно проверить что именно knxd рапортует ETS — захватить KNX/IP трафик tcpdump’ом в момент подключения ETS.
Пришлите дамп с началом общения - посмотрю.
До сих пор мне не попадались неподдерживаемые устройства.
Ну и для проверки - попробуйте использовать другой шлюз.
Вот я как раз сегодня утром закупил шлюз от Zennio
Правда обидно, что эксперименты дорого обходятся.
25 тыс. однако…
Все ж снимите дамп пожалуйста, по нему можно будет однозначно сказать.