[Frage] [V1.6.0 RC 6] Kein KNX-ACK-Telegramm bei Node-Red zu TW

[gbglace]

Hänge einfach Mal nen Taster an den Bus mit neuen nur einseitigen GA Verknüpfungen, und das gernmal an unterschiedlichen Stellen der grünen Leitung, wenn noch irgendein anderes Gerät mit einem der neuen Chips und der aktiven Option Auto-ACK am Bus ist dann sollte man das via Busmonitor sehen ob so ein ACK auch mal von einem anderen Teilnehmer als dem TWS kommt, oder Mal während einer update-Pause den TWS auch vom Bus nehmen und ein bissel auf dem Taster klicken, die ETS dann halt via USB mit horchen lassen.

@StefanW das schwere Lesen war da eher der Uhrzeit geschuldet.
Dieses Auto-ACK, warum hat man sich das ausgedacht? Mit solchen Geräten im Bus bekommt man ja in der Diagnose nur noch eine Aussage darüber, dass ein Telegramm im direkt angeschlossenen oder folgenden TP-Liniensegment angekommen ist, eine Aussage das mindestens eines derer Geräte zu denen die GA wirklich assoziiert ist das Telegramm wirklich erhalten hat gibt es nicht mehr.

Find ich spannend was da der Vorteil von sein soll.

Wenn es da so eine Abschaltoption gibt, denke ich das viele die wohl nutzen. Die Telegrammwiederholungen bei nur einseitig verbundenen GA sind im KNX-UF auch immer Mal Thema. Und das hier alle Hersteller noch mit den alten Chips hantieren kann ich mir kaum vorstellen (Ausnahme Merten wo meine Taster auch sind, die stellen jetzt auch erst auf TP256 Bauteile um).

[Eraser]

Das wäre interessant ja...

[StefanW]

Hallo zusammen,

Das ist interessant, das würde dann bedeuten, dass alle meine KNX-Geräte vom Jahr 2016 einen alten Chip benutzen.

Der TP-UART2 Chip hat ein anderes Gehäuseformat, in älteren Schaltungen konnte man das womöglich nicht ohne weiteres ersetzen. Es kommt vermutlich nicht darauf an, wann ein Gerät verkauft wurde, sondern wann es entwickelt wurde.

Was ich aber nicht verstehe: Warum hab ich das Problem nicht?

Ich würde annehmen, dass nur wenige Installation diese Besonderheit aufweisen, weil zumeist dürfte es ein moderneres KNX-Gerät geben, welches in der Lage ist, das sogenannte "non-selective Data-Link Layer acknowledge" (das ist das grundsätzliche ACKnowlege auf ALLE Multicast Gruppentelegramme "PA-zu-GA") zu senden, wie es z.B. der TP-UART2 Chip von Haus aus kann (oder ein Stack auch dürfte).

Wegen des im Timberwolf Server eingebauten Busmonitors wäre es schon längst aufgefallen, wenn es sehr häufig anders wäre.

=> Hab ich es nicht oder sehe ich sie nicht? .... Wobei ich mit Bus- und Gruppenmonitor und TWS-Busmonitor nachgesehen habe.

Dann hast Du es sehr vermutlich nicht.

Dieses Auto-ACK, warum hat man sich das ausgedacht?

Der Standard wird permanent verbessert. Die Menge an Änderungen ist groß, daher verhalten sich neuere Geräte auch leicht unterschiedlich zu älteren, wobei stets Abwärtskompatibilität gewahrt wird. Bei einem Kunden von uns läuft eine Anlage mit KNX Komponenten, die wurden zuletzt mit einer ETS 1.3 programmiert (dann ist das Projekt verloren gegangen, der TWS mit neuester KNX Technologie läuft dort auch). Derzeit sind wir bei KNX Standard V2.1.4

Warum man sich genau entschlossen hat, kann ich nicht sagen und habe es auch nach Lesen von 20 Standard-Dokumenten nicht in einem glasklaren Statement gefunden, nur dass es so ist.

