[Frage] [V4.8 IP1] Wie bidirektionales KNX-Objekt in der VISU für Übersteuerung nutzen

[jhaeberle]

Hi,

es gibt doch so KNX Objekte, die als Ein- und als Ausgang funktionieren. Mir geht es um solche, die zum Übersteuern von Konfiguration dienen.

Zum Beispiel die Einschalthelligkeit eines PM oder die Soll-Temperatur der Heizungssteuerung.

Wie verwendet man so was in der Visu? Ich hätte erwartet, dass ein Widget, sagen wir ein Pegelsteller, sowohl KNX-Objekt Ausgang auf Quelle als auch KNX-Objekt Eingang auf Ziel zugewiesen bekommt und dass initial der am KNX-Gerät konfigurierte Wert übermittelt wird. Aber egal mit welchem Gerät ich so vorgehe, ist initial der Wert undefiniert. Wozu brauche ich dann die Ausgangsseite des KNX-Objekts?

Macht ihr sowas? Geht Ihr dann mit euren Werten über die Logik-Engine, um die Einstellungen zwischenzuspeichern? Denn ich gehe davon aus, dass bei einem Busreset alles weg ist…

Danke, Gruß
Jochen

[AndererStefan]

Hi,

hast du für die entsprechenden KO das „I“ Flag im TWS gesetzt? Dann sollte der TWS beim Start eine Leseanfrage auf den Bus senden.

VG
Stefan

[jhaeberle]

Du meinst am KO des TWS-Objektes? Nö, das guck ich mir an…

Oder wie ist "im TWS" gemeint?

[gbglace]

Flags werden in der TWS-Applikation in der ETS gesetzt.

Ein TWS-KO welches als Eingang und Ausgang fungieren soll- kann man dann mit der passenden Flag-Kombination versehen.

Aber Achtung das I und gleichzeitig das L ergibt keinen Sinn, der TWS würde sich selbst dann auffordern einen Status zu senden.

Hochlaufzeiten verschiedener Geräte muss man natürlich beachten. Eine Leseanfrage auf dem Bus und andere Geräte sind noch nicht online verpufft diese dann ins Leere. Ist der TWS aber selbst Quelle und Owner einer Information, will ggf gerade den TWs möglichst schnell am KNX aktiv haben, damit er die Anfragen dazu beantworten kann bei Busreset.

Am Ende wird man es wohl nie allen gerecht machen können.

[gbglace]

Wie verwendet man so was in der Visu? Ich hätte erwartet, dass ein Widget, sagen wir ein Pegelsteller, sowohl KNX-Objekt Ausgang auf Quelle als auch KNX-Objekt Eingang auf Ziel zugewiesen bekommt und dass initial der am KNX-Gerät konfigurierte Wert übermittelt wird. Aber egal mit welchem Gerät ich so vorgehe, ist initial der Wert undefiniert. Wozu brauche ich dann die Ausgangsseite des KNX-Objekts?

beziehst Du Dich da jetzt auf den TWS mit seinen Objekten oder andere Geräte.

Nur weil Hersteller da alle Flags aktiv haben bedeutet das nicht das die intern mit der Firmware auch entsprechend Daten zum versenden haben. Das KO selbst wird mit einem L Flag antworten, wird aber womöglich irgendwann nur das senden was es vorher mal angeliefert bekommen hat aber nicht den Wert der in der Firmware gerade gesetzt ist, per z.B. Parameter in der ETS.

Das gerät verhält sich dann immer noch KNX Konform, denn die Kommunikationsfunktion bzgl. der Flags betrifft eben nur die Busseite des KO nicht die Seite zur inneren Firmware. Und da hat so mancher Hersteller auch immer mal wilde Flagkombinationen am Start. Gira hatte da früher die verrücktesten Flags an Ihren KO im Rohzustand. Andere Hersteller machen sich das mit dynamischen KO#s auch einfach und setzen einfach alle Flags aktiv oder inaktiv und je nachdem wie das KO dann über die Parameter mit der Firmware in Kontakt kommt muss man selbst sehen ob die Flags dann passend sind.

