UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

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

Diskussionen über die KNX-Funktionen im Timberwolf Server
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
Benutzeravatar

Ersteller
Eraser
Reactions:
Beiträge: 646
Registriert: So Aug 12, 2018 1:51 pm
Wohnort: Amstetten, Österreich
Hat sich bedankt: 205 Mal
Danksagung erhalten: 275 Mal

#91

Beitrag von Eraser »

Mir ist da auch etwas nicht klar:
StefanW hat geschrieben: Di Nov 03, 2020 10:46 pm ALLE Chips der 2. TP-UART Generation erzeugen die LL-ACKs bzw. bei deren Ausbleiben die Telegrammwiederholungen SELBSTTÄTIG bei allen PA-zu-GA Telegrammen. Das passiert also schon im Chip, nicht in Software im Stack.
Es wird dabei auf ALLE PA-zu-GA Telegramme reagiert, UNABHÄNGIG davon, ob eine GA auf ein Objekt bei dem mit einem solchen Chip gebauten KNX Gerät assoziert ist.
Das heißt dann also, dass so ein neuer Chip, wie er in allen ausgelieferten TW verbaut ist, automatisch alle Telegramme von extern kommend bestätigt?
Theoretisch würde es dann ja gar keine Telegrammwiederholungen mehr geben, wenn das Telegramm nicht von einem Tunnel kommt oder?
StefanW hat geschrieben: Di Nov 03, 2020 10:46 pm Alle PA-zu-PA-Telegramme werden vom KNX-Stack (bei uns im Co-Prozessor) acknowledged
PA zu PA wäre dann eine Geräte-Programmierung oder?
gbglace hat geschrieben: Mi Nov 04, 2020 4:04 am Wenn dem wirklich so ist, das der TP-UART Chip auch die Tunnel-PA Telegramme als seine eigenen erkennt und ACK unterdrückt, dann wäre ja im Umkehrschluss die Verfügbarkeit von 25 Tunnel am TWS eher kontraproduktiv, da alles darüber angeschlossene mit GA Ziel anderer Tunnel oder TWS selbst zu enormer Buslast führt.
Das geht mir auch durch den Kopf, da theoretisch dann alle nur mit dem TW verknüpften Telegramme von Containern, IP-Geräten, der ETS oder sonstigen "Devices" welche einen Tunnel des TW verwenden, automatisch immer 4-fach gesendet werden.
mfg
Wolfgang

Timberwolf 2500 #151 / VPN offen / Reboot nach Rücksprache
+ PBM #938

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7632 Mal
Kontaktdaten:

#92

Beitrag von StefanW »

Hallo Göran & Wolfgang,
gbglace hat geschrieben: Mi Nov 04, 2020 4:04 amDas musste ich jetzt mehrfach lesen.
Sorry, wenn ich es schlecht beschrieben habe

gbglace hat geschrieben: Mi Nov 04, 2020 4:04 amDann jetzt noch eine Frage, sofern du das Innenleben des TP-UART Chip kennst, wie denn der Chip erkennt das Telegramme auf dem Bus seine eigenen sind?
Der Chip hat sowohl Sender als auch Empfänger parallel auf dem Bus. Damit "sieht" der Empfänger, was jeder (auch der eigene) Sender auf den Bus schreibt. Damit kann die interne Chip-Logik jedes empfangene Bit im Empfangspuffer vergleichen mit den Bits die sich im Sendepuffer befinden. Sind beide Puffer gleich dann hat der Chip das Paket selbst auf den Bus gegeben.

Das ist vergleichbar mit einem Rundfunksender, bei dem der Tontechniker mit einem Radioempfänger die eigene Ausstrahlung checkt.

gbglace hat geschrieben: Mi Nov 04, 2020 4:04 amDenn meine Annahme wäre bisher gewesen, das der TP-UART Chip als PA nur die des TWS Host kennt und die daran angedockten KO und GA Verlinkungen, um effektiv ACK zu produzieren.
Das selbständige Acknowlege macht er nur für den Typ "PA-zu-GA" Telegramm.