Mit solchen Geräten im Bus bekommt man ja in der Diagnose nur noch eine Aussage darüber, dass ein Telegramm im direkt angeschlossenen oder folgenden TP-Liniensegment angekommen ist, eine Aussage das mindestens eines derer Geräte zu denen die GA wirklich assoziiert ist das Telegramm wirklich erhalten hat gibt es nicht mehr.

Das gab es ohnehin nie bei Gruppentelegrammen ("PA-zu-GA"). Das ist letztlich ein Multicast und der könnte ja auch 65.000 Empfänger haben (nehmen wir eine Zentralfunktion, die auf jedes Gerät gemappt wurde, z.B. ein Zeittelegramm). Es würde viel zu lange dauern, von allen diesen Empfängern eine Rückmeldung zu bekommen und diese auch noch auszuwerten.

Bitte auch daran denken, dass die KNX Geräte überwiegend einfache 8 Bit Microprozessoren beinhalten.

Find ich spannend was da der Vorteil von sein soll.

In einem Segment sind alle KNX Geräte an gleichen physikalischen Medium angeschlossen. Der maximale Abstand zwischen zwei Geräten darf dabei 700m betragen. Die elektrischen Signale breiten sich mit ca. 2/3 der Lichtgeschwindigkeit aus, mithin breitet sich jedes elektrische Signal binnen 3,5 µs zwischen zwei Teilnehmern aus.

Diejenigen KNX Geräte, die ein ACK senden, sollen dies binnen "15 Bit times" tun, mit einer Toleranz von - 5 µs bis + 30 µs*.

Wie gesagt, das läuft mit 2/3 der Lichtgeschwindigkeit, das ist gegenüber den 9600 Baud wirklich schweineschnell. Die elektrische Signalausbreitung ist Wirklich WESENTLICH schneller als jedes KNX-Kommunikation und auch schneller als ein ACK-Telegramm. Da ALLE KNX-Geräte an den selben beiden Kupferadern hängen, bekommen auch ALLE die gleichen elektrischen Signale.

Wenn also ein Empfänger das Telegramm als gültig bewertet (Teile des Frame, Übereinstimmung des Inhaltes mit der Prüfsumme) dann wurde es mit Sicherheit auch für alle anderen KNX Geräte störungsfrei auf dem Bus übertragen. Insofern kann IRGENDEIN KNX-Gerät in diesem Segment die eine Bestätigung senden, weil dies - stellvertretend für alle anderen - eben elektrisch gültig ist.

Im übrigen wird bei einem ACK gar nicht alles geprüft. Es wird zum Beispiel nicht geprüft, ob bestimmte Längeninformationen im Telegramm stimmen und es wird auch nicht geprüft, ob alle Geräte das Telegramm auch empfangen können.

==> Du hast nach dem Vorteil gefragt. Ich denke, je schneller ein ACK kommt, desto schneller kann das nächste Telegramm folgen. Insofern kann man mit einem schnellen ACK ein paar µs am Bus sparen pro Telegramm und der gesamte Durchsatz ist höher.


lg

Stefan

*Es gibt ein Draft von 2017, der eine Ausweitung der Toleranz vorschlägt, weil es wohl eine Implementierung gibt, die mit - 7µs schickt, also etwas zu schnell für den bisherigen Standard. Die neue Toleranz soll als von (15 Bit Times - 10 µs) bis (15 Bit Times + 30 µs) reichen, ist aber noch nicht abgesegnet nach meinen Info. Hinweis: Es ist beim dekodieren auch erlaubt, einen breiteren Toleranzbereich zu akzeptieren.

[gbglace]

Wenn also ein Empfänger das Telegramm als gültig bewertet (Teile des Frame, Übereinstimmung des Inhaltes mit der Prüfsumme) dann wurde es mit Sicherheit auch für alle anderen KNX Geräte störungsfrei auf dem Bus übertragen. Insofern kann IRGENDEIN KNX-Gerät in diesem Segment die eine Bestätigung senden, weil dies - stellvertretend für alle anderen - eben elektrisch gültig ist.

