Verständnisfrage: KNX & Kommunikationsobjekte

[sirtpx]

Hallo KNX-Gemeinde,

ich habe mir am Wochenende etwas Grundlagenwissen zum Thema Kommunikationsobjekte (KO) verschafft.

In dem Zusammenhang habe ich folgendes verstanden:

- Bei KNX werden Nutzinformationen mit Hilfe von Kommunikationsobjekten über Gruppenadressen ausgetauscht.
- Jedes KNX-Gerät wie Sensoren oder Aktoren besitzt ein oder mehrere KOs
- KO ist bestimmter Speicherbereich des KNX-Gerätes mit definierten Zugriff - hier gibt es die Flags C, R, W, T und U
- KO werden über Gruppenadressen identifiziert, wo unterschieden wird zwischen sendende und empfangende Gruppenadressen. Pro KO gibt es nur eine sendende Gruppenadresse.

Hier habe ich folgende Fragen:
1.) Wo kann ich denn definieren, ob eine Gruppenadresse eines Kommunikationsobjektes eine sendende oder empfangende Gruppenadresse ist?
2.) Zudem würde mich interessieren, was die oben genannten Flags im Falle einer sendenden bzw. empfangenden Gruppenadresse bewirken. Wie würde es denn aussehen, wenn ein bestimmter Objektwert mit Hilfe des R-Flags (lesen) ausgelesen werden würde? Würde der Requestor den Wert als Response-Telegramm erhalten?

Vielen Dank im Voraus + viele Grüße,
-sirtpx

[trollvottel]

1.) Wo kann ich denn definieren, ob eine Gruppenadresse eines Kommunikationsobjektes eine sendende oder empfangende Gruppenadresse ist?

Das kann man nicht definieren. In eine GA können in der Tat mehrere KOs reinschreiben, ein Homeserver oder sogar die ETS selber direkt wenn man das manuell macht.

Deine letzte Annahme ist also falsch: KOs werden nicht über GAs identifiziert. KOs sind über die physikalische Adresse des Geräts und die interne Nummerierung innerhalb des Geräts systemweit eindeutig. Über GAs werden diese KOs dann miteinander verknüpft, ggfs. auch kreuz- und quer.

2.) Zudem würde mich interessieren, was die oben genannten Flags im Falle einer sendenden bzw. empfangenden Gruppenadresse bewirken. Wie würde es denn aussehen, wenn ein bestimmter Objektwert mit Hilfe des R-Flags (lesen) ausgelesen werden würde? Würde der Requestor den Wert als Response-Telegramm erhalten?

Eine Leseanforderung auf einer GA wird vom entsprechenden KO mit aktiviertem Leseflag auf der selben GA beantwortet. Hier muss man aufpassen, dass nur *ein* KO innerhalb der GA das Leseflag gesetzt hat, sonst gibt's Races. Auch muss man das explizit ausprobieren, ob ein KO tatsächlich den gewünschten Wert liefert, wenn man manuell das Leseflag setzt. Bei meinem MDT Schaltaktor z.B. liefert das Schalt-KO mit manuell gesetztem Leseflag z.B. nicht zuverlässig den Schaltstatus zurück - Dafür gibts ein entsprechendes separates Statusobjekt mit Leseflag schon gesetzt...

[mumpf]

Hi,

ich versuche mal mit meinem Halbwissen zu glänzen

zu 1.) Gar nicht. Stell Dir eine GA als eine "Leitung" zwischen den KO vor. Alle KO, die mit der gleichen GA verbunden sind, sind miteinander verbunden. Wenn einer auf diese GA eine Information sendet, bekommen das alle KO mit! Ob ein KO sendet oder nur zuhört oder beides, bestimmen die Flags. Das Beispiel mit der "Leitung" hinkt, wenn ein KO mit mehreren GA verbunden ist. In einem solchen Falle hört das KO alle Informationen aller GA, wenn das KO aber schreibt, geht die Information nur über die erste GA raus.
zu 2.) Wenn auf eine GA ein Read-Request gesendet wird, werden alle KO, die das R-Flag (in der ETS ist es eigentlich das L-Flag) gesetzt haben, ihren Wert als Response-Telegramm auf dieser GA senden. Dieses Telegramm hören wiederum alle KO, die mit dieser GA verbunden sind. Wenn sie das U-Flag (in der ETS das A-Flag) gesetzt haben, werden sie diesen Wert auch übernehmen. Somit bekommt nicht nur der Requestor eine Antwort, sonder alle!

Noch zur Vollständigkeit: Wenn ein KO das W-Flag (in der ETS das S-Flag) gesetzt hat, reagiert es auf ein Write-Request und übernimmt den Wert. Wenn es das T-Flag (in der ETS das Ü-Flag) gesetzt hat, dann sendet das KO eingene Wertänderungen als Write-Request auf die ERSTE eingetragene GA.

