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

[StefanW]

Hallo Yves,

aber es sind schon andere KNX Geräte in der lokalen TP-Linie?

Die (offenbar fehlenden) ACKs sind von anderen KNX Geräten zu senden. Der TWS kann nicht die von ihm ausgehenden Telegramme selbst acknowledgen.

Der TWS würde dann einen Fehler machen, wenn ein anderes Gerät das ACK sendet und der TWS trotzdem die Pakete wiederholen würde. Wenn das passiert, dann bitte eine Busaufzeichnung geben.

In den Busaufzeichnungen - im von Dir verlinkten Thread - ist zu sehen, dass niemand dem TWS ein ACK sendet. Das können wir dann auch nicht ändern, der TWS verhält sich konform zum Standard.

lg

Stefan

[gbglace]

Ja da muss man unterscheiden.
Ist ein an den TWS-(nativ) angeschlossenes Zusatzsystem angebunden und via den internen Logiken des TWS und des DOS wird ein Telegramm auf den KNX-Bus gesendet, dann ist der TWS ganz klar der Absender und es kann der TWS kein ACK senden. Ist der Empfänger des Telegramms ein Gerät/System in einem Docker welcher auf dem TWS oder einem anderen Rechner läuft aber einen Tunnel vom TWS verwendet, so wäre ein ACK zu erwarten. Fehlende ACK sind dann aber im annehmenden System zu suchen, da im IP-Traffic die Art der Telegramme wohl egal sein sollte und somit der TWS unschuldig.

Kommt eine GA von einem auf dem TWS oder anderem Rechner gehosteten Docker durch einen TWS-Tunnel auf den KNX-Bus und der TWS mit seinem Logikeditor oder eine Timeserie aus einem programmierten KNX-Objekt, dann sollte auch hier ein ACK vom TWS gesendet werden. Gleiches gilt natürlich wenn direkt vom TP-Bussegment ein Telegramm auf ein TWS-KO trifft und es das einzige / erste Empfänger-KO ist.

[Eraser]

Ja so habe ich das auch verstanden.

Die PA 1.0.100 kann nicht Telegramme von der gleichen PA 1.0.100 ACKen, das wäre idiotisch.

Aber, Telegramme von PA 1.0.101 (Docker-Edomi/NodeRed/usw.) sollten vom TW 1.0.100 ACKed werden.
Dies gilt natürlich auch umgekehrt.

Aus KNX-Sicht sind der TW und die Docker-Instanz verschiedene Geräte mit verschiedenen PA's oder nicht?

Edit: Oder sind bei uns irgendwelche KNX-Schnittstellen-Einstellungen im TW anders als bei Elabnet, sodass deswegen dies nicht von euch nachgestellt werden kann?

[starwarsfan]

Hallo Stefan

aber es sind schon andere KNX Geräte in der lokalen TP-Linie?

Was genau meinst Du mit "lokaler" TP-Linie? Ich nehme an, das "grüne Kabel", mit welchem der TW an meiner KNX-Installation hängt? Wenn ja, dann ja.

Die (offenbar fehlenden) ACKs sind von anderen KNX Geräten zu senden. Der TWS kann nicht die von ihm ausgehenden Telegramme selbst acknowledgen.

Klar, macht Sinn. Damit deutet das auf einen Bug sowohl bei Edomi als auch bei Node-Red hin.

In den Busaufzeichnungen - im von Dir verlinkten Thread - ist zu sehen, dass niemand dem TWS ein ACK sendet. Das können wir dann auch nicht ändern, der TWS verhält sich konform zum Standard.

Ok, verstanden. Die ACKs müssen also von den Geräten verschickt werden, welche auf die entsprechende GA "hören", korrekt? Da das in dem Fall Node-Red bzw. Edomi sind und keine anderen Geräte, fehlt das ACK.

[Eraser]

Die ACKs müssen also von den Geräten verschickt werden, welche auf die entsprechende GA "hören", korrekt? Da das in dem Fall Node-Red bzw. Edomi sind und keine anderen Geräte, fehlt das ACK.

Ja das ist korrekt.

Aber es ist auch umgekehrt so:
NodeRed sendet auf die GA, der TW hört zu, aber es kommen trotzdem 4 Telegramme.
Das würde dann heißen, dass der TW als hörendes Gerät entweder auch nicht mit ACK antwortet oder NodeRed die ACK nicht auswertet.

[StefanW]

Hallo Wolfgang und Yves,

danke für die Rückmeldungen. Ich fasse zusammen, was ich verstanden habe:

Das beobachtete Verhalten mit den Telegrammwiederholungen tritt auf bei:

1. Nutzung von NodeRed, Edomi laufend im Docker Container auf dem TWS oder der ETS auf einem Windows PC ("externe Programme")
2. Diese "externen Programme" nutzen KNXnet/IP Tunneling Connections des Timberwolf Servers
3. Die Telegramme gehen von diesen "externen Programmen" aus und sind an GAs adressiert, die AUSSCHLIEßLICH mit KNX-Objekten auf dem KNX-Stack des Timberwolf Servers assoziert sind
4. oder umgekehrt, die Telegramme gehen vom Timberwolf Server aus und sind an GAs adressiert, die AUSSCHLIEßLICH von der "externen Software" genutzt werden.
5. Auch ReadRequests von "externen Programmen" werden wiederholt, ebenfalls die Antwort auf den ReadRequest

Das beobachtete Verhalten mit den Telegrammwiederholungen tritt NICHT auf bei:

1. Wenn eines der "externen Programme" auf eine GA schreibt, die (auch) mit einem KNX Objekt eines anderen KNX Gerätes am gleichen TP-Bus verbunden ist, tritt die Telegrammwiederholung NICHT auf
2. Bei uns im Labor und auch bei Juri lässt sich das Verhalten beim einem Write von ETS bze. NodeRed via Tunnel NICHT beobachten

==> Habe ich damit alle Beobachtungen aus dem Thread richtig zusammen gefasst?


lg

Stefan

[Eraser]

Ja von meiner Seite aus (mit NodeRed im TW-Container), ist dies so richtig zusammengefasst.

Es schaut so aus, als ob das Problem nur bei Tunnel zu Tunnel besteht.

[StefanW]

Hallo Wolfgang,

Es schaut so aus, als ob das Problem nur bei Tunnel zu Tunnel besteht.

Tunnel-zu-Tunnel verstehe ich nicht??

Stefan

[gbglace]

Tunnel zu Tunnel wäre ja wieder was anderes (Nodered zu EDOMI oder Nodered zu OpenHab und beides via KNX und alle Tunnel via TWS).
Ihr macht es den Jungs schon nicht leicht.

Der TWS selbst mit seinem eigenen Innenleben ist keine Tunnelverbindung, sondern der TWS ist da ein eigenständiges KNX-TP Gerät.

@StefanW
Als echtes Problem ist die Richtung Telegramm aus Nodered via TWS-Tunnel an KNX-TP TWS-KO only. Die Gegenrichtung kann auch ein Fehler bei Nodered/Edomi sein. Oder es besteht wirklich ein Problem mit den Systemtelegrammen durch einen TWS-Tunnel.
Deine Zusammenfassung stimmt soweit, was man untersuchen kann.

Vielleicht baue ich mir so eine Konstellation auch nochmal um das zu testen mit Nodered.

[Eraser]

Ich war der Meinung dass der TW auch einen Tunnel nutzt (so auf die Art den Haupttunnel).
War dann falsch formuliert, TW auf Tunnel statt Tunnel auf Tunnel wäre dann richtig.