Ja mit der Herleitung und Schlussfolgerung macht das dann Sinn, das es egal ist welches Gerät antwortet. Ich will aber trotzdem mal prüfen ob das im sonstigen Bus auch so zu beobachten ist, dass die Absende-PA des ACK von einem Gerät kommt welches eigentlich nichts mit der GA zu tun hat.

[StefanW]

Hallo Göran,

Ja mit der Herleitung und Schlussfolgerung macht das dann Sinn, das es egal ist welches Gerät antwortet.

Ja. Weil das muss es auch, den bei dem Multicast (Gruppentelegramm) ist es gar NICHT möglich, dass JEDER Empfänger einer GA individuell antwortet. Darum kann auch jeder andere Empfänger die Bestätigung vornehmen.

==> Es geht schließlich NICHT darum den Empfang des Multicast zu quittieren, sondern nur, dass die Aussendung korrekt war.

Ich will aber trotzdem mal prüfen ob das im sonstigen Bus auch so zu beobachten ist, dass die Absende-PA des ACK von einem Gerät kommt welches eigentlich nichts mit der GA zu tun hat.

Ich glaube, ein ACKnowledge hat KEINE Absende-PA. Ich finde gerade die genaue Länge nicht, aber es ist wohl nur ein Byte.

Man bekommt also NIE heraus, wer es gesendet hat, wenn es nicht nur EIN weitere Gerät am Bus gibt.


Zusammenfassung: Der zertifizierte KNX Chip und der zertifizierte KNX-Stack des Timberwolf Servers tut genau wie er soll.

==> Wir werden prüfen, ob wir ein "ACK ALLES" einbauen DÜRFEN, auch für eigene Telegramme (aber ich bin hier nicht zuversichtlich, dass dies erlaubt ist.). Alternativ prüfen wir die Herstellung eines "Acknowledegers" als Zubehör.

lg

Stefan

[gbglace]

Wenn man selbst ACK senden dürfte dann wäre ja zu überlegen (trotz gewissen Zeitverzuges) das es nur gemacht wird, wenn das Telegramm aus einem Tunnel und nicht aus dem TWS-Gerät stammt. Also in etwa wie unsere bisherige Annahme war, das jeder Tunnel ein eigenes Gerät direkt am Bus und damit Chip ist.

Und eben das Phänomen der nur einseitig verbundenen GA das gibt ja auch immer Telegrammwiederholungen das muss ich mir definitiv Mal anschauen oder hat da Mal hier jemand aus dem Thread das nochmal getestet?

[StefanW]

Hallo Göran,

Wenn man selbst ACK senden dürfte dann wäre ja zu überlegen (trotz gewissen Zeitverzuges)

Es würde keinen Zeitverzug geben. Dafür haben wir ja eine technisch tolle Lösung mit dem selbst entwickelten KNX-CoProzessor, der alles zeitkritische erledigt, was der Chip nicht macht und wofür der Stack zu langsam sein könnte (was eher eine Vorsichtsmaßnahme als tatsächliches technisches Problem ist). Dieser KNX-Koprozessor erledigt jetzt u.a. die ACKnowledges der Tunnel-Unicasts ("directly addressed" "PA-zuPA"-Telegramme zu den Tunneln).

das es nur gemacht wird, wenn das Telegramm aus einem Tunnel

genau, der KNX-CoProzessor in den TWS sollte dann zusätzlich auch die Telegramme VON Tunnel zu TP acknowledgen. Aber da müssen wir echt erst prüfen, ob wir das dürfen.

Und eben das Phänomen der nur einseitig verbundenen GA das gibt ja auch immer Telegrammwiederholungen

Ansich gibt der Standard vor. dass alle "nicht direkt adressierten Telegramme", das sind alle Multicasts (also "PA-zu-GA"-Telegramme), jeweils zu acknowledgen sind.

