Описание порта в имени триггера

[vanomel]

Не могу разобраться как мне сделать желаемое отображение или хотя бы описание триггера, который создается с помощью правил обнаружения.
Есть на мониторинге коммутатор, который отвечает по snmp.
Есть OID'ы для названий портов и для их описания.
Как прочитать эти значения и сделать по ним элементы я разобрался, но как создать правило обнаружения для триггера, чтобы в имени триггера или его описании был дискрипшен порта я не могу понять.
Такое вообще возможно?
Готов материально помочь тому, кто поможет разобаться.

Немного лишних деталей. DSLAM с 48 портами.
Создано правило обнаружения Network interfaces с SNMP OID IF-MIB::ifDescr.
Есть прототипы элементов данных: Operational status of interface {#SNMPVALUE} с ключом ifOperStatus[{#SNMPVALUE}] и Subscriber name port {#SNMPVALUE} с ключом IfSubscr[{#SNMPVALUE}] и SNMP OID .1.3.6.1.4.1.890.1.5.13.6.8.1.1.1.{#SNMPINDEX}.
При применении шаблона к узлу сети получаем данные: порты adsl1 до adsl48, получаем ключи с именами ifOperStatus[adsl1], IfSubscr[adsl1].
В последнем как раз и хранится необходимое описание порта, которое нужно выдавать в название триггера, так как port down adsl22 ничего не говорит тому, кто получает сообщения, а port down house 12 apartment 33 уже абсолютно понятно.
Как правильно указать шаблон имени триггера или его описания?
Обращения к названию ключа выдают просто эти же строки, не преобразуя их в значения.
Какие проблемы могут быть при переименовании описания порта в будущем?

[Jimson]

Вроде или в 2.2 или в 2.4 делали возможность использовать {host:key.func()} в названиях, как минимум для графиков, поищите в документации.
Я реализую подобное другим способом: правило LLD не обязательно должно быть одно из "из коробки", вы можете в качестве правила использовать "внешнюю проверку" - скрипт, который соберет все нужные для правила данные и сформирует JSON. В этом случае вы прототипах сможете пользоваться не только двумя simple макросами {#SNMPINDEX} & {#SNMPVALUE}, а всем чем захотите.
Здесь рассуждения на эту тему и немного примеров.

Что касается проблем, то надо проверить будет ли меняться triggerid при изменении названия, в 2.0 почти наверняка это приведет к пересозданию триггера, а следовательно потеряется история (events) по этому порту. С другой стороны если меняется название, то, наверно, меняется то что туда подключено, а следовательно потеря events по этому порту ни чем не мешает.