Verständnisproblem bei Kommunikationsobjekten und Gruppenadressen

[hansblafoo]

Hallo zusammen,

eigentlich dachte ich, ich hätte die Einschränkungen von Gruppenadressen (z.B. dass ein Sender nur an eine Gruppenadresse senden kann) verstanden, aber nun bin ich auf ein Problem gestoßen, dass vermutlich mit dem Sender-Fall verwandt ist, ich mir aber nicht so recht erklären kann.

Ich habe einen MDT JAL-0810M.02 Jalousieaktor und habe nun das Status-KO eines Kanals mit zwei Gruppenadressen verknüpft:
image.png
Da bin ich davon ausgegangen, dass das ja eigentlich kein Problem sein sollte, denn dieses KO sendet ja nicht selbst sondern kann ausgelesen werden. Wenn ich nun über die zweite verknüpfte GA 22/1/2 eine Leseanfrage an das KO sende, antwortet mir aber die erste GA 22/1/12.

image.png
Warum ist das so? Klar, ich kann das hier lösen, in dem ich die Verknüpfungen so ändere, dass kein KO mehr mit 22/1/2 verbunden wird sondern nur noch mit 22/1/12. Aber ich habe hier einfach ein Verständnisproblem, dass ich gerne beseitigen möchte. Gibt es vielleicht noch einen Workaround, wie ich doch zwei GAs hier verknüpfen könnte?

Danke und viele Grüße

[Beleuchtfix]

Nein.

[DirtyHarry]

Wenn ich nun über die zweite verknüpfte GA 22/1/2 eine Leseanfrage an das KO sende, antwortet mir aber die erste GA 22/1/12.
Warum ist das so?

Ist doch eigentlich ganz logisch: Das KO empfängt die Lese-Anforderung, egal ob die nun von der ersten (sendenden) GA kommt oder von der Zweiten. Dein Gerät macht nun seinen Job und antwortet drauf, kann das selbstverständlich aber nur mit der ersten (sendenden) GA.

Könnte man auch dafür ausnutzen, also eine GA nur zu verknüpfen, um mit einem Lesetelegramm mehrere Antworten zu bekommen. Ist aber mit Vorsicht zu genießen, je mehr KOs daran beteiligt sind, desto mehr Geräte wollen gleichzeitig senden und desto größer ist die Chance, dass Telegramme verloren gehen.


Die Frage ist aber eher, was willst du mit deiner GA 22/1/2 überhaupt erreichen? Ein Prozent-Status über alle Rollladen kann nur in einer ganz bestimmten Situation einen sinnvollen Wert haben: Alle Rollladen haben eine identische Position. Wird nur einer verändert, kann dieser Status nur noch Unsinn anzeigen.


Unabhängig davon: Die Namen deiner GA würden für mich eher bedeuten, dass du Fenster öffnest und schließt, nicht die Rollladen.

[gbglace]

Ein KO sendet immer nur mit einer GA Telegramme aus, welche GA das ist erkennt man daran das diese eine GA ein S als Markierung hat (nicht das S Flag). Man kann sich aussuchen welche GA die ist die gesendet wird.

Das Ganze ist aber nicht dynamisch sondern wird direkt in die Kommunikationseinheit des Gerätes programmiert von der ETS aus.


Zwei GA's an ein Status KO verbinden führt eben dazu das Group Value Read Telegramme mit beiden GA's die Antwortmechanik im KO auslösen, das KO dann aber eben nur mit seiner einen senden Adresse antwortet.


Ein mögliches Szenario könnte sein das Du irgendwo in einem Logikserver so eine Initialisierungs-GA hast und diese an verschiedenste Status-KOs verbindest. Dann ja ist es zwar sparsam mit einem Telegramm möglich sehr viele Geräte zum aktiven Senden Ihres Status zu bringen. Aber Du musst dann auch beachten dass dann zeitgleich all diese Geräte Ihre Antwort senden, das kann am Ende auch nachhinten losgehen, wenn der Bus in dem Moment an Überlastung leidet.
In allen anderen Szenarien ergibt es schlichtweg keinen Sinn da getrennte GAs dran zu verbinden. Zumindest nicht wenn man sich über die Konsequenzen nicht vollends im klaren ist.

ch hätte die Einschränkungen von Gruppenadressen (z.B. dass ein Sender nur an eine Gruppenadresse senden kann) verstanden

verstehe das nicht als Einschränkung. Denn wenn Du auf allen Ebenen der Zuordnung mit n:m Verknüpfungen arbeiten würdest wäre die Arbeit mit der ETS noch viel umständlicher und das gesamte System wäre deutlich schwieriger nachvollziehbar.