Die Frage ist, warum tun die anderen Busteilnehmer das bei Wolfgang und Yves dann eigentlich nicht? Ist es wirklich, weil die - vom Entwicklungsstand her - zu alt sind?


Eine mögliche Lösung könnte eine separate Platine sein, die als "Acknowledger" dient. Wäre jetzt nicht so aufwändig. Könnte man in eine Verteilerplatte mit Blitzschutz und Aktivitätsanzeige (für Fehlersuche) integrieren.


lg

Stefan

[starwarsfan]

Hallo Stefan

Die Frage ist, warum tun die anderen Busteilnehmer das bei Wolfgang und Yves dann eigentlich nicht? Ist es wirklich, weil die - vom Entwicklungsstand her - zu alt sind?

Wir sind 2015 eingezogen, meine Geräte sind also alle so ca. fünf Jahre "alt". Aktuell sind ca. 80 Geräte in Betrieb. Wenn ich so überlege, dann ist das von der Entwicklung her "neueste" Gerät wahrscheinlich die Enertex 960 Spannungsversorgung.

[Eraser]

Bei mir wahrscheinlich auch

Oder die Glastaster 2 Smart.

[StefanW]

Guten Morgen,

ich habe versucht nachzuvollziehen, in welchen der sechs mir vorliegenden Standard-Version es zu der Änderung bezüglich des ACK-Verhaltens kam.

Im Standard V 2.0 von 2009 zu "KNX-TP1" steht (diesbezüglich):

If the remote Data Link Layer receives a Frame shall send an acknowledgement frame only in the following cases:

• if the Destination Address is an Individual Address and if it corresponds to the own Individual Address of the receiver, or
• if the Destination Address is a Standard Mode Group Address or an LTE-HEE Group Address and if the receiver supports the non-selective Data Link Layer acknowledge, or
• if the Destination Address is a Standard Mode Group Address that is contained in the Group Address Table of the receiver or an LTE-HEE Group Address addressing an Area that is assigned to the device, or
• if the Destination Address is the broadcast address.

If in any of these cases the request Frame received is not correct (see 2.5.3), the remote Data Link Layer shall send a NAK character. If the request Frame received is correct but the remote Data Link Layer does not have resources to process it, the remote Data Link Layer shall react as follows.

• If the Destination Address in the received Frame is a Group Address or the Broadcast Address or an Individual Address that is identical to the Individual Address of the device and if the device will again be able to process Frames within 100 ms after the reception of the original Frame 15), the remote Data Link Layer may send a BUSY character.
• If the Destination Address in the received Frame is a Group Address or the Broadcast Address or an Individual Address that is identical to the Individual Address of the device and if the device will not be able to process Frames within 100 ms after the reception of the original Frame, the remote Data Link Layer shall not send a BUSY character,.
• If the Destination Address is an Individual Address that is not identical to the Individual Address of the device, the remote Data Link Layer shall not send a BUSY character.

If the request Frame received is correct, the remote Data Link Layer shall send an ACK character.

Meinung: Das mit "and if the receiver supports the non-selective Data Link Layer acknowledge" ist sehr weich formuliert. Ich kann nicht sagen, wie das damals bei der Zertifizierung gehandhabt wurde, aber für mich liest sich das so, dass wenn ein Multicast (Gruppentelegramm, "PA-zu-GA") Telegramm bei einem nach dieser Vorschrift entwickeltem KNX Gerät eintrifft UND es sich nicht um eine GA handelt, die auf ein Objekt in diesem KNX-Gerät gebunden ist UND das Gerät den Fall "non-selective" (ich interpretiere das als "Gerät nicht direkt adressiert") nicht unterstützt, dann eben KEIN ACK sendet.

Oder kurz: Es war damals für die KNX Hersteller offenbar freiwillig, ob man das ACK auch bei Gruppentelegrammen sendet, die NICHT vom eigenen KNX Gerät unterstützt werden.


