Raspberry Pi KNX-Gateway Troubleshooting: Die häufigsten Stolpersteine und ihre Lösungen

Keine Telegramme im Gruppenmonitor – KNX-Bus prüfen

Das wohl häufigste Problem beim Raspberry Pi KNX-Gateway ist: Es kommen keine Telegramme an. In der ETS siehst du nichts im Gruppenmonitor, Home Assistant bleibt stumm – der Bus wirkt wie tot. Hier solltest du zuerst die physikalische Ebene prüfen:

• Spannungsversorgung: Der KNX-Bus arbeitet mit 29 V DC. Prüfe mit einem Multimeter, ob dein 24 V-Trafo tatsächlich Spannung liefert.
• Busabschluss: KNX benötigt an den Enden des Busses Abschlusswiderstände. Fehlende oder doppelte Abschlüsse führen zu Signalreflexionen und Kommunikationsfehlern.
• Polarität: Der KNX-Bus ist polaritätsempfindlich. Achte darauf, dass + und – korrekt an der Klemme angeschlossen sind – ein häufiger Fehler, besonders bei selbstgelöteten TPUART-Interfaces.
• Galvanische Trennung: Bei HATs (z. B. ZDI KNX HAT) ist diese bereits integriert. Bei DIY-Schaltungen mit ADUM1201-Isolator sollte die Verbindung sorgfältig geprüft werden.

Wenn der Bus korrekt versorgt und abgeschlossen ist, aber trotzdem keine Telegramme erscheinen, lohnt sich ein Blick in das Log von knxd.

knxd startet nicht oder beendet sich sofort

Wenn der knxd-Dienst nicht startet oder sofort wieder stoppt, liegt das oft an einer fehlerhaften Konfiguration in /etc/default/knxd. Mit folgendem Befehl lässt sich der Dienst im Debug-Modus starten:

sudo systemctl stop knxd
sudo knxd -f -t1023 -D -S -i --eibaddr=1.1.128 tpuarts:/dev/ttyAMA0

So siehst du direkt, ob der serielle Port korrekt angesprochen wird oder ob der Daemon keine Verbindung zum Bus aufbauen kann. Achte darauf, dass der richtige UART-Port verwendet wird:

• Auf älteren Pis (z. B. Pi 2) ist das meist /dev/ttyAMA0.
• Auf Pi 3/4 muss Bluetooth deaktiviert werden (dtoverlay=disable-bt in /boot/config.txt), damit der UART für KNX frei wird. Danach ist /dev/ttyS0 korrekt.

Ein weiterer Klassiker: Der Dienst läuft, aber keine Clients finden den KNX/IP-Server. Prüfe, ob der UDP-Port 3671 offen ist und nicht durch die Firewall blockiert wird.

Gateway wird in Home Assistant oder ETS nicht gefunden

Wenn Home Assistant oder die ETS-Software dein Raspberry Pi Gateway nicht erkennen, liegt das Problem meist im Netzwerk. KNX/IP setzt auf UDP-Broadcasts im lokalen Netz. Befinden sich Gateway und Client in unterschiedlichen Subnetzen oder VLANs, funktioniert die automatische Erkennung nicht. Hier hilft es, in Home Assistant die Verbindung manuell einzurichten:

host: 192.168.1.50
port: 3671

Wichtig ist auch eine feste IP-Adresse für den Pi, um Verbindungsabbrüche zu vermeiden. In der /etc/dhcpcd.conf lässt sich diese dauerhaft setzen. Tritt das Problem nur sporadisch auf, kann die Ursache auch ein instabiles Netzteil oder eine überlastete SD-Karte sein. Besonders bei gleichzeitig laufenden Diensten (z. B. Home Assistant, MQTT, Node-RED) empfehle ich ein hochwertiges 3 A-Netzteil und eine SD-Karte der Klasse A1 oder besser.

Telegramme kommen doppelt oder gar nicht an

Wenn Telegramme im Bus doppelt auftauchen oder verschwinden, liegt das häufig an falschen knxd-Optionen oder an einer Mehrfachverbindung zum Bus. In der Datei /etc/default/knxd sollten die Parameter sorgfältig abgestimmt sein:

KNXD_OPTIONS="--eibaddr=1.1.128 --client-addrs=1.1.129:8 -D -S -i --listen-local=/tmp/knxd -T tpuarts:/dev/ttyAMA0"