Bei "PA-zu-PA" Telegramm sendet unser KNX-Koprozessor das ACK, weil im TP-UART passen nicht alle 25 PAs des TWS rein.

gbglace hat geschrieben: Mi Nov 04, 2020 4:04 amKennt er hingegen auch alle Tunnel-PA als seine eigenen, würde dies zwar die Unterdrückung des ACK bei Wolfgang seinem Problem erklären
Es handelt sich hier um "PA-zu-GA" Telegrammen (letztlich einem Multicast an eine Gruppe). Diese werden von TP-UART2-Chips GRUNDSÄTZLICH acknowledged. EGAL von welcher PA und egal ob die GA überhaupt mit einem lokalen Objekt assoziiert ist. Ausnahme: Das Paket wurde vom Chip selbst auf den Bus gelegt.
gbglace hat geschrieben: Mi Nov 04, 2020 4:04 amda er die hinter dem Tunnel assoziierten GA nicht kennen kann und somit nicht in der Lage ist selbständig ein ACK zu senden, was ja nur ein Stack im Container selbst entscheiden kann (Taster am TP an EDOMI im Container).
Doch, JEDER am Bus angeschlossene TP-UART2 acknowledged einfach JEDES "PA-zu-GA" Telegramm.

Hinweis: Dieses Default Acknowledge-Verhalten des Chips lässt sich laut Datenblatt auch abschalten. Es könnte in anderen Produkten auch anders laufen.

gbglace hat geschrieben: Mi Nov 04, 2020 4:04 amWenn dem wirklich so ist, das der TP-UART Chip auch die Tunnel-PA Telegramme als seine eigenen erkennt und ACK unterdrückt, dann wäre ja im Umkehrschluss die Verfügbarkeit von 25 Tunnel am TWS eher kontraproduktiv, da alles darüber angeschlossene mit GA Ziel anderer Tunnel oder TWS selbst zu enormer Buslast führt.
Eine KNX-TP Linie besteht mindestens aus zwei TP-Geräten (plus der Spannungsversorgung). Wenn nun eines davon ein IP Interface ist und einen eigenen Stack hat (wie der Timberwolf Server) dann liegt es an dem anderen KNX Gerät den ACK zu generieren. Im Normalfall sind eher Dutzende KNX Geräte angeschlossen. Die TP-UART2 werden mindestens seit 2013 angeboten. Normalerweise hat man wenigstens ein KNX Gerät im System, das einen solchen Chip hat und alle "PA-zu-GA" Telegramme acknowledged.

Eraser hat geschrieben: Mi Nov 04, 2020 6:24 amDas heißt dann also, dass so ein neuer Chip, wie er in allen ausgelieferten TW verbaut ist, automatisch alle Telegramme von extern kommend bestätigt?
Nicht alle, sondern nur "Gruppentelegramme" also von einer beliebigen PA an eine beliebige GA.

(Die PA-zu-PA-Telegramme werden vom CoProzessor betätigt)

Eraser hat geschrieben: Mi Nov 04, 2020 6:24 amTheoretisch würde es dann ja gar keine Telegrammwiederholungen mehr geben, wenn das Telegramm nicht von einem Tunnel kommt oder?
Im Prinzip Ja (sofern es keine Kommunikationsfehler gibt). Darum geht es ja, unnötige Telegrammwiederholungen zu vermeiden. Dadurch, das das ACK im Chip produziert wird, wird es auch schneller gesendet, womit der Bus schneller frei ist.

Eraser hat geschrieben: Mi Nov 04, 2020 6:24 amPA zu PA wäre dann eine Geräte-Programmierung oder?
Richtig. Typischerweise von der ETS zum KNX-Gerät.