Im Standard V 2.1 vom 10. Dezember 2013 zu "KNX-TP1" steht dann (diesbezüglich):

The remote Data Link Layer shall check whether it is addressed or not.

The remote Data Link Layer is addressed in any of the following cases.

1. The Destination Address is an Individual Address
1.1 that corresponds to the own Individual Address of the remote Data Link Layer, or
1.2 that is topologically located on the other side of a Coupler, or
1.3 that is one of the Tunnelling Individual Addresses of a KNXnet/IP Tunnelling Server

2. The Destination Address is

• a Standard Mode Group Address or
• an LTE-HEE Group Address,

and the remote Data Link Layer supports the non-selective Data Link Layer acknowledge.

3. The Destination Address
3.1 is a Standard Mode Group Address that is contained in the Group Address Table of the receiver or
3.2 is an LTE-HEE Group Address addressing an Area that is assigned to the remote Data Link Layer.

4. The Destination Address is the broadcast address.


If the remote Data Link Layer is addressed then it shall confirm the Frame with an acknowledge-Frame.

• If the request Frame received is correct, the remote Data Link Layer shall send an ACK-Frame.
• If the request Frame received is correct but the remote Data Link Layer does not have resources to process it, the remote Data Link Layer shall react as follows:
  - If the Destination Address in the received Frame is a Group Address or the Broadcast Address or an Individual Address that is identical to the Individual Address of the device and if the device will again be able to process Frames that starts 100 ms after the reception of the original Frame 16), the remote Data Link Layer may send a BUSY character.
  - If the Destination Address in the received Frame is a Group Address or the Broadcast Address or an Individual Address that is identical to the Individual Address of the device and if the device will not be able to process Frames that starts 100 ms after the reception of the original Frame, the remote Data Link Layer shall not send a BUSY character.
• If the received Frame is correct but exceeds that reception capabilities of the remote Data Link Layer (buffer size) then the Frame may be acknowledged by an ACK-Frame or may not be acknowledged (recommended); the Frame shall not be acknowledged by a NAK-Frame or a BUSY-Frame; the Frame shall not be passed to the Data Link Layer user.
• If the received Frame is not correct (see above) then the remote Data Link Layer shall send NAK-acknowledge.

Mit Version 2.1 wurde die Beschreibung umfassender. Hier hat man nun die Koppler und IP Tunnel Server mit aufgezählt. Aber im Kern gab es gar keine Änderung am Standard selbst. Es bleibt auch hier bei der weichen Formulierung "and the remote Data Link Layer supports the non-selective Data Link Layer acknowledge."

Es ist mithin nicht zwingend.

Was sich letztlich geändert hat, ist, dass die TP_UART Chips der 2. Generation (so ab 2013) dieses Feature für "non-selective Data Link Layer acknowledge in Silicon" enthalten (wobei es abschaltbar ist). Davor hätte dies sonst der KNX Stack übernehmen müssen. Hinsichtlich des "erlaubten aber nicht notwendigen" Charakters dafür im Standard ist man wohl auf die Industrie und die damals - wie heute - verbreiteten einfachen Mikroprozessoren zugegangen.

==> Zusammenfassend: Es ist also auch mit dem aktuellen Standard freigestellt, ob die KNX-Geräte auf nicht direkt diese betreffende Gruppentelegramme (Multicast, "PA-zu-GA") ein ACK senden - oder nicht.

Damit ist es durchaus möglich, dass selbst bei vielen KNX-Geräten in einer Linie man nur solche hat, die dieses "non-selective Data Link Layer acknowledge" nicht unterstützen.

Wieder was gelernt.

==> Wir werden rausfinden, ob wir auch auf "eigene" Telegramme (die über einen Tunnel kommen) ein ACK senden dürfen.

==> Wer kurzfristig eine Lösung braucht: Mit unserem separaten TP-UART (an der gleichen Linie) sollte das ACK bewirkt werden.


lg

Stefan