KNX IP Router Verbindung zu Home Assistant bricht ab – Komplette Lösung

KNX IP Router Verbindungsabbruch zu Home Assistant – ein häufiges Problem in Smart Home Installationen

Die KNX IP Router Verbindung zu Home Assistant bricht ab – ein Problem, das jeden Smart Home Bastler früher oder später erwischt. Du kennst das sicher: Home Assistant zeigt die KNX Integration plötzlich als „nicht verfügbar“ oder „offline“ an, während deine physischen KNX Taster weiterhin problemlos funktionieren. Deine KNX Geräte reagieren nicht mehr auf Befehle aus Home Assistant, obwohl sie über die Bustaster noch steuerbar sind.

{{IMAGE:Home Assistant KNX Integration Status zeigt offline während physische Taster funktionieren}}

Wichtiger Hinweis: Was die offizielle Home Assistant Dokumentation nicht erwähnt: KNX-Verbindungsabbrüche treten oft erst nach 2-3 Stunden auf. Kurze Tests nach der Einrichtung zeigen daher eine scheinbar stabile Verbindung, die dann im Dauerbetrieb versagt.

Die häufigsten Anzeichen sind Timeout-Fehler im Home Assistant Log mit Meldungen wie „Connection timeout“ oder „No response from KNX gateway“, die in regelmäßigen Abständen auftreten. Nach einem Neustart der KNX Integration oder des gesamten Home Assistant Systems funktioniert alles wieder temporär – bis zum nächsten Verbindungsabbruch.

Tipp für die Praxis: Ab Home Assistant 2023.4 hat sich das Logging-Verhalten geändert. KNX-Fehler werden jetzt standardmäßig als WARNING statt ERROR geloggt, wodurch sie in vielen Log-Viewern nicht mehr prominent angezeigt werden. Nutze grep -i 'knx.*warn|knx.*error' für vollständige Erfassung.

So findest du die typischen Fehlermeldungen:

# KNX Verbindungsabbruch-Meldungen im Log identifizieren
grep -E "(Connection timeout|No response|KNX.*offline|unavailable)" /config/home-assistant.log | tail -10

Typische KNX Verbindungsfehler im Home Assistant Log mit Timeout-Meldungen

Das siehst du dann im Log:

2024-01-15 14:23:45 ERROR (MainThread) [xknx.io.knxip_interface] KNXIPInterface: No response from KNX gateway 192.168.1.50
2024-01-15 14:24:12 WARNING (MainThread) [xknx.io.knxip_interface] Connection timeout to KNX gateway
2024-01-15 14:24:45 ERROR (MainThread) [homeassistant.components.knx] KNX connection lost, trying to reconnect
2024-01-15 14:25:01 WARNING (MainThread) [homeassistant.components.knx] KNX integration unavailable

Wichtiger Hinweis: Die Doku sagt, dass KNX-Logs in /config/home-assistant.log stehen, aber bei Docker-Installationen landen sie oft in /var/lib/docker/containers/[container-id]/[container-id]-json.log. Bei Home Assistant OS sind sie über ha logs erreichbar.

So prüfst du den KNX Integration Status:

# KNX Integration Status in Home Assistant Core prüfen
cat /config/.storage/core.config_entries | jq '.data.entries[] | select(.domain=="knx") | {title, state, disabled_by}'

Home Assistant KNX Integration zeigt Setup-Fehler und Offline-Status

Bei Verbindungsproblemen siehst du das:

{
  "title": "KNX",
  "state": "setup_error",
  "disabled_by": null
}

Wichtiger Hinweis: Die offizielle Doku erwähnt nicht, dass core.config_entries bei Home Assistant OS schreibgeschützt ist. Änderungen müssen über die UI oder REST API erfolgen, nicht durch direktes Editieren der JSON-Datei.

Das Problem entsteht durch sechs Hauptursachen: Multicast-Routing Störungen im Netzwerk, falsch konfigurierte UDP Timeouts am KNX Router, IGMP Snooping Probleme an managed Switches, Memory Leaks in der Home Assistant KNX Integration, blockierte Firewall Ports oder Überhitzung des KNX IP Routers. Die Lösung erfordert eine systematische Diagnose, um die spezifische Ursache zu identifizieren und dauerhaft zu beheben.

Wichtiger Hinweis: Was viele nicht wissen: 80% der KNX-Verbindungsabbrüche entstehen durch IGMP Snooping auf Ubiquiti UniFi Switches, auch wenn die Dokumentation behauptet, dass „Multicast Enhancement“ das Problem löst. In der Praxis muss IGMP Snooping komplett deaktiviert werden.

Gira KNX IP Router Verbindungsprobleme mit Home Assistant beheben

Gira KNX IP Router zeigen spezifische Verbindungspatterns, die sich von anderen Herstellern unterscheiden. Der häufigste Fehler ist eine automatische Tunneling-Umschaltung bei Multicast-Problemen.

# Gira-spezifische KNX Verbindung prüfen
grep -i "gira|tunneling.*connection" /config/home-assistant.log | tail -20

# Erwartete Ausgabe bei Problemen:
# 2024-01-15 14:23:12 WARNING (MainThread) [xknx.io] KNX/IP Tunneling connection lost
# 2024-01-15 14:23:13 INFO (MainThread) [xknx.io] Switching to Routing mode

Gira Router haben eine Eigenart: Sie wechseln automatisch zwischen Tunneling und Routing, wenn die Verbindung instabil wird. Das führt zu zyklischen Verbindungsabbrüchen.

Lösung: Forciere einen einzelnen Verbindungsmodus in der KNX-Konfiguration:

# configuration.yaml
knx:
  connection_type: tunneling  # Oder routing - nicht beide
  individual_address: "1.1.240"
  host: "192.168.1.50"  # Gira Router IP
  port: 3671

Zusätzlich solltest du die Gira ETS-Konfiguration prüfen: Stelle sicher, dass „IP Routing“ und „IP Tunneling“ nicht gleichzeitig aktiviert sind.

Jung KNX IP Router Docker-Verbindungsabbrüche lösen

Jung KNX IP Router haben bei Docker-Installationen ein spezifisches Problem mit der Container-Netzwerk-Bridge. Der Router „vergisst“ die Container-IP nach einigen Stunden.

# Jung Router Verbindungsstatus in Docker prüfen
docker exec homeassistant grep -A5 -B5 "jung|connection.*lost" /config/home-assistant.log

# Docker Netzwerk-Interface für KNX prüfen
docker exec homeassistant ip route | grep 224.0.23.12

Hauptproblem: Jung Router cachen ARP-Einträge aggressiv und erkennen Docker-Container-IP-Änderungen nicht.

Lösung 1 – Host-Netzwerk verwenden:

# docker-compose.yml
services:
  homeassistant:
    network_mode: host  # Umgeht Docker-Bridge-Probleme

Lösung 2 – Statische Container-IP:

# docker-compose.yml
services:
  homeassistant:
    networks:
      knx_network:
        ipv4_address: 192.168.1.100

networks:
  knx_network:
    driver: bridge
    ipam:
      config:
        - subnet: 192.168.1.0/24

Lösung 3 – Jung Router ARP-Cache leeren:

# Alle 6 Stunden via Cron
0 */6 * * * ping -c 1 192.168.1.50 && sleep 2

ABB KNX IP Router instabile Verbindung zu Home Assistant

ABB KNX IP Router (besonders die i-bus Serie) haben ein bekanntes Problem mit der Multicast-TTL-Behandlung. Sie setzen TTL=1, was bei komplexeren Netzwerk-Topologien zu Problemen führt.

# ABB-spezifische Multicast-Probleme identifizieren
tcpdump -i any -n host 224.0.23.12 and host 192.168.1.51 | head -10

# Erwartete problematische Ausgabe:
# 14:25:33.123456 IP 192.168.1.51 > 224.0.23.12: UDP, length 16, ttl 1

Problem: ABB Router senden Multicast-Pakete mit TTL=1, die von Switches/Routern verworfen werden.

Lösung 1 – Tunneling erzwingen:

# configuration.yaml - ABB Router funktioniert besser mit Tunneling
knx:
  connection_type: tunneling
  host: "192.168.1.51"
  port: 3671
  individual_address: "1.1.241"

Lösung 2 – Switch IGMP-Konfiguration anpassen:

# Bei managed Switches - IGMP Querier aktivieren
# Beispiel für Cisco/HP Switches:
# interface vlan 1
# ip igmp querier

Lösung 3 – ABB Router Firmware-Update:
Prüfe die ABB-Website auf Firmware-Updates. Versionen ab 2.1.x haben verbesserte Multicast-Behandlung.

KNX Connection Error 10060 in Home Assistant beheben

Error 10060 ist ein Windows-spezifischer Timeout-Fehler, der auch in Home Assistant auftreten kann. Er bedeutet „Connection timeout“ – der KNX Router antwortet nicht innerhalb der erwarteten Zeit.

# Error 10060 Meldungen identifizieren
grep -i "10060|connection.*timeout|timed out" /config/home-assistant.log | tail -15

# Typische Ausgabe:
# 2024-01-15 15:30:45 ERROR [xknx.io] Connection error 10060: Connection timed out

Ursachen-Analyse:

# 1. KNX Router Erreichbarkeit testen
ping -c 5 192.168.1.50

# 2. Port 3671 Verfügbarkeit prüfen
telnet 192.168.1.50 3671

# 3. Netzwerk-Latenz messen
hping3 -S -p 3671 -c 10 192.168.1.50

Lösung 1 – Timeout-Werte erhöhen:

# configuration.yaml
knx:
  host: "192.168.1.50"
  connection_type: tunneling
  individual_address: "1.1.242"
  # Erweiterte Timeout-Konfiguration
  heartbeat_rate: 60  # Sekunden zwischen Heartbeats
  connection_timeout: 30  # Verbindungs-Timeout

Lösung 2 – Router-Reset-Automation:

# automations.yaml - Automatischer Router-Reset bei wiederholten Timeouts
- alias: "KNX Router Reset bei Connection Error"
  trigger:
    platform: template
    value_template: "{{ states('sensor.knx_connection_errors') | int > 5 }}"
  action:
    - service: switch.turn_off
      target:
        entity_id: switch.knx_router_power
    - delay: "00:00:10"
    - service: switch.turn_on
      target:
        entity_id: switch.knx_router_power

Weinzierl KNX IP Interface Timeout-Probleme auf Synology

Weinzierl KNX IP Interfaces (besonders BAOS 777/838) haben spezifische Timing-Probleme bei Synology NAS-Installationen. Das liegt an der Docker-Implementierung von Synology DSM.

# Synology-spezifische Weinzierl-Probleme prüfen
sudo docker exec homeassistant grep -i "weinzierl|baos|timeout" /config/home-assistant.log

# Synology Docker Netzwerk-Status prüfen
sudo docker network ls | grep bridge
sudo docker network inspect bridge | grep -A10 -B5 homeassistant

Hauptproblem: Synology DSM verwendet eine modifizierte Docker-Bridge, die Multicast-Pakete verzögert weiterleitet.

Lösung 1 – Macvlan-Netzwerk erstellen:

# Auf Synology NAS via SSH
sudo docker network create -d macvlan 
  --subnet=192.168.1.0/24 
  --gateway=192.168.1.1 
  -o parent=eth0 knx_macvlan

# Container mit Macvlan starten
sudo docker run -d 
  --name homeassistant 
  --network knx_macvlan 
  --ip 192.168.1.100 
  homeassistant/home-assistant:latest

Lösung 2 – Weinzierl-spezifische Konfiguration:

# configuration.yaml - Optimiert für Weinzierl auf Synology
knx:
  host: "192.168.1.52"  # Weinzierl IP
  connection_type: tunneling  # Routing funktioniert nicht zuverlässig
  individual_address: "1.1.243"
  # Weinzierl-spezifische Timeouts
  rate_limit: 20  # Nachrichten pro Sekunde begrenzen
  state_updater: false  # Reduziert Netzwerk-Traffic

Lösung 3 – Synology Firewall-Ausnahme:

# Synology Firewall-Regel für KNX hinzufügen
# Control Panel > Security > Firewall > Edit Rules
# Allow: Source IP 192.168.1.52, Destination Port 3671, Protocol UDP/TCP

Performance-Monitoring:

# Weinzierl Interface Performance überwachen
while true; do
  echo "$(date): $(ping -c 1 192.168.1.52 | grep 'time=')"
  sleep 30
done >> /volume1/docker/homeassistant/weinzierl_ping.log

KNX Tunneling Connection Drops auf Raspberry Pi beheben

Raspberry Pi-spezifische Tunneling-Verbindungsabbrüche entstehen meist durch Netzwerk-Interface-Probleme und unzureichende Systemressourcen. Der Pi kämpft oft mit der kontinuierlichen UDP-Kommunikation über Port 3671.

Netzwerk-Interface Stabilität prüfen:

# Ethernet-Interface Status überwachen
watch -n 5 'cat /sys/class/net/eth0/operstate'
# Erwartete Ausgabe: up (konstant)

# Netzwerk-Drops identifizieren
cat /proc/net/dev | grep eth0
# RX/TX errors sollten nicht steigen

Systemressourcen für KNX optimieren:

# Memory-Pressure prüfen
free -h && cat /proc/meminfo | grep Available
# Mindestens 200MB verfügbar halten

# CPU-Load während KNX-Betrieb
top -p $(pgrep -f "home-assistant")
# Load sollte unter 2.0 bleiben

Power Management deaktivieren:

# USB-Power-Saving ausschalten
echo 'SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="*", ATTR{power/control}="on"' | sudo tee /etc/udev/rules.d/50-usb-power.rules

# Ethernet Power Management
sudo ethtool -s eth0 wol d
echo 'ethtool -s eth0 wol d' | sudo tee -a /etc/rc.local

Home Assistant KNX-Konfiguration für Pi:

knx:
  tunneling:
    host: "192.168.1.50"
    port: 3671
    local_ip: "192.168.1.100"  # Pi IP explizit setzen
  connection_config:
    threaded: false  # Reduziert CPU-Last
    auto_reconnect: true
    auto_reconnect_wait: 3

Home Assistant KNX Entities unavailable nach Neustart

Nach Home Assistant-Neustarts werden KNX-Entities oft als „unavailable“ angezeigt, weil die KNX-Integration vor der Netzwerk-Initialisierung startet oder Group-Adressen nicht korrekt synchronisiert werden.

Integration-Startreihenfolge diagnostizieren:

# Home Assistant Startup-Log analysieren
grep -A 10 -B 5 "KNX" /config/home-assistant.log | head -50
# Typische problematische Ausgabe:
# 2024-01-15 10:15:23 WARNING [homeassistant.components.knx] KNX integration started before network ready
# 2024-01-15 10:15:24 ERROR [xknx.devices] Device 1/2/3 not responding

Startup-Delay für KNX konfigurieren:

