I-Flag bei Tastern

[iLion]

Ich versuche gerade das I-Flag zu verstehen, insbesondere für Taster (in meinem Fall Busch-Jaeger Powerline). Folgendes Beispiel:

Aktor Kanal 1 hat für die Schaltadresse K=1, L=0, S=1, Ü=1, A=1 und I=0

Der zugehörige Status für Kanal 1 hat für die Rückmeldeadresse K=1, L=1, S=1, Ü=1, A=1 und I=0

I ist hier bei beiden aus, da ich davon ausgehe, dass sie sich ja nicht selber auslesen. Der Taster hat jetzt einen Schaltausgang für die Gruppenadresse und zwei Statuseingänge für die LED.

Schaltausgang: K=1, L=0, S=1, Ü=1, A=1 und I=?
Status LED 1 und LED 2: K=1, L=0, S=1, Ü=0, A=1 und I=?

Jetzt frage ich mich aber, ob der Kanal 1 des Aktors nicht für Schalten auch ein L=1 gebrauchen kann, und der Schaltausgangs des Taster ein I=1, damit er im Falle eines Stromausfalls beim Autor anfragt, wie der Stand ist und der mit den Rückmeldeadressen antwortet. Oder müssten die Status LED 1 und 2 mit einem I=1 selber anfragen, aber die Fragen ja dann direkt den Status ab.

Was ist hier der richtige Weg, nach einem Stromausfall Taster- und Aktorzustand synchron zu haben?

[Klaus Gütter]

Kann man machen, allerdings produzierst du dann bei Buswiederkehr einiges an Buslast. Un das I-Flag hat nur bei SystemB-Geräten überhaupt eine Auswirkung.

[iLion]

Je mehr ich darüber nachdenke, desto unsicherer werde ich. Auf Youtube habe ich eine Erklärung mit einem Verweis auf eine Grafik hier aus dem Forum gefunden. Leider hat das Video ansonsten leider einen Taster und ein Datum kombiniert. Und diesem Beitrag steht ja auch nochmal, nur ein L für ein Kommunikationsobjekt. Soweit fast klar, denn ich will ja nur den Status der Aktoren kennen und die Taster und die Visualisierung (bei mir openHAB) sollen diesen Status auslesen können. Ich glaube ich hänge an dem Sinn und Unsinn vom L-Flag in Verbindung mit dem I-Flag wenn es einen Rückkanal gibt. Ich hatte testweise bereits einen Aktor so parametrisiert, dass nur der Rückkanal ausgelesen werden kann. Das habe ich dann nicht am Taster, sondern in openHAB gemacht und so zuverlässig den aktuellen Status, auch nach einem Serverneustart, ermitteln können. Dabei konnte ich aber in openHAB auch die spezielle Gruppenadresse des Rückkanals zum Lesen mitgeben, was ja ausgereicht hat in der Visualisierung zu zeigen, ob das Licht an oder aus ist.

Aber, ich bin mir absolut nicht im klaren ob es neben dem Auslesen des Rückkanal noch einen Sinn macht, auch das L-Flag am Schaltkanal zu setzen. Denn an einem Taster arbeite ich ja mit zwei Adressen. Der Ausgang des Tasters sendet die eigentliche Gruppenadresse zum Schalten, die LED reagieren auf die Gruppenadresse aus dem Rückkanal. Wenn jetzt nur die LED ihre Gruppenadresse auslesen, dann weiss der Taster ja nicht den Status des Schaltkanals, richtig? Die LED zeigen zwar den Status des Rückkanal an, aber ob der Taster ein Ein oder Aus senden muss, wäre ja unbekannt.
Ich glaube also, ich müsste auch den Schaltkanal mit dem L-Flag versehen, damit die Taster ebenfalls den echten Status kennen. Und wenn dann ein Taster eine Gruppenadresse verwendet, die ausgelesen werden kann, würde das I-Flag beim Neustart Sinn ergeben. Oder?

[meti]

Wenn jetzt nur die LED ihre Gruppenadresse auslesen, dann weiss der Taster ja nicht den Status des Schaltkanals, richtig? Die LED zeigen zwar den Status des Rückkanal an, aber ob der Taster ein Ein oder Aus senden muss, wäre ja unbekannt.

Verbinde die GA "Status" auch mit dem KO des Tasters (aber nicht als `Sendend`) dann übernimmt der Taster immer den Status des Aktors und sendet gleich richtig. L-Flags sind dann in der ganzen GA "Schalten" nicht notwendig.

