ElabNET Technik Forum

Hallo,

mein TWS 3500 verfügt neben dem internen KNX-Busankoppler auch noch einen externen KNX-Busankoppler. Der interne KNX-Busankoppler wird im Applikationsmodus betrieben, und die TWS ist in der ETS entsprechend programmiert. Somit besteht Zugriff auf die TP-Linie, die am internen KNX-Busankoppler angeschlossen ist.

Neben dieser ersten TP-Linie gibt es noch eine zweite TP-Linie. Beide TP-Linien sind jeweils über einen IP-Router gekoppelt, da eine Linienkopplung auf Basis TP Lastprobleme am KNX-Bus bereiten würde. Es werden zwar nur wenig Daten zwischen den beiden TP-Linien ausgetauscht, aber enorm viel von jeder der beiden TP-Linien nach IP.

Nun stellt sich die Frage nach dem korrekten Setup in diesem Szenario. Wenn ich von entsprechend niedrig ausgelasteten TP-Linien ausgehe, würde es meines Erachtens ausreichen, den TWS an eine beliebige TP-Linie zu hängen. Da die IP-Router ohnehin über das korrekte Routing sorgen, würde der TWS grundsätzlich Zugriff auf Gruppenadressen aus beliebigen anderen Linien erhalten.

Wenn ich jedoch neben den Daten aus der ersten Linie auch noch so gut wie alle Daten aus der zweiten Linie vom TWS verarbeiten lassen will, würde das den KNX-Bus überlasten. Aus diesem Grund habe ich vor, die zweite TP-Linie über den externen KNX-Busankoppler auch mit der TWS verknüpfen.

Leider habe ich trotz Suche nach Informationen zu solch einem Setup nichts gefunden, und meine bisherigen Versuche waren auch nicht erfolgreich. Zwar kann ich den externen KNX-Busankoppler als Busmonitor nutzen oder den Applikationsmodus auf dem externen KNX-Busankoppler aktivieren. Letzteres führt aber nur dazu, dass der Applikationsmodus vom internen KNX-Busankoppler auf den externen KNX-Busankoppler wandert.

Wie ist in diesem Fall vorzugehen, wenn Daten aus mehreren Linien verarbeitet werden sollen und die schiere Datenmenge einen Transport über Liniengrenzen nicht mehr erlaubt, sodass der TWS die Daten der jeweiligen Linie direkt vom zugeordneten KNX-Busankoppler holen soll?

Viele Grüße
Peter

Dein TWS hat bestimmt auch ne Software installiert? Forenregeln gelten auch für Fragen.

In der Linie in der der TWS sitzt kann er im Applikationsmodus eine passende PA bekommen und Telegramme darüber senden und empfangen. Stand heute.

Im Busmonitor und dem Ringspeicher wird er aber nur jene Telegramme sehen die auf dieser TP-Linie laufen. Mit einer weiteren TP-UART Schnittstelle kann diese Funktion auch für die andere Linie genutzt werden. Aber eben nur den Busmonitor und den Ringspeicher.

Will man Telegramme der anderen Linie effektiv im TWS nutzen (Visu, Logiken, Weiterleitung auf MQTT usw.) Wird dies nur funktionieren, wenn man passende GA an TWS-KOs verbindet und die Filtertabellen der beiden IP-Router für diese GA anpasst (macht dann die ETS).

Kannst Du das etwas genauer beschreiben warum die Telegrammlast beider Linien zu hoch ist? Was sendet denn da so exezssiv auf den Bus?

gbglace hat geschrieben: ↑Fr Apr 15, 2022 8:47 pm Dein TWS hat bestimmt auch ne Software installiert? Forenregeln gelten auch für Fragen.

Bin davon ausgegangen, dass meine Frage von grundlegender Natur ist. Es handelt sich um einen TWS 3500 mit Firmware 3.4.1.

gbglace hat geschrieben: ↑Fr Apr 15, 2022 8:47 pm Will man Telegramme der anderen Linie effektiv im TWS nutzen (Visu, Logiken, Weiterleitung auf MQTT usw.) Wird dies nur funktionieren, wenn man passende GA an TWS-KOs verbindet und die Filtertabellen der beiden IP-Router für diese GA anpasst (macht dann die ETS).

Dass es damit auf jeden Fall funktioniert, liegt auf der Hand. Denn bei solch einem Setup werden die GA der anderen Linie in die Linie des TWS geroutet. Mir geht es aber genau um den Fall, dass ich dies vermeiden will. Schließlich liegen die benötigten Daten bereits im Busmonitor der zweiten KNX-Schnittstelle ohnehin an. Daher meine Frage, ob man auf dieser Basis etwas erreichen kann.

gbglace hat geschrieben: ↑Fr Apr 15, 2022 8:47 pm Kannst Du das etwas genauer beschreiben warum die Telegrammlast beider Linien zu hoch ist? Was sendet denn da so exezssiv auf den Bus?

