KNX/EIB Telegramm Quittierung - was ich schon immer fragen wollte - Verständnisfrage

[kropfm]

Guten Abend!

Angeblich sollen Telegramme die nicht bestätigt werden 3 mal wiederholt werden. Nun hier meine Frage wie weiss die sendende KO überhaupt wer alles mithört? Und was passiert wenn ich eine Gruppenadresse habe aber nur die sendende KO drin steht? Von denen habe ich einige die ich dann im Zusammenhang mit dem EibPC verwende. Jedoch konnte ich noch nie 3 Telegramme nacheinander sehen.

Habe ich hier etwas grundsätzlich falsch verstanden?

Für Feedback danke ich Euch im Voraus!

Gruss,

Martin

[Gaston]

zu 1.: Das sendende KO benötigt kein Wissen darüber wieviele mithören, es geht aber davon aus dass es zumindest einen Zuhörer gib. Alle zuhörer senden das ACK zusammen da das timing streng definiert ist und wird als einziges ACK wahrgenommen.

zu 2.: Wenn es keine Zuhörer gibt, gibt es im Prinzip kein ACK, und somit Wiederholungen. Ist allerdings ein Bereichs- oder Linienkoppler oder Linienverstärker vorhanden so sendet dieser je nach Konfiguration on GA ein ACK.

Gruss,
Gaston

[kropfm]

Vielen Dank Gaston. Wird dann im Falle des EibPC (einziger Zuhörer in manchen GAs) ein ACK durch diesen gesendet? Weil ich habe eine Telegrammwiederholung noch nie beobachten können.

[Gaston]

Wird dann im Falle des EibPC (einziger Zuhörer in manchen GAs) ein ACK durch diesen gesendet? Weil ich habe eine Telegrammwiederholung noch nie beobachten können.

Das sollte dann so sein, ansonsten gäbe Wiederholungen. "Früher" gab es Visus die keinen ACK gesendet haben, das sollt eheute aber kein Thema mehr sein.

Im Busmonitor der ETS 3 siehst du die ACKs j in der IACK Spalte. Wenn diese Leer ist wurde kein ACK/NACK/BUSY gesendet.

Gruss,
Gaston

[kropfm]

Habe ich gerade getestet und die werden in der Tat bestätigt. Vielen Dank Gaston und ein schönes Wochenende.

Gruss,

Martin

[enertegus]

Guten Abend!
Von denen habe ich einige die ich dann im Zusammenhang mit dem EibPC verwende. Jedoch konnte ich noch nie 3 Telegramme nacheinander sehen.

Wenn Du den EibPC im Busmonitormodus (nur FT 1.2) betreibst, dann würdest Du dies auch mit der ETS3 erkennen können. Der Gruppenmonitormodus ACK sich selbst - wie auch LK oder IP Schnittstellen, alsbald diese am KNX hängen.

[makki]

Der EibPC ACKed? energetus möge mich aufklären, wenn ich was verpasst habe?!
Das wäre gut, weil es einfach das Problem löst..

Jedenfalls, dasselbe "Problem" hat man auch mit dem HS oder jeglicher anderer Kiste, wenn man "einseitige" Gruppenadressen (z.B. Taster ohne selbe GA an einem Aktor o.ä.) hat - aber nur ohne LK (weil der ACKed - sofern eingestellt - vereinfacht ausgedrückt einfach dumm alles)
Auch auf die Gefahr hin, alte Diskussionen aufzuwärmen: Technisch sinnvoll ist das IMHO nur sehr eingeschränkt, wie bereits erwähnt, das ACK sagt rein garnicht darüber aus bei wem oder ob ein Telegramm beim richtigen ankam; es löst einfach nur das Problem der Telegrammwiederholungen (die schlimmstenfalls 3/4 der Kapazität des ohnehin nicht üppigen KNX mit 9,6kBit kosten können). Sonst nichts, weder sender noch empfänger wissen deshalb was, wie oder gar wo ankam oder nicht.

Nicht das das in der Praxis nicht wunderbar funktionieren würde, was ich damit sagen will ist lediglich, das die ACK's IMHO eh nur fürs Auge sind und wenn sie fehlen eben ein grosses Ärgerniss ohne grossen Nutzen.

