Fehlersuche im KNX-Bestand mit Busmonitor und Telegrammanalyse

Taster, die erst nach mehreren Sekunden reagieren. Storen, die sich ohne erkennbaren Grund bewegen. Leuchten, die sporadisch nicht schalten. Solche Störungen sind im KNX-Bestand häufig, und sie haben fast immer eine konkrete technische Ursache. Das Problem ist selten das Gerät selbst, sondern etwas, das im Bus passiert. Wer auf Verdacht tauscht, verliert Zeit und Geld, ohne die Ursache zu beseitigen.

Dieser zweite Teil der Serie «KNX in Betrieb und Bestand» zeigt, wie wir im Bestand systematisch vorgehen: mit Busmonitor, Buslastanalyse und Telegrammauswertung. Wir beschreiben die typischen Ursachen, die wir in der Praxis immer wieder antreffen, und erklären, wie man sie eingrenzt, bevor man zum Schraubenzieher greift. Den Grundlagen des KNX-Telegramms und der Buslast ist Teil 8 der Serie «KNX Grundlagen: die Schulungsreihe» gewidmet («Das KNX-Telegramm: Buszugriff, Bestätigung und Buslast»). Wer dort noch Lücken hat, liest diesen Beitrag am besten zuerst.

Was der Busmonitor zeigt und was nicht

Der Busmonitor ist das wichtigste Diagnosewerkzeug im KNX-Bestand. Er liest alle Telegramme mit, die auf dem Bus übertragen werden, und stellt sie mit Zeitstempel, physikalischer Adresse des Senders, Gruppenadresse, Datenpunkttyp und Bestätigungsstatus dar. In der ETS6 ist eine Busmonitor-Funktion direkt integriert. Daneben gibt es eigenständige Werkzeuge, die über eine KNX-Schnittstelle (USB oder IP) angebunden werden.

Was der Busmonitor zeigt: Welches Gerät wann sendet, ob Telegramme bestätigt werden (ACK), ob Geräte mit NAK oder BUSY antworten, und ob Telegramme wiederholt werden. Wiederholungen sind ein wichtiges Signal. Der KNX-Bus wiederholt ein Telegramm bis zu dreimal, wenn keine Bestätigung eintrifft. Häufen sich Wiederholungen, deutet das auf ein Kommunikationsproblem hin, das weiter untersucht werden muss.

Was der Busmonitor nicht zeigt: Er sieht nur den Bus, an dem die Schnittstelle angeschlossen ist. Telegramme auf anderen Linien, die über Linienkoppler gefiltert werden, erscheinen nur dann, wenn sie für die eigene Linie bestimmt sind. Wer eine Anlage mit mehreren Linien und IP-Backbone analysiert, muss die Schnittstelle an der richtigen Stelle anschliessen oder mehrere Messungen kombinieren.

Ein weiterer Punkt: Der Busmonitor zeigt Rohdaten. Ohne Kenntnis des ETS-Projekts, also ohne die Zuordnung von physikalischen Adressen zu Geräten und von Gruppenadressen zu Funktionen, sind die Daten schwer lesbar. Deshalb gehört das aktuelle ETS-Projekt zur Fehlersuche dazu. Fehlt es, ist die Analyse deutlich aufwendiger. Wir haben in Teil 5 der Serie «KNX richtig planen» («Das ETS-Projekt gehört dem Bauherrn») ausführlich beschrieben, warum das Projekt beim Betreiber liegen muss.

Buslast messen und einordnen

Bevor man einzelne Telegramme analysiert, lohnt sich ein Blick auf die Gesamtlast des Busses. Der KNX-TP-Bus überträgt mit 9600 bit/s. Das klingt nach wenig, reicht aber für eine gut geplante Anlage vollkommen aus, weil KNX ereignisgesteuert arbeitet: Ein Taster sendet, wenn jemand drückt. Ein Temperatursensor sendet, wenn sich die Temperatur ändert.

