FREIGEGEBENE HAUPTVERSION V 4.01 verfügbar!
LOGIK! VISU! IFTTT! FIXES!
Infos im Wiki: https://elabnet.atlassian.net/l/cp/TrZ03Nr7

NEU! Ausführliches Video Tutorial zur VISU
Jetzt werden alle Fragen beantwortet. Das Video: https://youtu.be/_El-zaC2Rrs

2.3.2 Übersicht / Empfehlungen zu Flags in der ETS-Applikation

Beschreibung: Einstellungen in der ETS

Kategorie: Grundwissen, Konfiguration, Logiken

Link zu diesem Beitrag: Alles auswählen

[url=https://forum.timberwolf.io/app.php/kb/viewarticle?a=122&sid=f6a077f284eb219e1bf04d5203a08e4d]Knowledge Base - 2.3.2 Übersicht / Empfehlungen zu Flags in der ETS-Applikation[/url]

Einleitung:
Flags gelten für JEDES KNX-Device und haben dort auch die gleichen Auswirkungen.

Der Grund, warum sich viele bisher damit nicht beschäftigt haben ist der, das bei anderen KNX Devices die jeweiligen Objekte eine feste Aufgabe haben und daher der Hersteller schon eine in der Regel ausreichend guten Defaultwert für die FLAGs setzen kann.

Beim Timberwolf Server haben wir die Freiheit, dass es Universalobjekte gibt, die für alles verwendet werden können, aber daher auch die Aufgabenstellung, die FLAGs richtig einzustellen, je nach dem welche Aufgabe das Objekt im KNX System haben wird.

Der TWS KNX-Stack ist zertifiziert und unterstützt alle im KNX Standard vorgesehenen Funktionen eines "System B" KNX Stacks.
Dazu gehört insbesondere das I (Initialisierungs)-Flag, das bei nur wenigen Geräten am Markt vorhanden ist. Damit kann ein aktives Lesen eines Objektwertes nach dem Neustart getriggert werden.

Das K, Ü, S und A Flag sollte standardmäßig gesetzt sein, außer man will bewusst das Senden zum Bus oder Übernehmen eines Objektwertes vom Bus unterdrücken.

Spezielle Aufmerksamkeit erfordern das L und I Flag (Hinweis: das I-Flag ist in der ETS Ansicht standardmäßig ausgeblendet! Zum Einblenden mit der rechten Maustaste auf die Spaltenüberschrift bei den anderen Flags klicken und zusätzlich das I-Flag zur Anzeige auswählen).


Empfehlung zum Setzen des L-Flag:
  • Für 1-wire Sensoren, damit die Werte auch vom Bus lesbar sind und bei denen der Sendezyklus sehr lange ist
  • Für Objekte, die nur in der Visualisierung verwendet werden
    Hinweis: für diese Objekte sind im Zusammenspiel mit Persistenz zusätzliche Schritte erforderlich, damit die Werte nach dem Neustart korrekt gelesen werden!
Empfehlung zum Entfernen des L-Flags:
  • wenn das TWS KO mit dem Statusobjekt eines Aktors verbunden ist (L-flag muss dort gesetzt sein)
  • wenn das TWS KO mit dem Eingang eines externen Logikbausteins verbunden ist
  • wenn das TWS KO mit einem Sensor verbunden ist, der innerhalb weniger Minuten neue Werte sendet bzw. man mit fehlenden Werten bis zum nächsten Sendezyklus des Sensors leben kann (bspw. Temp- Sensor)
  • überall da, wo ein falscher Wert (0) unerwünschte Nebenwirkungen haben kann, die man nicht tolerieren kann oder möchte
Empfehlung zum Setzen des I-Flag:
  • Sparsam einsetzen, da für jedes I-Flag ein Read-Request abgesetzt wird und entsprechende Response-Telegramme auf den Bus gesendet werden, die ihrerseits ggf. wieder weitere GAs ihren Status senden lassen und damit temporär den Bus stark (über)belasten.
  • Empfehlenswert ist das I-Flag für alle Objekte, deren GA nicht (oder sehr selten) zyklisch gesendet werden und als Eingang einer Logik verwendet werden.
  • Für Objekte, deren GA zyklisch gesendet werden muss abgewogen werden, ob ein falscher (oder bei Persistenz veralteter ) Zustand am Eingang einer Logik bis zum Empfang des nächsten Wertes ein Problem ist bzw. die Logik in dieser Zeit überhaupt getriggert werden kann.
Beispiele:
  • Objekt "Urlaub", das auch an einem KNX Info Display angezeigt wird und von dort lesbar ist => I Flag, kein L-Flag am TWS Objekt.
  • Objekt "Helligkeitsgrenze" für Beschattungslogik, das an der Visu angezeigt wird und nirgends lesbar ist L Flag, damit der Wert für die Visu lesbar ist.
    Hinweis: Zusatzlogik empfehlenswert (viewtopic.php?f=65&t=1894), damit auch nach einem Neustart des TWS auch vom KNX-Stack der richtig Wert gelesen werden kann.
  • Objekt "Aktuelle Helligkeit", das von einer Wetterstation alle 30sec gesendet wird (und von dort für die Visu lesbar ist): Kein L- und kein I-Flag, da zB die Beschattungslogik nur von der aktuellen Helligkeit zyklisch getriggert wird und ohnehin innerhalb kürzester Zeit mit dem richtigen Wert belegt wird.

Übersicht und Erklärung zu allen Flags:

Der KNX Standard sieht folgende Flags vor, leider ist die Abkürzung auch von der Sprache abhängig!

K: Kommunikations-Flag (englisch: C: the Communication flag):
Aktiviert die Kommunikation des Objektes (wie ein Hauptschalter), ohnw K-Flag wird jegliche Kommunikation unterdrückt. Bei aktiviertem K-Flag kann die genaue Art der Kommunikation mit den anderen Flags L/Ü/S/A/I verfeinert werden.

L: Lese-Flag (englisch: R: the Read flag):
Das Gerät wird für dieses Objekt auf ein vom Bus stammendes GroupValueRead-Telegramm reagieren, es sendet also ein GroupValueResponse-Telegramm an den Bus. Ein typische Usecase ist der Statuswert eines Schaltaktors oder ein Temperatur-Istwert an einem Raumtemperaturregler.

Ü: Übertragen-Flag (englisch: T: the Transmit flag):
Das Gerät überträgt für dieses Objekt jeden aktualisierten Objektwert, es sendet also ein GroupValueWrite-Telegramm an den Bus. Für ein Taster-Objekt bedeutet das beispielsweise, dass eine Wippe, die dieses Objekt darstellt, betätigt wurde.

S: Schreiben-Flag (englisch: W: the Write flag):
Das Gerät wird für dieses Objekt auf ein GroupValueWrite-Telegramm reagieren, das vom Bus kommt, d. h. es überschreibt den Objektwert. Für einen Schaltaktor bedeutet das beispielsweise, dass ein Relais, das dieses Objekt darstellt, geöffnet oder geschlossen wird.

A: Aktualisieren-Flag (englisch: U: the Update flag):
Das Gerät wird für dieses Objekt auf ein vom Bus stammendes GroupValueResponse-Telegramm reagieren, es überschreibt also den Objektwert. Dies gilt unabhängig davon, wer diesen Wert abgefragt hat.

I: Initialisierungs-Flag (englisch: I: the Initialization flag):
Das Gerät wird für dieses Objekt nach dem Zurücksetzen des Geräts ein GroupValueRead-Telegramm senden. Der Zweck besteht darin, den Objektwert über eine GroupValueResponse abzurufen. Der Grund für das Zurücksetzen des Geräts könnte ein Stromausfall, ein explizites Zurücksetzen des Busses oder eine explizite Anfrage zum Zurücksetzen des Geräts über ein Telegramm sein.
Typischer Anwendungsfall sind Werte/Statusobjekte, die in Logiken als Eingang verwendet werden und das L-Flag am jeweiligen Objekt eines anderen KNX-Geräts gesetzt haben.
Objekte von GAs einer Visualisierung brauchen kein I-Flag, da die Visualisierung beim Start ohnehin aktiv alle Werte liest.