Не совсем понятно.

Описание API на вики дайте, пжст.

Думаю, да.
Но обновлять лучше по групповому адресу, а не по названию. При несовпадении имени задавать вопрос.

Доброе утро!Пример:

Создаю проект 3 этажного дома, либо другого большого с несколькими различными зонами, которые запускаются поэтапно. Проект в Иридие создаю поступательно по мере настройки системы KNX, а именно:

- запускаем KNX на 1 этаже. В результате появляется список групповых адресов, например, 300шт

- создаем проект в iRidium при этом импортируем ETS-проект в сервер (в нашем случае это всегда UMC), все прорисовываем и создаем связи.

- запускаем и отлаживаем проект в iRidium.

Затем, возможно через какое-то время, запускаем KNX на 2 этаже, в результате проект ETS дополняется еще 300-ми адресами, которые также нужно добавить к существующим в iRidium. И вот тут возникает проблема, т.к. просто добавить к KNX Serial драйверу групповые адреса нельзя. Можно только импортировать проект ETS по новой, затем выбрать недостающие адреса (что занимает время), затем перетащить их в существующий драйвер (просто заменить драйвер нельзя, т.к. 1-й этаж уже настроен и работает и придется перепривязывать все элементы). После перетаскивания их названия дополняются пробелом с единицей "_1", т.к. это операция копирования (дублирования), а одинаковых имен быть не должно.

В итоге приходится вручную менять названия 600 переменным (команда + фидбэк).

Поэтому и обращаю ваше внимание на то, что нужен механизм синхронизации, либо возможности выбора копировать или перемещать переменные (раньше было перемещение и все было ок).

Через web удобно смотреть статистику за различные промежутки времени, а в проекте для этого ресурсов нет. Например, изменить временной интервал нельзя, можно только сделать миллион графиков на все случаи жизни, а это не удобно

Вот тут Вы меня подзагрузили. Где узнать про "MQTT брокер"?

Нужно запланировать

Т.е. Вы хотите сказать, что запрос на чтение из шины KNX обрабатывается сервером как событие EVENT_TAG_CHANGE?

Да. Все так и задумано

Все верно. Именно так я его и использую.

Проверю еще раз

Думаю, что я как-то не так объясняю.

3. по запросу от внешней системы отдавать внешней системе

Это означает, что от внешней системы должен поступить некий запрос по IP каналу с указание имени и пароля (произвольные для безопасности) на предоставление данных. Этот запрос должен увидеть UMC сервер и в качестве ответа сформировать и отправить пакет JSON