KNX Rückmeldeadressen werden nicht gelesen mit KNX_RequestStatus()

Ich würde gerne sicherstellen das einige Gruppenadressen beim Start von IP Symcon vom Bus gelesen werden. Dies ist insbesondere wichtig, damit manche Logiken nach einem Neustart (z.B. Spannungsausfall) sauber funktionieren.

Zu diesem Zweck gibt es ja ein Skript in der Doku welches beim Start von IP Symcon aufgerufen werden kann um diese Aufgabe zu erledigen. Mit dem Befehl KNX_RequestStatus() werden dort die Lesebefehle ausgeführt.

Bei allen Gruppenadressen die beim Neustart gelesen werden sollen, muss dazu in der jeweiligen Instanzkonfiguration der Gruppenadresse unter Experteneinstellung das Lesen Flag gesetzt werden.

Das ganze Funktioniert soweit auch wunderbar, sofern die Gruppenadresse keine Rückmeldeadresse enthält. Falls eine Rückmeldeadresse enthalten ist, müsste die Leseanfrage eigentlich für diese gestellt werden. Um das ganze zu verstehen hier noch ein Beispiel:

KNX Aktor
Kanal A Schalten (1/1/9)
Kanal A Rückmeldung (1/2/9)

Über 1/1/9 wird der Aktor also EIN/AUS geschaltet und über 1/2/9 sendet er den aktuellen Zustand zurück.

aktuelles Verhalten
Instanz (1/1/9)
→ lesen Flag aktiv
→ Rückmeldeadresse (1/2/9)

Wenn die Adressen mit dem Skript in der Doku gelesen werden wird nur die 1/1/9 vom Bus gelesen. Das kann man im Busmonitor ja schön beobachten.

Verhalten das ich erwarten würde
Instanz (1/1/9)
→ lesen Flag aktiv
→ Rückmeldeadresse (1/2/9)

Wenn eine Instanz eine Rückmeldeadresse enthält, sollte eine Leseanfrage für die Rückmeldeadresse 1/2/9 gestellt werden. Dann würde der Status korrekt zurückgemeldet werden.

Nun stellt sich mir die Frage ob das so sein soll oder ein Bug ist? Mit dem aktuellen Verhalten ist es mir zumindest nicht möglich den Status des Aktors abzufragen.

Und wenn die Instanz 27 hörende Adressen erhält? Dann kann man das nicht mehr abbilden. Ich habe ja schon mehrfach den Wunsch geäußert, die einzelnen Gruppenadressen nicht mehr als ‚erweiterte Adressen‘ sondern einfach auf einer Ebene und jeder GA einen Flag zuweisen.

Moment, also eine hörende Gruppenadresse ist doch etwas anderes als eine Rückmeldeadresse.

Gerade getestet, es ist so wie ich befürchtet habe: Die Rückmeldeadressen sind scheinbar gar keine Rückmeldeadressen sondern hörende Adressen. Denn der Status in IP Symcon reagiert nicht nur auf die Rückmeldeadresse. Um bei meinem Beispiel mit dem Aktor zu bleiben:

KNX Aktor
Kanal A Schalten (1/1/9)
Kanal A Rückmeldung (1/2/9)

Instanz (1/1/9)
→ lesen Flag aktiv
→ Rückmeldeadresse (1/2/9)

Die Variable der IP Symcon Instanz dürfte ja den Zustand gar nicht ändern wenn ich auf 1/1/9 einen Wert auf den Bus sende, macht sie aber.

Die von dir gemachte Unterscheidung kennt der KNX-Standard nicht.

Es gibt Hersteller wie MDT, die für die hörende GA eine separates KO zur Verfügung stellen und als Rückmelde-KO beschriften, aber macht funktionell keinen Unterschied sondern soll nur den Anfängern das Verständnis erleichtern und Fehlbedienung verhindern (Thema: auf welcher GA wird eine Leseanfrage beantwortet, wenn mehrere verbunden sind).

