KNX Data Secure Unterstützung
für KNX Logger und KNX Busmonitor

KNX Diagnose Monitor, Import des ETS Projektes deutlich beschleunigt, Suche in der Navigation
Mehr Informationen dazu hier im Forum

Insider Version 6 zur 4.5 jetzt für alle Mitglieder des Insider Clubs installierbar
Alle Infos zum Update im Timberwolf Wiki

[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

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

#51

Beitrag von StefanW »

Hallo Wolfgang,

der Timberwolf Server hat bezüglich KNX vier Grundfunktionen die weitestgehend unabhängig voneinander funktionieren:
  1. Logging auf KNX-TP (für TWS Busmonitor)
    SÄMTLICHE Telegramme, welche an einem der angeschlossenen KNX-TP Interfaces empfangen werden, werden in einem Ringspeicher gespeichert. Je nach verfügbarem Speicherplatz sind das mehrere hunderttausend bis mehrere Millionen Telegramme. Diese Funktion ist (fast) unabhängig von allen anderen Funktionen und kann für jedes Timberwolf TP Interface separat laufen. Damit kann man mehrere Linien aufzeichnen.
    Abhängigkeit: Sofern sich ein TP-Interface auch im "Applikationsmodus" befindet, ist nur eine Aufzeichnung von gültigen Telegrammen möglich (hier werden keine verstümmelten Telegramme aufgezeichnet und auch keine ACK / NACK / BUSY Signale).
  2. KNX Stack (Applikation - für das TWS Objkekt-System)
    Zunächst gelangen SÄMTLICHE Telegramme an den Stack. Dort wird zunächst geprüft, ob ein KNX Telegramm für die eigene PA oder für eine der GAs - die mit einem der KNX-Objekte durch die ETS assoziiert wurden - adressiert ist. Falls das Telegramm (auch) für diesen Stack bestimmt ist, wird es dekodiert und auf das Objektsystem des KNX-Stack kopiert (bzw. die Funktion ausgeführt, die damit verbunden ist bei ETS-Telegrammen zur Programmierung, Diagnose usw). Diese Funktion ist unabhängig von allen anderen. Die Zuordnung von GA zu Objekt wird durch die Programmierung mit der ETS bewirkt.
  3. KNXnet/IP Tunneling (für Verbindung via IP zum KNX-TP Bus)
    Diese Funktion ist weitestgehend technisch unabhängig von den anderen Funktionen. Hier werden - bis zu 25 gleichzeitige Tunnel-Verbindungen - über IP (Ethernet) bereitgestellt, die nun via IP genutzt werden können. Die Datenpakete aus IP werden dann auf den KNX-TP Bus kopiert, wobei jede Tunnelverbindung eine eigene PA bekommt (das ist seit einigen Jahren so Vorschrift, vor 2017 durfte man auch beliebig viele KNX Tunnel über eine PA tunneln, diese Änderung mitten in der Entwicklung hat uns in 2018 alleine ein dreiviertel Jahr gekostet, weil wir deshalb einen CoProzessor brauchten, weil wir sonst die 20 µs Reaktionszeit für das ACK nicht sicher hätten erreichen können).
  4. ETS Busmonitor-Mode(für den Gruppen- und Busmonitor der ETS)
    Das ist eine spezielle Version der KNXnet/IP Tunnelverbindung. Hiervon können theoretisch beliebig viele aufgebaut werden, da für diese Busmonitor-Tunnel keine PA vergeben wird (sieht man auch an einem der Screenshots oberhalb). Das ist eine unidirektionale Kopier-Verbindungen. Alle Busmonitor-Verbindungen erhalten eine Kopie KNX-TP Datenpakete die empfangen werden. Da wird nichts geprüft und gefiltert, es wird einfach durchkopiert. Daher auch beliebig viele solcher Verbindungen parallel, weil alles wird nur durchkopiert, es gibt keine PA weil auch kein Busteilnehmer (nur abhörend).
Insofern sind es in Deinem Fall Verbindungen von

Externer Software -> KNXnet/IP Datenstrom via IP -> KNXnet/IP Tunnel-Verbindung -> KNX-TP -> KNX Stack -> TWS Objektsystem

und wieder zurück.

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.

Robert_Mini
Reactions:
Beiträge: 3903
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1264 Mal
Danksagung erhalten: 2213 Mal

#52

Beitrag von Robert_Mini »

Ich kann bei mir im ETS Busmonitor keine Wiederholungen von NodeRed Telegrammen erkennen. NodeRed schickt bei mir regelmäßig Wetterdaten und die GAs sind ausschließlich an Objekte des TWS verbunden:
Screenshot 2020-10-31 085712.png
lg
Robert
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von Robert_Mini am Sa Okt 31, 2020 8:57 am, insgesamt 2-mal geändert.
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

gbglace
Reactions:
Beiträge: 4089
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1416 Mal
Danksagung erhalten: 1901 Mal

#53

Beitrag von gbglace »

Die Applikation des TWS selbst ist halt nur an der Host-PA 1.1.100, bei den Tunneln ist es ja schwierig zu definieren welches Gerät es gerade ist. (Es gibt da ja leider keine definierte Zuordnung IP-Adresse zu Tunnel :whistle: , als das es Sinn machen würde da in der ETS einen fixen Namen zu hinterlegen). Aber wenigstens TWS-Tunnel oder so wäre ja nicht schlecht, hat jemand eine normale IP-Schnittstelle, wie schaut das dort aus?
Grüße Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU

Robert_Mini
Reactions:
Beiträge: 3903
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1264 Mal
Danksagung erhalten: 2213 Mal

#54

Beitrag von Robert_Mini »

gbglace hat geschrieben: Sa Okt 31, 2020 9:00 am Die Applikation des TWS selbst ist halt nur an der Host-PA 1.1.100, bei den Tunneln ist es ja schwierig zu definieren welches Gerät es gerade ist. (Es gibt da ja leider keine definierte Zuordnung IP-Adresse zu Tunnel :whistle: , als das es Sinn machen würde da in der ETS einen fixen Namen zu hinterlegen). Aber wenigstens TWS-Tunnel oder so wäre ja nicht schlecht, hat jemand eine normale IP-Schnittstelle, wie schaut das dort aus?
Für die Mitleser: die Tunnel waren original im Posting ohne Namen.
@gbglace: Man kann in der ETS die Namen vergeben, fixer Bezug macht nicht wirklich Sinn, weil sich die Zuordnung ändern kann, aber bei mir ist NodeRed immer schon auf 1.1.104... (offensichtlich ergibt sich diese Reihenfolge nach dem Reboot und Start der Container...).

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

gbglace
Reactions:
Beiträge: 4089
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1416 Mal
Danksagung erhalten: 1901 Mal

#55

Beitrag von gbglace »

Ja deswegen wäre das auch mal ein feines kleines feature wenn man im TWS auf der Schnittstellenseite die Zuordnung IP-Adresse zu Tunnel vorgeben könnte und nicht first come, first serve gilt. Ich glaube die Enertex IP-Schnittstellen / Router bieten so eine Zuordnung an. Bei 25 Tunnel kann man ja auch einige undefiniert lassen für spontane Geräte, allen anderen vergibt man ja meist im DHCP eine fixe IP-Adresse.
Grüße Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU

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

#56

Beitrag von StefanW »

Hallo Göran,
gbglace hat geschrieben: Sa Okt 31, 2020 10:33 amJa deswegen wäre das auch mal ein feines kleines feature wenn man im TWS auf der Schnittstellenseite die Zuordnung IP-Adresse zu Tunnel vorgeben könnte und nicht first come, first serve gilt.
Jep, wir haben das auch schon länger auf der Liste stehen.

Wir sind nur grundsätzlich sehr zurückhaltend mit Änderungen an laufenden Engines, insbesondere wenn dies ein potentiell kritischer Eingriff ist.

Gerade und insbesondere bei KNX sind wir nochmal mehr zurückhaltend mit Änderungen oder Erweiterungen. Spezielle solche die eine Rezertifizierung bedingen, sparen wir uns ganz.

Auch wollen wir nicht mehr als eine potentiell kritische Änderung an einem System pro Release vornehmen.

In dem derzeitigen 1.6er Release haben wir eine - potentiell kritische -Erweiterung eingebaut (optimiertes Verhalten auf die Antwort auf frisch initialisierte Objekte) plus eine potentiell unkritische Erweiterung um die Diagnose-Schnittstelle, um interne Datenstrukturen nach außen transparent zu machen und die Ereignisse zur Oberfläche zu melden.

Eine nochmalige Erweiterung zur Erweiterung für eine Reservierung der Tunnel wollten wir in der 1.6er nicht machen, zumal ursprünglich ohnehin nur das ekey Feature für die 1.6 angedacht war.

Tatsächlich haben wir alle die anderen Leistungserweiterungen und Verbesserungen der 1.6 wegen Kundenwünschen (oder um Supportanfragen einzudämmen) eingebaut, was uns am Ende viel Zeit gekostet hat. Weil wir dafür mit dem 2.0er Release nicht schnell genug weiterkommen, erhalten wir nun Forenprügel von anderer Seite, denen diese neuen Features völlig egal sind, die aber die Modbus Features wollen.

Daher bitte ich um Verständnis, dass wir uns nun mehr darauf konzentrieren, völlig neue Leistungsmerkmale zu erschließen, anstatt die bestehenden und funktionierenden "guten bis sehr guten" Leistungsmerkmale hin zu "Top Exzellent" auszubauen. Das können wir auch später machen, wenn wir dafür die Anzahl der Möglichkeiten erstmal erweitert haben, für die der Timberwolf Server eigentlich stehen soll.

Auf der Liste künftiger Features steht eine IP-zu-Tunnel Reservierung durchaus, weil eine bessere Diagnostik dafür spricht.


lg

Stefan
Zuletzt geändert von StefanW am Sa Okt 31, 2020 11:52 am, insgesamt 4-mal geändert.
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.

gbglace
Reactions:
Beiträge: 4089
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1416 Mal
Danksagung erhalten: 1901 Mal

#57

Beitrag von gbglace »

Hi Stefan,
kein drängeln nur hier hatte der kleine Hinweis mal wieder gut gepasst, wo man Vorteile aus dem Feature ziehen kann.

Ja und keine aufbauenden Änderungen in einem Release macht meist Sinn gerade bei den Tests. Und jetzt wo ja auch die erweiterte Schnittstellenkonfigurationsansicht im Server gebaut ist, passt das ja als darauf aufsetzende Erweiterung erst richtig gut rein. Weis gar nicht ob die erweiterte Service-Seite zu den Schnittstellen schon in 1.5 ist. Bin ja immer beim Dev und Beta dabei, da hab ich das ja für mich schon gut verinnerlicht ;-).

