Aktor reagiert auf GA aus Gruppenmonitor, von Busteilnehmern aber nicht

[Sturmhardt]

Irgendwas habe ich unbeabsichtigt verbogen: Ich habe je eine KNX TP, PN, RF Linie. 3 von 60 Aktoren der PN Linie reagieren seit ... einigen Tagen nicht mehr auf GA Telegramme von Busteilnehmern der TP Linie. Klingt total einfach nach "Filtertabelle Gateway falsch". Die ist aber seit 2017 unverändert und nach erneuter Prüfung auch OK. Das für mich unerklärliche: GA Telegramme aus dem ETS Gruppenmonitor an diese PN Aktoren werden umgesetzt, egal ob von PN- oder TP (!) Seite. Obwohl diese Telegramme über das gleiche Gateway müssen. Konkret: Die GA 4/0/10 eines Jalousieaktors BJ 6920/ 40:

image.png
Diese GA wird auf vom Linienkoppler BJ 6987/ 10 mit dieser Filtertabelle auf zwischen PN/ TP geroutet:

image.png
Einziger gefundener Unterschied zwischen erfolgreichen/ erfolglosen Telegrammen an diese GA im Gruppenmonitor: Die "Route". Was isch dess? Hier ein Screenshot aus dem KNX Datenlogger der Anlage. Die rot eingekreisten Telegramme führten NICHT zu einer Reaktion, die grün eingekreisten lösten Reaktion aus:

image.png
Die 1.1.xx Adressen sind Tastsensoren der TP-Linie. Der 1.2.151 ist der KNX USB BJ6123 Busankoppler auf PN Seite. Das für mich unlogische: Schaue ich mir von der PN-Seite (!) aus den ETS Gruppenmonitor an (Gateway: BJ6123 auf BJ6931), sehe ich, dass die 4/0/10 GA geroutet wird, das Telegramm erscheint! Der Aktor ignoriert es aber. Kommt das gleiche Telegramm von PN-Seite aus, löst Aktor aus. Die Telegramme unterscheiden sich nur über den Wert bei "Route"; das sind entweder "5" oder "6". Und jetzt das übliche: Natürlich hat es seit 2017 funktioniert ;0). Die Wettersensoren/ Zeitlogiken sind auf TP-Seite und steuern auf einmal einige Behänge nicht mehr.

Ich habe den Linienkoppler und die Aktoren bereits mehrfach neu programmiert. Die Telegramme laufen sauber durch, ohne "unbeantwortete" oder ähnliche Schmerzen.

Guten Start in die Woche und Dank im Voraus fürs Reindenken!

[gbglace]

Die Telegramme Mit Routing-Counter 5 gehen durch einen LK bevor sie die Schnittstelle mit der die ETS sich mit dem Bus verbindet.
Die Telegramme mit Counter 6 haben von Quelle zum Ziel (ETS Busmonitor) keinen LK auf dem Weg.

Das KO6 mit der GA 4/0/10 dran hat ja noch einige andere GA dran verbunden, Wozu hat das KO da ein L-Flag gesetzt? Ist das ein Status-KO des Aktors?
Wenn Status, warum sind dann da überhaupt mehrere GA eingehend dran verbunden?

Das bedeutet Deine Schnittstelle zur ETS sitzt auf der Linie 1.1.x der Absender sitzt eben mal auf Linie 1.2.x. und mal auf 1.1.x.
Der LK von TP runter auf PN ist damit erstmal durchlässig für die Richtung PN an TP, scheint aber die Telegramme von TP an PN zu filtern.

Die 1.1.xx Adressen sind Tastsensoren der TP-Linie. Der 1.2.151 ist der KNX USB BJ6123 Busankoppler auf PN Seite. Das für mich unlogische: Schaue ich mir von der PN-Seite (!) aus den ETS Gruppenmonitor an (Gateway: BJ6123 auf BJ6931), sehe ich, dass die 4/0/10 GA geroutet wird, das Telegramm erscheint! Der Aktor ignoriert es aber.

Hier steige ich jetzt aus, welches gerät da jetzt was wo tut in Deiner Installation.

Kannst Du das mal auf die PA's und kurz nur Taster / Schnittstelle, Aktor dazu notieren, ich will mir da jetzt nicht aus dem Internet zu den Artikelnummern die Dokuarchive raussuchen.

[Sturmhardt]

Die Telegramme Mit Routing-Counter 5 gehen durch einen LK bevor sie die Schnittstelle mit der die ETS sich mit dem Bus verbindet.
Die Telegramme mit Counter 6 haben von Quelle zum Ziel (ETS Busmonitor) keinen LK auf dem Weg.

Danke! Passt, wenn ich den Gruppenmonitor nicht von der TP-Seite aus lesen lasse, sondern von der PN-Seite aus, sind die Werte 5/ 6 genau invertiert zugeordnet ;0).