Das ist irgenwo ein kleines integrales KNX-Problem, solange ein LK oder ein "Empfänger" in derselben Linie (mit max. jew. 255 GA's pro Gerät! Stand jetzt System 7) vorhanden ist: alles Ok, aber wenn es nur eine Linie und eine halbzentrale Logik gibt (die Regelmässig alle, also meist erheblich mehr als 250 GA empfängt), kommen die Telegrammwiederholungen wegen fehlender Acks unweigerlich. Daran kann man auch wenig ändern, weil z.B. mit FT1.2/BCU2 oder USB-SS das acken AFAIK zeitlich nicht machbar ist (bei mehr als 255 GA zumindest, dafür gibts ja die Adresstabelle in der BCU).

Makki

P.S.: Ich will jetzt keine Werbung machen, aber genau deshalb - mich selbst hat das mitm HS monatelang ausgebremst - ACKed das WG in seiner Funktion als IP-LK/BK alle Gruppentelegramme seit jeher (macht jetzt auch der offizielle eibd mit Kommandozeilen-Option);
Aber nur mit TP-UART Schnittstelle, weil es nur damit schnell genug geht.. Wie Gaston schon schrieb: das ist ziemlich Timing-kritisch.
Weil letztlich ist es IMHO egal, wer ACKed, solange es jemand empfangen hat und tut, damit einfach Ruhe am Bus ist..

[saft6luck]

Grundsätzlich ist das NACK schon interessant und das geht beim KNX nur, wenn es auch ein ACK (bzw. die Pause hierfür) gib.

Das ACK macht man ja idealerweise auch nicht selbst, sondern der/die BA/FT1.2 (Gruppenmonitor Modus) etc. sollte das machen, unabhängig davon, ob man das Telegramm braucht. Es geht darum, dass es gültig empfangen wurde (sobald wenigstens ein Empfänger das ACK schickt ist sowieso egal wie viele weitere Empfänger die Bestätigung senden).

@Makki: Was hat das denn mit der Anzahl der empfangenen GAs zu tun?

[enertegus]

Der EibPC ACKed? energetus möge mich aufklären, wenn ich was verpasst habe?!
Das wäre gut, weil es einfach das Problem löst..

Der Gruppenmonitormodus (wie wir ihn beim EibPC genannt haben) macht ein ACK einfach auf alles - wie etwa auch ein IP Router oder Lienenkoppler oder Verstärker. Das hatte ich gemeint. Am Ende sieht man keinerlei Telegramm mehr 3-fach. Mit Übertragungssicherheit hat das natürlich nix zu tun.

Ich will jetzt keine Werbung machen, aber genau deshalb - mich selbst hat das mitm HS monatelang ausgebremst - ACKed das WG in seiner Funktion als IP-LK/BK alle Gruppentelegramme seit jeher (macht jetzt auch der offizielle eibd mit Kommandozeilen-Option);

Ja das ist genau was der EibPC seit der Einführung dieses FT12. Modus (ca. 02/2010) auch schon macht. Wenn er an eine IP Schnittstelle angeschlossen ist, macht die das von sich aus - die arbeiten quasi a priori im Gruppenmonitormodus.

[saft6luck]

Mit Übertragungssicherheit hat das natürlich nix zu tun.

Das ist natürlich immer noch eine Frage der Übertragungssicherheit! Die Sicherungsschicht ist ja schon auf Schnittstellenseite implementierbar.

Was du ausschließen kannst ist, dass man auch sicher sagen kann, ob der eigentliche Empfänger das Telegramm auch bekommen hat oder nicht. Hier gilt: wenn keiner ein NACK schickt, wird wohl die Übertragung erfolgreich gewesen sein, oder der Empfänger ist nicht erreichbar. Das ist alles aber sowieso nur interessant, wenn es nur einen Empfänger gibt.

Oder anders ausgedrückt: die Wahrscheinlichkeit, dass ein fehlerhafter Empfang mit einem NACK bestätigt wird ist extrem viel höher, als dass ein Teilnehmer nicht erreichbar ist/war und der nun die Telegrammwiederholung doch erhält. Insbesondere bei mehreren Empfängern ist das dann sowieso wieder irrelevant.

Um diesen Fehler abzusichern bräuchte es individuelle ACKs und der Sender müsste alle Empfänger kennen. (Oder man sendet gleich alle Telegramme x-mal, IMHO alles Unfug)

[MarkusS]

Es ist ggf. durchaus legitim, einen Baustein einzusetzen der in einer Linie alle Telegramme ACKt - speziell in Konstrukten mit mehreren Linien. Man kann sich sowas fertig kaufen EIB-Ack-Baustein oder aus einer übrigen BCU1 - mit dem richtigen Werkzeug - selber basteln.

Ich denke dass viele der Leute die schon "länger" dabei sind solche ACK-Bausteine haben, zu einer anderen Zeit in einem anderen Forum wurden die mehrfach diskutiert und es gab da jemanden der BCU1 auf Anfrage umprogrammiert hat.

Mittlerweile gibts die fertig zu kaufen, siehe o.a. Link, damals war das noch nicht so.

Was den HS betrifft: Ich meine dass der mit einer FT1.2/BCU2 durchaus ACKen sollte wenn die FT1.2 nicht im Kompatibilitätsmodus betrieben wird.

[Gaston]

Nicht das das in der Praxis nicht wunderbar funktionieren würde, was ich damit sagen will ist lediglich, das die ACK's IMHO eh nur fürs Auge sind und wenn sie fehlen eben ein grosses Ärgerniss ohne grossen Nutzen.

Das sehe ich anders. Ich vergleiche ACKs auf dem EIB gerne mit Leitungsschutz in der Elektrik.

Leute sehen den Leitungsschutz gerne als "Sicherung" gegen schäden an den angeschlossennen Geräten oder gar Stromschlag. In Wirklichkeit ist er ja aber nur als Schutz der Leitungen ausgelegt.

Genauso verhält es sich beim ACK, er dient nicht des Schutzes der P2P Kommunikation sondern sozusagen der "Leitung". Ein ACK bedeutet also dass das Packet wohl richtig auf der Leitung gewesen sein muss. Dass jemand das Packet nicht mitbekommen at besagt es eben nicht. Obwohl ja noch immer doie Möglichkeit besteht explizit, wenn die Gruppenadresse erkannt wurde, das ACK mit einem NACK zu "überschreiben".

Gruss,
Gaston

[makki]

Natürlich habt ihr alle Recht (bis auf saft.., zumindest teilw.)

Was ich ausdrücken wollte (und was ja die Frage war): fehlende ACK's sind in modernen KNX-Kleinstinstallationen ohne LK IMHO ein ständiges Ärgerniss, solange nicht einfach irgendjemand in der Linie einfach "blöde" ACKed. NACK sind ein anderes Thema IMHO (denn dann ist richtig was im argen in kleinen Installationen) aber egal..

Ob es der HS tut werd ich nochmal prüfen (ich glaube nicht, aber diese Meinung ist 2J alt mit einer damals verhunzten Installation..)
-> die FT1.2-Specs, wie das geht, würde mich aber brennend interessieren - und ansonsten gilt das die BCU selbst (ohne Löterei) nur Acked, was in der Adresstabelle steht - und das sind maximal eben um die 250 GA's..

Makki

[saft6luck]

Natürlich habt ihr alle Recht (bis auf saft.., zumindest teilw.)

LOL

Was ich ausdrücken wollte (und was ja die Frage war): fehlende ACK's sind in modernen KNX-Kleinstinstallationen ohne LK IMHO ein ständiges Ärgerniss, solange nicht einfach irgendjemand in der Linie einfach "blöde" ACKed.

Es gibt kein blödes ACK: wenn ACK -> Telegramm richtig empfangen.

NACK sind ein anderes Thema IMHO (denn dann ist richtig was im argen in kleinen Installationen) aber egal..

Der Logik folgt ja auch der von dir als "blöde" bezeichnete ACK. Nur sind NACK durchaus möglich, denn ein Störer in der Küche muss nicht notwendigerweise im Wohnzimmer sichtbar sein.

und ansonsten gilt das die BCU selbst (ohne Löterei) nur Acked, was in der Adresstabelle steht - und das sind maximal eben um die 250 GA's..

Du meinst also die BCU der USB-Schnittstelle (?) bzw. wer trägt die da ein? Und vorher war doch von manuell die Rede??? Wird das auch gefiltert???

[MarkusS]

Ob es der HS tut werd ich nochmal prüfen (ich glaube nicht, aber diese Meinung ist 2J alt mit einer damals verhunzten Installation..)
-> die FT1.2-Specs, wie das geht, würde mich aber brennend interessieren - und ansonsten gilt das die BCU selbst (ohne Löterei) nur Acked, was in der Adresstabelle steht - und das sind maximal eben um die 250 GA's..

Da KNX-Professionals Deutschland e.V. Forum - Einzelnen Beitrag anzeigen - Telegramme gibt es eine dsbzgl. Aussage von Dacom. Ich gehe davon aus dass das nachträglich nicht mehr geändert wurde.