Добрый день, уважаемые специалисты!
Помогите, пожалуйста, разобраться с накопившимися вопросами по любимому протоколу). Проекты периодически появляются, а опытного советчика нет…
Интересует момент, которому не придал бы значения, если бы на него не обратил внимание заказчик на этапе эксплуатации:
элемент управления (клавиша выключателя или сенсорной панели) настроена на функционирование в режиме «toggle». С неё включается нагрузка (посылается телеграмма "on"). Если затем эта нагрузка выключается с другого устройства или с помощью сцены, в которой эта нагрузка выключена, то при желании включить её снова, следующим нажатием эта кнопка посылает команду "off" и «выключает» уже выключенную нагрузку. Таким образом, чтобы её включить приходится выполнять двойное нажатие. Вопрос: возможно, ли как-то оптимизировать такой алгоритм?

Недавно был удивлён тем, что в офисе в аналогичной ситуации клавиша (работающая как "toggle") каким-то образом распознавала, что нагрузка выключена с другого устройства и при следующем нажатии вместо "off" посылала "on". Это как, может просветите чуток J ?

все зависит от того, куда подвязан объекта статуса нагрузки. Если привязан в туже группу, в которую вы посылаете команды, то тугл будет работать правильно, если же в другие - то будет этот казус ... к сожалению, на сколько я знаю, не излечимый

Флажок Read установить в КО toggle клавиши!

Спасибо за ответ! Кстати, подозревал, что дело в статусах. Объясню. У меня под статус отведена отдельная средняя группа и в ней уже находятся соответствующие групповые адреса (например, Свет гр.1). В этой группе находятся объекты статуса канала от актуатора и объекты от элементов индикации (т.е. например светодиода на выключателе или картинка на панели). При этом объект статуса канала актуатара (универсальный актуатор света/штор Гиры, Беркера или Юнга) можно выбрать пассивным (вроде бы, без флага R) и активным (с этим флагом), так вот, я выбираю именно активный объект статуса. Подскажите, пожалуйста, в чём их принципиальное функциональное отличие?
Дело в том, что если этот активный объект статуса связать с той же группой, которая отвечает за включение канала, то получится зацикленная связка- после первого же включения или выключения с устройства управления в эту же группу приходит команда статуса актуатора, которая опять интерпретируется как команда с устройства управления – следовательно снова отправляется статус и так бесконечно…

зацикливание происходит на бинарниках Гиры точно ...
на сименсах - не происходит, можно в одну группу привязать и свитч и статус ))

Зацикливание может происходить если в группе два или более КО имеют флаг Read!

Не буду оригинальным, если скажу, что, прежде, чем приступать к "периодически появляющимся проектам" надо бы изучить теорию . Лучше всего и правильнее всего - на крусах. Вы об этом не думали? Досадно, что при изучении методом практического тыка появляются всякие knx-поделки, которые потом работают через пень-колоду. Выводы заказчика - "knx - это херня".... " "Абидно, да?..." (с)

По сути.

Набросал небольшой рисуночек - думаю, поможет.

Кнопка в режиме ПЕРЕКЛЮЧЕНИЯ посылает в группу телеграммы 1-0-1-0.... для управления акт-ом через группу 1/1/0.

Третья сверху кнопка (по рисунку) - через группу 1/10/10 - только команду OFF.

Для 1-й кнопки не существует телеграмм из группы 1/10/10, потому она и "не видит" команду от 2-й кнопки и тупо продолжает посылать все ту же 1-0-1-0...

Чтобы все работало правильно, есть несколько вариантов решения. Через объект из акт-ра статуса выхода - одно из решений.

Другое решение, когда нет такого объекта - как на рисунке. Необходимо объекту управления 1-й кнопки дать знать о группе 1/10/10. Для этого - просто добавить (обязательно!!! - после группы 1/1/0) в него группу 1/10/10. И будет вам счастье.

Кнопка 1-я теперь видит и телеграммы по группе 1/10/10 и если прошла телеграмма "0", то кнопка будет в след. раз посылать ОБЯЗАТЕЛЬНО "1" - т.е. противоположную от последней.

Кстати, ситуация абсолютно классическая и не надо ничего изобретать. Как говорил мой друг - *ули тут придумывать, все давно придумано

И еще - по поводу флагов. Всегда однозначно говорят - флаги необходимо менять только при крайнем случае и понимании сути их работы. Рекомендую - есть такая книга, как KNX advanced Course Documentation - там есть целая глава о флагах.

Нажмите для просмотра прикрепленного файла

Ещё раз большое спасибо всем!
Леонид, персональное спасибо за подробный ответ с рисунком! Теперь все стало совсем ясно.
По поводу обучения - курсы закончил около двух лет назад, но сожалению какие-то нюансы имеют свойство забываться Заказчик из-за этого, конечно, страдать не должен! Поэтому и решил проконсультироваться ...

Leonid как всегда молодец!

Хотелось бы дополнительно обсудить вопрос о объекте Status. Поделиться опытом

Дело в том, что не все актуаторы умеют их отправлять только при изменении.
Как бороться понятно, да Leonid рассказал Но хотелось бы все же либо добиться "правильного" статуса, либо знать какие актуаторы имеют недоделанную программу.

Например, Я не смог актуатору Jung, switch FM, 207201 - объяснить что статус следует отправлять только при изменении.