Eraser hat geschrieben: Mi Nov 04, 2020 6:24 amDas geht mir auch durch den Kopf, da theoretisch dann alle nur mit dem TW verknüpften Telegramme von Containern, IP-Geräten, der ETS oder sonstigen "Devices" welche einen Tunnel des TW verwenden, automatisch immer 4-fach gesendet werden.
Wie gesagt, sehr theoretisch, weil normalerweise wird ein KNX-TP Bus auch als solcher betrieben, also mit dutzenden KNX-Geräten an der gleichen Linie, die sich untereinander unterhalten und die dann auch für die aus dem Tunnel kommenden Telegramme den ACK auslösen. Daher tritt es ja auch im Labor und bei Robert_Mini nicht auf. Wir hören von dem Problem auch nur in Deinem Fall, daher ist das nicht wirklich kein typisches Szenario.

Für die Kommunikation mit dem TWS wird es dann ohnehin demnächst eine MQTT-Schnittstelle geben, die einen hundertfach höheren Durchsatz ermöglicht, ohne über den langsamen KNX-TP gehen zu müssen.


lg

Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.
Benutzeravatar

Ersteller
Eraser
Reactions:
Beiträge: 646
Registriert: So Aug 12, 2018 1:51 pm
Wohnort: Amstetten, Österreich
Hat sich bedankt: 205 Mal
Danksagung erhalten: 275 Mal

#93

Beitrag von Eraser »

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

Timberwolf 2500 #151 / VPN offen / Reboot nach Rücksprache
+ PBM #938

Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

#94

Beitrag von Robert_Mini »

Hallo zusammen!

Beim schnellen Mitlesen ist mir das etwas Zuviel.
Was ich aber nicht verstehe: Warum hab ich das Problem nicht?

=> Hab ich es nicht oder sehe ich sie nicht? Weder mit Telegrammen von NodeRed oder WG-Container am TWS.
Wobei ich mit Bus- und Gruppenmonitor und TWS-Busmonitor nachgesehen habe.

Ich habe aber keinen Linienkoppler und nur den TWS als Schnittstelle im Einsatz (plus das WG am TPUART).
Ich könnte mir der ETS auch noch über eine USB-Schnittstelle nachsehen - bringt das was?

lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297
Benutzeravatar

Ersteller
Eraser
Reactions:
Beiträge: 646
Registriert: So Aug 12, 2018 1:51 pm
Wohnort: Amstetten, Österreich
Hat sich bedankt: 205 Mal
Danksagung erhalten: 275 Mal

#95

Beitrag von Eraser »

Bei dir wird es höchstwahrscheinlich so sein, dass du irgendwo auf deiner KNX-Linie ein Gerät mit neuem Chip schon hast (außer dem TW), sodass sowieso alle PA-zu-GA-Telegramme bestätigt werden.
mfg
Wolfgang

Timberwolf 2500 #151 / VPN offen / Reboot nach Rücksprache
+ PBM #938
Benutzeravatar

Ersteller
Eraser
Reactions:
Beiträge: 646
Registriert: So Aug 12, 2018 1:51 pm
Wohnort: Amstetten, Österreich
Hat sich bedankt: 205 Mal
Danksagung erhalten: 275 Mal

#96

Beitrag von Eraser »

starwarsfan hat geschrieben: Sa Okt 31, 2020 3:11 pm ETS Gruppenmonitor laufen lassen, Timberwolf Busmonitor ebenfalls und dann Finger über den Scanner.
Im TW-Busmonitor sieht das so aus ...
Im ETS-Gruppenmonitor jedoch so ...
Dort kommt also offenbar nur ein Telegram an. Damit bin ich jetzt völlig verwirrt und habe den Faden verloren...
@starwarsfan
du hast das gleiche Symptom wie bei mir, kein anderes Gerät bestätigt die Telegramme und der TW kann sie nicht bestätigen, weil sie von ihm sind.
Die unterschiedlichen Anzeigen bei dir resultieren daraus, dass der TW-KNX-Busmonitor auch die wiederholten Telegramme anzeigt, der Gruppenmonitor der ETS hingegen nur das erste. Wenn du stattdessen den Busmonitor an der ETS beobachten würdest, dann kriegst du dort auch die 4 Telegramme angezeigt.
mfg
Wolfgang