Das KO6 mit der GA 4/0/10 dran hat ja noch einige andere GA dran verbunden, Wozu hat das KO da ein L-Flag gesetzt? Ist das ein Status-KO des Aktors?
Wenn Status, warum sind dann da überhaupt mehrere GA eingehend dran verbunden?

Das sind Schreib- und Lese KO. Die anderen GA sind diverse Gruppensteuerungen; da Aktor hat keine Zentral-KO. Im Objekt sind rund 30 Behänge in unterschiedlichen Himmelrichtungen, daher gibt es neben der Einzelsteuerung 4/0/10 auch Gruppierungen nach Himmelsrichtung (Beschattung), Etagen oder eben zentral.

Das bedeutet Deine Schnittstelle zur ETS sitzt auf der Linie 1.1.x der Absender sitzt eben mal auf Linie 1.2.x. und mal auf 1.1.x.
Der LK von TP runter auf PN ist damit erstmal durchlässig für die Richtung PN an TP, scheint aber die Telegramme von TP an PN zu filtern.

Ja, fast. Dies ist die Topologie:

image.png

Die PN Schnittstelle hat die Adresse 1.2.151
Die TP Schnittstelle meldet sich als 1.0.0

Hier steige ich jetzt aus, welches gerät da jetzt was wo tut in Deiner Installation.

Kannst Du das mal auf die PA's und kurz nur Taster / Schnittstelle, Aktor dazu notieren, ich will mir da jetzt nicht aus dem Internet zu den Artikelnummern die Dokuarchive raussuchen.

Na klar, gerne. Es sind 220 Geräte im Projekt die aus meiner Sicht relevanten zu den Screenshots oben:

1.1.35, 1.1.124 sind Busch Jäger 6127/ 02 Tastsensoren. Exemplarisch für andere Sensoren, z.B. Helligkeit außen für automatische Behangsteuerung.
1.2.0 ist der Busch Jäger 6987/ 10 Medienkoppler Powernet <-> TP
1.2.151 ist ein USB Busankoppler Busch Jäger 6123 = Schnittstelle.
1.2.54 ist ein Busch Jäger Jalousieaktor 6920/ 40.

Danke schonmal für die Aktivität.

[gbglace]

Wenn es schreib und lese KO sein sollen, dann muss die Status GA als erste verbunden sein und nicht eine Befehls GA. Das ergibt ja keinen Sinn, das wenn man nach einem Zustand fragt ob der Aktor in Bewegung ist eine Antwort auf der GA bekommt Aktor Fang mal an Dich zu bewegen.. Zustand und Befehl sind zwei unterschiedliche Sachen. Wenn nur Befehle dort eingehen dann macht man die Flags anders.

Wenn das die Topologie ist, dann hat da einer was falsch verdrahtet,. Der Hopcount müsste sich um zwei unterscheiden, da normal immer zwei Koppler involviert sind um von 1.1.x nach 1.2.x zu kommen.

Wenn die ETS aber Telegramme mit jur einem 5-er Hopcount erkennt hat sie nur einen LK gesehen.
Dann muss die Schnittstelle Teilnehmer der Linie 1.0.x sein.
Eine KNX-IP Schnittstelle mit einer PA 1.0.0 ist auch falsch, denn PAs x.y.0 sind Kopplern vorbehalten, sprich das kann dann nur ein Linienkoppler sein und wenn Du das mit nem PC im LAN machst, muss das ein IP-Router sein.
Solche Router bieten auch KNX IP Tunneling aber dann wird die ETS durch eine PA 1.0.x Kit x ungleich 0 repräsentiert. Kommen die Telegramme aber wirklich mit der 1.0.0, dann sitzt die ETS als KNX IP Teilnehmer auf der IP Bereichslinie, denn 1.0.0 ist eine PA für einen Bereichskoppler.
Aber dann müsste der Hopcount auch eine Nummer größer sein, da dann für jedes Telegramm von 1.1.x oder 1.2.x immer zwei Koppler bis zur ETS auf dem Weg waren.

Da passt was nicht zusammen.

Topologie zur Verklemmung der grünen Leitungen passt da nicht zusammen.

[Sturmhardt]

Für die Suchfunktion anderen Forennutzer: Der Fehler war tatsächlich im Aktor. Ich habe einen anderen BJ6920/ 40 angeschlossen, PA/ Applikation programmiert => seit 4 Tagen kein Fehler, der Aktor reagiert auf alle Telegramme. Mystisch, da der alte Aktor das bei Absendung der Telegramme auf der eigenen Linie auch tat, nur bei Telegramme von anderen Linien nicht. Obwohl der Logger bewies, dass die Telegramme durch den Koppler kommen.

Naja, wichtig: Es funktioniert wieder.

@gbglace: Trotzdem danke für´s Mitdenken. Bestimmt hast du mit der Topologie nicht unrecht, aber: Die Anlage ist komplex und läuft so seit 2017. Daher tat ich mich schwer damit, die Topo zu ändern. Da macht man vielleicht mehr kaputt und bei Powernet gibt´s keine grünen Leitungen ;0)). Scherz, ich weis, wie du es gemeint hast.