Die Option --client-addrs legt fest, wie viele virtuelle Clients der knxd bedienen darf. Zu viele oder überlappende Adressen können zu Telegrammkonflikten führen. Ein weiterer Punkt: Wenn du den Pi gleichzeitig als KNX/IP-Gateway und KNX/IP-Router einsetzt, kann es zu Routing-Loops kommen. In diesem Fall sollte nur eine Funktion aktiv sein. Prüfe außerdem, ob eventuell ein zweites Gerät (z. B. ein anderer knxd oder ein professionelles KNX/IP-Interface) dieselbe physikalische Adresse nutzt – das führt unweigerlich zu Chaos im Bus.

ETS zeigt nur Gruppenadressen, keine Namen

Ein häufig übersehener Punkt bei der Integration in Home Assistant: Nach erfolgreichem Import erscheinen in der Oberfläche nur Gruppenadressen – aber keine lesbaren Namen. Das ist kein Fehler im knxd oder im Bus, sondern liegt schlicht daran, dass die ETS-Projektdatei nicht importiert wurde. Home Assistant kann nur dann die Klartextnamen anzeigen, wenn die .knxproj-Datei vorhanden ist. Lösung:

1. ETS-Projekt exportieren.
2. In Home Assistant unter Konfiguration → Integrationen → KNX die Datei importieren.
3. Neustart durchführen.

Danach erscheinen deine Geräte mit den in ETS definierten Namen, was die Fehlersuche und Automationspflege deutlich erleichtert.

Serielle Schnittstelle reagiert nicht

Wenn die serielle Schnittstelle des Raspberry Pi keine Daten liefert, obwohl alles korrekt verkabelt scheint, ist die Ursache oft banal, aber tückisch:

• Falsche GPIO-Belegung: Der TPUART oder HAT muss auf die richtigen Pins gelegt werden. Die meisten HATs nutzen Pin 8 (TXD) und Pin 10 (RXD). Eine vertauschte Belegung führt zu kompletter Funkstille.
• Bluetooth-Konflikt: Wie bereits erwähnt, belegt Bluetooth beim Pi 3/4 den UART. Erst nach dtoverlay=disable-bt und Reboot steht der Port für KNX zur Verfügung.
• Fehlende Gruppenberechtigung: Der Benutzer pi muss in der Gruppe dialout sein, sonst hat knxd keine Rechte auf den Port.

Mit ls -l /dev/tty* kannst du prüfen, ob der Port überhaupt existiert. Fehlt er, liegt meist ein Problem in der config.txt oder im Overlay vor.

Langsame Reaktion oder hohe CPU-Last

Ein weiteres Problem, das mir besonders bei größeren Installationen begegnet ist: knxd läuft träge oder mit hoher CPU-Last. Das liegt häufig an zu vielen gleichzeitig verbundenen Clients oder an einer zu hohen Buslast. Jede Telegrammweiterleitung kostet Rechenzeit – insbesondere, wenn Home Assistant, MQTT und Node-RED parallel auf dem Pi laufen. Abhilfe schaffen:

• Separater knxd-Server: Wenn du viele Integrationen nutzt, lohnt es sich, knxd auf einem eigenen Pi oder in einem Docker-Container auszulagern.
• Busfilter aktivieren: In der ETS kannst du Telegramme auf notwendige Gruppenadressen begrenzen – das reduziert den Datenverkehr erheblich.
• Logging reduzieren: In /etc/default/knxd das -D-Flag entfernen, um Debug-Logs abzuschalten.

Mit htop oder top lässt sich gut prüfen, ob knxd dauerhaft hohe CPU-Last verursacht.

SD-Karte korrupt oder System instabil

Ein unterschätztes Problem: SD-Kartenverschleiß. knxd schreibt regelmäßig Logs, Home Assistant legt Datenbanken an – und irgendwann stirbt die SD-Karte leise. Symptome sind plötzliche Reboots, nicht startende Dienste oder beschädigte Konfigurationsdateien. Meine Empfehlungen aus der Praxis:

• Nutze nur hochwertige A1/A2-SD-Karten (z. B. SanDisk Industrial).
• Aktiviere Logrotation oder leite Logs in den RAM (tmpfs).
• Alternativ: Verwende eine SSD per USB 3.0 – seit dem Pi 4 problemlos möglich.

Ein regelmäßiges Backup der Konfigurationsdateien (/etc/default/knxd, ETS-Projekt, Home Assistant-Config) spart im Ernstfall Stunden.