Ошибка с длиной APDU

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.

Что проверить:

  1. Убедиться, что вы подключаетесь к шлюзу именно как к KNX/IP интерфейсу, а не через какой-то другой туннель/режим.
  2. Проверить, нет ли для этого устройства/прошивки известных ограничений в документации по WBE2-I-KNX; в найденной базе есть страница WBE2-I-KNX: Errata.
  3. Если ошибка возникает только при загрузке параметров/адреса, а чтение и связь работают, то это часто связано с тем, как ETS оценивает возможности интерфейса шины, а не с базовой связью.
  4. Нужны детали: как именно настроено подключение в 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? Что то тут не так …

https://support.knx.org/hc/en-us/community/posts/360001574339-Limit-the-MAX-APDU-length-used-for-configuration-in-a-global-ETS-parameter

О! Надо будет проверить …

Это - основная задача.

Те, которые используют “нестандартные” - могут быть нюансы.
Для примера.
Настраиваю соединение

Нажимаю “загрузить”

Получаю загруженное:

Про подобное не знал. И как, удалось?

Сам только нашел!

Дойду до дома, проверю вечерком …

Проверил.

Ни на 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

Вижу в шине
image
Таким образом - работает как и ожидается.
20 байт с префиксом 3C E0 и типом кадра L_DATA_EXTENDED`
Проверил также прием - в шину отправляется.

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

До сих пор мне не попадались неподдерживаемые устройства.
Ну и для проверки - попробуйте использовать другой шлюз.

Вот я как раз сегодня утром закупил шлюз от Zennio

Правда обидно, что эксперименты дорого обходятся.

25 тыс. однако…

Все ж снимите дамп пожалуйста, по нему можно будет однозначно сказать.

Хорошо.