[Gelöst] [V1.5 RC7.1] Defaultwerte für Flags der TWS ETS-Applikation

[Robert_Mini]

Ja, ich finde ein Hinweis, die L-Flags kritisch zu prüfen sollte in einer Doku zur Konfiguration der TWS-KO seinen Platz finden. Ich hatte mir erst auch keine Gedanken dazu gemacht und mich dann auch mal über falsch beantwortete Read-Requests gewundert. Bis mir der Zusammenhang bewusst wurde hat es etwas gedauert...

Wobei das absolut KNX Basiswissen ist (obwohl auch mir passiert).
Gilt ja für alle Objekte aller Aktoren wo eine GA verwendet wird, die auch gelesen wird.

=> ich füge einen Hinweis ein.

Robert

[gurumeditation]

Wobei das absolut KNX Basiswissen ist (obwohl auch mir passiert).
Gilt ja für alle Objekte aller Aktoren wo eine GA verwendet wird, die auch gelesen wird.

Es ist richtig, dass die Flags zu Basiswissen gehören. Dennoch hat sicher der ein oder andere für sein komplettes System bisher nicht ein Flag selbst setzen müssen, da diese von den meisten KNX-Geräten bereits in der Applikation korrekt gesetzt sind. Von daher Basiswissen ja, aber praktische Erfahrung damit kann man nicht unbedingt bei den Heimanwendern voraussetzen.

[Robert_Mini]

So hier ergänzt:
app.php/kb/viewarticle?a=11

Achtung: Bitte auch die Flag Einstellungen der Objekte prüfen. Wird auf eine GA ein Read Request gesendet, antwortet auch der TWS bei gesetztem Flag! Das kann bei einem 1-wire Sensorwert oder Logikausgang durchaus gewünscht sein, bei Statuswerten von Jalousien, Heizungsreglern etc. aber in der Regel nicht!

Ich bezweifle aber ernsthaft ob jemand die Doku bis dorthin liest ...

Lg
Robert

[Tomtheripper]

OK, das heißt, man sollte am besten die L-Flags aller "passiven" TW-Objekte (also diejenigen, die nicht der TW selber beschreibt) deaktivieren?


Thomas

[gbglace]

Jepp

[Dragonos2000]

In den meisten Fällen ja. Außer Du hast bewusst Persistenz aktiviert und möchtest, dass der TWS antwortet. Im Falle eines Restarts (bspw. Stromausfall) gilt dann aber zu bedenken, dass der TWS sehr viel länger braucht zum Booten, als der Rest.

Lange Rede, kurzer Sinn: Man sollte recht genau drüber nachdenken, wo das L-Flag gesetzt ist, wenn mehr als 2 KOs mit einer GA verbunden sind (nicht nur hinsichtlich TWS).

[Robert_Mini]

OK, das heißt, man sollte am besten die L-Flags aller "passiven" TW-Objekte (also diejenigen, die nicht der TW selber beschreibt) deaktivieren?


Thomas

So allgemein ist das nicht:

• grundsätzlich kein L-Flag
• Objekte, wo der TWS Quellsystem ist => L-Flag gesetzt:
  • 1-wire Sensoren
  • GA die aus Logik beschrieben wird und die sonst nirgends lesbar ist
  • GA aus Docker und die sonst nirgends lesbar ist
  • GA aus CometVisu, zb Schaltzustände wie Sommer/Winter, sofern sonst nirgends lesbar

Beispiel: Sollwert Höhe Jalousie aus TWS Logik => kein L-Flag, sollte vom Status des Aktors gelesen werden.
Gibt es kein Statusobjekt am Aktor, kann man das L-Flag am TWS verwenden, es gibt aber keine Garantie, dass der Wert auch angefahren wurde zb Sperre, Windalarm o.ä.

Gerade für die Visu kann das L-Flag aber super sein:
Sperrobjekt einer Logik, Wochentag, etc. was nur am TWS und CV existiert, kann von der CV beim Start gelesen werden. Leere Werte nach Neuladen der CV oder des CV Dockers gibt es seither bei mir nicht mehr (nur eventuell nach reboot des TWS)

Lg
Robert

[Dragonos2000]

