- √ - mit TS2+ zwei Heizkreise steuern

[Uwe!]

Hallo,

hab gestern ein Probelm entdeckt und bin der Lösun noch nicht so richtig auf der Spur.

Wir haben in einem Raum zwei FBH-Kreise, die über zwei Ventile gesteurt werden. Der Raum hat aber nur einen TS2+. Ich hab also die unter "heizwert" beide GAs von dn zwei Kreisen eingetragen.

Aufgefallen ist mir dann irgendwann, dass einer der beiden Kreise immer auf 100% war. Meine Nachforschung hat ergeben, dass dies am Heizungsaktor lag. Hier hatte ich eine zyklische Überwachung eingestellt und 100% für den "Notbetrieb" wenn keine Stellgröße kommt. Hab für die zwei Kanäle die zyklische Überwachugn erst mal raus genommen. Jetzt geht das Ventil auch wieder zu. Nur geht es jetzt vermutlich nciht mehr auf, weil wohl die Stellwert-Meldung vom TS2+ immer nur an eine GA geht.

Kann das sein? Darf man da keine zwei GAs eintragen? Soll ich die zwei Kreise unter einer GA zusammen fassen? ODer wo liegt mein Denkfehler?

Danke!
Uwe

[MarkusS]

So genannter Anfängerfehler. Ein Sensor sendet immer nur genau eine Gruppenadresse pro Kommunikationsobjekt, weitere eventuell auf ein KO gebundene GAs sind ausschliesslich hörende GAs - das Paradebeispiel dafür sind Zentralfunktionen.

Also beiden Heizkreise über eine GA ansprechen ...

Es gibt einige, sehr wenige, Ausnahmen, also z.B. Taster die pro Tastendruck mehrere Telegramme von mehreren GAs schicken können, der TS2+ gehört da aber nicht dazu.

Wenn Du eine "Intelligenz" wie den HS im Bus hast kannst Du Dir aber problemlos etwas hinbasteln was auf Tastendruck mehrere GAs anspricht ...

Gruss
Markus

[Uwe!]

jetzt wo Du's schreibst.... wie war das mit den Schuppen und den Augen...

Klar, kann nicht funktionieren! Jetzt muss ich mir aber noch mal das Original-Projekt vom Eli laden. Das hatte der doch schon so eingetragen....

EInen HS hab ich leider noch nciht, aber das InfoDisplay Touch könnte das auch ("Multiplexer"). Oder ich mach eben einfach eine GA draus.

Auf die "sendende GA" fall ich immer wieder rein.
Gibt's eigentlich irgendwo eine brauchbare Erkläung der Flags? Mit denen steh ich auch immer wieder mal auf Kriegsfuss. Meistes klappt es dann irgendwann, aber ich möchte es geren verstehen und nicht raten. Die Grafik im Wiki hilft da finde ich auch nicht viel weiter.

Uwe

[MarkusS]

Die Flags:

• K = Kommunikation: Wenn das K-Flag gesetzt ist redet das KO überhaupt mit dem Bus, d.h. ein KO ohne gesetztes K-Flag ist aus Bus-Sicht nicht vorhanden.
• L = Lesen: Das KO antwortet auf Leseanforderungen vom Bus.
• S = Schreiben: Das KO kann vom Bus beschrieben werden.
• Ü = Übertragen: Wertänderungen werden auf den Bus übertragen
• A = Aktualisieren: Wertantworten anderer Busteilnehmer werden als Aktualisierung gesehen, d.h. die überschreiben (aktualisieren) den aktuellen Wert.
• I = Init: Beim Starten wird der Wert vom Bus abgefragt (ist eher ein Exot, ist mir in der ETS noch nicht untergekommen, Option ist meistens ausgegraut)

Gruss
Markus

[Uwe!]

auch wenn die Überschrift nicht mehr passt, muss ich jetzt mal weiter zu den Flags nachhaken:

1. ist das schon mal eine gute Erklärung
2. woher weiß man, welche Flags mit welchem Gerät funktioneren? Oder funktionieren immer alle Flags? Denke nicht. Und in der Doku zu den Geräten hab ich da glaube ich auch noch nie was gesehen.
3. was ist der Unterschied zwischen S und A? In beiden Fällen wird der Wert im Gerät durch den Bus überschrieben!?
4. I: kenn ich auch nur ausgegraut
5. K: wann könnte es Sinn mach das K-Flag NICHT zu setzen?

Gruß
Uwe

[MarkusS]

