Verstaendnisfrage ACK

[wintermute]

Hi Christian,

ich haette da mal eine rein akademische Frage die nicht unmittelbar Edomi betrifft, aber weil Edomi sich da zu anderen Loesungen identisch verhaelt dachte ich mir, ich frag einfach mal doof nach
Wenn ich zwei Geraete habe, die in der ETS nur (wenn ueberhaupt) als Dummy auftauchen, ma (nur fuer Spass) sagen ein Edomi und einen HS. Wenn die beiden sich jetzt unterhalten, dann wird jedes Telegramm 4x gesendet, einmal initial und 3x als Resend weil keiner der beiden ein ACK schickt. Wenn ich jetzt zB noch nen Aktor (oder irgendein "echtes" Geraet aus der ETS) mit in den Topf werfe ist alles gut, weil eben das Geraet ordnungsgemaess ein ACK schickt.

Also Frage: wieso schickt Edomi zB kein ACK? Das wuerde mir vermutlich auch die Frage beantworten, wieso andere Visus das ebenfalls nicht tun. Ist doch irgendwie inkostent das Verhalten und nicht 100%ig korrekt, oder? Wenn ich auf eine GA hoere, dann muss ich doch auch ACKen, oder ist dem garnicht so? UNd wenn nein, wieso nicht?

danke :: Michael

[gaert]

Puh... Keine Ahnung (auf die Schnelle) Da muss ich mal die Spec wälzen, denn dort ist genau definiert, wann ein ACK gesendet wird und wann nicht. So aus'm Kopp würde ich behaupten, dass immer ein ACK gesendet wird - es gibt allerdings unterschiedliche Typen von ACKs... Vielleicht liegt's auch daran, dass die GA quasi als "unbekannt" auf dem Bus im Nirvana verschwindet, da kein echtes KNX-Gerät sagt: Alles klar - diese GA ist mir zugewiesen worden!

[wintermute]

Ich kann auch konkreter fragen: wieso sendet Edomi eigentlich kein ACK wenn es ein Paket empfaengt fuer das es sich selber verantwortlich fuehlt?
Weil, ich mein, ich bin da kein Experte, aber ne Visu ist doch auch ein "echtes KNX" Geraet, auch wenns keine Applikation dafuer gibt, oder?

[WagoKlemme]

Hi Michael,

ich glaube genau da ist das Problem Edomi ist m.M.n kein KNX-Gerät, sondern die Schnittstelle IP oder Router über das Edomi zugreift. Und da sollte man einstellen können ob eine Wiederholung stattfinden soll oder nicht. Wie bei Linienkopplern. Edomi ist in der ETS, bei mir, ein Dummy.
Leider kann man nichts einstellen, zumindest bei meiner IP Schnittstelle von MDT.
Wäre auch an einer Lösung interessiert, wegen unnötiger Buslast.

Edit: Ich finde hier ist es gut beschrieben

[wintermute]

Ja, ich bin da in grossen Teilen bei Dir. Aber Edomi benutzt ja einen Tunnel und verhaelt sich damit wie ein TP-Geraet - im Gegensatz zu Geraeten auf der IP-Linie die durch den Router kommen. Da isses zB bei mir so (bei Deiner Wago vermutlich auch ), dass alle Pakete TP->IP automatisch von der Wago ge-ACKed werden (weils ja anders auch keinen Sinn macht). Da sehe ich auch keine Wiederholungen - aber eben regelmaessig wenn die Telegramme die IP->TP Richtung haben (und eben auch bei Edomi wo die Pakete durch einen Tunnel kommen und daher garnicht durch den "Linienkoppler" laufen).

Wie gesagt, das ist kein Edomi Dingen, das ist zB auch beim HS so (vermutlich bei anderen Visus ebenfalls), ich taet nur gern verstehen wieso man kein ACK schickt wenn man ein Telegramm empfaengt fuer das man selber zweifelsfrei zustaendig ist - unabhaengig dessen ob das nu ueber die ETS parametrisiert wurde oder nicht.

Ganz frueher war mein HS mal per RS-232 angebunden, ich weiss leider nicht mehr ob da dann ge-ACKed wurde oder ob das ein reines IP/TP Dingen ist

[WagoKlemme]

Warum das so ist ? k.A
Das scheint aber, so nach dem o.g. Thread, bei IP->TP immer ohne ACK zu sein. Ack'd wird nur auf dem gleichen Medium.
Oder Du schickst Klaus Gütter eine PN, denn er scheint sich sehr gut mit KNX auszukennen. Zumindest hat er mir schon, mehrmals in diversen Threads, das Licht un-/bewusst angeknipst.

Nebenbei meine Wago ist kein Router mehr. Ich habe sie zum dummen Datensammler degradiert, da sie nur 1 Tunnel hat. Ich habe jetzt die neue MDT IP Schnittstelle mit 4 Tunneln.

[gaert]

Bevor ich tiefer einsteige: Warum ist das eigentlich wichtig? Du kannst ja EDOMI durchaus über eine beliebige GA "abfragen" (Requestauslöser bzw. KO-Einstellungen) - das ist doch ausreichend? Was da so auf Level 0 passiert ist doch eher Wurscht

[wintermute]

Ja, klar... das ist wie oben geschrieben aus rein akademischem Interesse.
Mich hatte das Verhalten schon gewundert bevor ich Edomi ueberhaupt eingesetzt habe - ich dachte nur, ich frag jetzt mal nen Experten