Probleme entstehen, wenn Geräte zyklisch senden, also in festen Zeitabständen, unabhängig davon, ob sich etwas geändert hat. Einzelne Geräte mit kurzen Sendezyklen können eine Linie so stark belasten, dass andere Telegramme verzögert werden oder verloren gehen. In der Praxis sehen wir das vor allem bei Energiezählern, Wetterstationen und schlecht konfigurierten Aktoren, die ihren Status regelmässig zurückmelden.

Die ETS6 zeigt im Busmonitor die Telegrammrate über die Zeit. Damit lässt sich erkennen, ob die Last gleichmässig verteilt ist oder ob es Spitzen gibt, die mit bestimmten Ereignissen zusammenfallen. Ein einfaches Muster: Die Anlage verhält sich tagsüber unauffällig, aber morgens beim Einschalten aller Geräte kommt es zu Verzögerungen. Das ist ein Hinweis auf eine Initialisierungslast, die viele Geräte gleichzeitig erzeugen.

Für eine saubere Buslastanalyse empfehlen wir, den Busmonitor über einen längeren Zeitraum laufen zu lassen, mindestens über einen typischen Betriebstag. Kurze Messungen zeigen nur einen Ausschnitt und können seltene Ereignisse verpassen.

Doppelte physikalische Adressen

Eine doppelte physikalische Adresse ist einer der häufigsten Fehler im KNX-Bestand, und einer der heimtückischsten. Zwei Geräte mit derselben Adresse antworten beide auf Telegramme, die an diese Adresse gerichtet sind. Das führt zu Kollisionen, zu unvorhersehbarem Verhalten und zu Fehlermeldungen, die scheinbar keinen Zusammenhang haben.

Wie entsteht das? Häufig bei Geräteersatz: Ein defektes Gerät wird ausgetauscht, das neue Gerät wird mit der Werksadresse 15.15.255 geliefert und in Betrieb genommen, ohne die physikalische Adresse zu programmieren. Oder ein Gerät wird kopiert, ohne die Adresse anzupassen. In grossen Anlagen mit vielen Geräten und mehreren Inbetriebnahme-Etappen schleichen sich solche Fehler leicht ein.

Im Busmonitor erkennt man doppelte Adressen daran, dass auf ein Telegramm zwei ACK-Signale kommen, oder dass ein Gerät auf Leseanfragen mit widersprüchlichen Werten antwortet. Die ETS6 bietet eine Diagnosefunktion, mit der man alle erreichbaren Geräte auf dem Bus abfragt und ihre physikalischen Adressen auflistet. Taucht eine Adresse doppelt auf, zeigt die ETS das direkt an.

Die Behebung ist einfach: Das falsch adressierte Gerät muss identifiziert und mit der korrekten physikalischen Adresse programmiert werden. Dazu muss man das Gerät in den Programmiermodus versetzen, was bei eingebautem Gerät manchmal einen kurzen Zugang zur Unterverteilung oder zum Gerät selbst erfordert.

Spannungsabfall auf der Busleitung

Der KNX-TP-Bus wird mit einer Busspannung von typisch 30 V DC betrieben. Die Geräte beziehen ihre Versorgung aus dem Bus, und die Kommunikation läuft über dasselbe Leitungspaar. Fällt die Spannung an einem Teilnehmer unter einen bestimmten Wert, kann das Gerät nicht mehr zuverlässig kommunizieren oder fällt ganz aus.

Spannungsabfall entsteht durch zu lange Leitungen, zu dünne Leiterquerschnitte, schlechte Verbindungen oder zu viele Geräte an einer Spannungsversorgung. Die Norm gibt für ein Liniensegment eine maximale Gesamtlänge von 1000 m vor, und der Abstand zwischen Spannungsversorgung und Teilnehmer darf 350 m nicht überschreiten. Werden diese Werte überschritten oder sind die Leitungen in schlechtem Zustand, leidet die Kommunikation.

Im Busmonitor zeigt sich Spannungsabfall oft durch häufige Wiederholungen von bestimmten Geräten, die räumlich weit von der Spannungsversorgung entfernt sind. Eine direkte Messung der Busspannung am betroffenen Gerät gibt Klarheit. Liegt die Spannung deutlich unter dem Sollwert, muss die Leitungsführung überprüft oder eine zusätzliche Spannungsversorgung eingeplant werden.