Grüße
Göran
Grüße Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU
Benutzeravatar

starwarsfan
Reactions:
Beiträge: 1395
Registriert: Mi Okt 10, 2018 2:39 pm
Hat sich bedankt: 864 Mal
Danksagung erhalten: 1199 Mal

#58

Beitrag von starwarsfan »

Hallo Stefan,

sry, war ein paar Tage anderweitig unter Wasser...

StefanW hat geschrieben: Fr Okt 30, 2020 5:51 pm 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")

==> Habe ich damit alle Beobachtungen aus dem Thread richtig zusammen gefasst?
Nicht ganz. Meine Edomi Instanz läuft als LXC-Container auf einem ProxMox-Cluster. Alles andere passt aber soweit.
Kind regards,
Yves

TWS 2500 ID:159 / TWS 3500 ID:618 / TWS 3500 ID:1653 + PBM ID:401 / ProxMox / 1-Wire / iButtons / Edomi (LXC / Docker) / evcc / ControlPro
(TW-VPN jeweils offen, Reboot nach Rücksprache)
Benutzeravatar

starwarsfan
Reactions:
Beiträge: 1395
Registriert: Mi Okt 10, 2018 2:39 pm
Hat sich bedankt: 864 Mal
Danksagung erhalten: 1199 Mal

#59

Beitrag von starwarsfan »

Hallo nochmal,

eben habe ich es nochmals durchgespielt. ETS Gruppenmonitor laufen lassen, Timberwolf Busmonitor ebenfalls und dann Finger über den Scanner. Im TW-Busmonitor sieht das so aus:
2020-10-31_EkeyTelegramme02.png
Im ETS-Gruppenmonitor jedoch so:
2020-10-31_EkeyTelegramme01.png
Dort kommt also offenbar nur ein Telegram an. Damit bin ich jetzt völlig verwirrt und habe den Faden verloren... :think:
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Kind regards,
Yves

TWS 2500 ID:159 / TWS 3500 ID:618 / TWS 3500 ID:1653 + PBM ID:401 / ProxMox / 1-Wire / iButtons / Edomi (LXC / Docker) / evcc / ControlPro
(TW-VPN jeweils offen, Reboot nach Rücksprache)

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

#60

Beitrag von StefanW »

Hallo Yves,

wie ist der ETS Busmonitor mit dem TP Verbunden? Über einen KNXnet/IP Tunnel des TWS oder einer anderen Schnittstelle?
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.
Antworten

Zurück zu „KNX“