• Ad 1: Danke.
• Ad 2. AFAIK sind das die Standardflags die alle Geräte unterstützen (mit Ausnahme von dem I-Flag). Um da Konkretes zu sagen bräuchte man Zugriff auf den KNX-Standard und den habe ich nicht - weder den Zugriff noch den Standard, ich bin also auf Sekundärquellen angewiesen. Im Zweifelsfall Applikation in die ETS importieren und nachsehen.
• Ad 3: A reagiert auf WertANTWORTEN anderer Geräte, also die Pakete die auf den Bus gesendet werden wenn man einen Status abfragt (ausliest) während S eben auf Schreibtelegramme reagiert. Mit dem A-Flag kann man sich, wenn man nicht aufpasst, eine ganz tolle Affenschaukel in den Bus bauen, in Kombination mit dem Ü-Flag bzw. der Funktion "Objektwert senden" (gerätespezifisch), das schaukelt sich Telegrammässig so auf dass der Bus innerhalb von 2-3 Sekunden unbenutzbar ist weil da ein paar Schelme Werttelegramme im Kreis rum schicken dass für nix anderes mehr Platz ist.
• Ad 5: Wenn Du willst dass ein bestimmtes KO an einem Gerät welches physikalisch am Bus vorhanden ist sicher nicht an der Buskommunikation teilnimmt. Bedarf hatte ich dafür noch nie, allerdings bin ich auch ein kleiner EIB-Krauter der das als Hobby betreibt, moderne Geräte können über die Produktdatenbank teilweise Funktionsbereiche nach Bedarf zu- bzw. abschalten, üblich ist wohl, nicht benötigte KOs einfach nicht mit GAs zu belegen (wobei es Geräte gibt die das unter bestimmten Umständen übel nehmen).

Diese Flags gehören wohl zum Urgestein des EIB. Irgendjemand hat sich da vor Jahren mal Gedanken drüber gemacht was man möglicherweise eventuell irgendwann vielleicht mal brauchen könnte.

Gruss
Markus

[Uwe!]

mit jede Antwort neue Fragen.....

zu 2: Mein Heizungsaktor (GIRA) hat z. B. ein KO für "Stellgröße" (da erwartet er die Stellgröße genant zu bekommen) und eines für "Status Stellgröße" (da gibt er die aktuelle Stellgröße auf Anforderung aus)
bei "Stellgröße" ist S gesetzt, L nicht. Bei "Status Stellgröße" genau umgekehrt. Ausgegraut sind die Flags bei beiden KOs nicht. Ich könnte also auch bei "Stellgröße" das L setzen. Wozu gibt's dann ein eigenes KO "Status Stellgröße"? Ich dachte immer, das bestimmte KOs sich sozusagen Hardwareseitig nur lesen oder nur beschrieben lassen.

zu 3: bin mir noch nicht sicher, ob ich's verstanden habe. Ich versuch mal ein Beispiel zu machen. Hab einen TS2+ zur Heizungssteuerung und eine Heizungsaktor dazu.

Fall 1:
KO für Stellgröße am TS2+ hat K und Ü
KO für Stellgröße am AKtor hat K und S
wenn der TS2+ die Stellgröße sendet reagiert der Aktor drauf. alles ok.

Fall 2:
setze beim TS2+ zusätzlich das L Flag
wenn ich den Wert auslese schickt der TS2+ den Wert zwar auf den Bus, so dass ich das Ergebnis verarbeiten kann, aber der Aktor reagiert nciht drauf, weil es eine Leseanforderung war???? Woher weiß das der Aktor?

Fall 3:
setzte zusätzlich zu Fall zwei beim Aktor das A Flag
jetzt reagiert der Aktor auch auf den Stellwert, der aufgrund einer Leseanforderung auf den Bus geschcikt wird?

Hab ich das so richtig verstanden? Glaube nicht....

Uwe

[MarkusS]

Ohne dass ich die Applikationsbeschreibung gelesen habe vermute ich dass der Aktor halt eigene Objekte für die Aktion und für die Rückmeldung / Status hat. Ist bei moderneren (~ 2 Jahre) Aktoren gängig, teilweise sind die Rückmelde-/Statusobjekte hart in den Applikationen drin, teilweise kann man die über die Parametrierung aktivieren. Die getrennten Objekte haben Vor- und Nachteile, z.B. Vorteil: man muss sich um die Flags nicht mehr so sehr kümmern, Nachteil: Man braucht mehr Gruppenadressen und hat somit mehr Zuordnungen und mehr Möglichkeiten, Fehler einzubauen.

Dass das eine Antwort auf eine Leseanforderung war weiss der Aktor weil das schlicht und einfach in dem Telegramm drin steht. Nimm Dir die ETS3 und werf mal den Busmonitor an ...

Die Systematik hinter den Flags verwirrt Einsteiger relativ leicht und wer damit "rumspielt" wird über kurz oder lang einige sehr interessante Effekte in seinem Bus sehen, gerade weil man mit falschen Flags den Bus problemlos platt machen kann. Bei mir waren das seinerzeit die ABB-Universaldimmer: Die Bude wurde zur Überraschung der Nachbarschaft zur Lichtorgel und die einzige Möglichkeit, das anzuhalten war ein Reset der Busspannung.

Meine Faustregeln (empirisch ermittelt und wahrscheinlich falsch):