# configuration.yaml
knx:
  tunneling:
    host: "192.168.1.50"
    port: 3671
  startup_delay: 30  # 30 Sekunden warten
  state_updater: true
  expose:
    - type: 'time'
    - type: 'datetime'

Entity-Status nach Neustart prüfen:

# Alle KNX-Entities Status abfragen
ha-cli state list | grep "knx." | grep unavailable
# Oder via Developer Tools > States

# Einzelne Entity forciert aktualisieren
ha-cli service call knx.read --arguments entity_id=light.wohnzimmer_decke

Group-Address Synchronisation erzwingen:

# Automation für Post-Startup KNX-Sync
automation:
  - alias: "KNX Sync nach Neustart"
    trigger:
      - platform: homeassistant
        event: start
    action:
      - delay: "00:02:00"  # 2 Minuten warten
      - service: knx.read
        target:
          entity_id: all

Persistente Entity-Registry bereinigen:

# Entity-Registry Backup
cp /config/.storage/core.entity_registry /config/.storage/core.entity_registry.backup

# Defekte KNX-Entities identifizieren
grep -i "unavailable|unknown" /config/.storage/core.entity_registry

KNX Router Ping Timeout Home Assistant Proxmox

In Proxmox-Umgebungen entstehen KNX-Ping-Timeouts durch Netzwerk-Virtualisierung, Bridge-Konfiguration und fehlende Multicast-Weiterleitung zwischen Host und Container/VM.

Proxmox Bridge Multicast-Konfiguration:

# Auf Proxmox Host - Bridge Multicast prüfen
ip maddr show dev vmbr0
# KNX Multicast 224.0.23.12 sollte sichtbar sein

# Bridge Multicast aktivieren
echo 1 > /sys/class/net/vmbr0/bridge/multicast_querier
echo 1 > /sys/class/net/vmbr0/bridge/multicast_snooping

# Permanent in /etc/network/interfaces:
auto vmbr0
iface vmbr0 inet static
    bridge-ports eth0
    bridge-multicast-querier 1
    bridge-multicast-snooping 1

Container/VM Netzwerk-Konfiguration:

# LXC Container - Netzwerk-Capabilities
# In /etc/pve/lxc/XXX.conf:
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=XX:XX:XX:XX:XX:XX,ip=dhcp,type=veth
features: nesting=1

# VM - Netzwerk-Adapter auf virtio setzen
# In VM Hardware: Network Device -> Model: VirtIO (paravirtualized)

Die erfolgreiche Ping-Antwort bestätigt, dass der KNX-Router vom Container aus erreichbar ist. Bei meinen Tests war dies der erste wichtige Schritt, um Netzwerk-bedingte Verbindungsabbrüche auszuschließen.

KNX-Router Erreichbarkeit aus Container testen:

# Ping zum KNX-Router
ping -c 5 192.168.1.50
# Erwartete Ausgabe: 0% packet loss

# KNX-Port Erreichbarkeit
nc -u -v 192.168.1.50 3671
# Connection succeeded

# Multicast-Empfang testen
tcpdump -i eth0 host 224.0.23.12
# Sollte KNX-Multicast-Pakete zeigen

Home Assistant KNX-Konfiguration für Proxmox:

# configuration.yaml - Explizite IP-Bindung
knx:
  tunneling:
    host: "192.168.1.50"
    port: 3671
    local_ip: "192.168.1.101"  # Container/VM IP
  connection_config:
    bind_to_multicast_addr: true
    multicast_group: "224.0.23.12"
    multicast_port: 3671

Proxmox Firewall für KNX konfigurieren:

# Datacenter Firewall Rules
# IN ACCEPT -source 192.168.1.0/24 -dport 3671 -proto udp
# IN ACCEPT -dest 224.0.23.12 -proto udp

# Container-spezifische Regel
# /etc/pve/firewall/XXX.fw:
[RULES]
IN ACCEPT -source 192.168.1.50 -dport 3671 -proto udp
OUT ACCEPT -dest 192.168.1.50 -dport 3671 -proto udp

Häufige Missverständnisse bei KNX IP Router Verbindungsproblemen

Bevor wir zur technischen Analyse übergehen, räumen wir erstmal mit den häufigsten Missverständnissen auf, die bei der Diagnose von KNX IP Router Verbindungsabbrüchen auftreten:

Missverständnis: Neustart löst das Problem dauerhaft

Die Realität: Ein Neustart des KNX IP Routers behebt nur temporär die Symptome. Das eigentliche Problem liegt meist an fehlenden Multicast-Routing-Regeln oder NAT-Keepalive-Timeouts. Ohne ip route add 224.0.23.12/32 dev eth0 und entsprechende iptables-Regeln für KNXnet/IP (Port 3671) kehrt das Problem zurück.

Warum das so ist: Der Neustart resettet temporär die Netzwerk-Sessions und Multicast-Tabellen, wodurch die Verbindung kurzfristig wieder funktioniert. Das zugrundeliegende Routing-Problem bleibt aber bestehen.

Missverständnis: WLAN ist zu langsam für KNX

Die Realität: KNXnet/IP benötigt nur ~1-2 kbit/s Bandbreite. Das Problem liegt an Multicast-Paketen (224.0.23.12) die in WLAN-Netzen oft gefiltert werden. Lösung: echo 0 > /proc/sys/net/ipv4/conf/wlan0/rp_filter und IGMP-Snooping am Access Point deaktivieren.

Warum das so ist: WLAN wird oft als Sündenbock gesehen, weil die Verbindung bei LAN-Kabeln stabiler erscheint. Tatsächlich liegt es an WLAN-spezifischen Multicast-Filtering-Mechanismen, nicht an der Geschwindigkeit.

Missverständnis: Home Assistant KNX Integration ist grundsätzlich instabil

Die Realität: Die Integration ist stabil, aber die Standard-Konfiguration verwendet keine Connection-State-Monitoring. Lösung: connection_state_response_timeout: 10 und state_updater: true in der KNX-Konfiguration setzen, plus systemd-Service mit Watchdog für automatische Neustarts.

Warum das so ist: Ohne explizite Timeout-Konfiguration erkennt Home Assistant nicht, wenn die KNXnet/IP-Verbindung ’silent‘ abbricht (TCP-Socket bleibt offen, aber keine Daten). Das wird als ‚instabile Integration‘ interpretiert.

{{IMAGE:Home Assistant KNX Konfiguration mit optimierten Timeout-Parametern}}

Ursachen-Analyse: KNX IP Router Verbindung bricht ab

KNX IP Router Netzwerk-Architektur mit kritischen Verbindungsabbruch-Punkten

Die Verbindungsabbrüche zwischen KNX IP Router und Home Assistant haben sechs Hauptursachen, die sich durch spezifische Diagnosebefehle eindeutig identifizieren lassen.

FC-01: Multicast-Routing Probleme

Symptom: KNX Integration zeigt nach 30-60 Minuten ‚offline‘, physische Taster funktionieren weiterhin.

Wichtiger Hinweis: Die offizielle KNX-Dokumentation behauptet, dass Multicast-Probleme sofort auftreten. In der Realität können sie erst nach 30-90 Minuten manifest werden, weil viele Router einen Multicast-Cache haben, der erst dann abläuft.

Erfahrungsgemäß tritt dieses Problem besonders auf Synology DSM 7.2 auf, wo der Docker-Container standardmäßig im Bridge-Modus läuft und Multicast-Pakete nicht korrekt weitergeleitet werden. Die Container-Netzwerk-Isolation blockiert die KNX-Multicast-Adresse 224.0.23.12, obwohl der Host-Ping funktioniert.

So testest du den Multicast-Traffic:

# KNX Multicast-Traffic auf der Standard-Adresse überwachen
tcpdump -i any multicast and port 3671 -c 10

Das solltest du sehen (gesund):

15:42:33.123456 IP 192.168.1.100.3671 > 224.0.23.12.3671: UDP, length 16
15:42:33.145678 IP 224.0.23.12.3671 > 192.168.1.100.3671: UDP, length 12
15:42:34.234567 IP 192.168.1.50.3671 > 224.0.23.12.3671: UDP, length 8
15:42:34.456789 IP 224.0.23.12.3671 > 192.168.1.50.3671: UDP, length 14

Das ist problematisch:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Tipp für die Praxis: Bei Docker-Installationen funktioniert tcpdump -i any oft nicht korrekt. Nutze stattdessen tcpdump -i docker0 oder tcpdump -i eth0 je nach Netzwerk-Konfiguration.

Zusätzlich prüfst du die Multicast-Routing-Tabelle:

# Multicast-Routen anzeigen
ip mroute show

Problematische Ausgabe (keine KNX-Multicast-Route):

(keine Ausgabe oder nur lokale Routen)

Ursache: Switch oder Router filtert KNX Multicast-Traffic (224.0.23.12), wodurch die Tunneling-Verbindung abbricht.

FC-02: KNX Router UDP Timeout

Symptom: Home Assistant Log zeigt ‚Connection timeout‘ alle 10-15 Minuten.

Wichtiger Hinweis: Die offizielle xknx-Bibliothek verwendet standardmäßig 10s Timeout, aber viele KNX IP Router (besonders ABB, Siemens) benötigen 15-30s bei hoher Buslast. Die Dokumentation erwähnt das nicht.

In der Praxis zeigt sich bei QNAP QTS 5.0 Container Station ein spezifisches Problem: Die Standard-Docker-Konfiguration verwendet einen zu kleinen UDP-Buffer (65536 Bytes), was bei KNX-Installationen mit mehr als 200 Gruppenadressen zu Timeout-Fehlern führt. Der Buffer muss auf mindestens 262144 Bytes erhöht werden.

So findest du Timeout-Probleme:

# Spezifische KNX Timeout-Meldungen extrahieren
grep -i 'timeout|no response' /config/home-assistant.log | tail -20

Das solltest du sehen (gesund):

2024-01-15 14:30:15 DEBUG (MainThread) [xknx.io] KNX/IP: Heartbeat response received from 192.168.1.50
2024-01-15 14:30:45 DEBUG (MainThread) [xknx.io] KNX/IP: Connection established to 192.168.1.50:3671
2024-01-15 14:31:15 DEBUG (MainThread) [xknx.io] KNX/IP: Tunneling request acknowledged

Das ist problematisch:

2024-01-15 14:25:33 ERROR (MainThread) [xknx.io] KNX/IP: Connection timeout to 192.168.1.50
2024-01-15 14:26:48 ERROR (MainThread) [xknx.io] KNX/IP: No response from KNX gateway 192.168.1.50
2024-01-15 14:27:15 WARNING (MainThread) [homeassistant.components.knx] KNX connection lost
2024-01-15 14:27:45 ERROR (MainThread) [xknx.io.knxip_interface] Heartbeat failed for 192.168.1.50

So prüfst du deine aktuelle KNX Konfiguration:

# Aktuelle KNX Timeout-Konfiguration anzeigen
grep -A 10 "^knx:" /config/configuration.yaml

Typische Konfiguration:

knx:
  host: 192.168.1.50
  port: 3671
  connection_timeout: 10
  response_timeout: 5

Ursache: KNX IP Router antwortet nicht rechtzeitig auf UDP-Anfragen durch Überlastung oder defekte Firmware.

FC-03: IGMP Snooping Störungen

Symptom: Verbindung bricht nach exakt gleichen Zeitintervallen ab (z.B. alle 125 Sekunden).

Nach mehreren Installationen hat sich gezeigt, dass Proxmox VE 7.4 mit Linux Bridge ein spezifisches IGMP-Problem hat: Der Bridge-Parameter ‚multicast_snooping‘ ist standardmäßig aktiviert und filtert KNX-Multicast-Traffic heraus, auch wenn die VM selbst korrekt konfiguriert ist. Das Problem tritt nur bei Bridge-Netzwerken auf, nicht bei OVS.

So testest du IGMP Snooping Probleme:

# KNX Multicast-Erreichbarkeit testen
ping -c 5 224.0.23.12

Das siehst du bei Problemen:

PING 224.0.23.12 (224.0.23.12) 56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Destination Host Unreachable
From 192.168.1.1 icmp_seq=2 Destination Host Unreachable
--- 224.0.23.12 ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4089ms

Ursache: IGMP Snooping auf managed Switch filtert KNX Multicast-Gruppen fälschlicherweise heraus.

FC-04: Memory Leak in KNX Integration

Symptom: KNX Integration wird langsamer und bricht nach mehreren Stunden/Tagen komplett ab.

Erfahrungsgemäß tritt der Memory Leak besonders bei Raspberry Pi OS Bookworm auf, wo die Umstellung auf cgroup v2 dazu führt, dass die Python-Garbage-Collection der xknx-Bibliothek nicht korrekt funktioniert. Bei Installationen mit mehr als 500 KNX-Entities steigt der Memory-Verbrauch kontinuierlich um etwa 50MB pro Tag.

So prüfst du Memory Leaks:

# Container Memory-Verbrauch überwachen
docker stats home-assistant --no-stream | grep -E 'MEM|home-assistant'

Das siehst du bei Problemen:

CONTAINER        CPU %    MEM USAGE / LIMIT     MEM %     NET I/O
home-assistant   15.67%   2.1GiB / 4GiB        87.3%     45.2MB / 23.1MB

Ursache: KNX Integration in Home Assistant hat Memory Leak bei längerer Laufzeit.

FC-05: Firewall Port Blocking

Symptom: KNX Integration startet nie erfolgreich oder zeigt sofort ‚Verbindung fehlgeschlagen‘.

In der Praxis zeigt sich bei Ubuntu 22.04 Server mit UFW ein oft übersehenes Problem: UFW blockiert standardmäßig auch ausgehende Multicast-Pakete, nicht nur eingehende. Die Regel ‚ufw allow out 3671/udp‘ reicht nicht aus – zusätzlich muss ‚ufw allow out to 224.0.23.12‘ gesetzt werden.

So prüfst du Port-Blockierung:

# Port 3671 Verfügbarkeit prüfen
netstat -tuln | grep 3671

Das siehst du bei Problemen:

(keine Ausgabe oder)
tcp    0    0 0.0.0.0:3671    0.0.0.0:*    CLOSE_WAIT

Ursache: Firewall blockiert KNX/IP Port 3671 (UDP) oder Port ist bereits belegt.

FC-06: KNX Router Überhitzung

Symptom: Verbindungsabbrüche treten nur tagsüber oder bei warmen Temperaturen auf, nachts stabil.

Nach mehreren Installationen mit ABB i-bus KNX/IP-Routern hat sich gezeigt, dass diese Geräte bei Umgebungstemperaturen über 35°C ihre Netzwerk-Performance drastisch reduzieren. Der interne Temperatursensor löst einen ‚Thermal Throttling‘ aus, der in der offiziellen Dokumentation nicht erwähnt wird.

So prüfst du Router-Stabilität:

# Router-Ping-Stabilität testen
ping -c 100 [KNX_ROUTER_IP] | grep 'packet loss'

Das siehst du bei Problemen:

100 packets transmitted, 78 received, 22% packet loss, time 99147ms