Was auch richtig ist.

Ja? Ich sehe da keinen Unterschied? Oder stehe ich auf dem Schlauch.

Ich sehe es aber auch so, dass die Status-GA, die mit dem Status KO eines Aktor verbunden ist, etwas anders ist als wenn man nun auf alle Schalt-GA‘s vom E/A KO hört. Weil nur das Status KO kennt den wahren Zustand der Antorkanals.

Da kannst du 20 hörende GA‘s lesen und du weißt trotzdem nicht, ob ein Kanal nun An oder Aus ist. Daher bin ich auch der Meinung, das es so sein sein muss, dass genau diese Rückmelde GA dann auch bei einem Neustart von IPS von Bus gelesen wird um seine Logiken zu initialisieren. Wenn aber nur mit hörenden GA‘s gearbeitet wird, wie das bei älteren Projekten durchaus üblich war, dann ist z.B. nach einem Neustart halt nicht möglich den Zustand von Geräten zu kennen. Was bringt es mir dann, wenn irgendeine der vielen GA‘s, die den Aktorkanal schalten gelesen wird? Das sagt doch bei Szenen oder Zentralbefehlen nichts darüber aus, welchen Zustand der Ausgang gerade wirklich hat.

Ich arbeite erst seit ein paar Wochen mit Symcon und hab mich mit den Experteneinstellungen der KNX-Instanzen noch nicht näher beschäftigt. Aber genau so etwas sollte sich hier definieren lassen. Daher hätte ich jetzt auch erwartet, dass diese einfach geht. So wie @gade8264 das aber beschreibt ist dem aber nicht so🤷🏻‍♂️ Ich werde das aber demnächst auch nochmal selbst testen.

1 „Gefällt mir“

Hier werden jetzt aber mehrere Themen vermischt. IPS arbeitet mit den GA, du sprichst vom KO. Das hängt zwar eng zusammen, aber IPS kennt nicht die Zuordnung der GA zu einem oder mehreren KO auf der Gegenseite. Hier immer eine Leseabfrage an die hörende(n) GA(s) zu machen wäre auch nicht korrekt und würde zu (anderen) Problemen führen.

Wenn du beim Start gezielt Leseabfrage auf bestimmte GA erzeugen willst, so würde ich diese zusätzlich als eigenständige Instanz in IPS anlegen. Dann hast du die volle Kontrolle.

Ich habe ja nicht behauptet, dass IPS die KOs kennt oder liest, aber ich weiß ja welche GA mit einem Status-KO verbunden ist und wollte damit nur verdeutlichen um was es mir dabei geht. Ich denke, das hast du sicher auch verstanden?

Ja, das wäre natürlich eine Möglichkeit. Aber wenn IPS bei einem TTl/XML-Import schon so toll die Status GA erkennen kann und diese dann automatisch als Rückmelde GA einer KNX-Instanz zuordnet, dann möchte ich jetzt nicht hingehen und mir für alle Status GA eine eigene Instanz erstellen. Das sind ja auch richtig viele, wenn man mal so drüber nachdenkt. Der Zustand von Lampen, Position der Beschattung uvm. Klar kommen die Informationen im laufe eines Tages nach und nach von alleine rein und ich bin mir selbst nicht sicher, ob ich bei einem Neustart immer eine Flut von Telegrammen generieren möchte.

Dass man aber in einer KNX Instanz nicht definieren kann, welche GA gelesen werden soll, finde ich nicht richtig. Für mein Empfinden sollte es aber bei entweder oder aber dann die GA für den Status sein. Bei dem semantischen Import von KNX Projekten, den ich übrigens ganz toll finde, gibt es ja z.B. für eine Jalousie ja einen Status für die Position der Lamelle und für die Höhe. Da wäre es sogar schön, wenn auch beide gelesen werden. Sind alles Dinge, die ich früher oder später mal brauchen werde.

1 „Gefällt mir“

