Kennst du deine KNX-Bus Auslastung? Weißt du wie viel auf deinem KNX-Bus los ist? Zugegeben, eine oder zwei KNX-Leitungen wird der KNX-Bus locker stemmen, egal wie viel du sendest. Bei größeren Objekten sieht das schon ganz anders aus. Ich habe bei mir den Busmonitor in der ETS gestartet und geschaut was so los ist. Warum ich dann sogar ein zweites Interface besorgen musste, liest du in diesem Artikel. Am Ende habe ich mich dann tatsächlich gefreut, dass ich die Thinka habe. Sie reduziert die Auslastung auf meinem Bus um einiges.
Inhalt
Geschwindigkeit auf dem KNX-Bus
KNX kommuniziert mit 9600 Bit pro Sekunde. Es ist, aus heutiger Sicht, nicht viel, allerdings ist diese Geschwindigkeit sehr stabil. Da du mit einer Spannungsversorgung bis zu 700 Meter KNX-Leitung versorgen kannst, die auch noch, ohne besondere Abschirmung, direkt neben 250V Wechselstrom liegen darf, muss die Übertragung sicher sein. Normalerweise reichen 9,6 kBit/s (oder auch 1200 Bytes pro Sekunde) auch vollkommen aus, es sei denn, du übertreibst es.
Ein KNX-Telegramm kann aus bis zu 23 Bytes bestehen. Im Durchschnitt sind die Telegramme allerdings kürzer, da weniger Information übertragen wird. Das kürzeste Telegramm (1 Bit Adresse, „Ein“ oder „Aus“) ist 9 Bytes lang. Du kannst also zwischen 50 und 133 Telegrammen pro Sekunde auf einer Leitung senden. Das klingt nach viel, kann aber auch zu einem Problem werden. Zum Beispiel wenn du die aktive Rückgabe zu sehr strapazierst.
Beispiel um den KNX-Bus zu strapazieren:
Wir hatten das Beispiel im KNX Kurs. Nehmen wir ein größeres Gebäude mit 300 Lichtquellen. Alle einzeln per Adresse erreichbar. Jetzt drückt der Pförtner auf den Taster „Alles aus„. Es geht eine Gruppenadresse über den KNX-Bus an alle Empfänger. Wenn nun jeder einzelne seinen Status aktiv als Gruppenadresse zurück meldet, dann sind das 300 Rückmeldungen. Zuerst alle gleichzeitig, aber nur einer gewinnt, die anderen warten und versuchen es nochmal sobald der Bus wieder frei ist. Da der Status nur ein kurzes Telegramm ist, ist der komplette Bus für ca. 3 Sekunden dicht. Es kann nichts anderes gesendet werden. Werden die Status Meldungen nicht bestätigt, wiederholen alle das Telegramm 3 mal. Im schlimmsten Fall haben wir also eine volle Auslastung für 12 Sekunden, in denen andere Telegramme nicht übertragen werden können.
Zugegeben, im Einfamilienhaus wird das so schnell nicht passieren, aber auch hier, ist es interessant die Buslast zu kennen.
Prüfen der Auslastung
Ich habe das knXpresso Interface, was baugleich ist mit dem MDT Interface und noch einigen anderen. Wenn ich versuche den Busmonitor auf der ETS zu starten, kommt eine Fehlermeldung: „Warnung: Die Schnittstelle unterstützt der Verbindungsmodus (Busmonitor?) nicht.„
Zum Glück gibt es ja das KNX User Forum. Dort habe ich dann gelernt, dass der Chip, der in den meisten Schnittstellen verwendet wird, entweder „Tunneling Modus“ oder „Busmonitor Modus“ kann. Nicht beides gleichzeitig. Die meisten IP-Schnittstellen unterstützen also nur einen Modus gleichzeitig. Wenn deine Schnittstelle das doch kann, schreib es bitte in die Kommentare. So wissen andere welche Schnittstelle sie kaufen sollten.
Also, alle Endgeräte die, die IP-Schnittstelle benutzen ausmachen und wieder versuchen. Bei mir sind das IP-Symcon und zwei knXpresso Instanzen. Danach funktionierte der Busmonitor tadellos.
Der erste Aufruf vom Busmonitor
Da sehe ich also was so auf meinem KNX-Bus los ist. Natürlich ohne die Telegramme von der IP-Symcon. Die sendet jedoch auch allerhand (zum Beispiel die Werte der Photovoltaik Anlage, jede Sekunde).
Hier fehlt doch was?
Da dachte ich allerdings: „Moment, wo sind die grünen und gelben Zeilen?“. Was für gelbe Zeilen fragst du? Nun der Monitor färbt die Telegramme unterschiedlich ein, je nach Art.
- Weißer Hintergrund: Quelladresse bekannt und Empfang von mindestens einem Teilnehmer bestätigt.
- Grauer Hintergrund: Quelladresse unbekannt, Empfang bestätigt.
- Grüner Hintergrund: Telegramm wurde nicht bestätigt.
- Gelber Hintergrund: Telegramm wurde wiederholt, weil kein Empfänger es bestätigt hat.
- Roter Hintergrund: Ungültiges Telegramm.
Die grauen Telegramme sind bei mir OK, da ich zwei Projekte für das Haus habe. Wenn du den Busmonitor ohne ein Projekt startest (direkt aus den BUS-Einstellungen der ETS) sind alle Telegramme grau.
Auf der Suche nach dem ACK
Sendet eine Komponente ein Telegramm auf den KNX-Bus, wartet diese auf eine Bestätigung. Wenn eine andere Komponente die Gruppenadresse „akzeptiert“, diese also für sie bestimmt ist, wird ein „ACK“ gesendet. Der Empfang wird so bestätigt. Übrigens: es ist unerheblich, wie viele Empfänger ein „ACK“ senden. Da alle Empfänger gleichzeitig ein identisches Telegramm senden, „hört“ es sich für den Sender so an, als würde nur einer senden (naja, vielleicht etwas lauter 🙂 ).
Meine Taster senden allerdings die Temperatur regelmäßig auf den Bus. Die Strom-Aktoren, senden die Stromstärke bei Veränderung auch. Wer Bestätigt hier den Empfang??? Die Symcon und die Visualisierungen waren ja aus. Die Thinka habe ich ausgeschlossen, da sie die Gruppenadressen nicht kennt.
Im Busmonitor steht nicht, wer das Telegramm bestätigt. Also bleibt nur eine Möglichkeit: ausprobieren.
Zuerst hatte ich das IP-Interface im Verdacht, da es ja die Telegramme weiter leitet, also habe ich mir ein zweites USB-Interface besorgt (danke an den Kollegen im KNX-Kurs 🙂 ) und ausprobiert. Gleiches Ergebnis, keine gelben Telegramme.
Dann geht die Suche also weiter: Voila, nachdem ich der Thinka den Strom gekappt habe, sah der Busmonitor schon viel farbiger aus:
So sieht es also aus, wenn die Telegramme nicht bestätigt werden. Jetzt wurde ich neugierig. Werden die Telegramme durch die Visualisierungen bestätigt? Oder durch die IP-Symcon? Immerhin werden die Werte dort angezeigt, oder zumindest verarbeitet.
Zweite Schnittstelle zum KNX-Bus!
Jetzt musste ich zwei Schnittstellen haben. Das knXpresso Interface für die Visualisierungen und die IP-Symcon und ein zweites Interface für den Busmonitor. Ich hatte noch das Merten USB-Interface von dem Kollegen. Also die ETS über USB angebunden und geschaut. Übrigens, ich hätte genau so gut ein zweites IP-Interface verwenden können, das nur für den Busmonitor benutzt wird.
Das ist also die Auslastung die mein KNX-Bus über Jahre vertragen hat. Es hat super funktioniert. Jetzt verstehe ich auch, warum die LEDs am Interface quasi dauerhaft geleuchtet haben. Das ging natürlich auch durchgehend durch den Router und durch mein WLAN zu den Tabletts. Geht das besser?
Die Thinka macht alles wieder gut
Na klar geht das besser, durch einen Server der direkt am KNX-Bus hängt. Zumindest ist das meine Lösung. Nachdem die Thinka wieder Strom gekriegt hat, ist die Last um einiges gesunken:
So, 10% Auslastung. Drunter komme ich nicht, wenn ich die Informationen weiterhin auf dem Bus haben will. Es ist allerdings genug Luft nach oben und die LEDs blinken auch sichtbar langsamer.
Ja, es besteht die Möglichkeit, dass ein Telegramm bestätigt wird, obwohl es den „richtigen“ Empfänger nicht erreicht hat. Das Risiko gehe ich allerdings ein, da ich bis heute so etwas nicht beobachtet habe.
Alternativ zur Thinka, kannst du auch eine Komponente zur „ACK“ Komponente machen. Dann ziehst du einfach alle Gruppenadressen die nicht irgendwo anders bestätigt werden auf diese Komponente und sie wird ein „ACK“ senden. Ob die Komponente die Adressen braucht, ist dann unerheblich.
Übrigens: Auch ein Koppler wird das Problem nicht lösen. Er wird zwar auf der Linie ein „ACK“ senden, von der das Telegramm kommt, wird es aber auf der anderen Seite 3 mal widerholen, da er keine Bestätigung erhält.
Fazit
Besonders, wenn „komische“ Dinge passieren, solltest du die Buslast kennen. Da es immer mal wieder „Spitzen“ gibt, in denen die Last höher ist, sollte die Auslastung im Schnitt nicht zu hoch sein. Ich habe überlegt, ob ich die Stromdaten wirklich jede Sekunde senden soll. Nach dieser Untersuchung weiß ich, das tut meinem KNX-Bus nicht weh.
Außerdem haben mich haben zwei Dinge interessiert: Was ist auf meinem KNX-Bus so los und: werden Telegramme die durch das IP-Interface gehen bestätigt? Beide Fragen konnte ich beantworten.
Kennst du vielleicht Komponenten, die über eine IP-Schnittstelle angebunden werden, und trotzdem ein „ACK“ senden? Bestätigen andere Server, die direkt über KNX angebunden werden, nur die Telegramme, die sie kennen? Das würde mich wirklich interessieren, schreib es also in die Kommentare, wenn du es weißt.
Viel Spaß mit KNX,
Damian
Beitragsbild: Bild von Nitin AHUJA auf Pixabay
Möchte das Engagement mit meinen Ausführungen jetzt nicht „untergraben“ und schmälern. Vorab meine Anerkennung!
Dieses Thema ist mein „Kind“ und ist ungeachtet aller Bemühungen noch nicht zur Serienreife ausgewachsen. An mir liegt es nicht, mein Ideenpool ist voll. Auch bekomme ich nichts für diese meine Ideen bezahlt!
Eine tolle Entwicklung gabs mal von Adyna (leider eingestellt). Einen Teil hieraus findet sich in den Routern von MDT.
Meine Ideen finden sich in der Entwicklung von Bab-tec, im Datalogger. Tolles Geärt, jedoch scheiden sich hier betreffend Applikation die Geister. Aktuell keine WEiterentwicklung erkennbar.
Neu auf dem Markt eine Entwicklung der ISE über eine Baustein Entwicklung. Auch die Entwicklung unseres Mitglieds Stefan Werner: https://shop.elabnet.de/timberwolfserver stellt dies sicher.
Zusammenfassend findet sich zwar ansatzweise was auf dem Markt, jedoch auf dem Punkt gebracht scheinen mir diese Entwicklungen noch viel viel Potential für vernünftige Anwendungen zu besitzen. Nur dieses Potential wird nicht ausgeschöpft. Somit schwächelt auch ein wenig der wirtschaftliche Nutzen für den Anwender.
In der Tat, viele anwender knallen den Bus zu. Der Datalogger wirft ein Torten Diagramm aus mit den GA der höchsten Bus Last. Es können GA überwacht werden u.a. sogar über IP etc. Bitte Doku lesen. Albert Baurmann freut sich immer wenn Interessenten sich bei ihm melden.
Nur zur Hälfte werden z.B. die „Star-Anwender“mitgenommen, welche einen Homeserver von Gira besitzen. Der Homeserver besitzt neben den GA aus der ETS für seine Programmierungen eigene GA´s. Wenn gepflegt können diese hervorragende Dienste leisten. Nur diese weren von keinem Gerät erfasst und damit ist das Thema nicht rund! Für die HS GA´s schrieb einer unserer Mitglieder ein tolles Tool, damit kann man diese GA´s u.a. mit loggen.
Das ganze krankt auch, dass man nur schlecht was langfristig speichern kann. Wird zwar angeboten, jedoch schaffte ich mein großes Projekt bis dato noch nie für dem Fall der Fälle raus zu laden und für Aktivitäten zu nutzen.
Hierbei waren die Entwicklungen für dieses Volumen an Daten ggf. nicht ausreichend vorbereited.
Aktuell in meinem Focus die Entwicklung der ISE, welche 24/7 mit schreibt und über den Daten Monitor der ETS wieder rein geladen werden kann.Schaun wir mal wa sich in dieser Szene künftig noch tun wird.
Aktuell werden derartige Entwicklungen seitens der Hersteller scheinbar unterbewertet und auch die Anwender neigen nicht zwingend dazu sich ein derartiges Tool zu zu legen. So wie immer wieder zu lesen funzt doch alles super und über die Probleme und eigenhaiten des Buses spricht keiner. Man möchte sich da nicht outen ggf. was falsch gemacht zu haben. Eines sei bemerkt, der welcher Fehler oder defkte Geräte zu suchen hat muss sehr viel Zeit bzw. GEld in die Hand nehmen um diese einzugrenzen. Hierbei nicht mit inbegriffen das Entwicklungen gleich welcher Art wie „Bananen“ beim Kunden reifen.
Persönlich prüfe ich auch derartige Entwicklungen gelegentlich und die Ergebnisse bestätigen die laufenden „Firmware Änderungen“ der Hersteller. Von denen erfährt man auch nur durch Zufall bzw. müssen diese Geäte dann kostenpfrlichtig eingesandt werden. Wer trennt sich schon mal gerne von seinen Lieblingen, welche nicht selten über den Bedürfnissen der Ehefrau liegen!
Nachtrag zu meinen Ausführungen:
Damit der Bus Monitor der ETS sauber funktionieren kann sind auch bei jedem Gerät unter Eigenschaften sauber die Hacken bei den jeweiligen Definitionen zu setzen z.B. Status, Schalten usw.
Wenn das nicht der Fall ist, so war es in älteren ETS Versionen teilweise nie gefordert, dann besitzt man ein Problem und eine Hausaufgabe. Der Timberwolf über seinen Busmonitor schmeist gnadenlos all diesen Datenschrott als nicht lesbar markiert raus. Er besitzt auch ein ausgefeiltes Grafiksystem alle Aktivitäten nahezu minitiös abzubilden. Tolle Entwicklung. Stefan Werner freut sich sicherlich angepsorchen zu werden.
Hiervon bin auch ich nicht gefeit. Aktuell warten so um die 200 GA, bei welchen die Bezeichnungen nachführt werden müssten.