Es kann pro KO nur eine GA sendend sein (die wird in ETS als erste aufgelistet). An die GA sendet der Taster dann wenn er gedrückt wird. Die restlichen - nicht sendenden - sind hörende GAs die den Status des KOs aktualisieren.

[mumpf]

Hi,

Ich glaube ich hänge an dem Sinn und Unsinn vom L-Flag in Verbindung mit dem I-Flag wenn es einen Rückkanal gibt.

ich glaube, Du versuchst Sachen zu verbinden, die erstmal für sich alleine stehend verstanden werden sollten .

L-Flag: Erlaubt es, den Wert des KO mit einem ReadRequest zu lesen. Sinn macht das Flag bei allen KO, die einen Ausgang (oder einen Ein-/Ausgang) repräsentieren. Sie Antwort auf ein ReadRequest ist ein ResponseRequest (nicht ein WriteRequest).

Ü-Flag: Erlaubt es dem KO, einen Wert aktiv (also ohne per Request gefragt worden zu sein) auf den Bus zu senden. Die Wertänderung wird als WriteRequest gesendet. Es wird immer nur an die erste GA des KO gesendet (Sendende GA).

S-Flag: Erlaubt es dem KO, WriteRequests zu übernehmen, genauer: Den Wert, den ein WriteRequest liefert, zu übernehmen. Macht bei Eingängen Sinn.
A-Flag: Erlaubt es dem KO, ResponseRequests zu übernehmen (also analog zum S-Flag, aber mit ResponseRequest).

I-Flag: Erlaubt es dem KO, beim Geräteneustart einen ReadRequest abzusetzen. Es wird immer nur ein ReadRequest für die erste GA des KO gesendet.

K-Flag: Erlaubt dem KO überhaupt eine Kommunikation mit dem Bus, ist für die Betrachtung unwesentlich, da es immer gesetzt sein sollte, sonnst geht sowieso nichts.

Was man noch wissen muss: Man kann viele GA an ein KO hängen, aber nur die erste GA ist sendend.

Wenn man das verinnerlicht hat, kann man durch logisches durchspielen der varianten auf die gewünschte Lösung kommen, sofern es eine gibt.

KO A: Schalteingang (Aktor) hat mindestens K,S gesetzt. Bekommt GA x zugeordnet.
KO B: Status (Aktor) ist ein Ausgang, also sind da K,L,Ü gesetzt. Bekommt GA y zugeordnet.
KO C: Schaltausgang (Taster) hat K,Ü gesetzt. Bekommt GA x zugeordnet.
KO D: Statuseingang (Taster) hat K,S gesetzt. Bekommt GA y zugeordnet.
KO E: LED-Eingang (Taster) hat K,S gesetzt. Bekommt GA y zugeordnet.

Das reicht für eine minimale Kommunikation. Statuseingang vom Taster und die Status-LED sind mit dem Statusausgang vom Aktor verbunden und der Schaltausgang mit dem Schalteingang. Funktioniert. Es gibt nur ein KO B, das ein L-Flag hat und dieses KO repräsentiert den Status des Systems. Will man in diesem System mit dem I-Flag arbeiten, dann setzt man es beim KO D oder KO E (nicht an beide). Das würde bei einem Neustart einen ReadRequest auf GA y auslösen, den KO B mit einem ResponseRequest beantworten würde. Derzeit hört aber noch keiner auf den ResponseRequest, der würde verpuffen. Also muss KO D und KO E noch ein A-Flag bekommen. Fertig.

Aber Du hast wahrscheinlich einen Taster, der keinen getrennten Schaltausgang und Statuseingang hat. Das sieht dann so aus
KO F: Schaltausgang/Statuseingang (Taster 2) hat K,S,Ü gesetzt. Bekommt GA x (schaltend) und GA y (hörend) zugeordnet.
KO G: LED-Eingang (Taster 2) hat K,S gesetzt. Bekommt GA y zugeordnet.

Hier hat KO F 2 GA zugeordnet und bekommt den Status des Aktors als hörende Adresse mitgeteilt. Wenn man dem das A-Flag zuordnet, dann wird der Status auch bei einem ResponseRequest übernommen.

Mit dem I-Flag ist es jetzt aber spannend: Wenn man das dem LED-Eingang zuordnet (KO G) ist alles gut. Wenn man es aber dem KO F zuordnet, wird der ReadRequest auf die GA x gesendet, was wiederum zum KO A gehen würde. Jetzt könnte man dem ein L-Flag setzen, aber ob ein Eingang einen ReadRequest korrekt beantwortet, ist nicht sichergestellt (muss man ausprobieren). Anders formuliert: Kombinierte Ein-/Ausgänge und I-Flag können Probleme verursachen.