Grundsätzlich stimme ich zu, dass der KNX Standard diese Unterscheidung nicht kennt, im Standard sind nur die hörenden Gruppenadressen definiert.

Es ist aber schon so, das sich Rückmeldeadressen als Konzept etabliert haben und von einigen Herstellern (z.B. auch MDT wie schon genannt wurde) in den Aktoren verwendet werden.

Die Behauptung, dass Rückmeldeadressen keinen funktionellen Unterscheid machen würden und Anfängern das Verständnis erleichtern soll, muss ich aber zurückweisen. Gerne erläutere ich das Konzept der Rückmeldeadressen kurz:

gegeben sind folgende Gruppenadressen
1/0/0 Schalten EIN/AUS
1/0/1 Schalten Rückmeldung EIN/AUS
1/0/3 Aktorkanal sperren EIN/AUS

KNX Schaltaktor
Kanal A (1/0/0)
Rückmeldung Kanal A (1/0/1)
Sperren Kanal A (1/0/3)

Mit der Adresse 1/0/0 kann nun der Aktor EIN bzw. AUS geschaltet werden. Je nach Sachaltzustand meldet die Gruppenadresse 1/0/1 den Zustand zurück. Noch könnte man sagen, dass auch die Adresse 1/0/0 den korreten Zustand wiedergibt.

Nun schalten wir den Aktorkanal mit 1/0/0 EIN und sperren den Kanal anschließend mit 1/0/3. Der Kanal ist nun verriegelt und verbleibt bis zum entsperren im Zustand EIN.
Wenn nun eine 1/0/0 AUS gesendet wird, verändert sich der Zustand des Schaltkanals nicht, denn er ist ja verriegelt. Die Rückmeldeadresse 1/0/1 liefert auch weiterhin den korrekten Zustand EIN. Die Gruppenadresse 1/0/0 hingehen hat den Wert AUS, der aber dann nicht den korrekten Schaltzustand angibt.

Man kann also sehen, das es einen Unterschied macht wenn eine separete Gruppenadresse für die Rückemeldung verwendet wird.
Das mit dem Sperren des Aktors ist natürlich nur ein kleines Beispiel, es gibt noch zahlreiche andere Anwendungsfälle in denen das Konzept von getrennten Gruppenadressen für eine korrekte Rückmeldung bewährt hat.

Zusammegefasst:

  1. So wie ich das aktuell sehe kennt Symcon aktuell nur hörende Gruppenadressen, die aber als „Rückemeldeadressen“ in der Instanz bezeichnet werden, das ist evtl. etwas verwirrend bezeichnet.
  2. Rückmeldeadressen (wie oben beschrieben) in einer Instanz können nicht abgebildet werden bzw. ich habe noch nicht herausgefunden wie sich das abbilden lässt.
  3. Es ist natürlich möglich zwei verschiedene Instanzen anzulegen: Eine Instanz für die Gruppenadresse zum Schalten (im Beispiel: 1/0/0) und eine Instanz für die Rückmelde Gruppenadresse (im Beispiel: 1/0/1). Dann ist mir allerdings nicht klar, wie ich das in der Visualisierung in einen Schalter bekomme, der über 1/0/0 schaltet und den Status über 1/0/1 anzeigt.
1 „Gefällt mir“

Das ist eben der Punkt - IPS bekommt den Status mit, wenn das Gerät sendet und sinnvollerweise konfiguriert man es ohnehin so, daß zyklisch und beim Start der Geräte der Status gesendet wird. Da würde ich ansetzen, beim zyklischen Senden alle 5 Minuten oder so.

Was du zusätzlich beim Start von IPS abfragen möchtest kannst du unabhängig davon als zusätzliche (!) Instanz anlegen und dort die Abfrage auf die gewünschte GA hinterlegen. Sinnvollweise etwas zeitversetzt, um ein Telegrammflut zu vermeiden.

Und wieder gehen GA und KO durcheinander. Wenn du von Rückmelde-GA schreibst meinst du die GA an einem separaten Rückmelde-KO. Du gehst implizit von zwei KO aus, Schalten und Rückmeldung, von denen jedes eine zu sendende GA besitzt.