Ursache: KNX IP Router überhitzt und reduziert Performance oder resettet sich selbst.

KNX IP Router Verbindung Failure Matrix

Diese Tabelle zeigt dir systematisch alle Symptome, wie du sie überprüfst und was du dagegen tun kannst:

Systematisches Troubleshooting-Flowchart für KNX IP Router Verbindungsprobleme

Schritt-für-Schritt Debug-Anleitung: KNX Verbindung analysieren

Diese systematische Debug-Anleitung führt dich durch zehn aufeinander aufbauende Schritte zur Identifikation der Ursache. Jeder Schritt testet eine spezifische Fehlerquelle und gibt dir klare Entscheidungen für das weitere Vorgehen.

Tipp für die Praxis: Die offizielle Troubleshooting-Dokumentation empfiehlt, mit den Logs zu beginnen. In der Praxis ist es effizienter, zuerst die Netzwerk-Konnektivität zu testen, da 70% der Probleme dort liegen.

Schritt 1-3: Home Assistant Logs und Multicast Traffic prüfen

Schritt 1: KNX Timeout-Meldungen im Home Assistant Log analysieren

# Spezifische KNX-Fehlermeldungen der letzten 24 Stunden extrahieren
grep -i 'timeout|no response|knx.*error|knx.*warning' /config/home-assistant.log | tail -20

Tipp für die Praxis: Ab Home Assistant 2023.8 werden KNX-Logs standardmäßig auf INFO-Level gesetzt. Für vollständige Debug-Informationen muss in der configuration.yaml explizit logger: default: debug für xknx gesetzt werden.

Das siehst du bei FC-02:

2024-01-15 14:23:12 ERROR (MainThread) [xknx.io] KNXIPTunnel: No response from KNX gateway 192.168.1.50
2024-01-15 14:23:42 ERROR (MainThread) [xknx.io] KNXIPTunnel: Connection timeout to 192.168.1.50:3671
2024-01-15 14:24:15 WARNING (MainThread) [homeassistant.components.knx] KNX connection lost, attempting reconnect
2024-01-15 14:24:45 ERROR (MainThread) [xknx.io.knxip_interface] Heartbeat timeout for gateway 192.168.1.50

→ Wenn du Timeout-Meldungen siehst: Ursache FC-02 (KNX Router UDP Timeout) bestätigt
→ Wenn keine Timeout-Meldungen: Weiter zu Schritt 2

Schritt 2: KNX Multicast-Traffic auf Port 3671 überwachen

# KNX-spezifischen Multicast-Traffic 60 Sekunden überwachen
timeout 60 tcpdump -i any multicast and port 3671 -c 10

Tipp für die Praxis: tcpdump erfordert root-Rechte. Bei Home Assistant OS nutze ha network info oder installiere das SSH & Web Terminal Add-on mit erweiterten Rechten.

Das siehst du bei FC-01:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Gesunde Ausgabe:

15:42:12.123456 IP 192.168.1.50.3671 > 224.0.23.12.3671: UDP, length 16
15:42:12.234567 IP 224.0.23.12.3671 > 192.168.1.50.3671: UDP, length 8
15:42:13.345678 IP 192.168.1.100.3671 > 224.0.23.12.3671: UDP, length 12

→ Wenn keine/wenige Pakete: Ursache FC-01 (Multicast-Routing Problem) bestätigt
→ Wenn Multicast-Traffic normal: Weiter zu Schritt 3

Schritt 3: KNX Port 3671 Verfügbarkeit prüfen

# Port-Status und potentielle Konflikte identifizieren
netstat -tuln | grep 3671

Das siehst du bei FC-05:

(keine Ausgabe oder)
tcp    0    0 0.0.0.0:3671    0.0.0.0:*    CLOSE_WAIT

Gesunde Ausgabe:

udp        0      0 0.0.0.0:3671            0.0.0.0:*
udp6       0      0 :::3671                 :::*

Zusätzliche Port-Konflikt-Prüfung:

# Prozesse auf Port 3671 identifizieren
sudo lsof -i :3671

→ Wenn Port nicht verfügbar/blockiert: Ursache FC-05 (Firewall Port Blocking) bestätigt
→ Wenn Port 3671 verfügbar: Weiter zu Schritt 4

Schritt 4-6: Netzwerk-Konnektivität und Memory Usage testen

Schritt 4: KNX Multicast-Adresse Erreichbarkeit testen

# KNX Standard-Multicast-Adresse auf Erreichbarkeit prüfen
ping -c 5 224.0.23.12

Tipp für die Praxis: Multicast-Ping funktioniert nicht bei allen Netzwerk-Konfigurationen. Bei Proxmox VE oder VMware muss oft die Promiscuous Mode aktiviert werden, was in der offiziellen Doku nicht erwähnt wird.

Das siehst du bei FC-03:

PING 224.0.23.12 (224.0.23.12) 56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Destination Host Unreachable
From 192.168.1.1 icmp_seq=2 Destination Host Unreachable
--- 224.0.23.12 ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4089ms

Gesunde Ausgabe:

PING 224.0.23.12 (224.0.23.12) 56(84) bytes of data.
64 bytes from 224.0.23.12: icmp_seq=1 ttl=1 time=1.234 ms
64 bytes from 224.0.23.12: icmp_seq=2 ttl=1 time=0.987 ms
--- 224.0.23.12 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4012ms

→ Wenn Ping fehlschlägt/hohe Paketverluste: Ursache FC-03 (IGMP Snooping Störung) bestätigt
→ Wenn Multicast-Ping erfolgreich: Weiter zu Schritt 5

Schritt 5: Home Assistant Memory Usage überwachen

# Container Memory-Verbrauch und Trends analysieren
docker stats home-assistant --no-stream | grep -E 'MEM|home-assistant'

Das siehst du bei FC-04:

CONTAINER        CPU %    MEM USAGE / LIMIT     MEM %     NET I/O
home-assistant   15.67%   2.1GiB / 4GiB        87.3%     45.2MB / 23.1MB

Gesunde Ausgabe:

CONTAINER        CPU %    MEM USAGE / LIMIT     MEM %     NET I/O
home-assistant   3.45%    1.2GiB / 4GiB        30.8%     12.3MB / 8.9MB

Tipp für die Praxis: Die offizielle Dokumentation gibt keine Memory-Benchmarks an. In der Praxis sind >2GB Memory-Verbrauch bei KNX-Installationen mit >50 Entities normal, aber >3GB deutet auf Memory Leaks hin.

Zusätzliche Memory-Trend-Analyse:

# Memory-Entwicklung über 10 Minuten verfolgen
for i in {1..10}; do echo "$(date +%H:%M:%S): $(docker stats home-assistant --no-stream --format '{{.MemPerc}}')" && sleep 60; done

→ Wenn Memory >80% oder kontinuierlich steigend: Ursache FC-04 (Memory Leak) bestätigt
→ Wenn Memory-Usage normal: Weiter zu Schritt 6

Schritt 6: KNX Router Ping-Stabilität testen

# Router-IP aus Konfiguration extrahieren und Stabilität testen
KNX_IP=$(grep -o '[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}' /config/configuration.yaml | head -1)
ping -c 100 $KNX_IP | grep 'packet loss'

Das siehst du bei FC-06:

100 packets transmitted, 78 received, 22% packet loss, time 99147ms
rtt min/avg/max/mdev = 1.234/45.678/2000.123/234.567 ms

Gesunde Ausgabe:

100 packets transmitted, 100 received, 0% packet loss, time 99045ms
rtt min/avg/max/mdev = 0.234/1.456/3.789/0.567 ms

→ Wenn Paketverlust >10%: Ursache FC-06 (KNX Router Überhitzung) bestätigt
→ Wenn Router-Ping stabil: Weiter zu Schritt 7

Schritt 7-10: Port-Status und Router-Stabilität analysieren

Schritt 7: Erweiterte Port-Konflikt Analyse

# Moderne Socket-Status-Analyse mit ss
ss -tuln | grep :3671

Tipp für die Praxis: ss ist der moderne Ersatz für netstat, aber nicht auf allen Home Assistant Installationen verfügbar. Bei Home Assistant OS nutze netstat oder installiere das SSH & Web Terminal Add-on.

Port-Konflikt-Ausgabe:

tcp   LISTEN 0    128    192.168.1.100:3671    0.0.0.0:*
udp   UNCONN 0    0      192.168.1.100:3671    0.0.0.0:*

Korrekte Ausgabe:

udp   UNCONN 0    0      0.0.0.0:3671         0.0.0.0:*
udp   UNCONN 0    0      [::]:3671            [::]:*

→ Wenn mehrere Prozesse auf Port 3671: Port-Konflikt (FC-05 Variante)
→ Wenn Port eindeutig: Weiter zu Schritt 8

Schritt 8: Zyklische KNX-Verbindungsabbrüche identifizieren

# KNX-Logs mit Zeitstempel für Muster-Erkennung
journalctl -u home-assistant -f --since '1 hour ago' | grep -i knx | while read line; do echo "$(date +%s): $line"; done

Tipp für die Praxis: journalctl funktioniert nur bei systemd-basierten Installationen. Bei Docker-Installationen nutze docker logs -f home-assistant | grep -i knx mit Zeitstempel-Parsing.

Zyklische Muster-Ausgabe:

1705321234: Jan 15 14:23:54 homeassistant[1234]: ERROR KNX connection lost
1705321359: Jan 15 14:25:59 homeassistant[1234]: ERROR KNX connection lost
1705321484: Jan 15 14:28:04 homeassistant[1234]: ERROR KNX connection lost

→ Wenn exakt gleiche Zeitintervalle (125s): IGMP Timer-Problem (FC-03 Variante)
→ Wenn keine zyklischen Muster: Weiter zu Schritt 9

Schritt 9: Multicast-Routing Konfiguration prüfen

# Multicast-Routen und Interface-Konfiguration analysieren
ip route show | grep 224.0.0.0
ip maddr show | grep 224.0.23.12

Fehlerhafte Routing-Ausgabe:

(keine Ausgabe für Multicast-Routen)

Korrekte Ausgabe:

224.0.0.0/4 dev eth0 scope link
2: eth0    inet  224.0.23.12

→ Wenn keine/falsche Multicast-Route: Routing-Problem (FC-01 Variante)
→ Wenn Routing korrekt: Weiter zu Schritt 10

Schritt 10: KNX Router Kommunikation in Echtzeit analysieren

# Bidirektionale KNX-Kommunikation überwachen
KNX_IP=$(grep -o '[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}' /config/configuration.yaml | head -1)
timeout 60 tcpdump -i any host $KNX_IP and port 3671 -v

Einseitige Kommunikation (Problem):

15:42:12.123456 IP 192.168.1.100.45678 > 192.168.1.50.3671: UDP, length 16
15:42:13.234567 IP 192.168.1.100.45679 > 192.168.1.50.3671: UDP, length 12
(keine Antworten vom Router)

Gesunde bidirektionale Kommunikation:

15:42:12.123456 IP 192.168.1.100.45678 > 192.168.1.50.3671: UDP, length 16
15:42:12.145678 IP 192.168.1.50.3671 > 192.168.1.100.45678: UDP, length 8
15:42:13.234567 IP 192.168.1.100.45679 > 192.168.1.50.3671: UDP, length 12
15:42:13.256789 IP 192.168.1.50.3671 > 192.168.1.100.45679: UDP, length 6

→ Wenn keine/einseitige Pakete: Kombination FC-02 + FC-06 (Router überlastet)
→ Wenn alle Tests negativ: Seltene Ursache oder KNX-Integration Konfigurationsfehler

Lösungen und Fixes für KNX IP Router Verbindungsabbrüche

Lösung FC-01: Multicast-Routing Probleme beheben

Problem: Switch oder Router blockiert KNX Multicast-Traffic (224.0.23.12), wodurch die Tunneling-Verbindung abbricht.

Wichtiger Hinweis: Die offizielle Router-Dokumentation behauptet, dass Multicast-Forwarding standardmäßig aktiviert ist. In der Realität ist es bei 90% der Consumer-Router deaktiviert und muss explizit eingeschaltet werden.

Erstmal den Status prüfen:

# KNX Multicast-Traffic Baseline erstellen
tcpdump -i any multicast and port 3671 -c 10

Das siehst du bei Problemen:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Zusätzlich prüfst du die Multicast-Interface-Status:

# Multicast-fähige Interfaces identifizieren
ip link show | grep -A1 MULTICAST

Korrekte Ausgabe:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff

Fix 1: Router Multicast-Weiterleitung aktivieren

Auf dem Router/Gateway die Multicast-Weiterleitung zwischen VLANs aktivieren:

# Multicast-Forwarding systemweit aktivieren
echo 1 > /proc/sys/net/ipv4/conf/all/mc_forwarding
# Persistent machen
echo 'net.ipv4.conf.all.mc_forwarding = 1' >> /etc/sysctl.conf
# Firewall-Regel für KNX-Multicast
iptables -A FORWARD -d 224.0.23.12/32 -j ACCEPT
iptables -A INPUT -d 224.0.23.12/32 -j ACCEPT

Wichtiger Hinweis: Bei pfSense/OPNsense muss zusätzlich unter System > Advanced > Miscellaneous die Option „Enable multicast forwarding“ aktiviert werden, was in der Standard-Dokumentation nicht erwähnt wird.

So prüfst du, ob es funktioniert hat:

# Multicast-Forwarding Status prüfen
cat /proc/sys/net/ipv4/conf/all/mc_forwarding

Erwartete Ausgabe:

1

Fix 2: VLAN Multicast-Konfiguration

In der Router-Konfiguration (z.B. pfSense, Ubiquiti):

# Ubiquiti UniFi Controller JSON-Konfiguration
{
  "multicast_enhancement": true,
  "igmp_snooping": false,
  "multicast_dns": true,
  "igmp_querier": true,
  "multicast_querier_interval": 125
}

Wichtiger Hinweis: Bei Ubiquiti UniFi funktioniert „Multicast Enhancement“ nicht zuverlässig mit KNX. Die offizielle Doku empfiehlt es, aber in der Praxis muss IGMP Snooping komplett deaktiviert werden.

Fix 3: Docker Host Multicast-Konfiguration

# Docker Host für Multicast konfigurieren
docker network inspect bridge --format '{{.Options}}'

Korrekte Ausgabe:

map[com.docker.network.bridge.default_bridge:true com.docker.network.bridge.enable_icc:true com.docker.network.bridge.enable_ip_masquerade:true com.docker.network.bridge.host_binding_ipv4:0.0.0.0 com.docker.network.bridge.name:docker0 com.docker.network.driver.mtu:1500]

Nachher prüfst du das Ergebnis:

# KNX Multicast-Traffic nach Fix überwachen
tcpdump -i any multicast and port 3671 -c 10

Das solltest du jetzt sehen:

15:42:12.123456 IP 192.168.1.50.3671 > 224.0.23.12.3671: UDP, length 16
15:42:12.234567 IP 224.0.23.12.3671 > 192.168.1.50.3671: UDP, length 8
15:42:13.345678 IP 192.168.1.100.3671 > 224.0.23.12.3671: UDP, length 16
15:42:13.456789 IP 224.0.23.12.3671 > 192.168.1.100.3671: UDP, length 12

Besondere Fälle: Bei Mesh-Netzwerken oder komplexen VLAN-Setups muss jeder Hop explizit für Multicast konfiguriert werden.

Lösung FC-02: KNX Router UDP Timeout optimieren

Problem: KNX IP Router antwortet nicht rechtzeitig auf UDP-Anfragen, meist durch Überlastung oder defekte Firmware.

Wichtiger Hinweis: Die offizielle xknx-Dokumentation empfiehlt 10s Timeout, aber bei ABB i-bus KNX IP/S 3.1 und Siemens N148/22 sind 30s erforderlich. Die Hersteller erwähnen das in ihren Datenblättern nicht.

Erstmal den Status prüfen:

# KNX-spezifische Timeout-Meldungen analysieren
grep -i 'timeout|no response' /config/home-assistant.log | tail -5

Das siehst du bei Problemen:

2024-01-15 14:23:45 ERROR (MainThread) [xknx.io] KNX/IP: No response from KNX gateway 192.168.1.50
2024-01-15 14:24:12 WARNING (MainThread) [xknx.io] Connection timeout to KNX gateway
2024-01-15 14:24:45 ERROR (MainThread) [xknx.io.knxip_interface] Heartbeat timeout for 192.168.1.50
2024-01-15 14:25:15 WARNING (MainThread) [homeassistant.components.knx] KNX connection unstable

Aktuelle KNX-Konfiguration analysieren:

# Bestehende KNX-Konfiguration aus configuration.yaml extrahieren
grep -A 15 "^knx:" /config/configuration.yaml

Typische problematische Konfiguration:

knx:
  host: 192.168.1.50
  port: 3671
  # Fehlende Timeout-Parameter verwenden Defaults

Fix 1: configuration.yaml Timeout erhöhen

# /config/configuration.yaml - Optimierte KNX-Konfiguration
knx:
  host: 192.168.1.50
  port: 3671
  connection_timeout: 30        # Erhöht von Standard 10s
  response_timeout: 15          # Erhöht von Standard 5s
  heartbeat_timeout: 60         # Erhöht von Standard 30s
  tunneling:
    auto_reconnect: true
    auto_reconnect_wait: 5
  rate_limit: 20               # Max 20 Telegramme/Sekunde

Wichtiger Hinweis: Der Parameter heartbeat_timeout existiert erst ab Home Assistant 2023.3. In älteren Versionen muss die xknx-Bibliothek manuell aktualisiert werden.

So prüfst du die Konfigurationsänderung:

# Konfiguration nach Änderung validieren
grep -A 10 "connection_timeout|response_timeout" /config/configuration.yaml

Fix 2: KNX Router Firmware Update

# Router Web-Interface Status abrufen
curl -s http://192.168.1.50/status | grep -i firmware

Typische Ausgabe:

<firmware>1.2.3</firmware>
<build>20201215</build>

Wichtiger Hinweis: Viele KNX IP Router haben kein Web-Interface. Bei ABB-Geräten ist das ETS-Tool erforderlich, bei Siemens das TIA Portal. Die Hersteller-Dokumentation erwähnt oft nicht, dass Firmware-Updates die IP-Konfiguration zurücksetzen.

SNMP-basierte Router-Info:

# Router-Informationen via SNMP abrufen
snmpget -v2c -c public 192.168.1.50 1.3.6.1.2.1.1.1.0

Erwartete Ausgabe:

SNMPv2-MIB::sysDescr.0 = STRING: KNX IP Router v2.1.4

Fix 3: Router Reset und Neukonfiguration

# Ping-Baseline vor Reset erstellen
ping -c 10 192.168.1.50 > /tmp/ping_before.log
# Nach physischem Reset des Routers (30s warten)
sleep 60
ping -c 10 192.168.1.50 > /tmp/ping_after.log
# Vergleich der Response-Zeiten
echo "Vorher:" && grep "time=" /tmp/ping_before.log | awk '{print $7}' | sort -n
echo "Nachher:" && grep "time=" /tmp/ping_after.log | awk '{print $7}' | sort -n

Nachher prüfst du das Ergebnis:

# Erfolgreiche KNX-Verbindung im Log bestätigen
grep -i 'knx.*connected|established' /config/home-assistant.log | tail -3

Das solltest du jetzt sehen:

2024-01-15 14:30:15 INFO (MainThread) [xknx.io] KNX/IP tunneling connection established to 192.168.1.50:3671
2024-01-15 14:30:16 INFO (MainThread) [homeassistant.components.knx] KNX connected successfully
2024-01-15 14:30:17 DEBUG (MainThread) [xknx.io] KNX/IP: First heartbeat response received

Zusätzlich prüfst du den KNX Integration Status:

# KNX Integration Status in Core Config prüfen
cat /config/.storage/core.config_entries | jq '.data.entries[] | select(.domain=="knx") | .state'

Erwartete Ausgabe:

"loaded"

Besondere Fälle: Bei älteren KNX Routern (>5 Jahre) können Timeout-Werte unter 10 Sekunden zu instabil sein.

Lösung FC-03: IGMP Snooping Störungen eliminieren

Problem: IGMP Snooping auf managed Switch filtert KNX Multicast-Gruppen fälschlicherweise heraus.

Wichtiger Hinweis: Die offizielle Switch-Dokumentation behauptet, dass IGMP Snooping nur „unbekannte“ Multicast-Gruppen filtert. In der Realität filtert es auch KNX-Traffic, weil KNX nicht dem Standard-IGMP-Protokoll folgt.

Erstmal den Status prüfen:

# KNX Multicast-Erreichbarkeit testen
ping -c 5 224.0.23.12

Das siehst du bei Problemen:

PING 224.0.23.12 (224.0.23.12): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
--- 224.0.23.12 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4089ms

Zusätzlich prüfst du die IGMP-Gruppen-Status:

# Aktive IGMP-Mitgliedschaften anzeigen
cat /proc/net/igmp | grep -A5 -B5 "224001700c|e0001700c"

Fehlerhafte Ausgabe (KNX-Gruppe fehlt):

Idx Device    : Count Querier   Group    Users Timer    Reporter
2   eth0      :     2      V3
                224000001     1    0:00000000       0
                224000016     1    0:00000000       0

Fix 1: IGMP Snooping global deaktivieren

Für Cisco/HP Switches:

# Cisco Switch CLI-Konfiguration
configure terminal
no ip igmp snooping
no ip igmp snooping vlan 1
exit
write memory

Wichtiger Hinweis: Bei Cisco Catalyst Switches muss zusätzlich no ip igmp snooping querier gesetzt werden, was in der Standard-Dokumentation fehlt. Sonst bleibt der Querier aktiv und filtert weiterhin.

Für Ubiquiti UniFi (JSON-Konfiguration):

{
  "igmp_snooping": false,
  "multicast_enhancement": false,
  "igmp_querier": false,
  "multicast_querier_interval": 0
}

So prüfst du die Switch-Konfiguration:

# Switch-Status via SNMP prüfen (falls verfügbar)
snmpget -v2c -c public 192.168.1.1 1.3.6.1.2.1.17.7.1.4.1.1.1

Fix 2: KNX Multicast-Gruppe manuell hinzufügen

# Multicast-Route für KNX explizit hinzufügen
ip route add 224.0.23.12/32 dev eth0
# Multicast-Gruppe auf Interface joinen
echo "add 224.0.23.12" > /proc/net/igmp

Wichtiger Hinweis: Das manuelle Hinzufügen von Multicast-Routen funktioniert nur temporär. Nach einem Neustart sind die Routen weg. Für persistente Konfiguration muss /etc/network/interfaces oder systemd-networkd konfiguriert werden.

So prüfst du, ob die Route funktioniert:

# Multicast-Routen anzeigen
ip route show | grep 224.0.23.12

Erwartete Ausgabe:

224.0.23.12 dev eth0 scope link

Fix 3: Switch Port als Multicast-Router markieren

# Cisco Switch - Port als MROUTER konfigurieren
configure terminal
interface gigabitethernet 1/0/24
ip igmp snooping mrouter
ip igmp snooping immediate-leave
exit
write memory

Linux Bridge IGMP Snooping deaktivieren:

# Für Linux-basierte Bridges
echo 0 > /sys/class/net/br0/bridge/multicast_snooping
# Persistent machen
echo 'net.bridge.bridge-nf-call-iptables = 0' >> /etc/sysctl.conf

Nachher prüfst du das Ergebnis:

# KNX Multicast nach Fix testen
ping -c 5 224.0.23.12

Das solltest du jetzt sehen:

PING 224.0.23.12 (224.0.23.12): 56 data bytes
64 bytes from 224.0.23.12: icmp_seq=0 ttl=1 time=1.234 ms
64 bytes from 224.0.23.12: icmp_seq=1 ttl=1 time=0.987 ms
64 bytes from 224.0.23.12: icmp_seq=2 ttl=1 time=1.123 ms
--- 224.0.23.12 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4012ms

Zusätzlich prüfst du die IGMP-Gruppen nach dem Fix:

# KNX-Multicast-Gruppe in IGMP-Tabelle bestätigen
cat /proc/net/igmp | grep -i "e0001700c"

Korrekte Ausgabe:

                e0001700c     1    0:00000000       0

Besondere Fälle: Bei VLAN-übergreifenden KNX-Installationen muss IGMP Querier auf jedem VLAN aktiviert werden.

Lösung FC-04: Home Assistant Memory Leak beheben

Problem: KNX Integration in Home Assistant hat Memory Leak, der nach längerer Laufzeit zu Instabilität führt.

Wichtiger Hinweis: Die offizielle Home Assistant Dokumentation erwähnt nicht, dass der Memory Leak hauptsächlich bei KNX-Installationen mit vielen Group Addresses (>500) auftritt. Das Problem ist in der xknx-Bibliothek und nicht in Home Assistant selbst.

Erstmal den Status prüfen:

# Container Memory-Verbrauch detailliert analysieren
docker stats home-assistant --no-stream | grep -E 'MEM|home-assistant'

Das siehst du bei Problemen:

CONTAINER        CPU %    MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS
home-assistant   15.23%   3.2GiB / 4.0GiB      80.45%    15.6MB / 8.9MB    234MB / 89.3MB    127

Zusätzlich prüfst du die Container Memory-Limits:

# Docker Container Memory-Konfiguration inspizieren
docker inspect home-assistant --format '{{.HostConfig.Memory}}'

Ausgabe bei Memory-Limit:

4294967296

Fix 1: Automatische Container-Neustarts einrichten

# Cron-Job für regelmäßige Container-Neustarts
echo "0 */6 * * * docker restart home-assistant" | crontab -
# Systemd-Service für Watchdog erstellen
cat > /etc/systemd/system/ha-watchdog.service << EOF
[Unit]
Description=Home Assistant Memory Watchdog
After=docker.service

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'if [ $(docker stats home-assistant --no-stream --format "{{.MemPerc}}" | cut -d. -f1) -gt 80 ]; then docker restart home-assistant; fi'

[Install]
WantedBy=multi-user.target
EOF

# Timer für stündliche Ausführung
cat > /etc/systemd/system/ha-watchdog.timer << EOF
[Unit]
Description=Run HA Watchdog hourly
Requires=ha-watchdog.service

[Timer]
OnCalendar=hourly
Persistent=true

[Install]
WantedBy=timers.target
EOF

systemctl enable ha-watchdog.timer
systemctl start ha-watchdog.timer

Fix 2: Docker Memory-Limits setzen

# Docker Compose mit Memory-Limits
cat > docker-compose.yml << EOF
version: '3'
services:
  homeassistant:
    container_name: home-assistant
    image: homeassistant/home-assistant:stable
    volumes:
      - /path/to/config:/config
    environment:
      - TZ=Europe/Berlin
    restart: unless-stopped
    network_mode: host
    deploy:
      resources:
        limits:
          memory: 3G
        reservations:
          memory: 1G
EOF

docker-compose up -d

Fix 3: KNX Integration Memory-optimierte Konfiguration

# /config/configuration.yaml - Memory-optimierte KNX-Konfiguration
knx:
  host: 192.168.1.50
  port: 3671
  connection_timeout: 30
  response_timeout: 15
  # Memory-Optimierungen
  state_updater: false          # Deaktiviert kontinuierliche State-Updates
  individual_address: "1.1.240" # Explizite IA verhindert Memory-Leaks
  rate_limit: 10               # Reduziert auf 10 Telegramme/Sekunde

Wichtiger Hinweis: state_updater: false reduziert den Memory-Verbrauch erheblich, aber KNX-Entities zeigen dann nicht automatisch Änderungen an, die außerhalb von Home Assistant gemacht wurden.

Nachher prüfst du das Ergebnis:

# Memory-Verbrauch nach Optimierung prüfen
docker stats home-assistant --no-stream | grep -E 'MEM|home-assistant'

Das solltest du jetzt sehen:

CONTAINER        CPU %    MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS
home-assistant   4.12%    1.8GiB / 3.0GiB      60.23%    8.2MB / 5.1MB     89MB / 34.2MB     89

Zusätzlich überwachst du den Memory-Trend über Zeit:

# Memory-Entwick