[gaert]

Kann ich verstehen Mir ist auch einiges unklar - ich bin _kein_ Low-Level-KNX-Experte!

Mir war aber auch garnicht bewusst, dass EDOMI nicht mit dem HS plaudern kann. Ich teste regelmäßig "gegen" die ETS - hier klappt die Kommunikation problemlos in beide Richtungen.

[wintermute]

Nene, die koennen schon miteinander reden, die Kommunikation klappt einwandfrei, es wird halt nur die 4fache Buslast erzeugt
Aber ich dachte, der gesamte Stack waer von Dir, also inkl. der Entscheidung wann man was zu ACKen haette und wann nicht.

Das passiert zB auch dann, wenn ein "regulaeres" Geraet als einziges an eine GA sendet, also niemand da ist, der drauf hoert... kann man dann in der ETS im Busmonitor sehen wenn da was gesendet wird: einmal Gruen, dann drei Gelbe Telegramme fuer die Resends. Wie gesagt, das Problem ist nicht neu, ich versteh halt nur nicht, wieso da keiner was gegen macht

[gaert]

Der Stack ist in der Tat von mir - mühsam aus der Spec abgeleitet... Aber es handelt sich ja um einen IP-Stack, d.h. die letzten Details auf KNX-Ebene interessierten mich nicht wirklich (das überlasse ich mal besser der IP-Schnittstelle/Router). Man kann durchaus noch an diversen Schrauben drehen (Anzahl der Wiederholungen, Priorität, etc.), aber das habe ich mir geschenkt

Generell ist das Verhalten aber in Ordnung würde ich sagen: Jemand sendet etwas an eine GA, niemanden interessierts (kein ACK), also wird's halt noch dreimal versucht und dann verworfen. Schließlich könnte ja auch eine "Störung" vorgelegen haben.

[wintermute]

Ja sicher, funktonieren tut das alles auch so... aber wenn ich zB was an Edomi schicke, also etwas, was Edomi auch interessiert, wieso wird dann kein ACK geschickt? Ich dachte, das waere Teil des Stacks und nicht Aufgabe der Schnittstelle bzw des FT1.2 oder wie auch immer das grad angeschlossen ist.
Als wir zB an der fruehen Arduino-Lib gebaut haben, da war das ACK-Handling Teil des Stacks - aber auch nicht richtig implementiert, btw

Ich muss das nochmal mit nem HS an nem seriellen Interface probieren, ob der dann ACKed oder ob das nur nicht passiert wenn er ueber Multicast arbeitet...

[gaert]

Verstehe ich nicht?! Wenn ich per ETS einen Read-Request an EDOMI schicke (und die GA entsprechend konfiguriert ist!), antwortet EDOMI ganz brav mit dem entsprechenden GA-Wert. Auf Stack-Basis wird natürlich geACKed, sonst würde die ETS meckern

[Klaus Gütter]

OK, da ich angesprochen wurde, gebe ich auch mal meinen Senf dazu.
Mit ACK ist er das ACK-Byte auf TP Link Layer gemeint, mit dem der (oder die) Empfänger kundtun, ob sie auf dem Bus alles korrekt empfangen haben. Schon wegen dem Timing ist das unmöglich, dass das von einer Visu generiert wird. Auch von Stack her ist klar, dass die Link Layer immer in der Schnittstelle implementiert ist (OK, es gibt Lösungen, die direkt auf dem TP-UART aufsetzen, aber das sind eher Exoten).

Wann schickt jetzt ein TP-Gerät (oder eine TP-Schnittstelle) ein ACK? Wenn sie sich bei der übertragenen Zieladresse angesprochen fühlt, also wenn sie z.B. direkt adressiert wurde (Zieladresse=eigene phys. Adresse) oder wenn die GA in der Adresstabelle (bei Kopplern in der Filtertabelle) eingetragen ist.

Eine Visualisierung konfiguriert die Schnittstelle normalerweise so, dass alle Gruppenadressen nach oben weitergeleitet werden. Eine Schnittstelle, die sich korrekt verhält, wird also in diesem Modus alle Gruppentelegramme bestätigen. Wenn es in so einem Szenario Wiederholungen gibt, ist das ein Fehler in der Schnittstelle oder in deren Initialisierung durch die Visu.

Der ETS ist das übrigens herzlich egal, ob das ACK kommt- auch diese setzt auf der Link Layer der Schnittstelle auf und das ACK interessiert nur die Link Layer.

Das Ganze gilt auch nur für TP. Auf IP (Routing) gibt's gar kein ACK. Und auf PL und RF ist es richtig kompliziert.

Gruß, Klaus

[WagoKlemme]

OK, da ich angesprochen wurde, gebe ich auch mal meinen Senf dazu.
Eine Visualisierung konfiguriert die Schnittstelle normalerweise so, dass alle Gruppenadressen nach oben weitergeleitet werden. Eine Schnittstelle, die sich korrekt verhält, wird also in diesem Modus alle Gruppentelegramme bestätigen. Wenn es in so einem Szenario Wiederholungen gibt, ist das ein Fehler in der Schnittstelle oder in deren Initialisierung durch die Visu.

Gruß, Klaus

Danke, Klaus.
Ist das auch bei einem IP-Interface so mit dem ACK auf den Bus als Bestätigung, dass es die Telegramme weitergeleitet hat an z.B. eine Visu ?