Timberwolf 2500 #151 / VPN offen / Reboot nach Rücksprache
+ PBM #938
Benutzeravatar

Ersteller
Eraser
Reactions:
Beiträge: 646
Registriert: So Aug 12, 2018 1:51 pm
Wohnort: Amstetten, Österreich
Hat sich bedankt: 205 Mal
Danksagung erhalten: 275 Mal

#97

Beitrag von Eraser »

Zusatz:
starwarsfan hat geschrieben: Sa Okt 31, 2020 2:59 pm Meine Edomi Instanz läuft als LXC-Container auf einem ProxMox-Cluster. Alles andere passt aber soweit.
Läuft dieser ProxMox-Cluster auf dem TW oder auf einer gänzlich anderen Hardware?

-) Wenn am TW, dann stimmt meine Aussage oben, dass wir das gleiche Problem haben.
-) Wenn auf einer separaten Hardware, aber verwendet einen Tunnel vom TW, dann stimmt die Aussage auch.
-) Wenn auf einer separaten Hardware und kein Tunnel vom TW, dann ist da wo der Wurm drin und das Edomi-Gerät sendet kein ACK.
mfg
Wolfgang

Timberwolf 2500 #151 / VPN offen / Reboot nach Rücksprache
+ PBM #938
Benutzeravatar

starwarsfan
Reactions:
Beiträge: 1152
Registriert: Mi Okt 10, 2018 2:39 pm
Hat sich bedankt: 744 Mal
Danksagung erhalten: 923 Mal

#98

Beitrag von starwarsfan »

Hi
Eraser hat geschrieben: Mi Nov 04, 2020 2:36 pm Läuft dieser ProxMox-Cluster auf dem TW oder auf einer gänzlich anderen Hardware?
Proxmox-Cluster heißt in dem Fall wirklich Cluster auf separater Hardware. Konkret zwei HP ProLiant DL380p Gen8 Server, auf welchen all meine Container laufen. Unter anderem auch Edomi. Verbindung zum KNX-Bus über den TW.
Kind regards,
Yves

- TWS 2500 ID:159 (VPN offen, Reboot nach Rücksprache) - PBM ID:401 - TWS 3500 ID:618 (VPN offen, Reboot nach Rücksprache) - ControlPro - ProxMox - Edomi (LXC / Docker) - ... -
Benutzeravatar

Ersteller
Eraser
Reactions:
Beiträge: 646
Registriert: So Aug 12, 2018 1:51 pm
Wohnort: Amstetten, Österreich
Hat sich bedankt: 205 Mal
Danksagung erhalten: 275 Mal

#99

Beitrag von Eraser »

OK dann ist es klar, warum du auch die Telegrammwiederholung hast so wie ich.
mfg
Wolfgang

Timberwolf 2500 #151 / VPN offen / Reboot nach Rücksprache
+ PBM #938

Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

#100

Beitrag von Robert_Mini »

Eraser hat geschrieben: Mi Nov 04, 2020 2:28 pm Bei dir wird es höchstwahrscheinlich so sein, dass du irgendwo auf deiner KNX-Linie ein Gerät mit neuem Chip schon hast (außer dem TW), sodass sowieso alle PA-zu-GA-Telegramme bestätigt werden.
Ehrlich gesagt - keine Ahnung. Meine KNX Basis ist 10 Jahre alt, allerdings sind später noch ein paar Aktoren dazugekommen (zB MDT Wetterstation und MDT Analogaktor).

Finde ich irgendwie in der ETS heraus, welche Geräte welchen Chip haben?

lg
Robert
Zuletzt geändert von Robert_Mini am Mi Nov 04, 2020 9:17 pm, insgesamt 1-mal geändert.
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297
Antworten

Zurück zu „KNX“