Und nochmal zu den Flags bzw. warum gibt es verschiedene Namen:
Englisch => Deutsch
C = Communication => K = Kommunikation
R = Read => L = Lesen
W = Write => S = Schreiben
T = Transfer => Ü = Übertragen
U = Update => A = Aktualisieren

Ich hoffe, ich habe T und U nicht verwechselt, ich habe nämlich nicht nochmal nachgelesen...

Gruß, Waldemar

[Uwe!]

Das Beispiel mit der "Leitung" hinkt, wenn ein KO mit mehreren GA verbunden ist. In einem solchen Falle hört das KO alle Informationen aller GA, wenn das KO aber schreibt, geht die Information nur über die erste GA raus.

und diese erste GA wird als "sendende GA" bezeichnet und kann selbstverständlich je KO definiert werden.

Ansonsten nehme ich auch immer das Beispiel mit GA=Drähte die verschiedene Ein-und Ausgänge verbinden. Und die KO sind eben die EIn- und Ausgänge eines Gerätes, über die Informationen gesendet und/oder empfangen werden.

[sirtpx]

Hallo zusammen,

vielen Dank für die schnelle Hilfe. Einige Dinge sind mir jetzt klarer geworden. Die impliziete Definition der ersten GA als sendende GA kannte ich bisher nicht.

Was ich mich noch frage, ist Folgendes....

1.) Wie und wo wird der Trigger definiert, um Request zu senden?
2.) Beinhaltet der Request die Flags des Sender? Oder nur einzelne?
3.) Was mit dem Request gemacht wird, wird durch die Konfiguration des empfangenden KO bestimmt, oder?
4.) Was passiert, wenn der Empfänger alle 5 Flags gesetzt hat? Dies führt doch zu einer Endlosschleife? Oder sind bestimmte Kombinationen verboten?
5.) Was genau ist denn der Unterschied zwischen den Flags W, T, U. Das sind doch meiner Meinung nach doch alle schreibende Operationen?

Besten Dank im Voraus + viele Grüße,
-sirtpx

[Uwe!]

1) meinst du mit Request Leseanforderung? Dafür gibt es keinen definierten Trigger. Das kann ein Gerät aufgrund einer bestimmten Situation/Konfiguration von sich aus machen oder eben über die ETS oder eine Logik-Maschine (Homeserver etc.)
2) nein
3) ja, wobei es da ja nur die Möglichkeiten gibt, dass der (oder die) Empfänger antwortet oder nicht
4) nichts besonderes, außer dass er drauf antwortet. Die Antwort ist als solche erkennbar und ist kein normaler Schreib-Befehl.
5) eins vorweg: 1. die Flags sind manachmal ganz schon tricky! 2. Grundsätzlich FInger weg von den Flags! In 9 von 10 Fällen (oder eher in 99 von 100) wird sich eine Änderung der Flags eher negativ als positiv auswirken.
U/A => wenn gesetzt, werden Antwort Telegranmme wie Write Telegramme interprtiert, aktualisieren also das KO, sonst werden Antworttelegramme von anderen Geräten ignoroert
W/S => wenn gesetzt, kann das KO beschrieben, also verändert werden, sonst nicht.
T/Ü => wenn gesetz, kann ein sich interen ändernter Wert des KO, kann er auf den Bus geschickt werden, sonst nicht. (also ein z. B. Tempsesnsor muss das haben, damit er überhaupt was auf den Bus schicken kann.

[sirtpx]

Hallo Uwe,

vielen Dank für die Klarstellungen. So langsam kommt etwas Licht ins Dunkle.

Wann wird denn ein Antwort-Telegramm geschickt? Passiert dies nur, wenn der Empfänger des initialen Telegramms das Lese-Flag gesetzt hat?

Wird denn allgemein zwischen "gewöhnlichem" Request und Antwort-Request unterschieden? Falls nicht würde doch U/A und W/S dasselbe darstellen?!

Beinhaltet das gesendete Telegramm ausschließlich den Objektwert des Speichers des sendenden KO (abgesehen von der Quell- und Zieladresse)?

Herzlichen Dank (!)

Beste Grüße,
-sirtpx

[mumpf]

Hi,

auch wenn das Ganze interessant ist - warum willst Du das wissen? Es ist doch schön, wenn die Kommunikation so funktioniert, dass man 2 KO miteinander verbindet und die dann auch miteinander reden...

Zu Deinen Fragen - Es gibt folgende Telegramme:

• Write: Sendet einen Wert auf den Bus. Alle KO, die das Write-Flag gesetzt haben, empfangen den Wert (ich glaube auch alle, die das Update-Flag haben, da bin ich aber nicht sicher). Alle KO, die ein Transfer-Flag gesetzt haben, senden ein Write, wenn sie ihren Wert ändern.
• Read: Sendet ein Read-Request auf den Bus, ist von Flags unabhängig, muss durch ein Response beantwortet werden. Kann nur von KO beantwortet werden, die das Read-Flag gesetzt haben.
• Response: Wird als Antwort auf ein Read gesendet, nur von KO, die das Read-Flag gesetzt haben. Alle KO, die das Update-Flag gesetzt haben, übernehmen den Wert.

Es gibt natürlich auch noch andere Telegrammarten, aber die kenne ich nicht, da gibt es sicherlich Profis, die sich da besser auskennen. Für's tägliche Leben reicht das.
Trotzdem würde es mich interessieren, warum Du so auf die Flags "abfährst"? Ich habe in den letzten 3 Jahren, in denen ich mit KNX rumspiele, gerade 1 mal was an den Flags ändern müssen...

Gruß, Waldemar

[sirtpx]

Hallo Waldemar,

ich hatte am Wochenende ein Buch in den Händen, das alle möglichen Aspekte von KNX beleuchtet hat. Auch das Thema der Buskommunikation wurde angerissen. Ich wollte es dann doch etwas tiefgründiger verstehen. Daraus sind dann die oben genannten Fragen und Nachfragen entstanden. MIttlerweile habe ich aber ein Wissenslevel erreicht, der mich zufriedenstellt - durch Eure kollektive Hilfe :-)