Ich hab schon Stunden über Stunden damit verbracht, durch zyklisches Senden und optimieren der Flags ein Konsistentes Kaltstart Verhalten der Anlage oder von Anlagenteilen hinzubekommen. Also dass nichts falsch ein-/aus-/umschaltet, falsche Stati angezeigt oder falsche Werte angesteuert werden. Je nach Kritikalität ist spätestens nach 1 Stunde alles konsistent.

[Robert_Mini]

Ich hab schon Stunden über Stunden damit verbracht, durch zyklisches Senden und optimieren der Flags ein Konsistentes Kaltstart Verhalten der Anlage oder von Anlagenteilen hinzubekommen. Also dass nichts falsch ein-/aus-/umschaltet, falsche Stati angezeigt oder falsche Werte angesteuert werden. Je nach Kritikalität ist spätestens nach 1 Stunde alles konsistent.

Kannst das mal grob beschreiben?
Danke
Robert

[Dragonos2000]

Was genau wie einstellen musst, hängt natürlich von Deinen Komponenten ab. Grundsätzlich hab' ich drauf geachtet, im Normalbetrieb möglich wenig Buslast zu generieren (ist wohl eine Berufskrankheit). Ansonsten kann man ja alles auf zyklisches Senden alle x Sekunden einstellen...

Vorgegangen bin ich folgendermaßen:

1. Raussuchen der GAs, die Anlagenweit unerwünschte Auswirkungen haben können. Prominente Beispiele sind hier hier Tag/Nacht, Anwesenheit und irgendwelche GAs, die Automatiken aktiveren (habe bei mir bspw. eine GA für die Anlagenweite Automatik und für die Beschattungsautomatik). Schauen, welche besonders kritisch sind und schnell konsistent sein müssen (weil sofort etwas passiert, wie Rolladen fahren oder Licht schaltet oder ggf. Beschattung inaktiv wird) und bei welchen ein korrekter Wert einige Zeit in Anspruch nehmen darf und wie lange es dauern darf.
2. Schauen, welche Werte nach dem Kaltstart gewünscht/nötig sind. Prüfen, ob Du ein KO in dieser GA hast, wo Du durch Startparameter und Leseflag oder zyklisches senden etwas erreichen kannst. Teilweise kannst Dir hier schon behelfen, indem Du die Logik invertierst, also 0 für aktiv und 1 für inaktiv/gesperrt und ob die Logik/Komponenten schon laufen, ohne ein Telegramm auf dem KO empfangen zu haben (kommt auf die Komponenten an).
3. Was besonders kritisch ist und einen Wert braucht, wird nach den Kaltstart direkt gesetzt. Und zwar über ein Init Telegramm (habe Komponenten, die das nach einen Neustart senden können) und einen Sequenzer (der dann an die GAs ein definiertes Telegramm schickt).
4. Bei allem was weniger kritisch ist, hab' ich drauf geachtet, dass dies irgendwann im Rahmen zyklischer Telegramme gesetzt wird.

Punkt 2 ist am kompliziertesten, weil Du hier Deine Komponenten kennen musst und eigentlich viele Optionen hast, für die dich entscheiden musst (sofern parametrierbar):

• Es kann ein Default-Wert parametriert werden
• Es wird ein Default-Wert aktiv geschrieben
• Welcher Teilnehmer hat ggf. den korrekten Wert und es reicht zu lesen (wenn das alle Teilnehmer können, hier sind wir wieder beim L-Flag und A-Flag)
• Es passiert einfach gar nichts, bis ein zyklischer Wert empfangen wird, der dann aber korrekt sein musst. Super Beispiel meine Wetterstation: Bei meiner ersten, hat die erstmal immer "Nacht" gesendet, bis die Verzögerungszeit abgelaufen war. Lösung: Ich habe sie über ein Tor auf die Tag/Nacht GA geschickt, das ich beim Kaltstart erst nach einer Verzögerungszeit durchgeschaltet habe. L-Flag war aus, das KO habe ich zyklisch senden lassen. Bei der neuen brauch' ich die Mimik nicht mehr. Da muss ich nur drauf achten, dass beide Verzögerungszeiten gleich sind (sonst wird's auch hier blöd).