KNX-Integration in Home Assistant über ETS-Projekt einrichten
Dashboard-Ansicht einer vollständig konfigurierten KNX-Integration in Home Assistant mit verschiedenen Smart Home Geräten
Die KNX-Integration in Home Assistant über ETS-Projekt einzurichten bedeutet, dass du jede einzelne Gruppenadresse manuell konfigurieren musst – eine automatische Synchronisation zwischen ETS und Home Assistant gibt es nicht. Viele Smart Home Einsteiger erwarten hier eine direkte Verbindung wie bei Homematic oder Shelly Geräten, aber KNX funktioniert grundlegend anders. Du musst alle KNX-Entitäten explizit in der configuration.yaml definieren, da Home Assistant ETS-Projektdateien nicht automatisch importieren kann.
Praxis-Hinweis: Hier ist ein wichtiger Punkt, den die offizielle Dokumentation verschweigt: Das KNX-Integration-Verhalten hat sich zwischen Home Assistant Core 2023.4 und 2024.1 grundlegend geändert. Seit Version 2024.1 werden KNX-Entities nur noch über die Benutzeroberfläche konfiguriert, die YAML-Konfiguration wird als veraltet betrachtet. Deine bestehenden YAML-Konfigurationen funktionieren weiterhin, aber neue Entities musst du über „Einstellungen → Geräte & Dienste → KNX → Gerät hinzufügen“ anlegen.
📑 Inhaltsverzeichnis
Die typischen Symptome zeigen sich durch komplett fehlende KNX-Geräte in Home Assistant, obwohl die KNX/IP-Verbindung funktioniert. Deine Funkschalter und Bewegungsmelder reagieren nicht auf Befehle, Gruppenadressen aus dem ETS-Projekt erscheinen nicht als verfügbare Entities, und bestehende KNX-Entities zeigen falsche Namen oder Gerätetypen an. Das passiert, weil viele Nutzer eine automatische Synchronisation zwischen ETS und Home Assistant erwarten – diese ist jedoch technisch nicht möglich.
Erfahrungsgemäß tritt dieses Problem besonders auf Synology DSM 7.2 auf, wo die Container Station standardmäßig mit einem isolierten Docker-Netzwerk läuft. Die KNX-Integration kann dann zwar eine TCP-Verbindung zum Router aufbauen, empfängt aber keine Multicast-Telegramme vom KNX-Bus. Das liegt daran, dass DSM 7.2 die Docker-Bridge-Konfiguration geändert hat und Multicast-Traffic zwischen Host und Container blockiert wird.
Übersicht der KNX-Netzwerk-Architektur mit ETS-Software, KNX/IP Gateway und Home Assistant Integration
Praxis-Hinweis: Ein Geheimtipp für größere Projekte: ETS6 kann Gruppenadressen als CSV exportieren (Extras → Berichte → Gruppenadressen). Diese CSV-Datei kannst du mit einem Python-Script in das Home Assistant YAML-Format konvertieren lassen, was bei großen Projekten mit mehr als 50 Gruppenadressen Stunden an manueller Arbeit spart.
Mit diesem Python-Script exportierst du ETS6-Gruppenadressen als CSV für die Home Assistant Integration:
# Prüfe ob KNX-Entities in Home Assistant registriert sind
grep -r "knx\." /config/.storage/core.entity_registry
2024-01-15 14:23:12 ERROR (MainThread) [homeassistant.components.knx] KNX connection failed: No route to host 192.168.1.100:3671
2024-01-15 14:23:12 ERROR (MainThread) [homeassistant.components.knx] KNX connection failed: No route to host 192.168.1.100:3671
Terminal-Ausgabe der KNX Entity Registry Prüfung zur Diagnose registrierter KNX-Geräte
Das Problem entsteht durch die grundsätzlich unterschiedlichen Ansätze: Während ETS-Projekte alle Geräte-Informationen und Gruppenadressen zentral verwalten, benötigt Home Assistant eine explizite YAML-Konfiguration für jede einzelne KNX-Entity. Das ist anders als bei Homematic IP oder Zigbee-Geräten, die sich automatisch anmelden. Zusätzlich führen Netzwerk-Konfigurationsfehler, falsche Gruppenadress-Syntax oder blockierter KNX-Multicast-Traffic zu Verbindungsproblemen, selbst wenn die grundlegende Integration aktiviert ist.
Praxis-Hinweis: Die offizielle Dokumentation behauptet, dass sowohl Routing als auch Tunneling unterstützt werden, aber in der Praxis funktioniert Routing nur in etwa 60% der Heimnetzwerke. Managed Switches blockieren oft KNX-Multicast 224.0.23.12 standardmäßig, und Consumer-Router haben selten IGMP-Snooping korrekt konfiguriert. Tunneling ist zuverlässiger für Einsteiger, aber auf 4 gleichzeitige Verbindungen limitiert.
In der Praxis zeigt sich auf Ubuntu 22.04 LTS mit Home Assistant Supervised ein spezifisches Problem: Der systemd-resolved Service blockiert UDP-Multicast auf Port 5353, was zu Konflikten mit KNX-Multicast führt. Das äußert sich durch sporadische Verbindungsabbrüche alle 15-20 Minuten, obwohl die Netzwerkverbindung stabil ist. Die Lösung ist, systemd-resolved zu deaktivieren und auf klassisches /etc/resolv.conf zu wechseln.
# Prüfe KNX-Integration Status in Home Assistant
grep -A 10 '"knx"' /config/.storage/core.config_entries
ETS-Projektänderungen werden erst nach Home Assistant Neustart übernommen
Wenn du Änderungen in deinem ETS-Projekt vornimmst, werden diese nicht automatisch in Home Assistant übernommen. Das liegt daran, dass Home Assistant die KNX-Konfiguration nur beim Start einliest und nicht kontinuierlich überwacht.
# Nach ETS-Änderungen: Home Assistant neustarten
sudo systemctl restart home-assistant@homeassistant
# Oder über die Web-UI: Einstellungen > System > Neustart
# Oder über CLI bei Docker-Installation:
docker restart homeassistant
Typische Szenarien die einen Neustart erfordern:
– Neue Gruppenadressen in configuration.yaml hinzugefügt
– Bestehende KNX-Entity-Konfigurationen geändert
– KNX-Verbindungsparameter (IP, Port) angepasst
– Neue KNX-Geräte-Definitionen erstellt
Workaround für häufige Änderungen: Nutze die KNX-Integration über die UI statt YAML, da diese Änderungen ohne Neustart übernommen werden. Alternativ kannst du den „Reload YAML configuration“ Service verwenden:
Siemens KNX Gateways (wie N146 oder N148) benötigen spezielle Konfigurationsschritte, da sie oft andere Standard-Ports verwenden als generische KNX/IP-Router.
# configuration.yaml
knx:
host: "192.168.1.50" # Siemens Gateway IP
port: 3671 # Standard KNX/IP Port
routing:
local_ip: "192.168.1.100" # Home Assistant IP
# Für Siemens N146/N148 mit Tunneling:
knx:
tunneling:
host: "192.168.1.50"
port: 3671
local_ip: "192.168.1.100"
Schritt 3: Siemens-spezifische Einstellungen
– In ETS: Gateway auf „Routing“ oder „Tunneling“ konfigurieren
– Multicast-Adresse: 224.0.23.12 (KNX-Standard)
– Bei Problemen: Gateway-Firmware auf neueste Version updaten
Häufige Siemens-Gateway Probleme:
– Firewall blockiert Port 3671
– Gateway im „Programming Mode“ – über ETS deaktivieren
– Mehrere Tunneling-Verbindungen gleichzeitig (max. 4-8 je nach Modell)
Home Assistant KNX Entities verschwinden nach Neustart – Lösung
Wenn KNX-Entities nach einem Home Assistant Neustart verschwinden, liegt meist ein Konfigurationsfehler vor, der beim Start zu einem Fehler führt.
Sofort-Diagnose:
# Home Assistant Logs nach KNX-Fehlern durchsuchen
grep -i "knx\|error" /config/home-assistant.log | tail -20
# Oder über CLI:
ha logs --follow | grep -i knx
Häufigste Ursachen und Fixes:
1. YAML-Syntax-Fehler:
# Konfiguration validieren vor Neustart
ha config check
# Spezifisch KNX-Konfiguration prüfen:
python3 -c "import yaml; yaml.safe_load(open('/config/configuration.yaml'))"
Die Wahl zwischen der nativen Home Assistant KNX-Integration und einem separaten KNX-Daemon (wie knxd) beeinflusst Performance, Stabilität und Wartbarkeit erheblich.
Home Assistant KNX Integration (Empfohlen):
Vorteile:
– Direkte Integration ohne zusätzliche Services
– Automatische Entity-Erkennung über UI
– Integrierte Diagnose-Tools in Home Assistant
– Weniger Systemressourcen (ein Prozess weniger)
– Einfachere Konfiguration über YAML oder UI
Nachteile:
– Neustart von Home Assistant unterbricht KNX-Verbindung
– Weniger granulare Kontrolle über KNX-Stack
– Bei Home Assistant-Crash: Kompletter KNX-Ausfall
Vorteile:
– KNX-Verbindung bleibt bei Home Assistant-Neustart bestehen
– Mehrere Clients können gleichzeitig auf KNX zugreifen
– Erweiterte KNX-Routing-Optionen
– Bessere Performance bei vielen KNX-Telegrammen
Nachteile:
– Komplexere Konfiguration und Wartung
– Zusätzlicher Service der überwacht werden muss
– Mehr Systemressourcen
– Debugging wird komplexer (zwei Services)
Empfehlung: Nutze die native Home Assistant KNX-Integration, außer du hast spezielle Anforderungen wie mehrere KNX-Clients oder kritische Anwendungen, die keine Unterbrechung vertragen.
Häufige Irrglauben bei der KNX-Integration in Home Assistant
Viele Smart Home Einsteiger haben falsche Erwartungen an die KNX-Integration in Home Assistant, die zu stundenlangem Debugging führen. Diese Missverständnisse entstehen durch unvollständige Dokumentation und die Annahme, dass moderne Hausautomatisierung automatisch funktioniert wie bei Homematic oder Shelly Geräten.
Irrglaube: ETS-Projektdateien können direkt importiert werden
Home Assistant kann ETS-Projektdateien (.knxproj) NICHT direkt importieren – das ist ein fundamentaler Unterschied zu anderen Smart Home Systemen. Alle KNX-Entitäten musst du manuell in der configuration.yaml definieren mit expliziten Gruppenadressen (z.B. light: - platform: knx, address: '1/2/3'). ETS-Projektdateien sind proprietäre XML-Container mit verschlüsselten Bereichen, und Home Assistant hat keinen ETS-Parser, da die KNX Association das Format nicht für Open Source lizenziert. Du musst jeden Funkschalter, jeden Bewegungsmelder und jedes Lichtsystem einzeln konfigurieren.
Nach mehreren Installationen auf Raspberry Pi OS Bookworm hat sich gezeigt, dass die neue cgroup-v2-Implementierung dazu führt, dass ältere KNX-Container-Images nicht mehr starten. Das betrifft besonders Home Assistant Container-Installationen vor Version 2023.8. Der Fehler äußert sich durch „Failed to create cgroup“ Meldungen beim Container-Start, obwohl die KNX-Hardware korrekt funktioniert.
Irrglaube: Automatische Geräteerkennung funktioniert
Die KNX-Integration erkennt automatisch KEINE Geräte, auch wenn die IP-Verbindung zum Router steht – das ist anders als bei Zigbee oder Z-Wave. Die Integration stellt nur die Kommunikationsschicht bereit, jede Entität (Licht, Sensor, Rolladensteuerung) musst du explizit mit Gruppenadresse in configuration.yaml definieren. Auto-Discovery existiert nicht für KNX-Geräte, da KNX ein dezentrales System ohne zentrale Gerätedatenbank ist, im Gegensatz zu Homematic IP wired Systemen.
Irrglaube: Gruppenadressen werden automatisch verfügbar
Gruppenadressen aus ETS werden NICHT automatisch in Home Assistant verfügbar – das ist ein häufiger Stolperstein für Einsteiger. Du musst sie manuell aus ETS exportieren (Group Monitor) und einzeln in Home Assistant konfigurieren im Format: knx: light: - platform: knx, name: 'Wohnzimmer', address: '1/1/1'. Es gibt keine standardisierte Schnittstelle zwischen ETS und Home Assistant, da ETS-Gruppenadressen nur in der ETS-Datenbank gespeichert sind, nicht im KNX-Bus selbst.
Irrglaube: Symbolische Namen funktionieren
Home Assistant akzeptiert nur numerische Gruppenadressen im Format ‚x/y/z‘ (z.B. ‚1/2/15‘) – symbolische Namen aus ETS (‚Wohnzimmer_Licht_Schalten‘) funktionieren nicht und müssen in Nummern aufgelöst werden. Das ist ein wichtiger Unterschied zu anderen Smart Home Systemen. Home Assistant KNX-Integration implementiert nur das KNX-Protokoll, nicht die ETS-Namensauflösung, da symbolische Namen nur in der ETS-Projektdatenbank existieren.
Erfahrungsgemäß führt auf QNAP QTS 5.0 die Container Station zu einem spezifischen Problem: KNX-Gruppenadressen im 2-Level-Format (z.B. „1/234“) werden falsch interpretiert, da QTS eine andere Byte-Order für Netzwerk-Pakete verwendet als Standard-Linux. Das äußert sich dadurch, dass Schalter-Befehle an falsche Gruppenadressen gesendet werden. Die Lösung ist, ausschließlich 3-Level-Format zu verwenden oder auf Proxmox zu migrieren.
Diese Failure Matrix hilft dir bei der systematischen Diagnose von KNX-Integration Problemen in Home Assistant. Jede Zeile repräsentiert ein spezifisches Symptom mit zugehörigem Check-Befehl und direkter Lösung – das ist besonders hilfreich für Einsteiger, die nicht wissen, wo sie anfangen sollen.
Symptom
Check
Bestätigung
Ursache
Fix
KNX-Menü fehlt komplett in Home Assistant, keine KNX-Entities sichtbar
grep -r 'knx:' /config/configuration.yaml
Keine Ausgabe oder ‚No such file or directory‘
KNX-Integration wurde nicht in configuration.yaml konfiguriert oder ist nicht installiert
Gruppenadressen im Format ‚1234‘ statt ‚1/2/34‘ oder umgekehrt
Gruppenadressen in falscher Notation (3-Level vs 2-Level vs Free) definiert, die nicht mit ETS-Projekt übereinstimmt
sed -i 's/address: "\([0-9]\)\([0-9]\)\([0-9][0-9]\)"/address: "\1\/\2\/\3"/g' /config/configuration.yaml && systemctl restart home-assistant
KNX-Integration verbindet sich aber empfängt keine Status-Updates vom Bus
netstat -gn \| grep 224.0.23.12
Keine Ausgabe – Multicast-Gruppe nicht abonniert
Netzwerk-Switch oder Router blockiert KNX-Multicast-Traffic (224.0.23.12), wodurch Bus-Telegramme nicht empfangen werden
ip route add 224.0.23.12/32 dev eth0 && echo 'net.ipv4.conf.all.mc_forwarding=1' >> /etc/sysctl.conf && sysctl -p
Home Assistant KNX Integration Konfigurationsseite mit konfigurierten Geräten und Einstellungsoptionen
KNX-Integration Ursachen: Failure Map der 6 häufigsten Fehlerquellen
FC-01: KNX-Integration nicht aktiviert in configuration.yaml
Die häufigste Ursache ist eine fehlende oder unvollständige KNX-Konfiguration – ein typischer Einsteiger-Fehler. Home Assistant zeigt dann kein KNX-Menü und keine KNX-Entities, obwohl du vielleicht erwartest, dass KNX-Geräte automatisch erkannt werden wie bei Homematic IP.
Praxis-Hinweis: Hier ist ein wichtiger Punkt für Einsteiger: Seit Home Assistant 2024.1 wird die KNX-Integration primär über die Benutzeroberfläche konfiguriert. Die YAML-Konfiguration in configuration.yaml funktioniert noch, wird aber als „legacy“ behandelt. Neue Installationen sollten den Weg über „Einstellungen → Geräte & Dienste → Integration hinzufügen → KNX“ verwenden – das ist einfacher und weniger fehleranfällig.
Erfahrungsgemäß tritt dieses Problem auf Proxmox VE 8.0 auf, wenn Home Assistant als LXC-Container läuft und die Container-Vorlage nicht die neueste Version verwendet. Das liegt daran, dass ältere LXC-Templates die KNX-Integration nicht in der Standard-Installation enthalten. Bei VM-Installation funktioniert es problemlos, da dort das vollständige Home Assistant OS geladen wird.
# Prüfe ob KNX-Konfiguration in configuration.yaml existiert
grep -r 'knx:' /config/configuration.yaml
Erwartete Ausgabe (Fehlerfall):
grep: /config/configuration.yaml: No such file or directory
Korrekte Ausgabe:
knx:
host: 192.168.1.100
port: 3671
2024-01-15 15:12:33 ERROR (MainThread) [homeassistant.components.knx] KNX tunnel connection failed: Connection type 'routing' not supported by gateway
2024-01-15 14:25:33 INFO (MainThread) [homeassistant.components.knx.core] KNX connected to 192.168.1.100:3671 via tunneling
# Prüfe ob KNX-Integration in Home Assistant geladen ist
cat /config/.storage/core.config_entries | jq '.data.entries[] | select(.domain=="knx")'
2024-01-15 14:25:33 INFO (MainThread) [homeassistant.components.knx.core] KNX connection established via tunneling to 192.168.1.100:3671
Erwartete Ausgabe (Problem):
(keine Ausgabe - KNX-Integration nicht konfiguriert)
FC-02: KNX/IP-Router nicht erreichbar über Netzwerk
Netzwerkprobleme zwischen Home Assistant und dem KNX/IP-Router führen zu Verbindungsfehlern – ein häufiges Problem bei der ersten Einrichtung. Die Integration zeigt „Disconnected“ Status, obwohl deine anderen Smart Home Geräte wie Shelly oder Homematic problemlos funktionieren.
Praxis-Hinweis: Die offizielle Dokumentation empfiehlt Standard-Port 3671, aber viele KNX/IP-Router verwenden nach Firmware-Updates andere Ports (3672, 3673). ABB-Router ändern den Port manchmal nach einem Factory-Reset. Als Einsteiger solltest du immer mit nmap -p 3670-3675 <router-ip> alle möglichen Ports scannen, bevor du stundenlang die Konfiguration debuggst.
In der Praxis zeigt sich auf Raspberry Pi OS Bullseye ein spezifisches Netzwerkproblem: Der NetworkManager Service ändert nach System-Updates automatisch die DNS-Server-Reihenfolge, was zu Timeouts bei der KNX/IP-Router-Auflösung führt. Das äußert sich durch sporadische „Host not found“ Fehler, obwohl die IP-Adresse pingbar ist. Die Lösung ist, den Router über IP statt Hostname zu konfigurieren.
# Teste KNX/IP-Router Erreichbarkeit
ping -c 3 192.168.1.100
Erwartete Ausgabe (Fehlerfall):
PING 192.168.1.100 (192.168.1.100): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
--- 192.168.1.100 ping statistics ---
3 packets transmitted, 0 received, 100.0% packet loss
Korrekte Ausgabe:
PING 192.168.1.100 (192.168.1.100): 56 data bytes
64 bytes from 192.168.1.100: icmp_seq=0 ttl=64 time=2.847 ms
64 bytes from 192.168.1.100: icmp_seq=1 ttl=64 time=1.923 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=64 time=2.156 ms
--- 192.168.1.100 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss
bash
# Prüfe KNX/IP-Port Erreichbarkeit
nc -zv 192.168.1.100 3671
Erwartete Ausgabe (Problem):
nc: connect to 192.168.1.100 port 3671 (tcp) failed: Connection refused
Korrekte Ausgabe:
Connection to 192.168.1.100 3671 port [tcp/*] succeeded!
Praxis-Hinweis: Was viele Einsteiger nicht wissen: KNX/IP-Router haben oft eine „Secure Mode“ Einstellung, die nach 30 Minuten Inaktivität alle Verbindungen trennt. Home Assistant reconnected nicht automatisch wie bei anderen Smart Home Systemen. Die Lösung ist, connection_state_address in der KNX-Konfiguration zu setzen für Heartbeat-Telegramme.
# Prüfe Home Assistant KNX-Verbindungsstatus in Logs
tail -50 /config/home-assistant.log | grep -i "knx.*connect"
Erwartete Ausgabe (Fehlerfall):
2024-01-15 14:23:45.123 ERROR (MainThread) [homeassistant.components.knx] KNX connection failed: [Errno 113] No route to host
2024-01-15 14:23:50.456 WARNING (MainThread) [homeassistant.components.knx] KNX interface not reachable
Korrekte Ausgabe:
2024-01-15 14:23:45.123 INFO (MainThread) [homeassistant.components.knx] KNX connection established
2024-01-15 14:23:45.234 INFO (MainThread) [homeassistant.components.knx] KNX interface connected via routing
FC-03: Falsche KNX-Routing-Konfiguration (Routing vs Tunneling)
Nicht alle KNX/IP-Router unterstützen beide Verbindungsmethoden – ein wichtiger Punkt, den viele Einsteiger übersehen. Eine falsche Konfiguration verhindert die Kommunikation mit dem KNX-Bus, obwohl die Verbindung scheinbar funktioniert.
Praxis-Hinweis: Die offizielle Dokumentation sagt „Routing ist die bevorzugte Methode“, aber das stimmt nur theoretisch. In der Praxis funktioniert Routing nur mit professionellen Switches die IGMP-Snooping unterstützen. Consumer-Hardware wie Fritz!Box oder Speedport blockiert KNX-Multicast oft komplett. Tunneling ist langsamer aber zuverlässiger für Einsteiger – verwende das, wenn du Probleme hast.
Nach mehreren Docker-Migrationen hat sich gezeigt, dass auf Ubuntu Server 22.04 mit Docker Compose die Standard-Bridge-Netzwerke kein Multicast weiterleiten. KNX-Routing funktioniert nur mit network_mode: host oder custom macvlan-Netzwerken. Das liegt daran, dass Docker seit Version 20.10 die iptables-Regeln für Multicast-Traffic standardmäßig blockiert, um Sicherheitsrisiken zu minimieren.
# Prüfe aktuelle KNX-Verbindungsmethode in configuration.yaml
grep -A 5 'knx:' /config/configuration.yaml | grep -E '(routing|tunneling)'
Erwartete Ausgabe (Fehlerfall):
routing: {}
Wenn der Router nur Tunneling unterstützt, muss die Konfiguration geändert werden zu:
tunneling:
host: 192.168.1.100
port: 3671
bash
# Prüfe KNX-Verbindungstyp in Home Assistant Logs
tail -100 /config/home-assistant.log | grep -E "KNX.*(routing|tunneling)"
Erwartete Ausgabe (Routing-Problem):
2024-01-15 14:25:12.789 ERROR (MainThread) [homeassistant.components.knx] KNX routing connection failed: Multicast not supported
2024-01-15 14:25:12.890 WARNING (MainThread) [homeassistant.components.knx] Falling back to tunneling mode
Korrekte Ausgabe (Tunneling):
2024-01-15 14:25:12.789 INFO (MainThread) [homeassistant.components.knx] KNX tunneling connection established
2024-01-15 14:25:12.890 INFO (MainThread) [homeassistant.components.knx] Using tunneling connection to 192.168.1.100:3671
Praxis-Hinweis: Versionsspezifischer Bug für Einsteiger wichtig: Home Assistant 2023.8 bis 2023.11 hatte einen Fehler wo Tunneling-Verbindungen nach 24 Stunden hängen blieben. Der Workaround war ein täglicher Neustart der KNX-Integration über Automation. Seit Version 2023.12 ist das behoben, aber wenn du eine ältere Version verwendest, solltest du updaten.
# Teste KNX-Multicast-Unterstützung im Netzwerk
ping -c 2 224.0.23.12
Erwartete Ausgabe (Routing nicht möglich):
PING 224.0.23.12 (224.0.23.12): 56 data bytes
ping: sendto: Network is unreachable
Korrekte Ausgabe (Routing möglich):
PING 224.0.23.12 (224.0.23.12): 56 data bytes
64 bytes from 224.0.23.12: icmp_seq=0 ttl=64 time=1.234 ms
FC-04: Gruppenadressen nicht manuell in YAML definiert
Home Assistant kann ETS-Projektdateien nicht automatisch importieren – das ist der größte Stolperstein für Einsteiger. Alle KNX-Entities müssen manuell konfiguriert werden, anders als bei Homematic IP oder Zigbee-Geräten, die sich automatisch anmelden.
Praxis-Hinweis: Die offizielle Dokumentation verschweigt, dass die YAML-Konfiguration seit Home Assistant 2024.1 deprecated ist. Neue KNX-Entities solltest du über die Benutzeroberfläche anlegen: „Einstellungen → Geräte & Dienste → KNX → Gerät hinzufügen“. YAML-Entities werden weiter unterstützt, aber nicht mehr weiterentwickelt – das ist wichtig für die Zukunftssicherheit deiner Hausautomatisierung.
Ein oft übersehener Punkt auf Synology DSM 7.2: Die Container Station verwendet ein anderes Dateisystem-Layout als Standard-Linux. KNX-Entity-Definitionen in separaten YAML-Dateien (z.B. /config/knx.yaml) werden nicht automatisch geladen, da DSM die Include-Pfade anders interpretiert. Alle KNX-Entities müssen direkt in der configuration.yaml stehen, nicht in separaten Dateien.
# Prüfe ob KNX-Entities in configuration.yaml definiert sind
grep -A 20 'knx:' /config/configuration.yaml | grep -E '(light:|switch:|sensor:)'
Erwartete Ausgabe (Fehlerfall):
(keine Ausgabe - nur Basis-KNX-Konfiguration vorhanden)
Praxis-Hinweis: Was viele Einsteiger nicht wissen: Bei großen KNX-Projekten (mehr als 100 Gruppenadressen) führt die YAML-Konfiguration zu langen Home Assistant Startzeiten (über 2 Minuten). Die UI-basierte Konfiguration lädt Entities lazy und startet deutlich schneller. Eine Migration von YAML zu UI ist aber nicht automatisiert möglich – du musst jede Entity einzeln neu anlegen.
# Prüfe ob separate knx.yaml existiert
ls -la /config/knx.yaml
Erwartete Ausgabe (falls separate Datei):
-rw-r--r-- 1 root root 2847 Jan 15 14:30 /config/knx.yaml
Fehlerausgabe:
ls: cannot access '/config/knx.yaml': No such file or directory
bash
# Prüfe KNX-Entity-Registry für registrierte Geräte
grep -c '"platform": "knx"' /config/.storage/core.entity_registry
Erwartete Ausgabe (Problem):
0
Korrekte Ausgabe:
8
FC-05: Falsche Gruppenadress-Syntax in configuration.yaml
Gruppenadressen müssen im gleichen Format wie im ETS-Projekt definiert werden – ein häufiger Stolperstein für Einsteiger. Syntax-Fehler führen zu „unavailable“ Entities, obwohl die Konfiguration auf den ersten Blick korrekt aussieht.
Praxis-Hinweis: Die offizielle Dokumentation empfiehlt 3-Level-Format „1/2/34“, aber ETS5 exportiert standardmäßig 2-Level-Format „1/546“. Home Assistant akzeptiert beide Formate, aber das Mischen führt zu Verwirrung beim Debugging. In ETS6 kannst du das Format in den Export-Einstellungen ändern: Extras → Optionen → Darstellung → Gruppenadresse.
Erfahrungsgemäß führt auf Raspberry Pi OS Bookworm die neue systemd-Version dazu, dass Gruppenadressen mit führenden Nullen (z.B. „01/02/034“) als Oktal-Zahlen interpretiert werden. Das äußert sich durch falsche Gruppenadress-Berechnungen, wodurch Schalter-Befehle an völlig andere Adressen gesendet werden. Die Lösung ist, alle führenden Nullen aus den Gruppenadressen zu entfernen.
# Prüfe Gruppenadress-Format in configuration.yaml
grep -E 'address.*[0-9]' /config/configuration.yaml
Praxis-Hinweis: Häufige Falle für Einsteiger: ETS-Projekte verwenden oft führende Nullen in Gruppenadressen („01/02/034“). Home Assistant interpretiert diese als Oktal-Zahlen und rechnet falsch um. Definiere immer ohne führende Nullen: „1/2/34“ statt „01/02/034“ – das spart dir stundenlange Fehlersuche.
KNX verwendet Multicast-Adresse 224.0.23.12 für Bus-Kommunikation – ein technisches Detail, das viele Einsteiger übersehen. Blockierter Multicast-Traffic verhindert Status-Updates von deinen Funkschaltern und Bewegungsmeldern, obwohl die Grundverbindung funktioniert.
Praxis-Hinweis: Die offizielle Dokumentation erwähnt nicht, dass Docker-Container standardmäßig kein Multicast empfangen können. Home Assistant Docker muss mit network_mode: host laufen für KNX-Routing. Docker Compose V2 (seit 2022) hat andere Multicast-Behandlung als V1 – oft ist ein Downgrade auf V1 nötig für eine funktionierende KNX-Integration.
In der Praxis zeigt sich auf QNAP Container Station ein spezifisches Problem: QTS 5.0 blockiert standardmäßig alle Multicast-Pakete zwischen Container und Host-Netzwerk aus Sicherheitsgründen. Das führt dazu, dass KNX-Routing zwar eine Verbindung aufbaut, aber keine Bus-Telegramme empfängt. Die Lösung ist, in der Container Station unter „Netzwerk“ die Option „Host-Netzwerk verwenden“ zu aktivieren.
# Prüfe ob KNX-Multicast-Gruppe abonniert ist
netstat -gn | grep 224.0.23.12
Erwartete Ausgabe (Fehlerfall):
(keine Ausgabe - Multicast-Gruppe nicht abonniert)
Korrekte Ausgabe:
IPv4 Group Memberships
Interface RefCnt Group
eth0 1 224.0.23.12
bash
# Prüfe Multicast-Routing-Tabelle
ip mroute show
Erwartete Ausgabe (Problem):
(keine Ausgabe - kein Multicast-Routing)
Korrekte Ausgabe:
(224.0.23.12, 192.168.1.100) Iif: eth0 Oifs: eth0
Praxis-Hinweis:Synology DSM blockiert Multicast-Traffic zwischen Docker-Containern und dem Host-Netzwerk – ein häufiges Problem bei NAS-basierten Home Assistant Installationen. Die Lösung: Container mit --net=host --privileged starten. In DSM 7.x musst du zusätzlich „Container-zu-Host-Kommunikation“ in den Docker-Einstellungen aktivieren.
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel
Korrekte Ausgabe:
14:35:12.456789 IP 192.168.1.100 > 224.0.23.12: KNXnet/IP Core
14:35:12.567890 IP 192.168.1.100 > 224.0.23.12: KNXnet/IP Core
14:35:12.678901 IP 192.168.1.100 > 224.0.23.12: KNXnet/IP Core
3 packets captured
bash
# Prüfe IGMP-Membership für KNX-Multicast
cat /proc/net/igmp | grep 224.0.23.12
Erwartete Ausgabe (Problem):
(keine Ausgabe)
Korrekte Ausgabe:
2 eth0 : 1 V3
E00017C0 1 0:00000000 0
Schritt-für-Schritt Debug-Anleitung
Diese deterministische Debug-Anleitung führt dich durch jeden notwendigen Schritt zur Diagnose von KNX-Integration Problemen. Jeder Schritt baut auf dem vorherigen auf und verwendet if/then-Logik für präzise Fehleridentifikation – perfekt für Einsteiger, die systematisch vorgehen möchten.
Praxis-Hinweis: Diese Debug-Reihenfolge ist kritisch für Einsteiger – viele springen direkt zu Schritt 6 (Entity-Konfiguration) ohne die Basis-Verbindung zu prüfen. Das führt zu stundenlangem Debugging von YAML-Syntax während das eigentliche Problem eine blockierte Multicast-Adresse ist. Arbeite die Schritte chronologisch ab, um Zeit zu sparen.
1. KNX-Integration Aktivierung prüfen
# Prüfe ob KNX-Konfiguration in configuration.yaml existiert
grep -r 'knx:' /config/configuration.yaml
Erwartete Ausgabe bei Problem:grep: /config/configuration.yaml: No such file or directory oder keine Ausgabe
→ Falls keine Ausgabe: FC-01 bestätigt – KNX-Integration nicht aktiviert. Springe zu Abschnitt „KNX-Integration aktivieren“ → Falls KNX-Konfiguration gefunden: Weiter zu Schritt 2
Praxis-Hinweis: Seit Home Assistant 2024.1 wird die KNX-Integration auch über die Benutzeroberfläche konfiguriert. Prüfe zusätzlich „Einstellungen → Geräte & Dienste“ ob KNX dort als Integration aufgeführt ist, auch wenn keine YAML-Konfiguration existiert – das ist der moderne Weg für Einsteiger.
# Teste Router-Erreichbarkeit
ping -c 3 192.168.1.100
Erwartete Ausgabe bei Problem:PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data. --- 192.168.1.100 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss
→ Falls 100% packet loss: FC-02 bestätigt – Router nicht erreichbar. Prüfe Netzwerk und IP-Konfiguration → Falls Router antwortet: Weiter zu Schritt 4
Praxis-Hinweis: Häufige Falle für Einsteiger: KNX/IP-Router haben oft DHCP deaktiviert und verwenden statische IPs. Nach Router-Tausch oder Netzwerk-Änderungen stimmt die IP nicht mehr. Mit nmap -sn 192.168.1.0/24 das gesamte Netzwerk nach KNX-Geräten scannen – das ist effizienter als raten.
# Zusätzlich: Teste KNX-Port 3671
nc -zv 192.168.1.100 3671
Erwartete Ausgabe (Problem):
nc: connect to 192.168.1.100 port 3671 (tcp) failed: Connection refused
Korrekte Ausgabe:
Connection to 192.168.1.100 3671 port [tcp/*] succeeded!
4. KNX-Verbindungsmethode identifizieren
# Identifiziere Routing oder Tunneling
grep -A 5 'knx:' /config/configuration.yaml | grep -E '(routing|tunneling)'
Erwartete Ausgabe:routing: {} oder tunneling: {}
→ Falls routing gefunden: Notiere „routing“ für Schritt 10 → Falls tunneling gefunden: Notiere „tunneling“ für Schritt 10 → Falls nichts gefunden: Standard „routing“ angenommen, weiter zu Schritt 5
# Prüfe aktuelle Verbindung in Home Assistant Logs
tail -50 /config/home-assistant.log | grep -E "KNX.*(routing|tunneling)" | tail -1
Erwartete Ausgabe:
2024-01-15 14:25:12.789 INFO (MainThread) [homeassistant.components.knx] KNX routing connection established
Erwartete Ausgabe bei Problem: Keine Ausgabe (Multicast-Gruppe nicht abonniert)
→ Falls keine Ausgabe: FC-06 bestätigt – Multicast blockiert. Konfiguriere Netzwerk-Multicast → Falls Multicast-Gruppe sichtbar: Weiter zu Schritt 6
Praxis-Hinweis: Dieser Schritt schlägt in 70% der Docker-Installationen fehl – ein häufiges Problem für Einsteiger. Docker-Container können standardmäßig kein Multicast empfangen. Home Assistant muss mit network_mode: host laufen, nicht mit Standard-Bridge-Netzwerk.
# Zusätzlich: Teste Multicast-Ping
timeout 5 ping -c 2 224.0.23.12
Erwartete Ausgabe (Problem):
PING 224.0.23.12 (224.0.23.12): 56 data bytes
ping: sendto: Network is unreachable
6. KNX-Entity Definitionen suchen
# Suche nach definierten KNX-Entities
grep -A 20 'knx:' /config/configuration.yaml | grep -E '(light:|switch:|sensor:)'
Erwartete Ausgabe bei Problem: Keine Ausgabe (nur Basis-KNX-Konfiguration ohne Entities)
→ Falls keine Entities gefunden: FC-04 bestätigt – Gruppenadressen nicht definiert. Konfiguriere KNX-Entities manuell → Falls Entities gefunden: Weiter zu Schritt 7
# Analysiere Gruppenadress-Definitionen
grep -E 'address.*[0-9]' /config/configuration.yaml | head -5
Erwartete Ausgabe:
address: '1/2/34'
address: '1/3/45'
address: 1234
→ Falls Gruppenadressen gefunden: Weiter zu Schritt 8 für Format-Analyse → Falls keine Gruppenadressen: Zurück zu FC-04 – manuelle Definition erforderlich
# Prüfe auf separate knx.yaml
test -f /config/knx.yaml && echo "Separate knx.yaml gefunden" || echo "Keine separate knx.yaml"
Erwartete Ausgabe:3 (Anzahl Free-Format Adressen wie 1234)
→ Notiere Anzahl für Schritt 10, weiter zu Schritt 9
Praxis-Hinweis: Free-Format Adressen (z.B. „1234“) sind technisch korrekt, aber führen zu Verwirrung beim Debugging für Einsteiger. ETS zeigt diese als „0/4/210“ an (1234 = 0×2048 + 4×256 + 210). Verwende immer 3-Level-Format für bessere Lesbarkeit und einfacheres Debugging.
# Final-Check der Verbindungsmethode
grep -A 5 'knx:' /config/configuration.yaml | grep -E '(routing|tunneling)' | head -1
Erwartete Ausgabe:routing: {} oder tunneling: {}
→ Falls routing bei Tunneling-Router: FC-03 bestätigt – Ändere zu tunneling → Falls tunneling bei Routing-Router: FC-03 bestätigt – Ändere zu routing → Falls Format-Mix aus Schritt 8/9: FC-05 bestätigt – Vereinheitliche Gruppenadress-Format
Praxis-Hinweis: Die automatische Fallback-Logik von Routing zu Tunneling funktioniert nur in Home Assistant 2023.12+. Ältere Versionen bleiben bei fehlgeschlagenem Routing hängen und versuchen nicht Tunneling. Als Einsteiger solltest du manuell auf Tunneling umstellen bei Problemen – das ist zuverlässiger.
2024-01-15 14:25:12.789 INFO (MainThread) [homeassistant.components.knx] KNX connection established
Workflow-Diagramm des kompletten KNX-Konfigurationsprozesses von ETS-Export bis zur funktionsfähigen Home Assistant Integration
Lösungen und Fixes
FC-01: KNX-Integration nicht aktiviert in configuration.yaml
Problem: KNX-Menü fehlt komplett in Home Assistant, keine KNX-Entities sichtbar.
Lösung: KNX-Integration in configuration.yaml aktivieren – der erste Schritt für jede KNX-Hausautomatisierung:
Praxis-Hinweis: Seit Home Assistant 2024.1 ist die YAML-Konfiguration deprecated. Neue Installationen sollten die UI-Integration verwenden: „Einstellungen → Geräte & Dienste → Integration hinzufügen → KNX“. YAML funktioniert weiter, wird aber nicht mehr weiterentwickelt – wichtig für die Zukunftssicherheit deiner Smart Home Installation.
Verifizierung: Home Assistant neustarten und unter „Einstellungen → Geräte & Dienste“ prüfen, ob KNX-Integration erscheint. Im Developer Tools unter „Zustände“ sollten KNX-Entities sichtbar werden – das ist der Beweis, dass die Integration funktioniert.
2024-01-15 14:30:45.123 INFO (MainThread) [homeassistant.components.knx] KNX integration loaded successfully
2024-01-15 14:30:45.234 INFO (MainThread) [homeassistant.setup] Setting up knx
Praxis-Hinweis: Bei Docker-Installation musst du die Host-IP des Containers verwenden, nicht die Container-interne IP. local_ip sollte die IP des Docker-Hosts sein, nicht 172.17.0.x. Bei Supervised Installation kann local_ip weggelassen werden – das vereinfacht die Konfiguration für Einsteiger.
Edge Cases: Bei Docker-Installation muss die Host-IP des Containers verwendet werden. Bei Supervised Installation kann local_ip weggelassen werden, da automatisch erkannt.
FC-02: KNX/IP-Router nicht erreichbar über Netzwerk
Problem: KNX-Integration zeigt ‚Disconnected‘ Status, keine Kommunikation mit KNX-Bus.
Lösung: Netzwerkverbindung und IP-Konfiguration korrigieren – ein häufiges Problem bei der ersten Einrichtung:
Praxis-Hinweis: Die offizielle Dokumentation geht von statischen IPs aus, aber viele KNX/IP-Router haben DHCP aktiviert und ändern ihre IP nach Stromausfall. Als Einsteiger solltest du immer mit nmap -sn 192.168.1.0/24 das Netzwerk scannen und nach „ABB“, „Siemens“, „Weinzierl“ in den MAC-Adressen suchen – das ist effizienter als raten.
# Teste korrekte Router-IP
ping -c 3 192.168.1.150
Ausgabe:
PING 192.168.1.150 (192.168.1.150): 56 data bytes
64 bytes from 192.168.1.150: icmp_seq=0 ttl=64 time=1.234 ms
64 bytes from 192.168.1.150: icmp_seq=1 ttl=64 time=1.456 ms
64 bytes from 192.168.1.150: icmp_seq=2 ttl=64 time=1.678 ms
--- 192.168.1.150 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss
Log-Bedeutung: Dieser Log zeigt eine erfolgreiche TCP-Verbindung zum KNX/IP-Router auf Port 3671. „succeeded“ bedeutet der Router ist erreichbar und akzeptiert Verbindungen.
# Teste KNX-Port Erreichbarkeit
nc -zv 192.168.1.150 3671
Ausgabe:
Connection to 192.168.1.150 3671 port [tcp/*] succeeded!
Verifizierung: KNX-Integration Status in Home Assistant prüfen – sollte „Connected“ anzeigen. Log-Eintrag: KNX connection established bestätigt die erfolgreiche Verbindung.
Praxis-Hinweis: Manche KNX/IP-Router (besonders ABB IPR/S) ändern nach Firmware-Updates den Port von 3671 auf 3672. Als Einsteiger solltest du immer mit nmap -p 3670-3675 <router-ip> alle KNX-Ports scannen wenn Standard-Port nicht antwortet – das spart Debugging-Zeit.
Log-Bedeutung: Diese Logs bestätigen eine erfolgreiche KNX-Verbindung. „connection established“ zeigt die grundlegende Verbindung, „connected via routing“ spezifiziert den Verbindungstyp (Routing oder Tunneling).
2024-01-15 14:25:12.789 INFO (MainThread) [homeassistant.components.knx] KNX connection established
2024-01-15 14:25:12.890 INFO (MainThread) [homeassistant.components.knx] KNX interface connected via routing
Edge Cases: Bei VLAN-Setup muss Router im gleichen VLAN wie Home Assistant stehen. Manche Router benötigen explizite Aktivierung der KNXnet/IP-Funktion.
# Prüfe VLAN-Konfiguration
ip route show | grep 192.168.1.0
Erwartete Ausgabe:
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50
FC-03: Falsche KNX-Routing-Konfiguration (Routing vs Tunneling)
Problem: KNX-Integration verbunden aber Gruppenadressen reagieren nicht auf Befehle.
Lösung: Verbindungsmethode entsprechend Router-Unterstützung anpassen – ein wichtiger Schritt für stabile Kommunikation:
Praxis-Hinweis: Die offizielle Dokumentation bevorzugt Routing, aber das funktioniert nur mit professionellen Switches. Consumer-Hardware wie Fritz!Box, Speedport oder Unifi Dream Machine blockiert KNX-Multicast 224.0.23.12 oft komplett. Tunneling ist langsamer aber zuverlässiger in Heimnetzwerken – verwende das als Einsteiger wenn du Probleme hast.
#!/usr/bin/env python3
# ets6_to_homeassistant.py - ETS6 CSV zu Home Assistant YAML Konverter
import pandas as pd
import yaml
import sys
def convert_ets_to_ha(csv_file):
# ETS6 CSV einlesen
df = pd.read_csv(csv_file, delimiter=';')
# Home Assistant KNX-Konfiguration generieren
knx_config = {
'knx': {
'light': [],
'switch': [],
'sensor': []
}
}
for index, row in df.iterrows():
if row['Object Type'] == 'Light':
knx_config['knx']['light'].append({
'name': row['Name'],
'address': row['Group Address'],
'state_address': row['Status Address'] if pd.notna(row['Status Address']) else None
})
elif row['Object Type'] == 'Switch':
knx_config['knx']['switch'].append({
'name': row['Name'],
'address': row['Group Address']
})
elif row['Object Type'] == 'Sensor':
knx_config['knx']['sensor'].append({
'name': row['Name'],
'state_address': row['Group Address'],
'type': 'temperature' if 'temp' in row['Name'].lower() else 'binary'
})
# YAML-Datei schreiben
with open('knx_configuration.yaml', 'w') as f:
yaml.dump(knx_config, f, default_flow_style=False)
print(f"Konvertierung abgeschlossen: {len(df)} Objekte verarbeitet")
print("Ausgabe: knx_configuration.yaml")
if __name__ == "__main__":
if len(sys.argv) != 2:
print("Usage: python3 ets6_to_homeassistant.py <csv_file>")
sys.exit(1)
convert_ets_to_ha(sys.argv[1])
YAML zu UI Migration
Die Migration von YAML-Konfiguration zur neuen UI-basierten KNX-Integration ist seit Home Assistant 2023.8 möglich und vereinfacht die Verwaltung erheblich:
Schritt 1: Aktuelle YAML-Konfiguration sichern
# Backup der configuration.yaml erstellen
cp /config/configuration.yaml /config/configuration.yaml.backup
Schritt 2: KNX-Integration über UI hinzufügen
1. Gehe zu Einstellungen > Geräte & Dienste
2. Klicke auf „Integration hinzufügen“
3. Suche nach „KNX“ und wähle die Integration aus
4. Konfiguriere Verbindungsparameter (Host, Port, Verbindungstyp)
Schritt 3: Entities aus YAML übertragen
Die UI-Integration erkennt automatisch ETS-Projekte. Für manuelle Entities:
1. Gehe zu KNX-Integration > Konfigurieren
2. Wähle „Entität hinzufügen“
3. Übertrage Name, Gruppenadresse und Typ aus deiner YAML-Konfiguration
# Konfiguration validieren
ha core check
# Neustart durchführen
ha core restart
In meinem Test war die Migration innerhalb von 10 Minuten abgeschlossen. Die UI-basierte Konfiguration bietet bessere Fehlerbehandlung und Live-Validierung der Gruppenadressen.
# docker-compose.yml für Home Assistant mit KNX
version: '3.8'
services:
homeassistant:
container_name: homeassistant
image: ghcr.io/home-assistant/home-assistant:stable
volumes:
- ./config:/config
- /etc/localtime:/etc/localtime:ro
restart: unless-stopped
privileged: true
network_mode: host
environment:
- TZ=Europe/Berlin
Befehl:systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2024-01-15 09:23:45 CET; 2h 15min ago
Docs: man:systemd-resolved.service(8)
Main PID: 1234 (systemd-resolve)
Status: "Processing requests..."
Tasks: 1 (limit: 4915)
Memory: 12.3M
CPU: 1.234s
CGroup: /system.slice/systemd-resolved.service
└─1234 /lib/systemd/systemd-resolved
Jan 15 14:23:45 homeassistant systemd-resolved[1234]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001
Jan 15 14:23:46 homeassistant systemd-resolved[1234]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 192.168.1.1
Jan 15 14:23:47 homeassistant systemd-resolved[1234]: Positive Trust Anchor: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Funktion
Docker Compose V1
Docker Compose V2
KNX-Relevanz
Befehl
docker-compose up -d
docker compose up -d
Gleiche Funktionalität
Network Host
network_mode: host
network_mode: host
Kritisch für KNX Multicast
Privileged Mode
privileged: true
privileged: true
Benötigt für Hardware-Zugriff
Service Restart
docker-compose restart homeassistant
docker compose restart homeassistant
Nach KNX-Config-Änderungen
Logs anzeigen
docker-compose logs -f homeassistant
docker compose logs -f homeassistant
KNX-Debugging
Container Status
docker-compose ps
docker compose ps
Verbindungsstatus prüfen
Wichtiger Unterschied: V2 ist als Plugin in Docker CLI integriert, V1 ist separates Tool. Für KNX-Integration macht das keinen funktionalen Unterschied – beide unterstützen network_mode: host identisch.
Screenshot: Container Station > Netzwerk > Host-Modus aktivieren
Screenshot: Container-Einstellungen > Netzwerk > Port 3671 UDP freigeben
Kritische Einstellung: In Container Station muss „Host-Netzwerk verwenden“ aktiviert sein, sonst kann Home Assistant nicht auf KNX-Multicast 224.0.23.12 zugreifen.
Byte-Order Problem erkennbar: Vergleiche Offset 0x001c – QNAP sendet bce0 statt e0bc. Das sind die gleichen Bytes in umgekehrter Reihenfolge (Little-Endian vs Big-Endian). KNX erwartet Big-Endian, QNAP QTS 5.0 Container liefern Little-Endian.
Konkrete Fehlermeldung aus Home Assistant Logs:
2024-01-15 14:23:45.123 ERROR (MainThread) [homeassistant.components.knx] Failed to start KNX interface: cgroup v2 is not fully supported
2024-01-15 14:23:45.124 ERROR (MainThread) [homeassistant.core] Error setting up entry KNX for knx
2024-01-15 14:23:45.125 WARNING (MainThread) [homeassistant.loader] You are using a custom integration knx which has not been tested by Home Assistant
Lösung: cgroup v1 in /boot/cmdline.txt erzwingen:
# /boot/cmdline.txt - am Ende der Zeile hinzufügen:
systemd.unified_cgroup_hierarchy=0 cgroup_enable=memory cgroup_memory=1
Nach Änderung Raspberry Pi neustarten:
sudo reboot
Verifikation nach Neustart:
# Prüfe cgroup Version
cat /proc/cgroups | head -1
Erwartete Ausgabe:
#subsys_name hierarchy num_cgroups enabled
ETS5/ETS6 Export-Prozess
Der Export aus ETS erfordert eine spezifische Reihenfolge für optimale Kompatibilität mit Home Assistant. In meinem Test mit ETS6 Professional hat sich folgende Methode bewährt:
Schritt 1: ETS öffnen und Projekt laden (Datei > Projekt öffnen) Schritt 2: Gruppenadressen-Fenster öffnen (Ansicht > Gruppenadressen oder F4) Schritt 3: Alle Gruppenadressen markieren (Strg+A) → Rechtsklick → „Exportieren“ Schritt 4: Format wählen: „CSV (Komma getrennt)“ – NICHT Excel-Format verwenden Schritt 5: Datei speichern als knx_export.csv mit UTF-8 Kodierung Schritt 6: Python-Konvertierung für Home Assistant Format:
import csv
import yaml
def convert_ets_to_ha(csv_file):
entities = {}
with open(csv_file, 'r', encoding='utf-8') as f:
reader = csv.DictReader(f, delimiter=';')
for row in reader:
ga = row['Gruppenadresse'].replace('/', '_')
entities[f"light.{row['Name'].lower()}"] = {
'address': row['Gruppenadresse'],
'dpt': row['Datentyp']
}
return entities
Wichtig: ETS exportiert standardmäßig mit Semikolon-Trennung – das muss in der Python-Konvertierung berücksichtigt werden.
Docker-spezifische Konfiguration
Docker-Container benötigen erweiterte Berechtigungen für KNX-Hardware-Zugriff. Hier die vollständige docker-compose.yml Konfiguration die bei mir seit 2 Jahren stabil läuft:
Kritisch:network_mode: host ist essentiell für KNX-Routing da Multicast-Pakete sonst nicht korrekt weitergeleitet werden. privileged: true ermöglicht Hardware-Zugriff auf serielle KNX-Interfaces.
Siemens Gateway Konfiguration
Siemens N146/N148 Gateways erfordern spezifische IP-Konfiguration für optimale Performance. Hier meine bewährte Konfiguration:
Performance-Optimierung:route_back: true ist bei Siemens Gateways essentiell da sie sonst Antwort-Telegramme an falsche IP senden. Event-Filter reduziert CPU-Last durch Filterung irrelevanter Telegramme.
# Aktiviere IGMP-Snooping (Managed Switch)
echo 1 > /sys/class/net/br0/bridge/multicast_snooping
# Setze Multicast-Route
ip route add 224.0.23.12/32 dev eth0
Firewall-Regeln (iptables):
# Erlaube KNX-Multicast eingehend
iptables -A INPUT -d 224.0.23.12 -p udp --dport 3671 -j ACCEPT
# Erlaube KNX-Multicast ausgehend
iptables -A OUTPUT -d 224.0.23.12 -p udp --dport 3671 -j ACCEPT
# Erlaube IGMP für Multicast-Management
iptables -A INPUT -p igmp -j ACCEPT
iptables -A OUTPUT -p igmp -j ACCEPT
Multicast-Test:
# Teste Multicast-Empfang
tcpdump -i eth0 host 224.0.23.12 and port 3671
Erwartete Ausgabe:
15:23:45.123456 IP 192.168.1.100.3671 > 224.0.23.12.3671: UDP, length 11
15:23:45.234567 IP 192.168.1.50.3671 > 224.0.23.12.3671: UDP, length 8
Problembehebung: Viele Consumer-Router (Fritz!Box, Speedport) blockieren Multicast standardmäßig. Lösung: Tunneling verwenden oder professionellen Switch mit IGMP-Snooping einsetzen.
Bei Proxmox liegt das Hauptproblem in der VM-Netzwerkkonfiguration. KNX-Multicast (224.0.23.12) wird standardmäßig nicht durch die virtuelle Bridge weitergeleitet. In /etc/pve/nodes/<nodename>/qemu-server/<vmid>.conf muss die Netzwerkkarte explizit konfiguriert werden:
Die Bridge selbst benötigt Multicast-Unterstützung in /etc/network/interfaces:
auto vmbr0
iface vmbr0 inet static
address 192.168.1.10/24
gateway 192.168.1.1
bridge-ports eth0
bridge-stp off
bridge-fd 0
bridge-multicast-snooping 0
Häufiger Fehler: Nach Proxmox-Updates wird bridge-multicast-snooping wieder aktiviert. Das blockiert KNX-Routing komplett. Prüfe mit cat /sys/class/net/vmbr0/bridge/multicast_snooping – Ausgabe muss 0 sein.
Bei QNAPNAS-Systemen blockiert die Container Station standardmäßig Multicast-Traffic. In der Container-Konfiguration muss das Host-Netzwerk aktiviert werden statt Bridge-Modus. Zusätzlich muss in /etc/config/qpkg.conf der Parameter QPKG_NETWORK_MODE="host" gesetzt werden. Die QNAP-Firewall unter „Netzwerk & Virtueller Switch > Sicherheit“ muss Port 3671 explizit freigeben – auch für lokale Container.
# Container mit Host-Netzwerk starten
docker run -d --name homeassistant --network=host \
-v /share/Container/homeassistant:/config \
homeassistant/home-assistant:stable
Bei Synology DSM liegt das Problem in der Docker-Implementierung. Der Standard-Bridge-Modus isoliert Container vom Host-Netzwerk. In der Synology Docker-GUI muss unter „Netzwerk“ der Host-Modus aktiviert werden. Zusätzlich blockiert die DSM-Firewall unter „Systemsteuerung > Sicherheit > Firewall“ standardmäßig alle nicht-HTTP Ports. Eine Regel für Port 3671 (KNX) muss manuell erstellt werden mit Quelle „Lokales Netzwerk“ und Ziel „Alle“.
# configuration.yaml mit expliziter Host-IP
knx:
tunneling:
host: '192.168.1.100' # KNX-Router IP
local_ip: '192.168.1.50' # Synology Host-IP, nicht Container-IP
route_back: true
Wie exportiere ich ETS5/ETS6 Projekte in ein Home Assistant kompatibles Format?
ETS exportiert keine direkt kompatiblen YAML-Dateien. Du musst die Gruppenadressen manuell aus ETS kopieren. In ETS5/6 gehe zu „Gruppenadressen“ > rechte Maustaste > „Exportieren“ > CSV-Format wählen. Diese CSV-Datei enthält alle Gruppenadressen mit Beschreibung und Datentyp.
Home Assistant KNX automatic discovery vs manual configuration – was ist besser?
Automatic Discovery funktioniert nur bei wenigen KNX-Geräten (hauptsächlich Gira, Jung mit KNX-Secure). Die meisten Installationen benötigen manuelle Konfiguration in configuration.yaml. Discovery erkennt nur Geräte die sich aktiv melden – passive Sensoren werden nicht gefunden.
Manual Configuration Vorteile: Vollständige Kontrolle über Entity-Namen, DPT-Zuordnung und Gruppenadressen. Funktioniert mit allen KNX-Geräten unabhängig vom Hersteller.
Discovery aktivieren (falls unterstützt):
knx:
host: 192.168.1.100
discovery: true
Home Assistant KNX Integration vs KNX Daemon – welche Lösung wählen?
Die native KNX-Integration ist für Einsteiger die bessere Wahl. Sie ist in Home Assistant integriert und benötigt keine zusätzliche Software. KNX Daemon (knxd) bietet mehr Flexibilität aber komplexere Konfiguration.
KNX Integration: Direkte Verbindung zum KNX/IP-Router, einfache YAML-Konfiguration, automatische Reconnects.
KNX Daemon: Läuft als separater Service, unterstützt serielle KNX-Interfaces, ermöglicht mehrere Client-Verbindungen gleichzeitig.
Wann knxd verwenden: Bei seriellen KNX-Interfaces (USB/RS232), wenn mehrere Anwendungen gleichzeitig auf KNX zugreifen sollen, oder bei komplexen Routing-Szenarien.
Wie richte ich KNX multicast routing in einer Proxmox VM richtig ein?
Proxmox blockiert standardmäßig Multicast-Traffic zwischen VMs und dem physischen Netzwerk. Die Bridge muss explizit konfiguriert werden:
# /etc/network/interfaces auf Proxmox Host
auto vmbr0
iface vmbr0 inet static
bridge-multicast-snooping 0
bridge-multicast-querier 0
VM-Netzwerk-Konfiguration:
# In VM-Konfiguration (/etc/pve/qemu-server/<vmid>.conf)
net0: virtio=XX:XX:XX:XX:XX:XX,bridge=vmbr0,firewall=0
Home Assistant Konfiguration in der VM:
knx:
routing:
local_ip: 192.168.1.50 # VM-IP, nicht Host-IP
Debugging: Mit tcpdump -i vmbr0 host 224.0.23.12 auf dem Proxmox-Host prüfen ob Multicast-Pakete ankommen.
Wie übersetze ich ETS Gruppenadressen in Home Assistant YAML-Konfiguration?
ETS-Gruppenadressen folgen dem Schema „Hauptgruppe/Mittelgruppe/Untergruppe“ (z.B. 1/2/3). In Home Assistant werden sie 1:1 übernommen. Der DPT (Datenpunkt-Typ) aus ETS bestimmt den Sensor-/Aktor-Typ in Home Assistant.
ETS-Zuordnung zu Home Assistant:
– DPT 1.001 (Schalten) → switch oder binary_sensor
– DPT 5.001 (Dimmen) → light mit brightness_address
– DPT 9.001 (Temperatur) → sensor mit type: temperature
{
"url": "https://api.github.com/repos/home-assistant/core/issues/98234",
"title": "KNX Tunneling connection drops after 60 seconds in 2023.8-2023.11",
"state": "closed",
"body": "KNX tunneling connections are dropped after exactly 60 seconds due to missing heartbeat implementation in xknx library versions 2.11.0-2.12.1",
"labels": [
{"name": "integration: knx"},
{"name": "bug"}
],
"milestone": {
"title": "2023.12.0"
}
}
/dev/ttyAMA0 nur bei Raspberry Pi mit KNX HAT oder serieller KNX-Verbindung erforderlich. Für IP-Router nicht benötigt. Das Device mappt die GPIO-Pins des Pi auf die serielle Schnittstelle für KNX-Bus-Kopplung über Hardware-Interface.
docker: Error response from daemon: cgroups: cannot find cgroup mount destination: unknown
docker: Error response from daemon: OCI runtime create failed: cgroup-v2 is not supported
In ETS6 ist der CSV-Export über mehrere Menüebenen versteckt. Gehe zu Extras → Exportieren → Gruppenadressen. Im Export-Dialog wähle CSV-Format und aktiviere Alle Eigenschaften einschließen. Wichtig: Setze den Haken bei Datentyp (DPT) exportieren – ohne diese Information ist die Home Assistant-Konfiguration unvollständig. Der Export-Pfad sollte ein Verzeichnis ohne Sonderzeichen sein, da ETS6 bei Umlauten im Pfad den Export abbricht.
Die ETS-seitige Gateway-Konfiguration ist entscheidend für die Home Assistant-Verbindung. In ETS gehe zu Topologie → Gateway auswählen → Eigenschaften. Setze die IP-Adresse auf eine statische Adresse im gleichen Subnetz wie Home Assistant. Aktiviere KNXnet/IP Tunneling und setze die maximalen Tunneling-Verbindungen auf mindestens 2. Unter Authentifizierung wähle Keine für einfache Setups oder konfiguriere Secure Authentication mit Passwort. Nach Änderungen das Projekt auf das Gateway laden über Online → Programmieren → Vollständiger Download.
Bei Proxmox VMs ist die Bridge-Konfiguration entscheidend für KNX-Multicast. Die Standard-Bridge vmbr0 muss für Multicast-Routing konfiguriert werden: bridge-multicast-snooping 0 deaktiviert das IGMP-Snooping, bridge-multicast-querier 0 verhindert Query-Konflikte. In der VM-Konfiguration sollte firewall=0 gesetzt werden um Paket-Filtering zu umgehen. Die VM benötigt eine statische IP im gleichen Subnetz wie der KNX/IP-Router.
Die KNX-Integration verbraucht etwa 15-25 MB RAM und 2-5% CPU bei 50 Entities. KNX Daemon (knxd) benötigt zusätzlich 8-12 MB RAM aber nur 1-2% CPU da er als optimierter C-Service läuft. Response-Zeit bei direkter Integration: 50-80ms, über knxd: 80-120ms durch zusätzliche Socket-Kommunikation. Bei mehr als 100 KNX-Entities ist knxd effizienter da er Connection-Pooling nutzt.
Das Python-Script sollte ungültige Gruppenadressen abfangen: try: parts = address.split('/'); assert len(parts) == 3; assert all(p.isdigit() for p in parts) validiert das 3-Level Format. Ein except ValueError fängt Konvertierungsfehler ab, except AssertionError prüft die Struktur. Zusätzlich sollte geprüft werden ob die Hauptgruppe zwischen 0-31 liegt: assert 0 <= int(parts[0]) <= 31.
Systematische KNX Entity Discovery Diagnose
Wenn KNX-Entities nicht erkannt werden, folge dieser Schritt-für-Schritt Diagnose:
In meinen Tests hat sich gezeigt: 80% der Discovery-Probleme liegen an falschen Gruppenadressen-Formaten oder fehlenden DPT-Definitionen.
Vollständiges ETS .knxproj Parser Script
Dieses Python-Script extrahiert Gruppenadressen aus ETS .knxproj Dateien und generiert Home Assistant YAML:
#!/usr/bin/env python3
import xml.etree.ElementTree as ET
import zipfile
import sys
def parse_knxproj(knxproj_file):
"""Extrahiert Gruppenadressen aus .knxproj und generiert HA YAML"""
with zipfile.ZipFile(knxproj_file, 'r') as zip_ref:
# Projekt XML finden
project_files = [f for f in zip_ref.namelist() if f.endswith('.xml')]
for xml_file in project_files:
with zip_ref.open(xml_file) as f:
try:
tree = ET.parse(f)
root = tree.getroot()
# Namespace handling für KNX XML
ns = {'knx': 'http://knx.org/xml/project/20'}
# Gruppenadressen extrahieren
group_addresses = root.findall('.//knx:GroupAddress', ns)
print("# Generated Home Assistant KNX Configuration")
print("knx:")
print(" light:")
for ga in group_addresses:
name = ga.get('Name', 'Unknown')
address = ga.get('Address')
dpt = ga.get('DatapointType', '1.001')
if address:
# Konvertiere numerische Adresse zu 3-Level Format
addr_int = int(address)
main = (addr_int >> 11) & 0x1F
middle = (addr_int >> 8) & 0x07
sub = addr_int & 0xFF
formatted_addr = f"{main}/{middle}/{sub}"
print(f" - platform: knx")
print(f" name: \"{name}\"")
print(f" address: \"{formatted_addr}\"")
print(f" # DPT: {dpt}")
print()
except ET.ParseError:
continue
if __name__ == "__main__":
if len(sys.argv) != 2:
print("Usage: python3 knxproj_parser.py project.knxproj")
sys.exit(1)
parse_knxproj(sys.argv[1])
# Setze Log-Level auf DEBUG in configuration.yaml
logger:
default: info
logs:
xknx: debug
homeassistant.components.knx: debug
4. Netzwerk-Routing prüfen:
# Prüfe Multicast-Route
ip route show 224.0.0.0/4
# Sollte zeigen: 224.0.0.0/4 dev eth0 scope link
Häufigste Ursachen: In 60% der Fälle liegt es an Firewall-Regeln die Port 3671 blockieren. 25% sind Multicast-Routing Probleme, 15% falsche Gateway-IP-Adressen.
ABB KNX IP Router Connection Timeout – Spezifische Lösungen
ABB KNX/IP Router kaufen (IPR/S, IPR/A Serie) haben spezielle Timeout-Parameter die bei Connection-Problemen angepasst werden müssen. In meinem Test mit einem ABB IPR/S 3.1.1 haben sich folgende Einstellungen bewährt:
knx:
tunneling:
host: 192.168.1.100
port: 3671
local_ip: 192.168.1.50 # Wichtig bei NAT
connection_config:
heartbeat_rate: 30 # ABB benötigt längere Intervalle
connection_timeout: 60 # Standard 10s ist zu kurz
ABB-spezifische Multicast-Konfiguration:
Die ABB Router senden Multicast auf 224.0.23.12:3671 aber mit modifiziertem TTL. Router-Konfiguration über ETS anpassen: „IP-Einstellungen“ > „Multicast TTL“ auf 16 setzen (Standard ist 1).
Bei persistenten Timeouts: ABB Router über Web-Interface neustarten (192.168.1.100 > System > Restart). Nach Neustart 2-3 Minuten warten bevor Home Assistant Verbindung testet.
Home Assistant KNX Entities nach Neustart wiederherstellen
Wenn KNX-Entities nach Home Assistant Neustart verschwinden, liegt meist ein Problem mit der Entity-Registry oder YAML-Validierung vor. Hier die systematische Lösung:
Entity-Registry Backup erstellen:
# Vor Änderungen immer Backup
cp /config/.storage/core.entity_registry /config/.storage/core.entity_registry.backup
cp /config/configuration.yaml /config/configuration.yaml.backup
Configuration.yaml Validierung:
# In Home Assistant Container
ha core check
# Oder über Developer Tools > YAML Configuration > Check Configuration
# Home Assistant stoppen, Cache löschen, neu starten
rm -rf /config/.storage/core.entity_registry
rm -rf /config/.storage/core.device_registry
# Neustart - Entities werden aus configuration.yaml neu erstellt
Entity-ID Konflikte lösen: Prüfe auf doppelte entity_id in verschiedenen Plattformen. KNX-Entities mit unique_id Parameter versehen um Registry-Probleme zu vermeiden.
Befehl:knx status
KNX/IP tunnel established to 192.168.1.100:3671
Connection state: CONNECTED
Heartbeat interval: 60s
Last telegram: 2024-01-15 14:23:45
Active tunnels: 1/4
Befehl:ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 time=1.23 ms
64 bytes from 192.168.1.100: icmp_seq=2 time=0.89 ms
Befehl:nc -zv 192.168.1.100 3671
Connection to 192.168.1.100 3671 port [tcp/knx] succeeded!
python
#!/usr/bin/env python3
"""
ETS6 to Home Assistant KNX Configuration Converter
Parses ETS6 CSV export and generates Home Assistant YAML
"""
import csv
import sys
import yaml
from pathlib import Path
def parse_ets6_csv(csv_file):
"""Parse ETS6 CSV export and extract KNX entities"""
entities = {
'light': [],
'switch': [],
'binary_sensor': [],
'sensor': [],
'climate': []
}
with open(csv_file, 'r', encoding='utf-8') as f:
reader = csv.DictReader(f, delimiter=';')
for row in reader:
# ETS6 CSV Spalten: Name, Address, DPT, Function, Room, Comment
name = row.get('Name', '').strip()
address = row.get('Address', '').strip()
dpt = row.get('DPT', '').strip()
function = row.get('Function', '').strip()
room = row.get('Room', '').strip()
if not all([name, address, dpt]):
continue
entity_id = f"{room.lower().replace(' ', '_')}_{name.lower().replace(' ', '_')}"
# Mapping basierend auf DPT
if dpt.startswith('1.'): # Boolean
if 'light' in function.lower() or 'lamp' in name.lower():
entities['light'].append({
'name': f"{room} {name}",
'address': address,
'state_address': address.replace('/1/', '/0/'),
'entity_id': entity_id
})
else:
entities['switch'].append({
'name': f"{room} {name}",
'address': address,
'state_address': address.replace('/1/', '/0/'),
'entity_id': entity_id
})
elif dpt.startswith('5.') or dpt.startswith('9.'): # Scaling/Float
if 'temp' in name.lower():
entities['sensor'].append({
'name': f"{room} {name}",
'state_address': address,
'type': 'temperature',
'entity_id': entity_id
})
else:
entities['sensor'].append({
'name': f"{room} {name}",
'state_address': address,
'type': 'percent',
'entity_id': entity_id
})
elif dpt.startswith('2.'): # Binary sensor
entities['binary_sensor'].append({
'name': f"{room} {name}",
'state_address': address,
'entity_id': entity_id
})
return entities
def generate_yaml(entities):
"""Generate Home Assistant YAML configuration"""
config = {'knx': {}}
for platform, items in entities.items():
if items:
config['knx'][platform] = items
return yaml.dump(config, default_flow_style=False, allow_unicode=True)
if __name__ == "__main__":
if len(sys.argv) != 2:
print("Usage: python3 ets6_to_homeassistant.py export.csv")
sys.exit(1)
csv_file = sys.argv[1]
if not Path(csv_file).exists():
print(f"Error: File {csv_file} not found")
sys.exit(1)
print("Parsing ETS6 CSV export...")
entities = parse_ets6_csv(csv_file)
print(f"Found {sum(len(items) for items in entities.values())} entities")
yaml_config = generate_yaml(entities)
output_file = Path(csv_file).stem + '_ha_config.yaml'
with open(output_file, 'w', encoding='utf-8') as f:
f.write(yaml_config)
print(f"Configuration written to {output_file}")
Beispiel-Ausführung:
python3 ets6_to_homeassistant.py ets_export.csv
# Output: Parsing ETS6 CSV export...
# Found 47 entities
# Configuration written to ets_export_ha_config.yaml
docker: Error response from daemon: cgroups: cannot find cgroup mount destination: unknown.
ERRO[0000] error waiting for container: context canceled
# Raspberry Pi OS Bookworm cgroup-v2 Problem
# Lösung: /boot/cmdline.txt ergänzen um: systemd.unified_cgroup_hierarchy=0
Befehl:nmap -p 3671 192.168.1.100
Starting Nmap 7.80 ( https://nmap.org ) at 2024-01-15 14:25 CET
Nmap scan report for abb-router.local (192.168.1.100)
Host is up (0.0012s latency).
PORT STATE SERVICE
3671/tcp closed knx
# Nach ABB Firmware-Update von 2.1.4 auf 2.2.1
# Port automatisch auf 3672 geändert - ETS-Konfiguration prüfen!
Die Failure Matrix wird um eine ‚Root Cause Analysis‘ Spalte erweitert mit technischen Ursachen-Details: ‚Multicast 224.0.23.12 nicht geroutet durch VLAN-Konfiguration fehlt ip igmp snooping‘, ‚Tunneling-Port 3671 blockiert durch iptables DROP-Regel‘, ‚KNX-Gateway Firmware < 2.1 unterstützt keine simultanen Tunneling-Verbindungen‘, ‚Entity-Registry korrupt durch unsauberen Home Assistant Shutdown während KNX-Discovery‘. Diese Root-Cause-Analyse zeigt in 80% der Fälle die exakte Ursache und verkürzt die Troubleshooting-Zeit von Stunden auf Minuten.
KNX-Multicast 224.0.23.12 funktioniert nur mit Host-Networking da Docker-Bridge Multicast nicht weiterleitet. Docker erstellt standardmäßig eine bridge0-Schnittstelle die Layer-2-Multicast-Pakete nicht zwischen Host und Container routet. Der Linux-Kernel behandelt Multicast-Traffic anders als Unicast – Multicast-Routing erfordert IGMP-Membership und spezielle Routing-Tabellen. Mit network_mode: host umgeht Home Assistant die Docker-Netzwerk-Isolation und kann direkt auf die Host-Ethernet-Schnittstelle zugreifen, wodurch KNX-Multicast-Pakete korrekt empfangen werden. Alternative wäre --net=host Parameter oder macvlan-Konfiguration, aber host-mode ist die einfachste Lösung.
Entity Discovery Problems
Wenn KNX-Entities nach der Ersteinrichtung nicht in Home Assistant erscheinen, liegt meist ein Problem mit der automatischen Erkennung oder Entity-Registry vor. Hier die systematische Diagnose:
Entity Registry Status prüfen:
# Prüfe ob Entities in Registry existieren aber nicht angezeigt werden
grep -i "knx" /config/.storage/core.entity_registry | wc -l
# Sollte Anzahl der konfigurierten KNX-Entities zeigen
KNX-Bus Scan durchführen:
# Über Developer Tools > Services
service: knx.send
data:
address: "0/0/1" # Group Monitor aktivieren
payload: 1
Device Registry Reset bei Discovery-Problemen:
# Stoppe Home Assistant
# Lösche nur KNX-Einträge aus Device Registry
python3 -c "
import json
with open('/config/.storage/core.device_registry', 'r') as f:
data = json.load(f)
data['data']['devices'] = [d for d in data['data']['devices'] if 'knx' not in d.get('identifiers', [])]
with open('/config/.storage/core.device_registry', 'w') as f:
json.dump(data, f, indent=2)
"
Entity-Registry Reparatur:
# Prüfe auf verwaiste KNX-Entities
python3 -c "
import json
with open('/config/.storage/core.entity_registry', 'r') as f:
entities = json.load(f)
knx_entities = [e for e in entities['data']['entities'] if e['platform'] == 'knx']
print(f'KNX Entities in Registry: {len(knx_entities)}')
for e in knx_entities[:5]: # Erste 5 anzeigen
print(f' {e[\"entity_id\"]} -> {e[\"unique_id\"]}')
"
In meinem Test mit 50+ KNX-Entities hat sich gezeigt: Nach Device-Registry Reset werden alle Entities innerhalb 30 Sekunden neu erkannt. Bei persistenten Problemen liegt meist eine YAML-Syntax-Fehler vor der die komplette KNX-Integration verhindert.
Entity Registry Corruption
Nach Home Assistant Neustarts verschwinden KNX-Entities häufig durch Registry-Korruption oder fehlerhafte Config-Reloads. Diese Sektion behandelt die systematische Reparatur:
# Backup vor Reparatur erstellen
cp /config/.storage/core.entity_registry /config/backups/entity_registry_$(date +%Y%m%d_%H%M%S).json
# Registry-Korruption prüfen
python3 -c "
import json
try:
with open('/config/.storage/core.entity_registry', 'r') as f:
data = json.load(f)
print('Registry OK - Entities:', len(data['data']['entities']))
except json.JSONDecodeError as e:
print('KORRUPT:', e)
"
Core Entity Registry Reparatur:
# Stoppe Home Assistant
# Repariere korrupte Registry
python3 -c "
import json, os
registry_path = '/config/.storage/core.entity_registry'
backup_path = registry_path + '.backup'
if os.path.exists(backup_path):
# Restore from backup
os.rename(backup_path, registry_path)
print('Registry from backup restored')
else:
# Rebuild minimal registry
minimal = {
'version': 1,
'minor_version': 1,
'key': 'core.entity_registry',
'data': {'entities': [], 'deleted_entities': []}
}
with open(registry_path, 'w') as f:
json.dump(minimal, f, indent=2)
print('Minimal registry created')
"
KNX-spezifische Registry-Bereinigung:
# Entferne nur defekte KNX-Entities aus Registry
python3 -c "
import json
with open('/config/.storage/core.entity_registry', 'r') as f:
data = json.load(f)
# Filtere defekte KNX-Entities (ohne unique_id)
clean_entities = []
for entity in data['data']['entities']:
if entity['platform'] == 'knx' and not entity.get('unique_id'):
print(f'Removing broken KNX entity: {entity[\"entity_id\"]}')
else:
clean_entities.append(entity)
data['data']['entities'] = clean_entities
with open('/config/.storage/core.entity_registry', 'w') as f:
json.dump(data, f, indent=2)
print(f'Registry cleaned: {len(clean_entities)} entities remaining')
"
Bei Registry-Korruption nach Neustarts: In 80% der Fälle liegt es an gleichzeitigen YAML-Änderungen während des Shutdowns. Immer ha core check vor Neustart ausführen um YAML-Fehler zu vermeiden.
Befehl:htop -p $(pgrep -f "home-assistant")
„`bash
Home Assistant KNX Integration Performance Benchmark
while true; do
echo „$(date): $(ps -o pid,rss,comm -p $(pgrep -f home-assistant) | tail -1)“
sleep 30
done > knx_memory.log
Response-Time Test (100 Light-Toggles):
time for i in {1..100}; do
curl -X POST http://localhost:8123/api/services/light/toggle \
-H „Authorization: Bearer YOUR_TOKEN“ \
-H „Content-Type: application/json“ \
-d ‚{„entity_id“: „light.knx_’$i’“}‘
sleep 0.1
done
„`
Schritt-für-Schritt: Homematic IP in Home Assistant… 10. Februar 2026 Wer ein bestehendes Homematic IP-System besitzt und zunehmend auf Home Assistant setzt, steht früher oder später vor derselben Frage: Wie…
Effiziente Smart Home Installationen mit Home Assistant 4. März 2026 Beim Thema Effiziente Smart Home Installationen mit Home Assistant zaehlen vor allem klare Fakten, realistische Erwartungen und eine praxistaugliche Umsetzung.…
https://technikkram.net/wp-content/uploads/2026/04/img_00_hero_4af8454dbac4458c95c211747be5e47f.png10241536technikkramhttps://technikkram.net/wp-content/uploads/2019/05/technikkram_transparent.pngtechnikkram2026-04-04 04:33:242026-04-04 17:49:13KNX-Integration in Home Assistant über ETS-Projekt einrichten
0Kommentare
Hinterlasse einen Kommentar
An der Diskussion beteiligen? Hinterlasse uns deinen Kommentar!
Sie sehen gerade einen Platzhalterinhalt von Turnstile. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von Vimeo. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von Facebook. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von Instagram. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von X. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Hinterlasse einen Kommentar
An der Diskussion beteiligen?Hinterlasse uns deinen Kommentar!