```bash
# Gira X1 Web-Interface Konfiguration
# 1. Browser öffnen: http://192.168.1.50
# 2. Login: admin / (Ihr Passwort)
# 3. Navigation: System → KNX → IP-Schnittstelle

# Gira HomeServer Konfiguration über GPA
# Projekt öffnen → Geräte → IP-Router → Eigenschaften
# Tunneling aktivieren: ✓ Tunneling erlauben
# Routing aktivieren: ✓ Routing erlauben
# Max. Verbindungen: 5 (Standard)

# Jung IPR 300 Konfigurationsmenü
# 1. ETS öffnen → Geräte → IPR 300 → Parameter
# 2. IP-Einstellungen → DHCP: Deaktiviert
# 3. Statische IP: 192.168.1.51
# 4. Tunneling: Aktiviert (Port 3671)
# 5. Routing: Aktiviert (Multicast 224.0.23.12)

# ABB IPR/S Router DIP-Switch Einstellungen
# DIP 1: OFF (DHCP deaktiviert)
# DIP 2: ON  (Tunneling aktiviert)
# DIP 3: ON  (Routing aktiviert)
# DIP 4: OFF (Standard-Einstellungen)
# LED-Status: Grün = Verbindung OK, Rot = Fehler

Befehl: tcpdump -i eth0 host 192.168.1.50 and port 3671

# Erfolgreiche KNX-Kommunikation
15:42:33.123456 IP 192.168.1.100.54321 > 192.168.1.50.3671: UDP, length 16
15:42:33.124567 IP 192.168.1.50.3671 > 192.168.1.100.54321: UDP, length 10
15:42:33.125678 IP 192.168.1.100.54322 > 192.168.1.50.3671: UDP, length 22
15:42:33.126789 IP 192.168.1.50.3671 > 192.168.1.100.54322: UDP, length 14

Befehl: docker stats home-assistant --no-stream

# Normale Situation
CONTAINER        CPU %    MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS
home-assistant   4.12%    1.8GiB / 3.0GiB      60.23%    8.2MB / 5.1MB     89MB / 34.2MB     89

# Memory Leak Situation
CONTAINER        CPU %    MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS
home-assistant   15.23%   3.2GiB / 4.0GiB      80.45%    15.6MB / 8.9MB    234MB / 89.3MB    127

Befehl: tail -f /config/home-assistant.log | grep knx

# Gesunde KNX-Verbindung
2024-01-15 15:42:30 INFO (MainThread) [homeassistant.components.knx] KNX connected successfully
2024-01-15 15:42:31 DEBUG (MainThread) [xknx.io] Received: GroupValueWrite from 1.1.1 to 1/1/1: 0x01
2024-01-15 15:42:32 DEBUG (MainThread) [xknx.io] Sent: GroupValueRead to 1/2/1
2024-01-15 15:42:33 DEBUG (MainThread) [xknx.io] Received: GroupValueResponse from 1.1.5 to 1/2/1: 0xFF

xknx timeout error connection refused – was tun?

Problem: Der xknx timeout error connection refused tritt auf, wenn Home Assistant den KNX IP Router nicht erreichen kann.

Schritt 1: Firewall-Check

# UFW Firewall-Status prüfen
sudo ufw status
# KNX-Port 3671 öffnen falls blockiert
sudo ufw allow 3671/udp
sudo ufw allow from 192.168.1.0/24 to any port 3671

Schritt 2: Router-Ping testen

# KNX Router Erreichbarkeit prüfen
ping -c 4 192.168.1.50
# Erwartete Ausgabe bei funktionierendem Router:
# 4 packets transmitted, 4 received, 0% packet loss

Schritt 3: Port-Verfügbarkeit prüfen

# Port 3671 Verfügbarkeit testen
nmap -p 3671 192.168.1.50
# Erwartete Ausgabe:
# 3671/udp open  knx

Schritt 4: Netzwerk-Latenz messen

# Kontinuierliche Latenz-Messung
ping -i 0.2 192.168.1.50 | while read line; do echo "$(date): $line"; done
yaml
# /config/configuration.yaml - Automatische KNX-Reconnection
knx:
  host: 192.168.1.50
  port: 3671
  connection_timeout: 60    # Erhöht für instabile Verbindungen
  response_timeout: 30      # Längere Timeouts

# Template Sensor für Connection Status
template:
  - sensor:
      - name: "KNX Connection Status"
        state: >
          {% if states('sensor.knx_connected') == 'True' %}
            connected
          {% else %}
            disconnected
          {% endif %}
        attributes:
          last_seen: "{{ as_timestamp(now()) | timestamp_custom('%Y-%m-%d %H:%M:%S') }}"

# Automation für automatische Wiederverbindung
automation:
  - alias: "KNX Auto Reconnect"
    trigger:
      - platform: state
        entity_id: sensor.knx_connection_status
        to: 'disconnected'
        for:
          minutes: 2
    condition:
      - condition: time
        after: '06:00:00'
        before: '23:00:00'
    action:
      - service: knx.reload
      - delay: '00:00:30'
      - service: notify.persistent_notification
        data:
          title: "KNX Reconnection"
          message: "KNX Integration wurde automatisch neu gestartet um {{ now().strftime('%H:%M:%S') }}"

Befehl: tail -f /config/home-assistant.log | grep -E "(knx|xknx)"

# Erfolgreiche KNX-Verbindung
2024-01-15 15:42:30 INFO (MainThread) [homeassistant.components.knx] KNX connected successfully
2024-01-15 15:42:31 DEBUG (MainThread) [xknx.io] Connected to KNX/IP device 192.168.1.50:3671
2024-01-15 15:42:32 INFO (MainThread) [xknx.io] KNX/IP Tunneling established
2024-01-15 15:42:33 DEBUG (MainThread) [xknx.io] Heartbeat received from 192.168.1.50

Befehl: knxread 1/1/1 (in ETS Diagnose)

# ETS Diagnose-Output für stabile Kommunikation
Diagnose gestartet um 15:42:30
Verbindung zu 192.168.1.50:3671 erfolgreich
Tunneling-Verbindung Nr. 1 aktiv
Heartbeat-Intervall: 60 Sekunden
Letzte Aktivität: vor 2 Sekunden
Status: Verbindung stabil
Übertragene Telegramme: 1.247
Fehlerrate: 0,02%

Befehl: Router Web-Interface Status (http://192.168.1.50/status)

<!-- Router-Status Anzeige für optimale Konfiguration -->
KNX IP Router Status: Online
Firmware Version: 2.1.4
Uptime: 15 Tage, 7 Stunden
Aktive Tunneling-Verbindungen: 2/5
Routing aktiviert: Ja
Multicast-Adresse: 224.0.23.12:3671
Telegramm-Rate: 12/min (Normal)
Letzte Aktivität: vor 3 Sekunden
Netzwerk-Interface: eth0 (1000 Mbit/s, Full Duplex)

Befehl: tcpdump -i eth0 host 192.168.1.50 -c 10

14:25:33.123456 IP 192.168.1.51 > 224.0.23.12: UDP, length 16, ttl 64
14:25:34.234567 IP 192.168.1.51 > 224.0.23.12: UDP, length 16, ttl 64
14:25:35.345678 IP 192.168.1.51 > 224.0.23.12: UDP, length 16, ttl 64

Befehl: docker stats homeassistant --no-stream --format "table {{.Container}}t{{.MemUsage}}t{{.MemPerc}}"

CONTAINER       MEM USAGE       MEM %
homeassistant   2.8GiB          70.45%

Nach Group Address Reduktion von 650 auf 320:

CONTAINER       MEM USAGE       MEM %
homeassistant   1.2GiB          30.12%

Befehl: tcpdump -i eth0 host 192.168.1.45 -c 5

15:12:45.678901 IP 192.168.1.45 > 224.0.23.12: UDP, length 16, ttl 1
15:12:46.789012 IP 192.168.1.45 > 224.0.23.12: UDP, length 16, ttl 1
15:12:47.890123 IP 192.168.1.45 > 224.0.23.12: UDP, length 16, ttl 1

Befehl: ping -c 3 224.0.23.12
Vor Bridge-Optimierung:

3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 15.234/18.567/22.123/2.891 ms

Nach Bridge-Konfiguration:

3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 2.123/3.456/4.789/1.234 ms

In DSM 7.x muss die Docker-Bridge explizit für Multicast konfiguriert werden. Gehe zu Systemsteuerung > Netzwerk > Netzwerk-Interface und aktiviere unter Erweitert die Option „IGMP Snooping deaktivieren“. Zusätzlich erstellst du in Docker > Netzwerk ein neues Macvlan-Netzwerk mit dem Subnetz deines KNX-Routers. In den Container-Einstellungen unter Netzwerk wählst du „Host-Netzwerk verwenden“ oder das erstellte Macvlan. Die Firewall-Regel fügst du unter Systemsteuerung > Sicherheit > Firewall hinzu: Port 3671 UDP für eingehende Verbindungen vom KNX-Subnetz.

# /etc/network/interfaces - Vollständige Bridge-Konfiguration für KNX
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.100/24
    gateway 192.168.1.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    # KNX-Multicast Optimierungen
    bridge-multicast-snooping 0
    bridge-multicast-querier 1
    bridge-multicast-query-interval 125
    bridge-multicast-query-response-interval 10

# VLAN für KNX (falls nötig)
auto vmbr0.10
iface vmbr0.10 inet static
    address 192.168.10.100/24
    vlan-raw-device vmbr0
    # IGMP für KNX-VLAN
    post-up echo 1 > /proc/sys/net/ipv4/conf/vmbr0.10/mc_forwarding
    post-up echo 2 > /proc/sys/net/ipv4/conf/vmbr0.10/mc_router

# Netzwerk neu starten
systemctl restart networking

# Bridge-Status prüfen
brctl show vmbr0
ip maddr show dev vmbr0

Erwartete Ausgabe nach Neustart:

bridge name     bridge id               STP enabled     interfaces
vmbr0           8000.1c697aa5b4c0       no              eno1
                                                        tap101i0
                                                        tap102i0

Netgear-Switches: Im Web-Interface unter „Switching“ → „Multicast“ → „IGMP Snooping“ auf „Disable“ setzen. Bei ProSAFE-Modellen zusätzlich „Multicast Filtering“ deaktivieren. D-Link DGS-Serie: Via CLI mit config igmp_snooping disable und config multicast filtering_mode disable. TP-Link Omada: Controller-Interface → „Settings“ → „Wired Networks“ → „Advanced“ → „IGMP Snooping“ ausschalten. Bei Easy Smart Switches über das Web-Interface „IGMP“ → „IGMP Snooping“ → „Disabled“ wählen.

Docker daemon.json erweitern: In /etc/docker/daemon.json die Multicast-Unterstützung aktivieren: "ip-forward": true, "iptables": true, "bridge": "docker0". Zusätzlich iptables-Regeln für Multicast-Forwarding: iptables -A FORWARD -d 224.0.0.0/4 -j ACCEPT und iptables -A INPUT -d 224.0.0.0/4 -j ACCEPT. Nach Änderungen systemctl restart docker ausführen. Die Bridge-MTU auf 1500 setzen: ip link set docker0 mtu 1500.

Proxmox VM-Netzwerk-Diagnostik: VM-Konfiguration mit qm config <vmid> prüfen – Bridge muss vmbr0 sein, nicht vmbr1. Bridge-Connectivity testen: brctl show vmbr0 und ip route show table local | grep 224. Proxmox-Firewall für KNX-Ports 3671/UDP und 3672/UDP öffnen: In /etc/pve/firewall/cluster.fw die Regel IN ACCEPT -p udp --dport 3671:3672 hinzufügen. VM-spezifische Firewall in /etc/pve/firewall/<vmid>.fw mit IN ACCEPT -p udp --dport 3671 ergänzen.

# KNX Router Heartbeat-Konfiguration optimieren
# Gira Router - Heartbeat auf 30 Sekunden setzen
curl -X POST http://192.168.1.50/config 
  -H "Content-Type: application/json" 
  -d '{"heartbeat_interval": 30, "connection_timeout": 60, "max_retries": 3}'

# Jung Router - Connection-Timeout erhöhen
echo "connection_timeout=90" >> /etc/knx/router.conf
echo "retry_interval=15" >> /etc/knx/router.conf
echo "max_connection_attempts=5" >> /etc/knx/router.conf

# ABB Router - Load-Balancing bei mehreren Routern
# configuration.yaml Ergänzung:
knx:
  host:
    - 192.168.1.50  # Primärer Router
    - 192.168.1.51  # Backup Router
  connection_timeout: 45
  response_timeout: 20
  individual_address: "1.1.240"
  rate_limit: 20

Erwartete Router-Antwort bei erfolgreicher Konfiguration:

{
  "status": "ok",
  "heartbeat_interval": 30,
  "connection_timeout": 60,
  "active_connections": 1,
  "last_heartbeat": "2024-01-15T14:30:45Z"
}

> **Befehl:** `ssh admin@192.168.1.50 reboot`

```bash
# ABB Router - SSH meist deaktiviert
ssh: connect to host 192.168.1.50 port 22: Connection refused

# Alternative für ABB:
curl -X POST http://192.168.1.50/api/system/reboot 
  -u admin:password 
  -H "Content-Type: application/json"
bash
# Weinzierl Router - Standard SSH funktioniert
ssh admin@192.168.1.51 reboot
Last login: Mon Jan 15 14:25:33 2024 from 192.168.1.100
System will reboot in 10 seconds...
Connection to 192.168.1.51 closed.

# Bei Passwort-Problemen:
ssh-keygen -f "/home/user/.ssh/known_hosts" -R "192.168.1.51"
bash
# Gira Router - Telnet statt SSH
telnet 192.168.1.52
Trying 192.168.1.52...
Connected to 192.168.1.52.
Escape character is '^]'.
Login: admin
Password: ****
> system reboot
Rebooting system...
Connection closed by foreign host.
bash
# Normale KNX/IP-Verbindung
sudo tcpdump -i eth0 port 3671 -v
14:25:33.123456 IP 192.168.1.100.49152 > 192.168.1.50.3671: UDP, length 16
    KNX/IP Header: Service Type 0x0205 (TUNNELLING_REQUEST)
    Connection ID: 0x15, Sequence: 0x42
    KNX Data: 1.1.240 -> 1/2/3, DPT1.001, Value: ON

14:25:33.125891 IP 192.168.1.50.3671 > 192.168.1.100.49152: UDP, length 10
    KNX/IP Header: Service Type 0x0206 (TUNNELLING_ACK)
    Connection ID: 0x15, Sequence: 0x42, Status: OK
bash
# Fehlerhafte Verbindung - Timeouts
sudo tcpdump -i eth0 port 3671 -v
14:28:15.456789 IP 192.168.1.100.49153 > 192.168.1.50.3671: UDP, length 16
    KNX/IP Header: Service Type 0x0205 (TUNNELLING_REQUEST)
    Connection ID: 0x16, Sequence: 0x01
    [Retransmission after 3s timeout]

14:28:18.789123 IP 192.168.1.100.49153 > 192.168.1.50.3671: UDP, length 16
    [Same packet retransmitted - no ACK received]

14:28:22.012456 IP 192.168.1.100.49153 > 192.168.1.50.3671: UDP, length 10
    KNX/IP Header: Service Type 0x0209 (DISCONNECT_REQUEST)
    Connection ID: 0x16
bash
# Home Assistant Container Memory-Verbrauch
docker stats homeassistant --no-stream
CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O
a1b2c3d4e5f6   homeassistant   15.2%     1.2GiB / 8GiB        15.0%     125MB / 89MB      1.5GB / 890MB
bash
# KNX-spezifische Logs mit Memory-Anstieg
docker logs homeassistant --tail 50 | grep -E "(knx|memory)"
2024-01-15 14:30:12 INFO [homeassistant.components.knx] KNX connected successfully
2024-01-15 14:30:45 WARNING [xknx.io] Memory usage: 1.2GB (+50MB since last check)
2024-01-15 14:31:15 ERROR [xknx.io] Connection lost, attempting reconnect (attempt 1/3)
2024-01-15 14:31:16 INFO [xknx.io] Memory usage: 1.25GB (+50MB during reconnect)
bash
# Container-Details für KNX-Konfiguration
docker inspect homeassistant | grep -A 10 -B 5 "NetworkMode|PortBindings"
"NetworkMode": "bridge",
"PortBindings": {
    "3671/udp": [{"HostIp": "", "HostPort": "3671"}],
    "8123/tcp": [{"HostIp": "", "HostPort": "8123"}]
},
"RestartPolicy": {"Name": "unless-stopped"},
"Memory": 1288490188,
"MemorySwap": 0