Letztendlich muss man, wenn man mit Flags rumspielt, genau die Telegrammfolge durchspielen und sich vollkommen klar sein, was man will und was man bewirkt. Und man muss sich über Read-, Write- und Response-Requests klar sein und bei welchen Flags die wirken.

Und nochmal was allgemeines zum I-Flag: Bei einem Neustart der Anlage nach einem Busspannungsausfall kannst Du Dir nicht sicher sein, ob die ReadRequests, die durch das I-Flag gesendet werden, überhaupt vom Ziel beantwortet werden können. Wenn Dein Taster nur 200 ms für den Neustart benötigt, der Aktor aber 1s, dann geht nach 200ms ein ReadRequest los, wird 3 mal wiederholt und kommt trotzdem beim Aktor nicht an, weil die letzte Wiederholung nach 900ms erfolgte.

Ich bevorzuge Geräte, die kontrolliert (in der Applikation einstellbar) ReadRequests verschicken, da kann man auch eine Geräteanlaufzeit einstellen und damit so lange rumspielen, bis die Abhängigkeiten auch bei einem Systemneustart stimmen.

Gruß, Waldemar

[iLion]

Ganz herzlichen Dank für die ausführlichen Antworten. Freue mich sehr über die Hilfe. Da in anderen Beiträgen häufiger gesagt wurde, die Hersteller würden in den Geräteeinstellungen schon logische Parameter vorgeben, habe ich noch mal testweise in ein leeres Projekt den Powerline Steuerbaustein 6997/60 von Busch-Jaeger eingesetzt, den ich mehrfach in meiner Anlage habe. Hier wird dann aber sowohl für Eingänge, als auch für (Rückmelde-)Ausgänge K-SÜA gesetzt. Wenn ich die tolle Anleitung oben aber richtig verstanden habe, würde man ja bei einem Rückmeldeausgang S nicht setzen müssen, denn von extern würde ja niemand den Status manipulieren wollen, das macht doch nur der Aktor selber durch seinen zugehörigen Eingang? Und wenn man das S nicht setzt, dann wäre ja auch ein A nicht notwendig.
Und das gesetzte Ü bei den Eingängen (die beim diesem Baustein aber als Ausgang bezeichnet sind, vermutlich weil hier der Verbraucher angeschlossen ist), wäre doch auch nicht notwendig. Das vermittelt mir etwas dein Eindruck, dass die Voreinstellung nicht unbedingt dem logischen Nutzen entspricht, sondern eher dem "angeschaltet schadet es auch nicht" folgt. Kann man das so sehen?

Meine Taster haben leider keinen reinen Statuseingang und in der Bezeichnung auf keinen Kombinierten Ein-/Ausgang. Das KO heisst z.B. nur "Wippe x - Schalten". Meine KNX Anlage ist in den ersten Bauteilen knapp sicher schon 15 Jahre alt und besteht nur aus Powerline Komponenten. Diese haben meistens nur den Ausgang für die zu sendende GA und je einen Eingang pro LED. Falls statt eines Bus-Ankopplers ein UP-Aktor oder Dimmer verbaut wurde, dessen Ein- (bzw. Ausgänge) zusätzlich.

[mumpf]

Hi,

Das vermittelt mir etwas dein Eindruck, dass die Voreinstellung nicht unbedingt dem logischen Nutzen entspricht, sondern eher dem "angeschaltet schadet es auch nicht" folgt. Kann man das so sehen?

ja, ich denke auch, dass es eher so ist. Ich habe aber persönlich keinerlei Erfahrungen mit KNX-PL. Ich weiß nicht, wie es von 15 Jahren war, aber auch heute finden sich noch Geräte, bei denen die Flags - sagen wir mal - überarbeitungswürdig wären

Das KO heisst z.B. nur "Wippe x - Schalten".

Es gibt noch nicht so lange Taster, die einen eigenen Statuseingang haben, sehr viele Taster, die auch heute noch zu kaufen sind, bekommen den Status als hörende Adresse. Somit wirst Du da mindestens K,L,S,Ü und evtl. A finden. Ob etwas ein Ein-, Ausgang oder beides ist, entscheide ich immer anhand der Flags, nicht an der Bezeichnung.

Aber das mit KNX-PL und 15 Jahren: Ich bin mir nicht sicher, ob es damals schon System B gab (ist lange vor meiner KNX Zeit). Und entsprechend der Aussage von Klaus

Un das I-Flag hat nur bei SystemB-Geräten überhaupt eine Auswirkung.

bringt dir das I-Flag wahrscheinlich nichts.

Gruß, Waldemar