[Frage] Wiregate-Plugin Multi-RTR im TWS: Wer nutzt es und kann mal kurz analysieren

[Robosoc]

Habe einen Treffer, verstehe aber leider noch nicht, wie ich das jetzt interpretiere:



Der vierte Eintrag hat ein LL-ACK ganz rechts. Und die Flags in der vierten Spalte sind immer unterschiedlich. Ansonsten sehe ich keinen Unterschied, ausser im Zeitstempel bei den Millisekunden. Aber welcher Teilnehmer erzeugt denn das Acknoledging? Ich hätte gedacht, dass müsste ein Gegentelegramm vom einer anderen PA sein... Das ist vermutlich aber falsch, oder?

[Matze76]

Der vierte Eintrag hat ein LL-ACK ganz rechts.

Steht da nicht LL-NAK (zumindest sehe ich ein "N") ? Das wäre ja dann die Quittierung eines fehlerhaft übermittelten Telegramms. Das würde ja auch die 3 Sende-Versuche erklären.

[gbglace]

Ja da fehlen die ACK und irgendwann ist Schluss mit dem Fehler-Telegramm.

Welche PA wäre denn die Empfänger PA des Telegramms in GA 4/4/30 ? Womöglich ist da was faul.

[Robosoc]

Okay, das Ganze ist für mich noch sehr merkwürdig, aber ich habe mich vorher auch noch nie mit Acknoledge und Route oder so beschäftigt.

In der GA 4/4/30 sind zwei Objekte eingetragen:
1: der TWS auf 1.0.101, alle 5 Flags aktiv (quasi default und noch nicht sauber gepflegt)
2: ein Antriebsaktor auf 1.3.31, K- und S-Flag aktiviert.

Dazwischen ist ein Linienkoppler 1.3.0, der noch auf "Testzweck: Weiterleiten" eingestellt ist. (Ich habe mich nie getraut den auf beideitiges filtern zu stellen, wofür er aber ja eingeltich da ist.)

Nach meinem Verständnis müsste der Linienkoppler mit der PA 1.3.0 die Telegramme bestätigen (-> LL_ACK) und nicht der Antriebsaktor, der ja in einer anderen Linie hängt.

Nun kann man aber ja im Busmonitor sehen, dass nicht die erste Schnittstelle vom TWS die Sendende ist, sondern die Zweite 1.0.102. Ich vermute, dass liegt daran, dass das Wiregateplugin sich der zweiten Schnittstelle bedient, vermutlich weil das zu dem Zeitpunkt die erste freie Schnittstelle war (ENV Parameter des TW-APP-Wiregate-Plugin-Environment ist KNXPA = 0.0.0), korrekt interpretiert? Was würde passieren, wenn ich hier manuell KNXPA = 1.0.101 einstelle? Das ist bei mir die erste Adresse des TWS950.

Der Linienkoppler kennt die Verbindung zwischen dem PA 1.0.102 und der GA 4/4/30 ja nicht und würde diese vermutlich im regulären Betrieb herausfiltern / sperren, oder? Eventuell bestätigt er sie deshalb auch nicht immer im Testbetrieb. Aber meistens klappt es ja und die Stellwerte werden "acknoledged" also kann es auch nicht so richtig daran liegen...

Es gibt noch drei weitere Linienkoppler 1.1.0, 1.2.0 und 1.4.0
Alle sind im Testbetrieb und leiten quasi alle Telegramme weiter. Telegrammbestätigungen sind "nur bei Weiterleitung" eingestellt, was aber ja dann quasi immer ist. Ich fange jetzt mal vorsichtig an mutig zu werden und habe den Linienkoppler 1.4.0 auf beidseitig filtern gestellt. Sollte ja eigentlich funktionieren...Und dann werde ich von Tag zu Tag mutiger

[gbglace]

Naja die Filtertabellen der Koppler interessieren sich ja weniger für die PA's, von wo das Telegramm kommt ergibt sich aus dem Stück CU. Die Filtertabelle wiederum rechnet die ETS in dem sie erkennt das eine GA in beiden Linien verbunden ist und somit ein Weg vorzuhalten ist. Insofern sollte es egal sein welche Tunnel PA 1.1.1xx sendet, selbst wenn es unsauber aus 0.0.0 kommt wäre es dem LK noch egal. Würde er die PA interpretieren müsste der LK auch die Routingzähler beachten und würde dann ggf verwirrt sein wenn ein Telegramm von 0.0.0 in der Cu-Leitung 1.1.x daher kommt aber der Routingzähler noch voll ist und nicht ein Stelle runter gezählt wurde, was ja ein Bereichskoppler / IP-Router machen würde um von 0.x.x runter auf 1.0.x zu koppeln. Ich denke aber nicht das die Filter soviel Intelligenz eingebaut haben und maximal noch auf die 1 am Routingzähler achten und dann nicht mehr weiter leiten.

Ob man sowas in einer KNX-Spec genauer nachlesen könnte?

[Robosoc]

Jo, danke Göran. Habe auch parallel auf support.knx.org gelesen, dass Koppler lediglich nach der GA Filtern. HAbe mich daher auch getraut alle 4 Koppler auf Filtern zu stellen. Zumindest in den letzten knapp 30 Minuten hatte ich bei 1700 Telegrammen keinen einzigen Wiederholer... Das sieht schon einmal viel versprechend aus.

Aber ich habe noch immer ca. 13% Write-Telegramme ohne LL_ACK (aber auch ohne BUSY oder LL_NAK und ohne Wiederholung), was ich noch nicht deuten kann. Vermutlich schlechte FLAG-Vergabe...aber bei einigen konnte ich es auf Anhieb nicht nachvollziehen. Egal...ich geh mal lieber ins Bett

[Robosoc]

Nur noch einmal der Vollständigkeit wegen: Der Grund dafür, dass ich die Linienkoppler nie mit der Filtertabelle aktiviert habe, war übrigend ursprünglich nicht Faulheit oder Mutlosigkeit, sondern schlichtweg, dass es für mich nach einer Horroraufgabe aussah meine 800 bis später 1.000 GA mit der Gira-Applikation zu verbinden, die den Wiregate-Server in der ETS abgebildet hat. Das wäre ja notwendig gewesen um die Filtertabellen der Linienkoppler zu füllen. Dann habe ich mich 4 Jahre lang daran gewöhnt, dass mir die Linienkoppler lediglich eine übersichtlichere Struktur ermöglichen. Mit dem TWS und der Timberwolf-Importer App war das ja eigentlich in wenigen Minuten erledigt, nur habe ich das nie so ganz richtig und sicher erkannt, dss ich da schon fertig bin!

TWS vs. WG 10:0 aus meiner Sicht.
Der Kauf hat sich bei mir wirklich voll gelohnt...und ja, ich schreibe das auch irgendwann noch einmal als Erfolgsstory.