Es ist die schiere Größe der Linie, die die hohe Last bewirkt. Bei 200 Geräten und einer SPS mit hunderten von Messwerten, die ohnehin nur bei Datenänderungen auf den Bus geschrieben werden, kommt allerlei zusammen. Zunächst war alles auf einer Linie, mit dem Ergebnis, dass sich die KNX IP Router regelmäßig aufgehängt haben und sich Nachrichten am Bus gegenseitig überschrieben haben. Teilweise habe ich die Mindestintervalle für Messwertänderungen auf 5 Minuten / 10 Minuten limitiert, um die Last zu senken, aber selbst das hat nicht gereicht. Erst ein Aufteilen der Last auf zwei Linien hat die Probleme beseitigt. Wenn ich nun hergehe und alle Daten wieder in eine gemeinsame Linie weiterleite, wird das einfach zu viel Last.

Deshalb verbleibt die Frage, wie die Daten aus mehreren Linien ausgelesen werden können, ohne die gesamten Daten in einer einzigen TP-Linie bei 9,6 kBit/s bündeln zu müssen, denn das bekomme ich aus Lastgründen nicht mehr hinein.

Nein der TWS ist nicht darauf ausgelegt aus seiner Datenbank zu lesen und darüber nachzudenken. Im Objektsystem des TWS sind die Telegramme des Busmonitors eben genau nicht enthalten. Sie lassen sich halt mit Grafana-Mitteln visualisieren.

Der TWS ist halt immer ein KNX-TP Gerät. Anders wäre es wenn der TWS ein reines KNX-IP Gerät wäre, dann könntest einfach alle Telegramme durch die Router auf die KNX IP-Linie (Hauptlinie/Bereichslinie) geben und hättest dann alles im TWS Objektsystem. Limitierung wäre dann die Applikation mit der maximalen Anzahl KO.

Jetzt könntest Dir einen Container bauen mit z.B. einen knxd und MQTT Sender. Dann wären die Daten auch via dem Medium IP durch MQTT am TWS Objektsystem angebunden. Ggf gibt es von der SPS aus auch direkt IP-Protokolle ansprechbar auf die der TWS zugreifen kann, dann wäre es auch erstmal ganz weg vom KNX.

Hallo Peter,

wie ich sehe, hast Du ebenfalls ein Ticket beim Support eröffnet mit der gleichen Frage.

Da dies doch von allgemeinen Interesse ist (es haben mehrere Integratoren bei großen Anlagen das Problem, dass die 9.6 kBIt/s irgendwann nicht mehr ausreichen) beantworten wir das hier und nicht mehr im Ticket.

Göran hat es ja schon skizziert.

1. Es gibt den KNX Applikationsstack, der mit der ETS zu programmieren ist und mit dem KNX Objekte im Server erstellt werden und mit Gruppenadressen assoziiert werden können.

2. Einen solchen KNX Applikationsstack kann es nur einen geben (zumindest ist es so implementiert, weil alles andere wäre komplex, auch in der Oberfläche und würde die meisten Nutzer überfordern, wenn man es mit mehreren Stacks auf mehreren Linien und mehrfacher TWS-Appliaktion im Projekt zu tun hat... wir müssen den Server auch an normale Endnutzer verkaufen können, die nicht mit beiden Armen und Beinen im KNX Thema stecken). Insofern kann man den KNX Applikationsstack nur auf einem Interface aktivieren.

3. Nur im KNX Stack hat man Objekte die man im Server beliebig mit Objekten anderer Systeme verknüpfen kann (Modbus, MQTT, Logik, andere KNX Objekte, Zeitserien).

4. Busmonitore kann es mehrere geben, diese Zeichnen den Telegrammverkehr in eine DB auf. Diese Telegramme landen nicht in der Ebene der Objekte, sondern eben als Eintrag in einer DB, wodurch diese per SQL, Grafana usw. auswertbar werden.


==> Bei dem Ratschlag den Du möchtest, kommt es nun darauf an, was der TWS machen soll mit den KNX-Daten? Wenn Du uns das näher beschreiben magst?


Im Ticket hast Du noch gefragt:

Gibt es in Zukunft Ansätze, direkt über KNXnet/IP zu kommunizieren, um die Last in der TP-Linie des TWS klein zu halten? Was raten Sie uns für solch ein Setup?

Jein. Wir denken darüber nach, dass der KNX-Stack auch über KNXnet/IP kommunizieren kann. Das würde in solchen Anlagen helfen. Eine korrekte und zertifizierte Implementierung kostet da aber gut 70 bis 100k EUR und da fragen wir uns schon, wie wir das jemals wieder herein bekommen sollen. Da müssten wir wenigstens 1000 Server extra verkaufen, um nichts damit verdient zu haben oder dieses Leistungsmerkmal als extra Lizenz 250 mal für 300 EUR verkaufen. Es ist eher eine finanzielle Sache, so ein Leistungsmerkmal anzubieten.