Ein weiterer Hinweis: Geräte, die sporadisch ausfallen und sich nach kurzer Zeit wieder melden, ohne dass jemand eingegriffen hat, können auf einen grenzwertigen Spannungsabfall hinweisen. Das Gerät fällt aus, wenn die Last auf dem Bus hoch ist, und erholt sich, wenn es ruhiger wird.

Falsche Filtertabellen und Linienkoppler

Linienkoppler trennen den KNX-Bus in Linien und filtern Telegramme: Nur Telegramme, die für Geräte auf der anderen Seite des Kopplers bestimmt sind, werden weitergeleitet. Diese Filtertabellen werden in der ETS automatisch berechnet und in die Koppler geladen. Stimmt die Filtertabelle nicht mit dem aktuellen Projektstand überein, werden Telegramme entweder nicht weitergeleitet oder unnötigerweise auf alle Linien geflutet.

Falsche Filtertabellen entstehen, wenn Geräte oder Gruppenadressen im ETS-Projekt geändert werden, die Koppler aber nicht neu programmiert werden. Das passiert häufig bei nachträglichen Erweiterungen oder wenn mehrere Personen am Projekt arbeiten. Im Busmonitor sieht man das daran, dass Telegramme auf der Quelllinie vorhanden sind, auf der Ziellinie aber fehlen, obwohl die Geräte korrekt konfiguriert sind.

Die Behebung ist einfach: Die Koppler müssen mit der aktuellen Filtertabelle aus dem ETS-Projekt neu programmiert werden. Wichtig ist dabei, das Projekt vorher auf Konsistenz zu prüfen, damit die neue Filtertabelle korrekt ist. Ein Koppler, der im Modus «alle Telegramme weiterleiten» betrieben wird (also ohne Filterung), belastet alle Linien unnötig und sollte nur als temporäre Massnahme eingesetzt werden.

Schleifen über IP-Backbone

Mit dem IP-Backbone hat KNX eine leistungsfähige Möglichkeit bekommen, Linien über das Netzwerk zu verbinden. KNXnet/IP-Router nutzen Multicast-Kommunikation (Adresse 224.0.23.12), um Telegramme zwischen Linien auszutauschen. Das funktioniert gut, wenn die Topologie sauber geplant ist. Ist sie es nicht, entstehen Schleifen.

Eine Schleife entsteht, wenn dasselbe Telegramm mehrfach auf dem Bus erscheint, weil es über verschiedene Wege zurückgeleitet wird. Das kann passieren, wenn IP-Koppler und TP-Linienkoppler dieselbe Linie verbinden, oder wenn Multicast-Pakete im Netzwerk nicht korrekt begrenzt werden. Im Busmonitor erkennt man Schleifen daran, dass dasselbe Telegramm mit identischem Inhalt kurz hintereinander mehrfach erscheint, oft mit leicht unterschiedlichen Zeitstempeln.

Schleifen können eine Linie innerhalb kurzer Zeit vollständig überlasten. Die Behebung erfordert eine genaue Analyse der Topologie: Welche Koppler sind vorhanden, welche Linien verbinden sie, und gibt es redundante Verbindungen, die nicht beabsichtigt sind? In der ETS6 lässt sich die Topologie grafisch darstellen und mit dem tatsächlichen Aufbau vergleichen. Wir empfehlen, bei jeder Anlage mit IP-Backbone die Topologie zu dokumentieren und bei Änderungen zu aktualisieren. Wie eine saubere Topologie aufgebaut wird, beschreibt Teil 2 der Serie «KNX richtig planen» («Topologie, Linien und IP-Backbone sauber aufbauen»).

Telegrammauswertung: Schritt für Schritt

Eine strukturierte Telegrammauswertung folgt einem klaren Ablauf. Wir beschreiben, wie wir dabei vorgehen.

Schritt 1: Symptom und Linie eingrenzen