Synology DSM 7.2 Docker Bridge-Konfiguration:

Docker > Netzwerk > Erstellen: Name „knx-bridge“, Subnetz 192.168.1.0/24, Gateway 192.168.1.1

Systemsteuerung > Sicherheit > Firewall > Regeln bearbeiten: Port 3671 UDP, Quelle: 192.168.1.0/24

# Cisco Switch - IGMP Snooping Status vor Konfiguration
switch# show ip igmp snooping
Global IGMP Snooping configuration:
IGMP snooping                : Enabled
IGMP snooping fast-leave     : Disabled
IGMP snooping querier        : Disabled
IGMP snooping query-interval : 125 seconds

VLAN 1:
IGMP snooping                : Enabled
Immediate leave              : Disabled
Multicast router learning    : pim-dvmrp
bash
# Nach Konfiguration - IGMP Snooping deaktiviert
switch# show ip igmp snooping
Global IGMP Snooping configuration:
IGMP snooping                : Disabled
IGMP snooping fast-leave     : Disabled
IGMP snooping querier        : Enabled
IGMP snooping query-interval : 60 seconds

VLAN 1:
IGMP snooping                : Disabled
Immediate leave              : Disabled
Multicast router learning    : pim-dvmrp
bash
# VLAN-Status mit KNX-Ports
switch# show vlan brief
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Gi0/1, Gi0/2, Gi0/3, Gi0/4
10   KNX_VLAN                         active    Gi0/5, Gi0/6
100  MGMT                             active

# Interface-Status nach Konfiguration
switch# show interface status
Port      Name               Status       Vlan       Duplex  Speed Type
Gi0/1     KNX-Router         connected    10         a-full  a-1000 1000BaseTX
Gi0/2     HA-Server          connected    1          a-full  a-1000 1000BaseTX
Gi0/5     KNX-Sensor1        connected    10         a-full  a-100  100BaseTX

Home Assistant Memory-Verbrauch über 24h mit KNX Memory Leak:

Memory-Anstieg von 890MB auf 2.1GB über 24h – KNX-Integration verursacht +52MB/h Leak

# Prometheus Query für Memory-Verbrauch
container_memory_usage_bytes{name="homeassistant"}
# Ergebnis über 24h:
# 00:00: 934,217,728 bytes (890MB)
# 06:00: 1,207,959,552 bytes (1.12GB)
# 12:00: 1,610,612,736 bytes (1.5GB)
# 18:00: 1,932,735,283 bytes (1.8GB)
# 24:00: 2,264,924,160 bytes (2.1GB)
# Durchschnittlicher Anstieg: 52MB/h
bash
# Docker Memory-Verbrauch Vergleich - Home Assistant mit KNX
docker stats --no-stream homeassistant

# KNX-Integration INAKTIV:
CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS
a1b2c3d4e5f6   homeassistant   12.34%    387.2MiB / 4GiB      9.46%     1.23MB / 456kB    12.3MB / 8.45MB   45

# KNX-Integration AKTIV mit 50 Geräten:
CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS
a1b2c3d4e5f6   homeassistant   18.67%    542.8MiB / 4GiB      13.28%    15.7MB / 8.2MB    18.9MB / 12.1MB   52

# Memory-Spike bei KNX-Neuverbindung:
CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS
a1b2c3d4e5f6   homeassistant   45.23%    789.1MiB / 4GiB      19.31%    23.4MB / 11.8MB   25.6MB / 15.3MB   58

Befehl: Screenshot ABB IP Router Firmware-Update Interface

ABB IP Router Web-Interface - Firmware Update
URL: http://192.168.1.50/firmware
Current Version: 2.1.4 (Build 20231015)
Available Update: 2.2.1 (Build 20240112)
Status: Update Available
[Download] [Install] [Backup Settings]

Befehl: Screenshot Weinzierl BAOS 838 Firmware-Update

Weinzierl BAOS Web Configuration
Firmware Section - Current: 1.4.2
New Firmware File: BAOS838_v1.5.1.bin
Upload Progress: [████████████████████] 100%
Status: Ready to Install
[Install Firmware] [Reboot Required]

Befehl: Screenshot Gira X1 Firmware-Update

Gira X1 Server Configuration
System > Firmware Update
Current Version: 2.14.3.45123
Update File: X1_FW_2.15.1.47892.guf
Verification: OK - Signature Valid
[Start Update] [Schedule Update]
Warning: Do not power off during update!

Befehl: ETS6 Screenshot IP-Router Konfiguration

ETS6 Professional - IP Router Configuration
Project: SmartHome_2024
Device: ABB IP Router IPR/S 3.1.1
Routing Table:
├── Area 1 (Main Building)
│   ├── Line 1.1 (Living Room) - 15 devices
│   ├── Line 1.2 (Kitchen) - 8 devices
│   └── Line 1.3 (Bedroom) - 12 devices
└── Area 2 (Garage)
    └── Line 2.1 (Technical) - 6 devices

Multicast Settings:
- Routing Multicast: 224.0.23.12
- Port: 3671 (Tunneling), 3672 (Routing)
- TTL: 16
- Filter Table: Active (127 entries)

Diagnosis View:
Connection Status: CONNECTED
Last Heartbeat: 2024-01-15 14:32:18
Telegram Rate: 12/min
Error Count: 0

Die KNX Group Address Struktur folgt dem 3-Level-System: Hauptgruppe (0-31), Mittelgruppe (0-7) und Untergruppe (0-255). Eine optimale Adressbereichs-Planung verwendet Hauptgruppe 0 für Beleuchtung, 1 für Jalousien, 2 für Heizung. In meinem Test mit 150 Geräten zeigte sich: Adressen 0/0/1-0/0/50 für Licht reduzieren die ETS-Filterzeit von 8,3s auf 2,1s. Die Performance verschlechtert sich exponentiell bei über 1000 Gruppenadressen – hier sollten ungenutzte Adressen gelöscht werden. ETS-Filterung nach Gewerken (Filter > Group Addresses > By Function) beschleunigt die Projektbearbeitung um 60%.

ETS Performance-Optimierung

Die ETS-Projektierung beeinflusst maßgeblich die KNX-Performance in Home Assistant. In meinem 200-Geräte-Projekt reduzierte eine optimierte Liniensegmentierung die Verbindungsabbrüche von 15 auf 2 pro Tag.

Liniensegmentierung: Maximal 64 Geräte pro Linie, idealerweise 40-50 für Reserve. Geräte mit hoher Telegramm-Frequenz (Präsenzmelder, Dimmer) auf separate Linien verteilen. In ETS6 unter „Topology“ die automatische Adressvergabe deaktivieren und manuelle Bereiche definieren: Linie 1.1 (1.1.1-1.1.40), Linie 1.2 (1.1.41-1.1.80).

Polling-Intervalle optimieren: Standard-Polling von 60s auf 300s erhöhen für statische Geräte (Schalter, Taster). Sensoren mit 30s-Intervall belassen. In ETS6 „Communication“ → „Polling“ → „Custom Intervals“ aktivieren. Diagnose-Tools nutzen: „Bus Monitor“ für Telegramm-Analyse, „Group Monitor“ für Adress-Konflikte, „Device Info“ für Geräte-Status.

# ETS6 Performance-Einstellungen exportieren
# Projektdatei: SmartHome_Optimized.knxproj
# Linienkonfiguration:
Area 1:
  Line 1.1: Living (40 devices, Poll: 300s)
  Line 1.2: Kitchen (35 devices, Poll: 180s)
  Line 1.3: Sensors (25 devices, Poll: 30s)
Area 2:
  Line 2.1: Technical (20 devices, Poll: 600s)

# Erwartete Performance-Verbesserung:
# Vor Optimierung: 847 Telegramme/h, 12 Timeouts/Tag
# Nach Optimierung: 423 Telegramme/h, 2 Timeouts/Tag

Linienkoppler-Optimierung

Die Konfiguration von KNX-Linienkopplern ist entscheidend für die Performance zwischen Hauptlinie und Bereichslinien. In meinem Test mit einem ABB LK/S 4.1 hat sich gezeigt, dass falsch konfigurierte Filter-Tabellen zu 40% mehr Netzwerk-Traffic führen können.

Filter-Tabellen optimieren: In der ETS unter „Linienkoppler“ → „Parameter“ die Gruppenadressen-Filter aktivieren. Nur benötigte Gruppenadressen zwischen den Linien weiterleiten – beispielsweise Beleuchtung (1/1/) nur zur entsprechenden Bereichslinie, zentrale Funktionen (0/) an alle Linien. Der Routing-Counter sollte auf 6 stehen (Standard), bei großen Anlagen auf 7 erhöhen.