1. Vermeide Rückmelde-/Statusobjekte nach Möglichkeit , d.h. nutze diese nur da wo man wirklich eine aktive Rückmeldung braucht, z.B. bei "sicherheitsrelevanten" Aktionen. Der Bus funktioniert mit grosser Zuverlässigkeit und es macht oft wenig Sinn, einen Schaltbefehl auf den Bus zu senden um sich dann in einem weiteren Telegramm bestätigen zu lassen dass das angekommen ist - spätestens bei Zentralfunktionen ist auf dem Bus richtig was geboten wenn zig Aktoren zurückmelden dass gerade irgendein Licht eingeschaltet wurde.
2. Das L-Flag darf nur 1x pro Gruppenadresse im Bus gesetzt sein. Wenn das L-Flag mehrfach gesetzt ist antworten entsprechend zig Busgeräte auf eine Leseanfrage - absolut sinnfrei.
3. Das Ü-Flag darf nur 1x pro Gruppenadresse im Bus gesetzt sein, Grund siehe L-Flag.
4. Prüfe jede Applikation auf die Flags, gelegentlich ist z.B. das Ü-Flag standardmässig in der Applikation gesetzt, böse böse ...

Gruss
Markus

[Uwe!]

Hallo Markus,

vielen Dank!! Hat mir gut weitergeholfen. Denke, ich hab das nun auch verstanden. Zum verinnerlichen brauch ich noch ne Weile

Uwe

PS: mit dem Busmonitor schau ich mir das noch mal an!

[HartmutB]

1. Das Ü-Flag darf nur 1x pro Gruppenadresse im Bus gesetzt sein, Grund siehe L-Flag.
2. Prüfe jede Applikation auf die Flags, gelegentlich ist z.B. das Ü-Flag standardmässig in der Applikation gesetzt, böse böse ...

Gruss
Markus

Hallo Markus,
ich hadere zwar auch bisweilen mit den Flags, aber ein Ü-Flag z.B. in jedem Schalter einer Lampe (und damit mehrfach pro Gruppenadresse !) macht schon Sinn, sonst kann man sich auch den Schalter sparen, da der dann nicht mehr schaltet ...

Nur 1 mal "L" pro GA: OK
Mehrere "Ü" pro GA: ganz normal und richtig ...

Gruß
Hartmut

[Sebaberlin]

L-Flags

Hallo

bin gerade auf den alten Fred gestoßen und habe meine L Flags gecheckt.

Tatsächlich habe ich bei der Heizungssteuerung ( an der ich schon das ganze Wochenende verbracht habe ) gesehen, dass ich doppelte L Flags bei einer und derselben GA habe.

Frage... ist es wichtig ob das Lese Flag vom Sensor- oder vom Aktorkanal abgefragt wird ?
und wie ist es mit dem A Flag soll der auch nur einmal pro GA aktiviert werden?

Grüße
Sebastian

[Uwe!]

Die erste und wichtigste Regel bei den Flags lautet eigentlich: alles auf Standard lassen!

Es ist nur sehr selten nötig, an den Flags was zu ändern!

L am besten beim Sensor.

A kann theoretisch mehrfach gesetzt werden, aber die Frage ist, was man damit erreichen will.

[Sebaberlin]

Die erste und wichtigste Regel bei den Flags lautet eigentlich: alles auf Standard lassen!

Das ist wahr!!! Davon kann ich ein Lied singen, habe schon die tollsten Dinge mit falscher Flag stellung erlebt.

Danke für die schnelle Antwort.

Ist da auch ein Hintergrund warum vom Sensor?

Persönlich hätte ich vermuttet am Aktor (denn ich schalte einen und möchte den Status auslesen.. halt vom Aktor / andersrum bei Heizung pasiert die Regelung ja im Tastsensor und da macht es wieder sinn am Sensor zu Lesen)

Grüße
Sebastian

PS. das mit A Flag habe ich bis heute nicht gerafft wann es einer Aktualisierung bedarf (gibt es da auch eine Faustregel?)

[Uwe!]

Ist da auch ein Hintergrund warum vom Sensor?

Also erst mal allg.: Auch hier gibt's natürlich Ausnahmen von der Regel!
Sensor deshalb, weil der Sensor erst mal den "original" Wert liefert. Also insbesonder bei Messwerten aller Art. Bei einem reiner Taster/Schalter kann es auch Sinn machen das L-Flag lieber am Aktor zu haben, aber nur, wenn es kein eigenes Rückmeldeobjekt am Aktor gibt, was eigentlich meist vorhanden ist. Das hat dann ja ne eigene GA und da ist das L-Flag natürlich am Aktor! (weil diese GA ja auch im Regelfall mit keinem Sensor verbunden ist, sondern höchstens mit einer Visu)

Das A-Flag kann man meines Erachtes ganz vergessen. Es soll ja unterscheiden, ob ein Antworttelegramm (also die Antwort wenn Du mit Read eine GA abfragst) ignoriert wird (nicht gesetzt) oder so gewertet wird, als wenn das ein normales "write" gewesen wäre.
Aber das unterscheiden viele Geräte eh nicht sauber. Mein Tipp zum A-Flag: Finger weg.

Ansonsten auch mal hier klicken FLAGS