P.S.: Aus welchem Walldorf kommst du denn?

Viele Grüße,
-sirtpx

[mumpf]

Aus dem bei dir in der Nähe...

[PeterPan]

Mal kurz gurgeln...

http://bfy.tw/1uxv

http://www.knx.org/fileadmin/templat...ags_E1008a.pdf

http://www.kruse-elektro.de/03%20KNX%20Komunikation.pdf (Seite 8)

[sirtpx]

Hallo zusammen,

vielen Dank für die Vielzahl an hilfreichen Infos, Links und persönlichen Gesprächen :-)

Ich habe hier beim Lesen diverser Threads hier im Forum mitbekommen, dass man aus Gründen der Ausfallsicherheit möglichst viel in KNX und ETS direkt realisieren sollte. Wie würde ich denn mit KNX/ETS-Boardmitteln den Fall realisieren, dass eine Leuchte erst dann geschaltet wird, wenn zwei unanhängige PM eine Bewegung gemeldet haben. Geht das überhaupt unter Verwendung von Gruppenadressen? Oder brauche ich dazu zusätzliche Hardware bzw. Software wie FHEM, smarthome.py etc?

Vielen Dank schon mal im Voraus.

Beste Grüße,
-sirtpx

[DirtyHarry]

Hi.

Wenn dein Aktor Logikfunktionen bietet, ist es ganz einfach. Jedem Präsenzmelder eine eigene Gruppenadresse und im Aktor ein UND-Gatter.

[ANDR]

2.) Wenn auf eine GA ein Read-Request gesendet wird, werden alle KO, die das R-Flag (in der ETS ist es eigentlich das L-Flag) gesetzt haben, ihren Wert als Response-Telegramm auf dieser GA senden. Dieses Telegramm hören wiederum alle KO, die mit dieser GA verbunden sind. Wenn sie das U-Flag (in der ETS das A-Flag) gesetzt haben, werden sie diesen Wert auch übernehmen. Somit bekommt nicht nur der Requestor eine Antwort, sonder alle!

Nochmal für Anfängerinnen: A bedeutet, dass die Antwort auf eine L-Anfrage geschrieben wird?

Also ein KO fragt die Gruppe "ja oder nein?", nur das KO mit "L" antwortet, aber alle mit "A" übernommen (i.e. speichern) den Wert?

Aber selbst initiierte Telegramme (also von KO mit "Ü"-Flag) werden von den "A"-Teilnehmern nicht übernommen?


LG
Andrea

[BadSmiley]

Nein, das auf Antworten von lesen Anfragen reagiert wird.

A heißt, Aktor Kanal A ist physisch ein, warum auch immer und ist mit der GA vom Dämmerungsschalter verbunden.

Du liest über den Gruppenmonitor als 3. Den Zustand des Dämmerung Schalter. Also sagt die Wetterstaion -> Gruppenmonitor "gerade ist aus - 0".

Hat dein Aktor das A FLAG am ko gesetzt, übernimmt er den Wert und schaltet aus. Hat er das A FLAG nicht gesetzt, sagt er "mir egal, war nicht für mich".