Die einfache IPS-Instanz entspricht aber einem KO, nicht zwei. Dein Wunsch würde bedeuten, daß eine Instanz in IPS sich quasi wie zwei separate KO verhält: eines sendet den Schaltbefehl auf die Schalt-GA, das andere KO empfängt den Status und sendet auf diese GA auch die Leseanfrage. So wie es auch in deinem MDT-Geraten implementiert ist. Könnte man machen.

Er/wir verwenden in dem Fall halt das Wording von IPS:
image

Wenn sich eine KNX-Instanz so verhalten würde, dann wäre das top! Weil man es von einem KNX-Gerät auch so erwarten würde. Klar ist IPS kein echter KNX-Teilnehmer, aber es soll hier ja ein KNX-Gerät emuliert werden.

Das habe ich schon verstanden, daher schrieb ich ja:

Das mit den Rückmeldeadressen wird ja sogar beim Import so benannt, das habe ich mir ja nicht selber ausgedacht :wink: Hier ist ja an keiner Stelle von hörenden Gruppenadressen die Rede.

Da mir die Variante mit zwei verschiedenen Instanzen auch schon in den Sinn kam schrieb ich ja weiter:

Aber wie gesagt, dann ist mir nicht klar wie ich einen Schalter in der Visualisierung abbilden soll. Über die eine Variable müsse er dann den Status senden, über die andere den Wert empfangen.

Oder meinst du @volkerm das mit der zusätzlichen Instanz wie folgt:

Instanz 1
Gruppenadresse 1/0/0
hörende Adresse 1/0/1 (in Symcon Rückmeldeadresse genannt)

Instanz 2
Gruppenadresse 1/0/1
lesen Flag aktiv

Kurze Rückmeldung nach einem kleinen Test was funktioniert:

Instanz 1
Gruppenadresse 1/0/0
hörende Adresse 1/0/1 (in Symcon Rückmeldeadresse genannt)

Instanz 2
Gruppenadresse 1/0/1
lesen Flag aktiv

Ist etwas nervig das man dann jeweils zwei Instanzen anlegen muss, allerdings würde das ja auch nur auf die Gruppenadressen zutreffen für die man tatsächlich eine Leseanfrage beim Start stellen möchte.

Aber generell ist dann die Bezeichnung „weitere Rückmeldeadressen“ oder generell Rückmeldeadressen in Symcon sehr missverständlich.

Man kann es noch weiter vereinfachen auf IPS-Seite, wenn man dafür in der ETS etwas umkonfiguriert:

Du könntest in der ETS eine neue, zusätzliche GA vom abzufragenden Typ anlegen (z.B. 5.001 für Positionsrückmeldung). Diese GA verbindest du in der ETS als hörende Adresse auf alle Positionsrückmeldungen, die du abfragen möchtest. Diese KO haben dann zwei verbundene GA: die erste auf die gesendet wird (individuelle Status-GA) und zusätzlich deine neu angelegte Abfrage-GA als hörende Adresse.

Wenn du nun von IPS aus eine Leseanfrage an diese neue „Abfrage-GA“ sendest, so wird das von allen verbundenen Status-KO der Geräte empfangen und sie antworten alle - und zwar auf ihrer ersten GA die am KO verbunden ist. Sie antworten also auf ihrer Status-GA, obwohl du mit einer anderen GA die Leseanforderung geschickt hast.

Damit würden alle mit der Abfrage-GA verbundenen Geräte in IPS aktualisiert, bei Leseabfrage auf nur eine neu angelegte GA.

Wie oft ist man denn in der Situation, dass IPS neu startet und man diese Abfrage durchführen muss?

Ich starte IPS alle 4 Monate mal neu. Danach führe ich einen Zentralbefehl aus der alle Rollläden fährt und schon ist alles wieder aktuell.

Ich sehe hier das Problem nicht.