In Kurz, nur weil das Ü Flags standardmäßig gesetzt ist beutet es nicht dass das Gerät da auch innere Werte der Firmware zur Verfügung stellt.

[jhaeberle]

Hallo Göran,

ich komme hier leider grad nicht weiter - ich fürchte, ich habe einen Knoten im Hirn.

Drum hier noch mal mein Vorhaben:

1.) Ein Präsenzmelder (OpenKNX) hat Objekte für Einschalt- und Ausschalthelligkeit sowie Nachlaufzeit. Wichtige Werte, um den Präsenzmelder auf die eigenen Vorlieben einzustellen. Zwei der Objekte (Einschalthelligkeit und Nachlaufzeit) des Gerätes sind Ein-/Ausgänge, der Dritte "nur" ein Ausgang.



Ich würde diese Konfig gerne über die Visu des Wolfs konfigurierbar machen. Dazu müsste der Wolf also zunächst den konfigurierten Wert in der ETS-App auslesen und anzeigen. Dann würde ich den Wert in einem Widget anpassen und zurück geben wollen. Im nächsten Schritt muss wohl noch eine Logik dazwischen, die den Wert speichert, sonst ist nach einem Reset/Update/Busreset alles wieder weg.
Aber eins nach dem anderen. Schritt 1 wäre mal, den in der ETS konfigurierten Wert in der Visu zu sehen.
Schritt 2 wäre, eine Änderung des Wertes in der Visu einzustellen und zu verifizieren, dass das auch so angekommen ist

An welchem Objekt setze ich I (Lesen bei Init) statt L (Lesen) und warum?
- an der Gruppe
- am TWS Objekt
- Am Objekt des PM

2.) Die Solltemperatur-Einstellung der Heizung ist auch so. Allerdings sind da die Geräteobjekte wieder ganz anders…

Danke sehr für das Lösen des Knotens…

[AndererStefan]

Hi,

ich bin kein großer Experte was die Flags angeht, aber ich würde auf dem Präsenzmelder für das KO die Flags K, L, S setze. K um überhaupt aktiv zu sein, L damit es auf Leseanfragen antwortet, S damit es auch beschrieben werden kann. Ü würde ich nicht setzen um keine Echo-Schleife zu riskieren (kann das passieren??).

Auf dem TWS würde ich die Flags K, S, A, I setzen. A sorgt dafür, dass der Wert nicht nur aus einem Schreib-Telegramm übernommen wird, sondern auch aus einem Antwort-Telegram auf eine Leseanfrage. L darf nicht aktiv sein. Eiserne Regel: Je GA darf nur ein KO das L-Flag haben.

Eine Logik zum Speichern brauchst du nicht, der PM ist die Quelle der Wahrheit für den Zustand, der TWS fragt den aufgrund des I nach einem Neustart ab.

VG
Stefan

Edit: Typos

[gbglace]

@AndererStefan das wird so nicht funktionieren.

Das wesentliche ist, man muss sich bewusst sein. Status einer Information ist etwas anderes als der Befehl, und dementsprechend muss das immer zwei verschiedene GA ergeben, es müssen aber nicht an beiden beteiligten Geräten zwei KO dafür vorhanden sein.

Wenn der PM die Quelle der Wahrheit ist dann muss der PM die Flags KLSÜ haben aber das KO muss dann zwingend mit zwei GA verbunden werden, eine mit dem eingehenden Befehl setze Wert auf XY und dem Status es wirkt gerade Wert XY. Die Status GA muss als erste GA verbunden werden also die als sendende definiert sein.

Am TWS müssen es dann zwei KO werden, wenn der TWS selbst auch aktiv den Status abfragen soll, denn dann hat er das Bedürfnis zwei GA zu senden und das geht nicht an einem KO. Ein KO ist der Befehl für den jeweiligen Wert und da bekommt das TWS-KO die Flags KÜ weil er soll ja einfach nur das senden was Du in der Visu einstellst. Und das andere KO bekommt die Status-GA und die Flags KSAI, damit er möglichst stabil den Status empfängt bzw. abfragen kann.