Wir beobachten derzeit die Nachfrage danach.


lg

Stefan

Hallo Stefan,

vielen Dank für die sehr klare Stellungnahme zur etwaigen Unterstützung von KNXnet/IP. Eine Antwort dieser Art habe ich zwar befürchtet und überrascht mich dadurch zwar nicht, aber die Hoffnung stirbt ja zuletzt... Abgesehen von dieser Einschränkung habt ihr jedenfalls ein phantastisches Produkt zusammengestellt.

Primär geht es mir bei den einzulesenden KNX-Daten aus anderen Linien um eine Protokollierung in der InfluxDB / Darstellung in Grafana. Gibt es speziell für diesen Anwendungsfall vielleicht eine Lösung, die sich kostengünstiger realisieren lässt?

Mir liegen tausende Gruppenadressen, deren DPT und Bezeichnungen in Textform vor, die über KNXnet/IP abrufbar sind bzw. über UARTs aus anderen TP-Linien, und ich suche nach einer Lösung, die damit verknüpften Daten in eine Time Series Datenbank zu schreiben, am besten einheitlich wie die Daten aus GAs, die der TWS ohnehin direkt verwalten kann.

VIele Grüße
Peter

Hallo Peter,

petertau hat geschrieben: ↑Do Mai 19, 2022 8:07 amvielen Dank für die sehr klare Stellungnahme zur etwaigen Unterstützung von KNXnet/IP. Eine Antwort dieser Art habe ich zwar befürchtet und überrascht mich dadurch zwar nicht, aber die Hoffnung stirbt ja zuletzt...

Wir wollen das durchaus implementieren, auch mit - dann beiden - Stacks in Secure. Aber das muss man auch finanziell abbilden. Wobei es nicht unmöglich ist, weil der Zuspruch durch die Integratoren ist groß, wir bekommen viel Lob von allen Seiten und der Server wird in immer mehr und größere Projekte eingeplant. Wenn sich das weiterhin gut entwickelt, sieht das sicher anders aus, meine Auskunft ist nur eine Momentaufnahme.

Denkbar wäre auch, dass solche zusätzlichen Features als buchbare Lizenzen freigeschaltet werden können gegen entsprechenden Aufpreis. Dann läßt sich das noch sehr viel leichter darstellen.

petertau hat geschrieben: ↑Do Mai 19, 2022 8:07 amAbgesehen von dieser Einschränkung habt ihr jedenfalls ein phantastisches Produkt zusammengestellt.

Vielen Dank. Es freut uns das aus dem Munde eines berufenen Integrators zu hören. Wir arbeiten daran, dass es beständig besser wird.

Falls noch nicht gemacht, bitte an dieser Umfrage zu künftigen Leistungsmerkmalen teilnehmen: Abstimmung: Leistungsmerkmale ab V4

petertau hat geschrieben: ↑Do Mai 19, 2022 8:07 amPrimär geht es mir bei den einzulesenden KNX-Daten aus anderen Linien um eine Protokollierung in der InfluxDB / Darstellung in Grafana.

Der Busmonitor schreibt schon alle GA die er auf den jeweiligen Busmastern sieht, in die Influx DB. Da kann man die auch rausfischen.

petertau hat geschrieben: ↑Do Mai 19, 2022 8:07 amGibt es speziell für diesen Anwendungsfall vielleicht eine Lösung, die sich kostengünstiger realisieren lässt?

Einfach mal in den GA Manager gehen und dort zu einer GA auf das Grafana-Symbol drücken, damit sieht man, wie das in Grafana zu machen ist. Und wenn man sich das als Beispiel nimmt, kann man sicher gut herausfinden, wie man die Busmonitor-Aufzeichnungen des zweiten Busankopplers aus Influx auslesen kann.

Die andere Möglichkeit ist, jeweils einen TWS 3500XS in jede Linie und dort alle aufzuzeichnenden GAs per MQTT zu einem Hauptwolf (3500M oder 3500L) senden, der diese MQTT-Telegramme dann jeweils in Zeitserien aufzeichnet. Auf diese Weise hat man alle Daten aller Wölfe in einer Datenbank und kann diese einfach mit Grafana auswerten. Das funktioniert auch über Standorte hinweg, weil man leicht über das Internet eine Standortkopplung mit dem TWS machen kann (da gibt es ein Video von uns dazu). Dauert nur Minuten übrigens.

Versteht Ihr da auch Routing zwischen den TP-Linien darunter, oder "andere Baustelle"?

Echtes Routing, andere Baustelle. Sich per MQTT-Brücke eine zweite Anlage in separaten GA-Bereich mehrere Sachen kombinieren ginge schon aber eben eher anderen Threads zur Vertiefung aufmachen.