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

[Robert_Mini]

Basierend auf der Diskussion hier (4 Postings abgetrennt): viewtopic.php?f=24&t=1530,
möchte ich mal die Frage einwerfen, ob die Flags am TWS standardmäßig alle gesetzt sein sollen?
Ich hab das noch vor mir, dass ich bei 1000 Objekten die Flags anpassen muss, denn das L-Flag passt eigentlich nie.

1) meist ist der Aktor führend
2) nach einem Speichern der Logik ist derzeit nicht zwingend Logik und Stack am gleichen Stand, so dass ein lesen einen falschen Wert zurück liefert.

Lg
Robert

Lg
Robert

[Dragonos2000]

Nachdem ich da letztens selbst ein bisschen auf die Nase gefallen bin, ist die Frage gut. Ich sehe es auch so, dass das L-Flag meist unpassend sein dürfte. Die anderen könnten m.E. gesetzt sein. Das sollten wir im größeren Kreis mal diskutieren, welche Standardeinstellung sinnvoll wäre (m.M.n. alles gesetzt außer L).

Ich hab bei mir mittlerweile an vielen KO das L-Flag rausgenommen, bin aber noch weit von 1000 entfernt. Wo ich weiß, dass zyklisch ein plausibler Wert gesendet wird, hab ich das aus Faulheit noch nicht gemacht, obwohl es richtig wäre.

Insgesamt ein Thema, das bei den Meisten vermutlich unter dem Radar ist...

[gurumeditation]

Top Thema! Macht einer von euch beiden dazu einen neuen Thread auf? Würde darüber gerne mehr erfahren, nur geht das thematisch hier unter und wird nie mehr gefunden....

[danik]

Ich habe die L-Flags auch überall deaktiviert wo der Aktor führen ist.

[Dragonos2000]

Das führt letztlich auch wieder zu dem Thema Read-Request durch den TWS selbst, was auch schon öfter kontrovers diskutiert wurde. Definitiv sollte dieses Feature -wenn es mal kommt- selektiv und sehr bewußt aktiviert werden. Ich habe einen OpenHAB Docker laufen und nutze auch die OpenHab Visu. Die allein frägt beim Start oder Änderungen schon jede konfiguriete GA ab (wird jede andere Visu auch so machen, um konsistent zu sein). Wenn dann noch eine Dev und Prod parallel läuft, vielleicht noch die ein oder andere Spielwiese und der TWS selbst würde nochmal alles abfragen: Da ist mal mehr als ein paar Minuten "Schicht im Schacht".
Einzig vernünftige Konfiguration ist m.E. eigentlich: TWS kommuniziert mit dem Bus und frägt ab, die Docker-Visus gehen per MQTT o.ä. an den TWS, aber nicht direkt auf den Bus. Aber jetzt schweife ich gerade ein bisschen vom Thema ab.

[StefanW]

Wenn dann noch eine Dev und Prod parallel läuft, vielleicht noch die ein oder andere Spielwiese und der TWS selbst würde nochmal alles abfragen: Da ist mal mehr als ein paar Minuten "Schicht im Schacht".

Ja, genau und dann gehen die Requests womöglich sogar in den Timeout der jeweiligej KNX Stacks und die Antwort kommt gar nicht mehr.

Nicht zu vergessen, wenn solche Abfragen auch Stati beinhalten von DALI-Endgeräten, dann geht das bei 6 Telegrammen pro Sekunde auf dem DALI-Abschnitt noch langsamer.

Einzig vernünftige Konfiguration ist m.E. eigentlich: TWS kommuniziert mit dem Bus und frägt ab, die Docker-Visus gehen per MQTT o.ä. an den TWS, aber nicht direkt auf den Bus.

Jep, so sehen wir das auch, der KNX Bus sollte geschont werden, damit er seine Arbeit tun kann.

lg

Stefan

[gurumeditation]

[

Einzig vernünftige Konfiguration ist m.E. eigentlich: TWS kommuniziert mit dem Bus und frägt ab, die Docker-Visus gehen per MQTT o.ä. an den TWS, aber nicht direkt auf den Bus.

Jep, so sehen wir das auch, der KNX Bus sollte geschont werden, damit er seine Arbeit tun kann.

Was seht ihr denn für hohen KNX-Traffic bei Visus?
So wie ich das verstanden habe, lauschen die wie alle anderen KNX-Teilnehmer am Bus und senden, wenn eine Aktion (z. B. Klick auf Schaltfläche) stattfindet. Ist das nicht das Standardverhalten? Die Stati werden ja in der Regel nicht periodisch abgefragt, sondern kommen von den Aktoren, wo die Telegramme auch eingestellt werden (periodisch, bei Änderung, gar nicht, usw.).

[gbglace]

Was seht ihr denn für hohen KNX-Traffic bei Visus?

Es geht da weniger um den Regelbetrieb als viel mehr das Systemverhalten bei Wiederanlauf entweder vom Server oder vom gesamten Bus.
Beides kann unterschiedlich oft auftreten.

[Dragonos2000]

@gurumeditation : Wie Göran schon geschrieben hat, geht es um das Anlaufverhalten. Wenn da hunderte / tausende GAs mitunter mehrfach und gleichzeitig abgefragt werden, legst Du den KNX lahm.

Das ursprüngliche Thema, nämlich die KO Flags, sind auch hauptsächlich in diesem Zusammenhang in der Diskussion. Nämlich welcher Teilnehmer hat den richtigen Zustand und darf/sollte überhaupt eine Leseanfrage beantworten...

[Matze76]

Ich hab bei mir mittlerweile an vielen KO das L-Flag rausgenommen, bin aber noch weit von 1000 entfernt. Wo ich weiß, dass zyklisch ein plausibler Wert gesendet wird, hab ich das aus Faulheit noch nicht gemacht, obwohl es richtig wäre.

Insgesamt ein Thema, das bei den Meisten vermutlich unter dem Radar ist...

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...