Also der PM wird mit dem S Flag in der Lage sein neue Werte entgegen zu nehmen mit der Befehls GA aber auch mit der Status-GA.
Da aber niemand anders als er selbst mit der Status-GA group value write Telegramme sendet ergibt das hier keine Probleme, da ein sendendes KO nicht auf seine eigenen Telegramme horcht.

Ändert sich durch ein empfangenes Telegramm der Wert im PM, dann wird er wohl wegen des Ü flags auch einen neuen Status versenden. das dann aber mit der Status-GA die als erste verbunden ist. Und das ist dann auch ein group value write Telegram aber eben eine andere GA und das KO horcht eben nicht auf eigene Telegramme und selbst wenn, dann passiert hier nix mehr im PM da der Wert eben schon diesen Wert hat und dann kein Bedürfnis besteht per Flag Ü einen geänderten Wert zu senden. Damit keine Telegrammschleife.

Kommt vom TWS eine Leseanfrage gesendet mit der Status-GA dann wird der PM wegen des L Flags auf das group readrequest Telegramm reagieren. Und mit der Status-GA eine Antwort grou read respond senden. Da der PM kein A Flag hat interessiert ihm dieses Telegramm sowieso nicht.
Kommt vom TWs oder sonst wem ein group readrequest Telegramm mit der Befehls GA am PM vorbei, dann wird er auch darauf reagieren, (er hat ja das L Flag gesetzt und auch die Befehls GA verbunden) er wird dann aber auch seine Antwort mit der Status-GA versenden, da er alles was er sendet nur mit der einen sendenden GA sendet.

Das ist soweit der Punkt der im Buslog zu Verwirrung führen kann wenn da einer Leseanfragen mit GA sendet dann aber irgendwie mehrere Antworten zu unterschiedlichen GAs als Antworttelegrammen erscheinen. Das kommt dann von KOs mit L Flag und mehreren horchenden GAs.

Auf der TWS Seite mit zwei expliziten KO ist es dann aber eindeutig.



Es ist also sehr wohl möglich mit Flags und korrekter GA Verbindung mit einem KO Befehl und Status zu verarbeiten, das gilt aber nur beim Owner der Information oder an KOs die passiver Nutzer von Befehl und Status sind, also keinen Bedarf haben selbst aktiv nach einem Status zu fragen. Wenn das notwendig ist, dann muss es da getrennte Ko geben.

Getrennte GA sollte es immer geben.

[jhaeberle]

Danke für eure Inputs. Bevor ich Görans ausführliche Erklärung gelesen habe, hatte ich es mit einer GA und dem I-Flag am KO des Wolf geschafft, ein scheinbar funktionierendes Widget in der Visu zu bauen. Neu war auf jeden Fall, dass der Wert in der Visu initialisiert wurde. Änderungen gehen durch und werden zurück geschrieben.

Ich habe angefangen mit einer Logik zu experimentieren, um den eingestellten Wert da einmal durch zu schieben und ihn dann darin zu speichern. Aber das geht erst Mal völlig schief. Wenn ich den KO mit dem I-Flag von oben als Input an die Logik packe, erhalte ich da wieder keinen Wert, also nicht initialisiert…

Jetzt werde ich es mal mit zwei GA probieren, wie von Göran vorgeschlagen. Mal sehen, wie das da aussieht…

[jhaeberle]

Hey Göran,

ich habe zwei KO am TWS gemacht und zwei GA.

Die Status-Gruppe:


Die Update neuer Wert Gruppe:


Die beiden verwende ich in der Visu in einem Pegelsteller:


Funktioniert! Aber wenn der PM neu startet ist der Wert wieder auf den Wert gesetzt, der in dessen ETS-App eingestellt ist. Jetzt suche ich eine Logik, die den Wert speichert/puffert, auch über Resets hinweg. Aber ich bekomme keinen Wert an den Eingang, wo der Status anliegt. Die Logik liest ds KO nicht aktiv aus. Es schaut auch ähnlich aus, wenn ich den Ausgang des Widgets an einen Logikausgang anfüge. Erst mit Betätigung des Widgets passiert was.

Mhmm…