ElabNET Technik Forum

Ich stelle bei mir fest, dass ich bei der deutlich überwiegenden Zahl der KOs das L-Flag entferne, um unerwünschte Zufallsergebnisse zu vermeiden. Es wäre m.E. sinnvoll, dass das L-Flag standardmäßig in der ETS-Applikation nicht gesetzt ist.

Sehe ich auch so.
Ist vor allem beim Import mit der ETS Importer App ein Problem.
Einzelne GA die man später hinzufügt sind kein Problem.

Lg
Robert

Aus aktuellem Anlass: ich finde, dass auch das A-Flag defaultmäßig aus sein muss!

Warum? Bei einem Restart des KNX-Daemons antwortet der TWS auf ein Read vom KNX-Bus mit Default 0. Dies kann richtig oder falsch sein (machen aber andere KNX-Geräte teilweise genauso!).

Mit dem A-Flag wird dies aber verschlimmert, da ein Read vom Bus nicht nur einen falschen Wert zum Bus zurückliefert, sondern dieses "nicht initialisierte KNX-Objekt" bei diesem Read diesen falschen Wert 0 in den TWS schickt und damit die richtigen persistenten Werte mit einem falschen Wert überschreibt!!!

Ich habe mir, bevor ich zu schreiben begonnen habe, auch die anderen KNX-Geräte angesehen. Fast alle haben kein einziges A-Flag gesetzt (kein Schaltaktor, kein Heizungsaktor, RTR 2x A-flag von 60 Objekten)!

Daher unbedingt L- und (noch wichtiger) A-Flag standardmäßig deaktivieren.

lg
Robert

Wenn Du nur das L-Flag deaktiviert ist und auf die GA ein Read gemacht wird, dann -davon gehe ich aus- antwortet ein anderer Teilnehmer mit dem richtigen Wert. Durch das A-Flag übernimmt der TWS dann dieses Wert. Das scheint mir dann plausibel und okay. Daher versteh' ich das Problem gerade nicht.

Hallo Foristen,

wir areiten daran das Verhalten des Stacks so zu ändern, dass er bei mit NULL neuinitialisierten Werten keine Antwort mehr gibt, sondern intern (beim Dispatcher) zurück frägt.

Weil der Dispatcher hat alle zuletzt bekannten Werte und hält diese auch über Reboots perstistent (weil er diese beim runterfahren auf den Flash rettet). Wir denken hierbei darüber nach, dass diese Werte auch alle 10 Minuten weggeschrieben werden, um die Werte auch bei einem Stromausfall gerettet zu haben.

Mithin würde der Stack also in Zukunft keine "NULL"-Werte mehr senden. Ich kann jetzt aber noch nicht sagen, wie lange diese Implementierung dauern wird.

lg

Stefan

Die KNX-Flags beginnen mich zu verwirren, die Megathreads zu dem Thema sind kaum verständlich. Ist es eventuell möglich, das in die FAQ einzuarbeiten, dass man dort nachlesen kann, bei welchem Objekttyp man welche Flags braucht und welche ungesetzt bleiben müssen?

Grüße
Marc

Hi Marc,
in der KB gibt es ein paar Hinweise dazu, leider lässt sich das aber nicht pauschal verallgemeinern, was richtig oder besser ist. Am heikelsten ist eigentlich das Lese (L)-Flag.

Best practice m.M.n. das L-Flag zu entfernen, wenn das TWS KO...
...mit dem Statusobjekt eines Aktors verbunden ist
...mit dem Eingang eines externen Logikbausteins verbunden ist
...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 (Temp- Sensor o.ä.)
...überall da, wo ein falscher Wert (0) unerwünschte Nebenwirkungen haben kann, die man nicht tolerieren kann oder möchte

hth und mal schaun, ob wir das in der KB etwas präzisieren können.

Ihr sprecht von den Flags auf den Kommunikationsobjekten des TWS in der ETS, richtig?

Grüße
Marc

Derzeitiger Stand:
app.php/kb/viewarticle?a=122

Gerne ergänze ich noch mehr (Göran hat das oben gerade gut beschrieben).

Lg
Robert

Zugschlus hat geschrieben: ↑Sa Jan 25, 2020 6:09 pm Ihr sprecht von den Flags auf den Kommunikationsobjekten des TWS in der ETS, richtig?

Ja, richtig. Es ging mir um die Flags der Kommunikationsobjekte des TWS.