denn dieses KO sendet ja nicht selbst sondern kann ausgelesen werden.

Da steckt Dein Missverständnis.

Es gibt nix im KNX was irgendwie gelesen wird. Alles im KNX ist quasi Push.
Das was Du lesen nennst bedeutet das ein KO ein spezielles Telegramm sendet (Group Value Read Request) mit einer GA und alle KO die diese GA dran verbunden haben und das L-Flag gesetzt haben schreiben dann aktiv eine Antwort (Read Respond genauen Typ-Bezeichner musst im Busmonitor anschauen).
Kein Absender weiß wo er hinschauen müsste um etwas zu lesen.
Es sind also zwei ganz spezielle Telegramm typen die da gesendet werden. Auch die Antwort ist ein anderer Telegramm typ als wenn das Rollo KO einen neune Status sendet wenn der Rollo sich bewegt hat.

Das ist auch notwendig weil ansonsten ein A-Flag sinnlos wäre, wodurch man steuern kann ob ein KO sich überhaupt für solche Antworten von Leseanfragen interessiert. Nur das S-Flag reicht da nicht, um auch eine solche Antwort zu verarbeiten am KO.


Wie gesagt wenn einfach die reine Existenz von GAs an einem KO dazu führen würde das alles in allen Arten reagieren würde in der Kommunikation dann würdest da teilweise Endlosschleifen genrieren und den Bus blockieren. Von daher ist das strickte 1:n Prinzip notwendig und sinnvoll und technisch keine Einschränkung.


Und ja Namen der GA sind sehr wichtig um den Überblick zu behalten.

Gibt es vielleicht noch einen Workaround, wie ich doch zwei GAs hier verknüpfen könnte?

Da gibt es keine Workaround einfach machen.
Nur das KO dazu zu bewegen, dass es mit mehr als einer GA sendet geht nicht und wenn es gehen würde wäre es außerhalb der KNX Spezifikation und kein Gerät welches ich in meiner Installation einbauen würde.

[hansblafoo]

Ist doch eigentlich ganz logisch: Das KO empfängt die Lese-Anforderung, egal ob die nun von der ersten (sendenden) GA kommt oder von der Zweiten. Dein Gerät macht nun seinen Job und antwortet drauf, kann das selbstverständlich aber nur mit der ersten (sendenden) GA.

Und mein Gedankengang war, dass es im Protokoll so verankert ist, dass die anfragende GA auch die ist, die die Antwort bekommt.

Die Frage ist aber eher, was willst du mit deiner GA 22/1/2 überhaupt erreichen? Ein Prozent-Status über alle Rollladen kann nur in einer ganz bestimmten Situation einen sinnvollen Wert haben: Alle Rollladen haben eine identische Position. Wird nur einer verändert, kann dieser Status nur noch Unsinn anzeigen.

Richtig beobachtet, dass es so erstmal keinen Sinn ergibt. Mein Gedanke war da mehr aus Faulheit/Wunsch nach Übersichtlichkeit entstanden: ich möchte an verschiedenen Stellen (z.B. einem Taster) einen Überblick über alle Rollladen eines Zimmers haben. Dazu bräuchte ich logischerweise eine Aggregationsfunktion, z.B. min() auf alle Rollladenpositionen. Diese Logik habe ich aber noch nicht umgesetzt, jedoch wollte ich an diesem Taster-KO schon mal die finale GA hinterlegen, sodass ich dann nur noch die Logik integrieren muss, ohne neu verknüpfen zu müssen. Damit aber schon mal halbwegs sinnvolle Werte darin stehen, hatte ich eben den Rollladen des meistgenutzten Fensters hinterlegt und bin so auf diesen Konflikt gestoßen.

Unabhängig davon: Die Namen deiner GA würden für mich eher bedeuten, dass du Fenster öffnest und schließt, nicht die Rollladen.

Sehr guter Hinweis, danke! Ich habe das gleich mal korrigiert.

[gbglace]

Damit aber schon mal halbwegs sinnvolle Werte darin stehen, hatte ich eben den Rollladen des meistgenutzten Fensters hinterlegt

Wenn dann eben eine spezielle GA nur für den zentralen Status-Abruf aber niemals eine spezifische Status-GA.

Die Spezielle zentrale GA kann dann auch jene sein die später das Ergebnis der Logik verteilt. Aber da wirst Dich dann damit abfinden müssen, das wenn Du dann eine solche zentrale Abfrage auslöst x Rolloantriebe = x +1 direkte Antwort erhältst, verteilt auf x+1 GAs und ein paar Sekundenbruchteile später ggf. nochmal x Antworten auf der zentralen GA.
Denn zuerst wird auch die Logik ihren letzten Zustand senden, danach wird sie ggf durch die vielen eingehenden Einzelstatusnachrichten auch x-mal getriggert neu zu rechnen und dann sendet die noch ein paar mal ihren Status.