Zuerst klären wir, welches Gerät oder welche Funktion betroffen ist, und auf welcher Linie es sich befindet. Dann schliessen wir die Busmonitor-Schnittstelle an dieser Linie an. Wenn die Anlage mehrere Linien hat und das Symptom linienübergreifend ist, beginnen wir auf der Hauptlinie und arbeiten uns vor.

Schritt 2: Buslast beobachten

Wir lassen den Busmonitor laufen und beobachten die Telegrammrate. Ist die Last auffällig hoch? Gibt es Geräte, die sehr häufig senden? Gibt es Wiederholungen? Diese erste Beobachtung dauert typisch einige Minuten bis eine halbe Stunde, je nach Anlage.

Schritt 3: Symptom provozieren

Wenn möglich, lösen wir das Symptom gezielt aus: Wir drücken den betroffenen Taster, aktivieren die betroffene Funktion oder warten auf den Zeitpunkt, zu dem das Problem erfahrungsgemäss auftritt. Dann schauen wir im Busmonitor nach, was genau passiert. Kommt das Telegramm an? Wird es bestätigt? Gibt es eine Reaktion des Aktors?

Schritt 4: Telegramme zuordnen

Mit dem ETS-Projekt ordnen wir die physikalischen Adressen den Geräten und die Gruppenadressen den Funktionen zu. So sehen wir, welches Gerät sendet, welche Funktion angesteuert wird und ob die richtigen Geräte reagieren.

Schritt 5: Ursache eingrenzen und beheben

Auf Basis der Beobachtungen grenzen wir die Ursache ein. Ist es eine Buslastproblematik? Eine doppelte Adresse? Ein Spannungsproblem? Ein Filterfehler? Dann beheben wir die Ursache und überprüfen anschliessend, ob das Symptom verschwunden ist.

Häufige Fehler beim Geräteersatz im Bestand

Ein eigenes Kapitel verdient der Geräteersatz, weil er häufig neue Probleme erzeugt. Wird ein Gerät ausgetauscht, muss es mit der korrekten physikalischen Adresse und der richtigen Applikation programmiert werden. Das klingt selbstverständlich, wird aber in der Praxis oft vernachlässigt.

Typische Fehler: Das neue Gerät hat eine andere Firmware-Version als das alte, und die Applikationsparameter sind nicht mehr kompatibel. Oder das Gerät wird mit der Werksadresse in Betrieb gelassen, weil «es ja funktioniert». Oder die Kommunikationsobjekte werden nicht korrekt mit den Gruppenadressen verknüpft, weil das ETS-Projekt nicht aktuell ist oder nicht vorliegt.

Wir empfehlen, jeden Geräteersatz im ETS-Projekt zu dokumentieren und das Gerät vollständig neu zu programmieren, nicht nur die physikalische Adresse zu setzen. Nur so ist sichergestellt, dass alle Parameter und Verknüpfungen korrekt sind. Die Inbetriebnahme und Abnahme einer KNX-Anlage, einschliesslich des Vorgehens bei Geräteersatz, beschreibt Teil 1 dieser Serie («Inbetriebnahme und Abnahme einer KNX-Anlage»).

Wann man externe Unterstützung beiziehen sollte

Viele Störungen im KNX-Bestand lassen sich mit den beschriebenen Methoden selbst eingrenzen, wenn das ETS-Projekt vorliegt und jemand mit dem Busmonitor umgehen kann. Es gibt aber Situationen, in denen externe Unterstützung sinnvoll ist.

Das gilt vor allem dann, wenn die Anlage gross und komplex ist, wenn das ETS-Projekt fehlt oder veraltet ist, wenn die Störung intermittierend auftritt und schwer reproduzierbar ist, oder wenn mehrere Ursachen gleichzeitig vorliegen. In solchen Fällen ist eine systematische Analyse durch eine erfahrene Fachperson effizienter als ein langer Suchprozess im Betrieb.