Михаил, тема достаточно актуальная. Думаю, можно подробно к ней вернуться через недельку

Кстати, на удивление, много белых пятен в общих вопросах KNX - кроме вот этого, обсуждаемого в данной ветке, есть также световые сцены - тоже масса непоняток в народе витает

Почему-то не рассматривается он достаточно системно и полно в одном обзоре - в итоге все на уровне экспериментов и догадок.

Может и его вынести в отдельный "разбор полетов" ? Думаю, многим будет полезно

Не совсем понял, в чём проблема, если реле посылает статус всегда, а не только при изменении своего состояния? В нагрузке на шину? Если можно, поясните, пожалуйста.

Проблема в следующем:

Я создаю "главную" адресную группу для канала DO. В нее "привязываю" объект Switch (команду) и Status (состояние).
Объект Switch (команду) Я использую еще в нескольких местах.
Если Status отправляется ТОЛЬКО при изменении - Я имею адресную группу в которой ВСЕГДА текущее состояние канала. Независимо от того как когда и каким образом были произведены какие-либо изменения. Соответственно, если привяжу эту группу к визуализации и/или к индикатору у меня все будет правильно работать.
НО!!! если Status (состояние) будет отправляться всегда - канал "положит" шину общаясь "сам с собой" отвечая себе же на свой же статус!!!

Конечно же, Я могу выделить отдельную адрессную группу для "статуса" и избежать этого эффекта.

Но в целом ряде случаев это не удобно и не хорошо
Как минимум, Я должен буду тогда вместо одной "главной" адресной группы, во многих местах коммуникационный объект отправить в две адресные группы. (А как не крути эти связи считаются, везде есть ограничения)

В результате таких вот мыслей и возникло предложение обсудить этот "академический" вопрос

Проблемы нет никакой.
Канал или объект связи - это элемент шинного устройства, который отвечает за определенную функцию, выполняемую данным устройством, его каналом или клавишей, для канала исполнительного устройства или за включение, или за статус (состояние) устройства, к которому он относится и больше не за что. Заметьте, что это разные объекты у одного канала одного исполнительного устройства.
Значение статуса определяется значением параметра объекта включения для 1 битного соответственно 1 - 1 или 1 - 0 если в параметрах статуса задали инверсию. Для байта (в диммерах это объект уровня яркости) 1 - если значение байта отлично от нуля и 0 если его значение равно нулю.
А вот как вы используете этот статус и какой функцией (групповым адресом) в проекта свяжите данный объект с объектами других устройств, такой результат и получите.
Самое важное понять что объекты устройств - это его виртуальные клеммы, А групповые адреса - это виртуальные провода. А флаги в свойствах объекта связи задают свойства этим проводам в месте их присоединения.
Еще нужно четко понимать, что устройства может отправлять от объекта (канала) телеграмму только с одним групповым адресом, тем, который в ETS видится первым, то есть назначен посылаемым имеет (обозначение "S"), независимо от того, сколько групповых адресов привяжите к данному объекту. Другими словами он будет принимать и выполнять команды по всем групповым адресам, которые Вы к нему прицепили, а посылать будет команду только по выбранному этому одному.
Кстати при желании можете переназначить посылаемый и посмотреть, что будет. Особенно интересно это работает при попытке прочитать значение параметра по любому из групповых адресов из комплекта этого объекта опять же при наличии у него включенным флага "R".

Если честно, всегда был уверен, что для статуса лучше использовать отдельный выделенный адрес, нежели для управления DO/выходом реле. Обычно для этого и коммуникационные объекты предусмотрены разные (по-моему, у Siemensa видел исключение, но нет ETS-ки под рукой, не могу точно сказать). При таком подходе все выключатели с функцией toggle при включении с нескольких мест "подслушивают" только этот адрес статуса (а не все адреса, на которые реагирует соответствующий switch объект) и знают, какую команду следует отправить при нажатии. Возможно я что-то недопонимаю, с визуализацией пока не работал, но мне кажется, что там это должно работать аналогично. Как доберусь до Wago web visu - обязательно проверю -)

Мне кажется главное понять принцип формирования групповых адресов. Они формируются по функциям. Если это прочувствовать, то выкладки Leonida и Melnikova становятся очень понятными. Не работать может потому, что у Вас есть отдельная функция, а Вы или поленились или по незнанию не создали для неё адрес. Пытаетесь групировать разные объекты, а всё равно не работает

Ребята читаю вашу переписку и думаю вы наверное из тех людей которые всегда хотят знать , А КАК ЭТО РАБОТАЕТ по моему если вы собрались заниматся технологией УМНЫ ДОМ то система EIB\ KNX это смесь выключателя с софтом космического корабля, какие адреса, какие функции вы с каждым объектом строите новое колесо для меня главное понятный софт это первое, второе интуитивно понятный интерфес управления , третье это ценовая категория оборудования . Вот и посудите сами EIB/ KNX подходит под эти критерии?, бывает прогинаешся перед заказчиком стелишся а когда назовеш цену заказчик смотрит на тебя как на инопланетянина , так это заметьте мы не устанавлеваем системы EIB/KNX . Итог по моему мнению эвропейцы любят создавть системы которые можно раскрутить как бренд , а мы их ввозим на територию СНГ и еше хотим наварить себе да еше кто сколько хочет . Ребята посмотрите вокруг есть системы лучше . Желаю удучи