Mit solchen pauschalen Sammel-Statusanfragen kann man sich so eine Installation auch mal schnell zumüllen.

Aber wenn du das machen magst dann aktiviere am Taster am Status-KO das I-Flag dann sollte das KO von selbst bei jeder Reinitialisierung (Busrest) eine Leseanfrage senden.

[hansblafoo]

Ein KO sendet immer nur mit einer GA Telegramme aus, welche GA das ist erkennt man daran das diese eine GA ein S als Markierung hat (nicht das S Flag). Man kann sich aussuchen welche GA die ist die gesendet wird.

Ahhh, also kann ich mir als Grundregel merken, dass an KOs immer nur eine GA hängt, außer es ist ein KO mit S-Flag, weil hier potentiell mehrere GAs auf das KO schreiben könnten? Ich denke hier gerade z.B. an einen Schaltaktor mit einem Schalten-KO für einen Kanal, der ja potentiell über mehrere GAs geschaltet werden könnte. Oder anders gesprochen: immer wenn ein Gerät über ein KO etwas auf den Bus schickt, darf nur eine GA dranhängen. Erhält das KO dagegen eine Information vom Bus, dürfen da mehrere GAs dranhängen.

Zwei GA's an ein Status KO verbinden führt eben dazu das Group Value Read Telegramme mit beiden GA's die Antwortmechanik im KO auslösen, das KO dann aber eben nur mit seiner einen senden Adresse antwortet.

Und das war mir so, wie oben schon geschrieben, nicht bewusst. Ich dachte immer, dass die GA, die anfragt auch die GA ist, die die Antwort erhält.

Ein mögliches Szenario könnte sein das Du irgendwo in einem Logikserver so eine Initialisierungs-GA hast und diese an verschiedenste Status-KOs verbindest. Dann ja ist es zwar sparsam mit einem Telegramm möglich sehr viele Geräte zum aktiven Senden Ihres Status zu bringen. Aber Du musst dann auch beachten dass dann zeitgleich all diese Geräte Ihre Antwort senden, das kann am Ende auch nachhinten losgehen, wenn der Bus in dem Moment an Überlastung leidet.

Nee, nee, mit sowas fange ich nicht an. ;-)

verstehe das nicht als Einschränkung. Denn wenn Du auf allen Ebenen der Zuordnung mit n:m Verknüpfungen arbeiten würdest wäre die Arbeit mit der ETS noch viel umständlicher und das gesamte System wäre deutlich schwieriger nachvollziehbar.

Naja, es nimmt aus meiner Sicht Flexibilität und von daher finde ich das schon eine Einschränkung. Aber du hast natürlich Recht, diese Designentscheidung zwingt zu einem stringenteren und damit vielleicht besser nachvollziehbarem Verhalten.

Da gibt es keine Workaround einfach machen.
Nur das KO dazu zu bewegen, dass es mit mehr als einer GA sendet geht nicht und wenn es gehen würde wäre es außerhalb der KNX Spezifikation und kein Gerät welches ich in meiner Installation einbauen würde.

Verstanden. Jetzt ist mir da auch vieles klarer geworden, danke auch dir!

Wenn dann eben eine spezielle GA nur für den zentralen Status-Abruf aber niemals eine spezifische Status-GA.

Die Spezielle zentrale GA kann dann auch jene sein die später das Ergebnis der Logik verteilt. Aber da wirst Dich dann damit abfinden müssen, das wenn Du dann eine solche zentrale Abfrage auslöst x Rolloantriebe = x +1 direkte Antwort erhältst, verteilt auf x+1 GAs und ein paar Sekundenbruchteile später ggf. nochmal x Antworten auf der zentralen GA.
Denn zuerst wird auch die Logik ihren letzten Zustand senden, danach wird sie ggf durch die vielen eingehenden Einzelstatusnachrichten auch x-mal getriggert neu zu rechnen und dann sendet die noch ein paar mal ihren Status.

Mit solchen pauschalen Sammel-Statusanfragen kann man sich so eine Installation auch mal schnell zumüllen.

Aber wenn du das machen magst dann aktiviere am Taster am Status-KO das I-Flag dann sollte das KO von selbst bei jeder Reinitialisierung (Busrest) eine Leseanfrage senden.

Der Unterschied zwischen spezieller GA und spezifischer Status-GA ist mir gerade nicht so ganz klar. Die spezielle GA hast du danach ja erklärt und nee, die würde ich nicht umsetzen wollen. ;-) Was meinst du aber mit spezifischer Status-GA?