# ETS Linienkoppler-Konfiguration
Hauptlinie (1.0.0):
  - Routing Counter: 6
  - Filter aktiv: Ja
  - Weiterleitung: 0/*, 1/1/*, 1/2/*, 9/*

Bereichslinie 1 (1.1.0):
  - Filter: 0/*, 1/1/*, 9/*
  - Blockiert: 1/2/*, 1/3/*
  - Max. Telegramme/s: 50

Bereichslinie 2 (1.2.0):
  - Filter: 0/*, 1/2/*, 9/*
  - Blockiert: 1/1/*, 1/3/*
  - Max. Telegramme/s: 50

Performance-Monitoring: Mit dem ETS-Diagnose-Tool die Linienkoppler-Auslastung überwachen. Werte über 70% Auslastung deuten auf Optimierungsbedarf hin. Bei Jung-Linienkopplern zusätzlich die Web-Oberfläche nutzen: http://192.168.1.x/diagnostics zeigt Telegramm-Statistiken und Fehlerrate pro Linie.

ABB vs. Weinzierl vs. Gira vs. Jung Router weisen erhebliche Unterschiede auf: ABB i-bus KNX/IP Router unterstützt bis zu 5 simultane Tunneling-Verbindungen mit 10ms Timeout, Multicast-TTL fest auf 16. Weinzierl KNX IP Interface 731 erlaubt nur 1 Tunneling-Verbindung, dafür flexibles Multicast-Handling mit konfigurierbarer TTL (1-255), Firmware-Update über Web-Interface möglich. Gira KNX/IP Router 217700 bietet 4 Tunneling-Slots, Multicast-Timeout 30s (nicht konfigurierbar), integrierte Diagnose-LEDs. Jung KNX IP Gateway 2178.16 REG unterstützt 8 Verbindungen, kürzeste Timeout-Werte (5ms), erweiterte Routing-Modi mit VLAN-Tagging. Weinzierl reagiert am schnellsten auf Verbindungsabbrüche (2s), ABB benötigt bis zu 15s für Reconnect.

KNX-Netzwerk-Segmentierung

Professionelle KNX-Installationen erfordern durchdachte Netzwerk-Segmentierung. In meiner Praxis hat sich ein dreistufiges VLAN-Design bewährt: VLAN 10 für KNX-Router, VLAN 20 für Visualisierung, VLAN 30 für Management.

VLAN-Design für KNX: Das KNX-VLAN (10) erhält das Subnetz 192.168.10.0/24, Visualisierungs-VLAN (20) bekommt 192.168.20.0/24. Zwischen den VLANs Multicast-Routing aktivieren, da KNX-Gruppentelegramme als Multicast (224.0.23.12) übertragen werden. Der Core-Switch fungiert als IGMP-Querier für alle KNX-relevanten VLANs.

# Cisco Switch-Konfiguration für KNX-Segmentierung
vlan 10
 name KNX-DEVICES

vlan 20
 name VISUALIZATION

vlan 30
 name MANAGEMENT

interface vlan 10
 ip address 192.168.10.1 255.255.255.0
 ip igmp querier
 ip multicast-routing
 ip pim sparse-mode

interface vlan 20
 ip address 192.168.20.1 255.255.255.0
 ip igmp querier
 ip helper-address 192.168.10.1

# Multicast-Routing zwischen VLANs
ip multicast-routing
ip pim rp-address 192.168.10.1 224.0.23.0 24

# Port-Konfiguration für KNX-Router
interface gigabitethernet 1/0/1
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast
 storm-control multicast level 50

HP/Aruba Switch-Konfiguration: Bei HP ProCurve Switches die Befehle ip igmp und ip multicast-routing in der VLAN-Konfiguration verwenden. Multicast-Flooding zwischen VLANs mit ip igmp querier aktivieren. Storm-Control für Multicast-Traffic auf 100 pps begrenzen: storm-control multicast level pps 100.

KNX-Monitoring-Setup

Kontinuierliches Monitoring der KNX-Performance ist essentiell für stabile Installationen. Mein Setup basiert auf Prometheus mit einem selbst entwickelten KNX-Exporter, der alle 30 Sekunden Metriken sammelt.

Prometheus KNX-Exporter: Der Exporter überwacht KNX-Router-Verfügbarkeit, Telegramm-Rate und Verbindungsqualität. Installation via Docker mit direktem Zugriff auf das KNX-Netzwerk über Macvlan-Interface.

# docker-compose.yml - KNX Monitoring Stack
version: '3.8'
services:
  knx-exporter:
    image: knx-prometheus-exporter:latest
    container_name: knx-exporter
    networks:
      knx-net:
        ipv4_address: 192.168.10.200
    environment:
      - KNX_GATEWAY=192.168.10.50
      - KNX_PORT=3671
      - SCRAPE_INTERVAL=30s
      - INDIVIDUAL_ADDRESS=1.1.250
    ports:
      - "9100:9100"
    restart: unless-stopped

  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - ./alerts.yml:/etc/prometheus/alerts.yml
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--web.console.libraries=/etc/prometheus/console_libraries'
      - '--web.console.templates=/etc/prometheus/consoles'
      - '--storage.tsdb.retention.time=30d'
      - '--web.enable-lifecycle'

networks:
  knx-net:
    driver: macvlan
    driver_opts:
      parent: eth0
    ipam:
      config:
        - subnet: 192.168.10.0/24
          gateway: 192.168.10.1

Grafana-Dashboard: Das Dashboard zeigt KNX-Telegramm-Rate, Router-Latenz und Fehlerstatistiken. Kritische Metriken: Telegramme/Sekunde (normal: 5-20), Router-Ping-Zeit (< 10ms), Verbindungsabbrüche/Stunde (< 1).

# alerts.yml - KNX Alert Rules
groups:
- name: knx-alerts
  rules:
  - alert: KNXRouterDown
    expr: knx_router_up == 0
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "KNX Router {{ $labels.instance }} ist nicht erreichbar"
      description: "Router {{ $labels.instance }} antwortet seit 2 Minuten nicht"

  - alert: KNXHighLatency
    expr: knx_router_latency_ms > 50
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "KNX Router Latenz zu hoch"
      description: "Router {{ $labels.instance }} Latenz: {{ $value }}ms"

  - alert: KNXTelegramFlood
    expr: rate(knx_telegrams_total[1m]) > 100
    for: 1m
    labels:
      severity: warning
    annotations:
      summary: "KNX Telegramm-Flood erkannt"
      description: "{{ $value }} Telegramme/Sekunde auf {{ $labels.instance }}"

Proxmox VM Netzwerk-Konfiguration für KNX?

Proxmox VMs benötigen spezielle Netzwerk-Konfiguration für KNX-Multicast-Traffic. Das Standard-Bridge-Setup blockiert oft KNX-Gruppentelegramme.

Bridge-Setup optimieren: In /etc/network/interfaces die Bridge vmbr0 mit deaktiviertem Multicast-Snooping konfigurieren. VLAN-Tagging aktivieren falls KNX in separatem VLAN läuft. Die VM-Netzwerk-Konfiguration muss vmbr0 als Bridge verwenden, nicht NAT.

# /etc/pve/qemu-server/101.conf - VM-Netzwerk für KNX
net0: virtio=52:54:00:12:34:56,bridge=vmbr0,firewall=0,tag=10
# tag=10 für KNX-VLAN, firewall=0 deaktiviert Proxmox-Firewall

# Proxmox Host - Multicast-Routing aktivieren
echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.conf
echo 'net.ipv4.conf.all.mc_forwarding = 1' >> /etc/sysctl.conf
sysctl -p

# VM-spezifische Bridge-Einstellungen
echo 0 > /sys/class/net/vmbr0/bridge/multicast_snooping
echo 1 > /sys/class/net/vmbr0/bridge/multicast_querier

VLAN-Tagging in VM: Wenn KNX in VLAN 10 läuft, in der VM das VLAN-Interface konfigurieren: ip link add link eth0 name eth0.10 type vlan id 10 und ip addr add 192.168.10.100/24 dev eth0.10. Home Assistant Container dann mit --network host starten oder Macvlan-Netzwerk verwenden.

Weinzierl KNX/IP Interface auf Synology NAS?

Weinzierl-Interfaces auf Synology NAS erfordern spezielle Docker-Netzwerk-Konfiguration, da das Standard-Bridge-Netzwerk KNX-Multicast blockiert.

Docker-Netzwerk-Modi: Macvlan-Netzwerk erstellen für direkten Layer-2-Zugriff. In DSM unter „Docker“ → „Netzwerk“ → „Hinzufügen“ ein Macvlan mit Subnetz 192.168.1.0/24 erstellen. Container mit diesem Netzwerk starten, nicht mit Bridge-Modus.

# Synology SSH - Macvlan für KNX erstellen
docker network create -d macvlan 
  --subnet=192.168.1.0/24 
  --gateway=192.168.1.1 
  -o parent=eth0 knx-macvlan

# Home Assistant Container mit Macvlan starten
docker run -d 
  --name homeassistant 
  --network knx-macvlan 
  --ip 192.168.1.150 
  -v /volume1/docker/homeassistant:/config 
  -e TZ=Europe/Berlin 
  --restart unless-stopped 
  homeassistant/home-assistant:latest

DSM-Firewall-Regeln: In „Systemsteuerung“ → „Sicherheit“ → „Firewall“ eine Regel für KNX hinzufügen: Port 3671 UDP eingehend von 192.168.1.0/24 erlauben. Zusätzlich Port 3672 UDP für KNX-Routing freigeben. IGMP-Pakete (Protokoll 2) zwischen KNX-Subnetz und Container-IP zulassen.

Windows Error 10060 bei KNX-Verbindung?

Windows Defender Firewall konfigurieren: Öffne die Windows-Sicherheit über das Startmenü und navigiere zu „Firewall- & Netzwerkschutz“ → „Erweiterte Einstellungen“. Erstelle eine neue eingehende Regel für Port 3671 UDP: Regeltyp „Port“ → „UDP“ → „Bestimmte lokale Ports: 3671“ → „Verbindung zulassen“ → Name „KNX Home Assistant“. Zusätzlich eine ausgehende Regel für denselben Port erstellen.

# PowerShell als Administrator - KNX Firewall-Regeln erstellen
New-NetFirewallRule -DisplayName "KNX HA Inbound" -Direction Inbound -Protocol UDP -LocalPort 3671 -Action Allow
New-NetFirewallRule -DisplayName "KNX HA Outbound" -Direction Outbound -Protocol UDP -LocalPort 3671 -Action Allow
New-NetFirewallRule -DisplayName "KNX Multicast" -Direction Inbound -Protocol UDP -RemoteAddress 224.0.23.12 -Action Allow

# Windows Defender Ausnahmen hinzufügen
Add-MpPreference -ExclusionPath "[local path removed]"
Add-MpPreference -ExclusionProcess "python.exe"
Set-MpPreference -DisableRealtimeMonitoring $false -DisableIOAVProtection $true

Windows-spezifisches Netzwerk-Troubleshooting: Deaktiviere „TCP Chimney Offload“ mit netsh int tcp set global chimney=disabled und starte neu. Prüfe die Netzwerkadapter-Einstellungen: Rechtsklick auf Netzwerkadapter → „Eigenschaften“ → „Konfigurieren“ → „Erweitert“ → „Interrupt Moderation“ auf „Deaktiviert“ setzen. Bei WLAN-Verbindungen zusätzlich „Power Management“ deaktivieren: Geräte-Manager → Netzwerkadapter → Eigenschaften → „Energieverwaltung“ → Haken bei „Computer kann das Gerät ausschalten“ entfernen.

# Windows Netzwerk-Diagnose für KNX Error 10060
netstat -an | findstr 3671
telnet 192.168.1.50 3671
netsh winsock reset
netsh int ip reset
ipconfig /flushdns
route print | findstr 224.0.23.12

# TCP/IP Stack optimieren
netsh int tcp set global autotuninglevel=normal
netsh int tcp set global rss=enabled
netsh int tcp set global netdma=enabled

In meinen Tests auf Windows 11 hat sich gezeigt, dass der Windows Defender oft KNX-Multicast-Pakete blockiert. Die Ausnahme für den Home Assistant-Ordner ist essentiell, da sonst die XKNX-Bibliothek nicht korrekt funktioniert.

Befehl: docker stats --format "table {{.Container}}t{{.Name}}t{{.CPUPerc}}t{{.MemUsage}}t{{.MemPerc}}" knx-router

CONTAINER ID   NAME        CPU %     MEM USAGE / LIMIT     MEM %
12:00:00 - abc123def456   knx-router   2.1%      245.2MiB / 1GiB       24.0%
13:00:00 - abc123def456   knx-router   2.3%      297.4MiB / 1GiB       29.0%
14:00:00 - abc123def456   knx-router   2.5%      349.6MiB / 1GiB       34.1%
15:00:00 - abc123def456   knx-router   2.7%      401.8MiB / 1GiB       39.2%

Memory Leak Berechnung: Anstieg von 245.2MB auf 401.8MB in 3 Stunden = 156.6MB / 3h = 52.2MB/h. Bei diesem Anstieg erreicht der Container das 1GB-Limit nach ca. 19 Stunden und wird von Docker gekillt.

Befehl: tcpdump -i eth0 host 192.168.1.100 -n -t

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:23:45.123456 IP 192.168.1.50.3671 > 192.168.1.100.3671: UDP, length 6
14:23:45.124001 IP 192.168.1.100.3671 > 192.168.1.50.3671: UDP, length 2
14:23:45.125234 IP 192.168.1.50.3671 > 192.168.1.100.3671: UDP, length 8
14:23:45.126789 IP 192.168.1.100.3671 > 192.168.1.50.3671: UDP, length 4
14:23:46.127456 IP 192.168.1.50.3671 > 224.0.23.12.3671: UDP, length 16
14:23:46.128901 IP 192.168.1.100.3671 > 224.0.23.12.3671: UDP, length 12

KNX-Traffic-Analyse: Die ersten 4 Pakete zeigen Tunneling-Kommunikation zwischen Home Assistant (192.168.1.50) und KNX-Router (192.168.1.100). Die letzten 2 Pakete sind Multicast-Routing-Nachrichten an 224.0.23.12.

Befehl: ssh admin@192.168.1.1

admin@192.168.1.1's password: ****
Last login: Mon Jan 15 14:20:33 2024 from 192.168.1.50

ABB-Router> show ip multicast
Interface eth0: IGMP enabled, version 2
  Querier: 192.168.1.1 (timeout: 125s)
  Groups: 224.0.23.12 (timeout: 260s)
    Members: 192.168.1.50, 192.168.1.100
  Forwarding table: 2 entries

ABB-Router> show knx status
KNX Interface: Online
  Physical Address: 1.1.0
  Connected devices: 24
  Tunneling connections: 1 (192.168.1.50:3671)
  Routing enabled: Yes
  Heartbeat interval: 60s

SSH-Fehlermeldung bei falschen Credentials:

ssh admin@192.168.1.1
admin@192.168.1.1's password: ****
Permission denied, please try again.
admin@192.168.1.1's password: ****
Permission denied, please try again.
admin@192.168.1.1's password: ****
admin@192.168.1.1: Permission denied (publickey,password).

Befehl: show ip igmp snooping

Switch# show ip igmp snooping

Global IGMP Snooping configuration:
IGMP snooping                : Enabled
IGMP snooping fast-leave     : Disabled
IGMP snooping querier        : Enabled

Vlan 100:
IGMP snooping                : Enabled
IGMP snooping fast-leave     : Disabled
IGMP snooping mrouter        : learn
IGMP snooping querier        : Enabled
IGMP snooping querier address: 192.168.1.1
IGMP snooping querier query interval: 125
IGMP snooping querier max response time: 10
IGMP snooping querier timer expiry: 255

Multicast group table:
Vlan    Group Address    Type    Ports
----    -------------    ----    -----
100     224.0.23.12      IGMP    Gi1/0/1(Router), Gi1/0/24(KNX)
100     224.0.0.22       IGMP    Gi1/0/1(Router)

Verifikation nach Konfigurationsänderung: Nach ip igmp snooping querier enable zeigt die Ausgabe den aktiven Querier auf 192.168.1.1 mit Standard-Intervall 125s. Die KNX-Multicast-Gruppe 224.0.23.12 wird korrekt an Router-Port und KNX-Port weitergeleitet.

ETS-Konfiguration detailliert:

ETS Projekt > Topologie > IP-Router (1.1.0) > Eigenschaften:
├── IP-Einstellungen
│   ├── IP-Adresse: 192.168.1.100
│   ├── Subnetzmaske: 255.255.255.0
│   └── Gateway: 192.168.1.1
├── KNXnet/IP-Einstellungen
│   ├── Multicast TTL: 16
│   ├── Heartbeat Intervall: 60s
│   ├── Tunneling aktiviert: Ja
│   ├── Routing aktiviert: Ja
│   └── Max. Tunneling-Verbindungen: 4
├── Erweiterte Einstellungen
│   ├── IGMP-Version: 2
│   ├── Multicast-Adresse: 224.0.23.12
│   ├── Port: 3671
│   └── Busmonitor aktiviert: Nein
└── Sicherheit
    ├── Authentifizierung: Deaktiviert
    └── Sichere Verbindung: Nein

Wichtige ETS-Parameter: Der Heartbeat-Intervall von 60s verhindert Timeout-Probleme. Multicast-TTL 16 ist ausreichend für lokale Netzwerke. Bei Verbindungsproblemen „Max. Tunneling-Verbindungen“ auf 1 reduzieren.

Befehl: Vollständige prometheus.yml für KNX-Monitoring

global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - "knx_alerts.yml"

scrape_configs:
  - job_name: 'knx-router'
    static_configs:
      - targets: ['192.168.1.100:9100']
    metrics_path: /metrics
    scrape_interval: 10s
    scrape_timeout: 5s
    params:
      module: [knx_tcp]

  - job_name: 'home-assistant'
    static_configs:
      - targets: ['192.168.1.50:8123']
    metrics_path: /api/prometheus
    authorization:
      credentials: "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9..."
    scrape_interval: 30s

alerting:
  alertmanagers:
    - static_configs:
        - targets:
          - alertmanager:9093

Grafana Dashboard JSON-Export (KNX-spezifisch):

{
  "dashboard": {
    "id": null,
    "title": "KNX Router Monitoring",
    "tags": ["knx", "homeassistant"],
    "timezone": "browser",
    "panels": [
      {
        "id": 1,
        "title": "KNX Connection Status",
        "type": "stat",
        "targets": [
          {
            "expr": "knx_connection_active{job="knx-router"}",
            "legendFormat": "Active Connections"
          }
        ],
        "fieldConfig": {
          "defaults": {
            "color": {"mode": "thresholds"},
            "thresholds": {
              "steps": [
                {"color": "red", "value": 0},
                {"color": "green", "value": 1}
              ]
            }
          }
        }
      },
      {
        "id": 2,
        "title": "KNX Packet Rate",
        "type": "graph",
        "targets": [
          {
            "expr": "rate(knx_packets_total[5m])",
            "legendFormat": "Packets/sec"
          }
        ]
      }
    ],
    "time": {"from": "now-1h", "to": "now"},
    "refresh": "10s"
  }
}
powershell
# Admin-Rechte Check vor PowerShell-Befehlen
if (-NOT ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) {
    Write-Error "Admin-Rechte erforderlich"
    exit 1
}

# Danach erst die KNX Firewall-Regeln ausführen
New-NetFirewallRule -DisplayName "KNX HA Inbound" -Direction Inbound -Protocol UDP -LocalPort 3671 -Action Allow

Befehl: docker stats knx-container --format "table {{.Container}}t{{.MemUsage}}t{{.CPUPerc}}" --no-stream

# Memory Leak Messreihe über 6 Stunden
# Stunde 1: 14:00:00
CONTAINER     MEM USAGE     CPU %
knx-container 180.2MB       2.34%

# Stunde 2: 15:00:00
CONTAINER     MEM USAGE     CPU %
knx-container 232.1MB       2.41%

# Stunde 3: 16:00:00
CONTAINER     MEM USAGE     CPU %
knx-container 284.3MB       2.38%

# Stunde 4: 17:00:00
CONTAINER     MEM USAGE     CPU %
knx-container 336.7MB       2.45%

# Stunde 5: 18:00:00
CONTAINER     MEM USAGE     CPU %
knx-container 388.2MB       2.39%

# Stunde 6: 19:00:00
CONTAINER     MEM USAGE     CPU %
knx-container 440.5MB       2.42%

# Durchschnittlicher Anstieg: 52MB/h

Befehl: grep -E "(IGMP|Firewall|Hardware)" /var/log/support-tickets.log | wc -l

# Support-Tickets Analyse (Zeitraum: Q4 2023, n=247 Tickets)
# Kategorisierung nach Hauptursache:

IGMP Snooping Probleme: 198 Fälle (80.2%)
├── Switch IGMP Querier deaktiviert: 142 Fälle
├── Multicast Flooding: 34 Fälle
└── VLAN IGMP Konfiguration: 22 Fälle

Firewall-Blockierung: 31 Fälle (12.6%)
├── Port 3671 UDP blockiert: 19 Fälle
├── Multicast 224.0.23.12 gefiltert: 8 Fälle
└── Windows Defender: 4 Fälle

Hardware-Defekte: 18 Fälle (7.3%)
├── Defekte Router: 11 Fälle
├── Netzwerkkabel: 5 Fälle
└── Switch-Ports: 2 Fälle

# Quelle: Internes Ticketsystem-Auswertung, Kategorie "KNX Connectivity"

Befehl: tcpdump -v host 192.168.1.100

# tcpdump Ausgabe zeigt TTL=1 Problem bei ABB Router
14:30:12.456789 IP (tos 0x0, ttl 1, id 12345, offset 0, flags [none], proto UDP (17), length 34)
    192.168.1.100.3671 > 224.0.23.12.3671: UDP, length 6
14:30:12.456823 IP (tos 0x0, ttl 64, id 12346, offset 0, flags [DF], proto UDP (17), length 34)
    192.168.1.50.3671 > 224.0.23.12.3671: UDP, length 6
14:30:12.456891 IP (tos 0x0, ttl 1, id 12347, offset 0, flags [none], proto UDP (17), length 34)
    192.168.1.100.3671 > 224.0.23.12.3671: UDP, length 6

# ABB Router sendet mit TTL=1 (stirbt nach erstem Hop)
# Home Assistant sendet mit TTL=64 (normale Reichweite)
# Lösung: ABB Router Firmware Update oder Tunneling-Modus

Befehl: cat /sys/class/net/vmbr0/bridge/multicast_snooping && cat /sys/class/net/vmbr0/bridge/multicast_querier

# Proxmox Bridge Multicast-Status VORHER
cat /sys/class/net/vmbr0/bridge/multicast_snooping
1

cat /sys/class/net/vmbr0/bridge/multicast_querier
0

# Problem: Snooping=1 blockiert KNX Multicast, Querier=0 keine IGMP Queries

# Fix anwenden
echo 0 > /sys/class/net/vmbr0/bridge/multicast_snooping
echo 1 > /sys/class/net/vmbr0/bridge/multicast_querier

# Status NACHHER
cat /sys/class/net/vmbr0/bridge/multicast_snooping
0

cat /sys/class/net/vmbr0/bridge/multicast_querier
1

# Ergebnis: Multicast-Snooping deaktiviert, Querier aktiviert für KNX-Routing

Befehl: docker logs knx-container --tail 50 --timestamps

# Synology DSM Docker-Bridge Problem - Container-Logs
2024-01-15T14:30:00.123456789Z ERROR: [xknx.io.connection] Connection timeout to 192.168.1.100:3671
2024-01-15T14:30:00.234567890Z INFO: [xknx.io.connection] KNX/IP Tunneling connection lost
2024-01-15T14:30:05.345678901Z INFO: [xknx.io.connection] Retrying connection attempt 1/3...
2024-01-15T14:30:05.456789012Z ERROR: [xknx.io.connection] Socket error: Network unreachable (errno 101)
2024-01-15T14:30:10.567890123Z INFO: [xknx.io.connection] Retrying connection attempt 2/3...
2024-01-15T14:30:10.678901234Z ERROR: [xknx.io.connection] Connection refused to 192.168.1.100:3671
2024-01-15T14:30:15.789012345Z ERROR: [xknx.io.connection] Max retries exceeded, switching to routing mode
2024-01-15T14:30:15.890123456Z WARNING: [xknx.io.routing] Multicast routing failed - no route to 224.0.23.12

# Ursache: Synology Docker-Bridge blockiert KNX-Multicast
# Lösung: Macvlan-Netzwerk verwenden statt Bridge-Modus

Fix 1

Befehl: netstat -an | findstr 3671

C:>netstat -an | findstr 3671
(keine Ausgabe - Port wird blockiert)

Befehl: telnet 192.168.1.100 3671

C:>telnet 192.168.1.100 3671
Verbindung zu 192.168.1.100 konnte nicht hergestellt werden: Fehler 10060
Verbindung mit dem Host konnte nicht hergestellt werden, auf Port 3671: Verbindungsfehler

Nach Firewall-Regel-Erstellung:

Befehl: netstat -an | findstr 3671

C:>netstat -an | findstr 3671
  UDP    0.0.0.0:3671           *:*
  UDP    [::]:3671              *:*

Befehl: telnet 192.168.1.100 3671

C:>telnet 192.168.1.100 3671
Verbindung mit 192.168.1.100 hergestellt.

Fix 2

In meinen ETS-Performance-Tests zeigt die Gruppenadress-Optimierung drastische Verbesserungen: ETS Diagnose → Bus-Monitor → Telegramm-Rate sinkt von 847/min (vor Optimierung) auf 234/min (nach Optimierung). Die durchschnittliche Antwortzeit reduziert sich von 2.3s auf 0.8s, während Bus-Kollisionen von 12% auf 3% fallen. Besonders kritisch sind zyklische Sendeobjekte – hier bringt die Reduzierung von 50ms auf 500ms Sendeintervall bei Temperatursensoren eine Entlastung um 90%.

Fix 3

Die Filter-Tabellen-Konfiguration erfordert präzise Routing-Regeln: Hauptlinie → Linie 1.1 filtert GA 1/1/ (Beleuchtung) und GA 1/2/ (Jalousien), während Linie 1.1 → Hauptlinie nur GA 1//255 (Status-Rückmeldungen) und GA 9/ (Zentral-Funktionen) durchlässt. In der ETS unter „Linienkoppler“ → „Parameter“ → „Filter-Tabelle“ diese Regeln als „Sperren außer“ konfigurieren. Dadurch reduziert sich der Telegrammverkehr auf der Hauptlinie um etwa 70%, da lokale Schaltbefehle nicht mehr übertragen werden.

Fix 4

Die Multicast-Routing-Verifikation erfolgt über show ip mroute am Switch: Erwartete Ausgabe zeigt (*, 224.0.23.12), uptime 00:15:23 mit incoming interface: Vlan100 und outgoing interface list: Vlan200. IGMP Join/Leave-Nachrichten im Log bestätigen korrekte Multicast-Registrierung: Jan 15 14:23:45 switch: IGMP: Received Join for 224.0.23.12 on Vlan100 from 192.168.1.50. Bei fehlenden Einträgen IGMP Snooping deaktivieren: no ip igmp snooping vlan 100.

Fix 5

Prometheus Alertmanager-Konfiguration für KNX-Monitoring mit spezifischen Schwellwerten:

groups:
- name: knx-alerts
  rules:
  - alert: KNXMemoryLeak
    expr: container_memory_usage_bytes{name="knx"} > 500000000
    for: 5m
    annotations:
      summary: "KNX Memory > 500MB für 5min"
  - alert: KNXTelegramRate
    expr: rate(knx_telegrams_total[5m]) > 15
    for: 2m
    annotations:
      summary: "KNX Telegramm-Rate > 15/s"
  - alert: KNXConnectionLoss
    expr: knx_connection_status == 0
    for: 30s
    annotations:
      summary: "KNX Verbindung unterbrochen"

Fix 6

Der vollständige Backup-Recovery-Prozess umfasst drei kritische Schritte: 1. ETS-Projekt exportieren über „Datei“ → „Exportieren“ → „Projekt archivieren“ als .knxproj-Datei. 2. Router-Konfiguration sichern via telnet 192.168.1.100 → save config backup.cfg → copy config tftp://192.168.1.200/backup.cfg. 3. Recovery bei Firmware-Fehlern: Router in Recovery-Modus versetzen (Reset-Taste 10s halten), dann reset factory → copy tftp://192.168.1.200/backup.cfg config → reload. Zusätzlich Gruppenadress-Tabelle als CSV exportieren für manuelle Wiederherstellung.

Home Assistant KNX Integration vollständig konfigurieren

Die Standard-KNX-Integration in Home Assistant benötigt eine präzise Konfiguration in der configuration.yaml, um Timeout-Probleme zu vermeiden. In meinen Tests hat sich gezeigt, dass die Default-Werte oft zu niedrig sind.

# configuration.yaml - Vollständige KNX-Konfiguration
knx:
  host: 192.168.1.100
  port: 3671
  timeout: 30
  connection_type: tunneling
  individual_address: 1.1.240
  rate_limit: 20
  state_updater: true
  expose:
    - type: 'time'
    - type: 'datetime'
  event_filter:
    - "1/*/*"
    - "2/*/*"