Wir führen solche Analysen regelmässig durch, oft im Rahmen von Bestandsaufnahmen vor einer Sanierung oder Erweiterung. Was danach mit einer Bestandsanlage gemacht werden kann, ob Modernisierung oder Ersatz, zeigt Teil 3 dieser Serie («KNX-Bestandsanlagen modernisieren statt ersetzen»).

Der rote Faden zu unseren Fachbeiträgen

Dieser Beitrag ist Teil 2 der Serie «KNX in Betrieb und Bestand». Teil 1 («Inbetriebnahme und Abnahme einer KNX-Anlage») beschreibt, wie eine KNX-Anlage korrekt in Betrieb genommen und abgenommen wird, und legt damit die Grundlage für einen störungsarmen Betrieb. Teil 3 («KNX-Bestandsanlagen modernisieren statt ersetzen») zeigt, welche Optionen es gibt, wenn eine Anlage nach der Fehlersuche grundlegend überarbeitet werden muss. Teil 4 («Raumautomation mit KNX nach EN ISO 52120») behandelt die energetische Bewertung von KNX-Anlagen im Betrieb.

Für das Verständnis des KNX-Telegramms und der Buslast empfehlen wir Teil 8 der Serie «KNX Grundlagen: die Schulungsreihe» («Das KNX-Telegramm: Buszugriff, Bestätigung und Buslast»). Die Grundlagen der Topologie, die für die Analyse von Linienkopplern und IP-Backbone wichtig sind, erklärt Teil 2 der Serie «KNX richtig planen» («Topologie, Linien und IP-Backbone sauber aufbauen»). Warum das ETS-Projekt beim Betreiber liegen muss, beschreibt Teil 5 derselben Serie («Das ETS-Projekt gehört dem Bauherrn»).

Wer sich fragt, ob KNX für ein bestimmtes Projekt überhaupt die richtige Wahl ist, findet eine ehrliche Einschätzung in Teil 1 der Serie «KNX richtig planen» («KNX im Zweckbau: wann es passt und wann nicht»). Und wer die Kosten über den Lebenszyklus im Blick behalten möchte, liest unseren Einzelbeitrag «Was KNX über den Lebenszyklus wirklich kostet».

Fazit

Störungen im KNX-Bestand haben fast immer eine konkrete Ursache: Buslast durch zyklisches Senden, doppelte physikalische Adressen, Spannungsabfall, falsche Filtertabellen oder Schleifen über den IP-Backbone. Mit Busmonitor, Buslastanalyse und Telegrammauswertung lassen sich diese Ursachen systematisch eingrenzen, ohne Geräte auf Verdacht zu tauschen. Voraussetzung ist ein aktuelles ETS-Projekt und ein strukturiertes Vorgehen. Wer beides hat, löst die meisten Störungen schneller und günstiger als mit dem klassischen Austausch auf Verdacht.

Sie haben Fragen dazu?

Sie haben eine KNX-Anlage mit sporadischen Störungen und wissen nicht, wo die Ursache liegt? Wir analysieren den Bus, werten die Telegramme aus und zeigen Ihnen, was zu tun ist. Melden Sie sich unter wenget.ch oder info@wenget.ch.

Quellenverzeichnis

• KNX Association: KNX System Specifications, insbesondere Abschnitte zu TP-Kommunikation, Topologie und Linienkopplern (kein Datum; aktuelle Version über knx.org)
• KNX Association: ETS6 Dokumentation und Diagnosefunktionen (Busmonitor, Gerätediagnose, Topologieansicht)
• EN 50090 (Reihe): Elektrische Systemtechnik für Heim und Gebäude (ESHG), Grundnorm für KNX
• ISO/IEC 14543-3: Informationstechnik, Heimelektronik-Systeme (HES), KNX-Normierung
• EN ISO 22510: KNXnet/IP-Kommunikation über IP-Netzwerke
• KNX ist eine eingetragene Marke der KNX Association, Brüssel. ETS ist eine eingetragene Marke der KNX Association.
• Eigene Projekterfahrung der WENGET GmbH aus KNX-Analysen, Fehlersuche im Bestand und Inbetriebnahmebegleitung