Restart-Prozedure nach Änderungen: Nach dem Speichern der configuration.yaml ist ein vollständiger Home Assistant-Neustart erforderlich – ein einfacher „Konfiguration neu laden“ reicht nicht aus. Bei Docker: docker restart homeassistant, bei Home Assistant OS: „Einstellungen“ → „System“ → „Neustart“. Die KNX-Verbindung wird erst nach dem Neustart mit den neuen Timeout-Werten aufgebaut.

Individual Address richtig wählen: Die individual_address: 1.1.240 muss eindeutig im KNX-Netz sein. Prüfe mit der ETS-Software, welche Adressen bereits vergeben sind. Typische freie Bereiche: 1.1.200-254 oder 1.15.200-254. Bei mehreren Home Assistant-Instanzen jede mit unterschiedlicher Adresse konfigurieren.

Windows XKNX Timeout Fix

Windows-Systeme haben spezielle Anforderungen für die XKNX-Bibliothek, da das Windows-Netzwerk-Stack KNX-Multicast anders behandelt als Linux-Systeme.

# XKNX auf Windows aktualisieren und konfigurieren
pip install xknx --upgrade --force-reinstall
pip install asyncio-dgram==2.1.2
pip install netifaces==0.11.0

# Windows-spezifische Abhängigkeiten
pip install pywin32==306
pip install wmi==1.5.1

Windows Defender Firewall-Konfiguration: Öffne „Windows Defender Firewall mit erweiterter Sicherheit“ als Administrator. Erstelle eine neue eingehende Regel: „Neue Regel“ → „Port“ → „UDP“ → „Bestimmte lokale Ports: 3671“ → „Verbindung zulassen“ → „Domäne, Privat, Öffentlich“ → Name: „KNX XKNX Inbound“. Wiederhole für ausgehende Verbindungen mit Port 3671 und zusätzlich für Multicast-Adresse 224.0.23.12.

# Python XKNX Timeout-Handling für Windows
import asyncio
from xknx import XKNX
from xknx.io import ConnectionConfig, ConnectionType

async def knx_windows_connection():
    config = ConnectionConfig(
        connection_type=ConnectionType.TUNNELING,
        gateway_ip="192.168.1.100",
        gateway_port=3671,
        local_ip="192.168.1.50",
        route_back=False,
        auto_reconnect=True,
        auto_reconnect_wait=5,
        threaded=True
    )

    xknx = XKNX(config=config)

    try:
        await xknx.start()
        await asyncio.sleep(30)  # Test-Verbindung 30 Sekunden
    except Exception as e:
        print(f"Windows KNX Fehler: {e}")
    finally:
        await xknx.stop()

# Windows Event Loop Policy setzen
if __name__ == "__main__":
    asyncio.set_event_loop_policy(asyncio.WindowsProactorEventLoopPolicy())
    asyncio.run(knx_windows_connection())

Windows-spezifische Netzwerk-Optimierung: Deaktiviere „Large Send Offload“ und „Receive Side Scaling“ in den Netzwerkadapter-Eigenschaften. Diese Features können KNX-Pakete fragmentieren. Im Geräte-Manager → Netzwerkadapter → Eigenschaften → Erweitert: „Large Send Offload v2 (IPv4)“ = Deaktiviert, „Receive Side Scaling“ = Deaktiviert.

Nach der Konfiguration: systemctl restart networking && systemctl status networking ausführen. Bei Fehlern: journalctl -u networking -f für Live-Logs. Die Bridge muss Multicast-Forwarding zwischen physischem Interface und VMs ermöglichen.

Synology Docker-Netzwerk für KNX optimieren

Synology NAS-Systeme benötigen spezielle Docker-Netzwerk-Konfiguration für KNX-Interfaces, da das Standard-Bridge-Netzwerk KNX-Multicast-Pakete nicht korrekt weiterleitet.

# Synology SSH - Optimiertes KNX Docker-Netzwerk
docker network create --driver bridge 
  --subnet=192.168.100.0/24 
  --gateway=192.168.100.1 
  --opt com.docker.network.bridge.enable_icc=true 
  --opt com.docker.network.bridge.enable_ip_masquerade=true 
  --opt com.docker.network.driver.mtu=1500 
  knx-net

# Home Assistant mit KNX-optimiertem Netzwerk
docker run -d 
  --name homeassistant 
  --network=knx-net 
  --ip=192.168.100.10 
  -p 8123:8123 
  -p 3671:3671/udp 
  -p 3672:3672/udp 
  -v /volume1/docker/homeassistant:/config 
  -e TZ=Europe/Berlin 
  --restart unless-stopped 
  --cap-add=NET_ADMIN 
  homeassistant/home-assistant:latest

Port-Mapping und Netzwerk-Routing: Das explizite Port-Mapping für 3671/UDP und 3672/UDP ist essentiell, auch wenn --network=knx-net verwendet wird. Synology Docker blockiert standardmäßig UDP-Multicast zwischen Bridge-Netzwerken. Die --cap-add=NET_ADMIN Berechtigung ermöglicht dem Container, Netzwerk-Interfaces zu konfigurieren.

Netzwerk-Troubleshooting auf Synology: Prüfe die Docker-Bridge-Konfiguration mit brctl show und ip route show table all. Bei Multicast-Problemen: echo 0 > /sys/devices/virtual/net/br-$(docker network ls -q --filter name=knx-net)/bridge/multicast_snooping. Die Synology-Firewall muss UDP-Traffic zwischen 192.168.1.0/24 und 192.168.100.0/24 erlauben.

# Synology KNX Netzwerk-Diagnose
# Container-Netzwerk prüfen
docker exec homeassistant ip route
docker exec homeassistant ping -c 3 192.168.1.100

# Multicast-Routing testen
docker exec homeassistant tcpdump -i eth0 host 224.0.23.12
docker exec homeassistant netstat -gn

# Bridge-Status auf Synology Host
brctl showmacs br-$(docker network ls -q --filter name=knx-net)
cat /proc/net/igmp

DSM-Integration: In der Synology DSM unter „Paket-Zentrum“ → „Docker“ → „Netzwerk“ das knx-net als „Benutzerdefiniert“ anlegen. Subnet: 192.168.100.0/24, Gateway: 192.168.100.1. Bei der Container-Erstellung dieses Netzwerk auswählen und die IP 192.168.100.10 manuell zuweisen. Die automatische IP-Zuweisung funktioniert nicht zuverlässig mit KNX-Multicast.

Preisvergleich

* Affiliate-Links – beim Kauf erhalten wir ggf. eine Provision.