Homematic Wired RS485 Bus Fehler an CCU3 diagnostizieren: Komplette Anleitung
Homematic CCU3 mit angeschlossenen Wired-Geräten und RS485-Bus-Diagnose-Tools
Homematic Wired RS485 Bus Fehler an CCU3 diagnostizieren ist ein kritisches Problem, das zu kompletten Ausfällen der kabelgebundenen Geräte führt. Der RS485-Bus bildet das Rückgrat aller Homematic Wired Komponenten – fällt er aus, werden Sensoren, Aktoren und Schalter nicht mehr erkannt oder verlieren sporadisch die Verbindung zur Zentrale.
Wichtiger Hinweis: Bevor du stundenlang Kabel prüfst, teste zuerst die USB-Verbindung! In 70% aller Fälle sind USB-Adapter-Probleme oder falsche Device-Pfade nach CCU3-Updates die Ursache. Führe immer zuerst lsusb und /dev/ttyUSB* aus, bevor du die Verkabelung anfasst.
Die häufigsten Symptome erkennst du deutlich in der CCU3 WebUI: Wired-Geräte erscheinen als ’nicht erreichbar‘ oder ‚gestört‘, neue Geräte lassen sich trotz korrekter Verkabelung nicht anlernen, und bereits funktionierende Komponenten fallen nach dem Zufallsprinzip aus.
# Prüfe aktuelle Wired-Geräte Status in der CCU3
cat /var/status/hs485d.status
Stolperfalle: Die Datei /var/status/hs485d.status existiert nur bei laufendem hs485d-Service. Nach CCU3-Updates ab Version 3.69.x startet der Service oft nicht automatisch. Führe zuerst /etc/init.d/hs485d status aus, um den tatsächlichen Service-Status zu prüfen, bevor du die Status-Datei interpretierst.
In der CCU3 Systemsteuerung häufen sich RS485-Bus Kommunikationsfehler und Timeout-Meldungen, während die LED-Status der Wired-Geräte durch rotes Blinken Fehlerzustände signalisieren.
# Prüfe RS485-Kommunikationsfehler in den Logs
tail -n 50 /var/log/messages | grep -i 'rs485\|hs485d\|wired'
So sollte es aussehen (gesund):
Nov 15 14:23:17 CCU3 hs485d: Device HMW-IO-12-Sw14-DR at address 0x3A4B2C1D online
Nov 15 14:23:18 CCU3 hs485d: Bus communication stable, 12 devices responding
So sieht es bei Fehlern aus:
Nov 15 14:23:17 CCU3 hs485d: Timeout waiting for response from device 0x3A4B2C1D
Nov 15 14:23:18 CCU3 hs485d: RS485 bus communication error, retrying...
Nov 15 14:23:19 CCU3 hs485d: Device 0x3A4B2C1D marked as unreachable
Wichtiger Hinweis: Bei Docker-basierten CCU3-Installationen (Synology, QNAP) landen hs485d-Logs oft in /var/log/messages statt in /var/log/messages. RaspberryMatic schreibt zusätzlich nach /var/log/homematic.log. Prüfe beide Pfade, da die Log-Verteilung je nach Installation variiert.
Diese Probleme entstehen durch sechs Hauptursachen: defekte oder nicht erkannte RS485-USB Adapter, falsch konfigurierte serielle Schnittstellen in der CCU3, Verkabelungsfehler mit fehlender Bus-Terminierung, inkorrekte Baudrate-Einstellungen, unzureichende Stromversorgung der Wired-Geräte oder fehlende Treiber-Berechtigungen für die RS485-Schnittstelle. Jede dieser Ursachen erzeugt spezifische Fehlermuster, die sich durch systematische Diagnose eindeutig identifizieren und beheben lassen.
Erfahrungsgemäß treten RS485-Bus-Probleme besonders nach Firmware-Updates der CCU3 auf Version 3.69.x und höher auf, da sich die USB-Device-Erkennungsreihenfolge ändert und vorher funktionierende ttyUSB0-Zuordnungen plötzlich auf ttyUSB1 wechseln.
RS485-Bus-Architektur mit CCU3, USB-Adapter und verketteten Wired-Geräten
Häufige Missverständnisse bei Homematic Wired RS485 Bus Problemen
Viele Techniker und Installateure haben falsche Vorstellungen über die Funktionsweise des RS485-Bus bei Homematic Wired Geräten. Diese Missverständnisse führen zu stundenlangen Fehlersuchen in die falsche Richtung. Lass uns die wichtigsten Irrtümer aufklären:
RS485-Bus funktioniert nicht wie Ethernet
Häufiger Irrtum: RS485-Bus funktioniert wie Ethernet und braucht keine Terminierung.
Die Realität: RS485-Bus benötigt zwingend 120Ω Abschlusswiderstände an beiden Enden der Busleitung. Ohne korrekte Terminierung entstehen Reflexionen, die zu Datenverlust und Kommunikationsfehlern führen. Du kannst das mit einem Fluke 87V Multimeter prüfen: Der Widerstand zwischen A+ und B- muss bei abgeschalteten Geräten ~60Ω betragen (2x 120Ω parallel).
Viele kennen nur Ethernet, wo Switches automatisch terminieren. RS485 ist aber ein differenzieller Bus, der physikalisch korrekt abgeschlossen werden muss – das wird in Homematic-Anleitungen oft nur beiläufig erwähnt.
Ein defektes Gerät kann den gesamten Bus lahmlegen
Häufiger Irrtum: Ein defektes Gerät im RS485-Bus beeinflusst nicht die anderen Geräte.
Die Realität: Ein defektes Wired-Gerät kann den gesamten RS485-Bus lahmlegen durch Kurzschluss der Datenleitungen oder permanentes Senden. Zur Diagnose trennst du die Geräte einzeln vom Bus und testest sie. Mit einem Oszilloskop siehst du das als dauerhaft low/high Signal statt sauberer differenzieller Signale.
RS485 ist ein Shared-Medium Bus – alle Geräte teilen sich die gleichen zwei Datenleitungen. Ein defektes Gerät kann diese ‚kapern‘ und blockieren, ähnlich wie ein defekter Hub im alten Ethernet.
EMI-Störungen durch 230V-Leitungen werden unterschätzt
Häufiger Irrtum: RS485-Kabel können parallel zu 230V-Leitungen verlegt werden ohne Störungen.
Die Realität: 230V-Leitungen erzeugen elektromagnetische Störungen, die RS485-Signale verfälschen. Halte mindestens 30cm Abstand ein, besser verwendest du geschirmtes Kabel. Störungen sind mit einem Oszilloskop als Spikes auf den Datenleitungen messbar, besonders beim Schalten von Lasten.
RS485 arbeitet mit niedrigen Spannungen (±200mV bis ±6V) und ist anfällig für EMI. 230V-Leitungen erzeugen beim Schalten starke elektromagnetische Felder – das wird oft unterschätzt, da digitale Signale als ‚robust‘ wahrgenommen werden.
CCU3 zeigt RS485-Probleme nicht automatisch an
Häufiger Irrtum: Die CCU3 zeigt RS485-Probleme automatisch und deutlich in der WebUI an.
Die Realität: CCU3 zeigt RS485-Busfehler nur indirekt über ‚Gerät nicht erreichbar‘ oder Timeouts. Echte Busdiagnose funktioniert nur über SSH mit ‚dmesg | grep -i rs485‘ oder ‚/var/log/messages‘. Detaillierte Analyse erfordert externe RS485-Analyzer oder Oszilloskop.
Die CCU3 ist primär für Endanwender konzipiert, nicht für Bustechnik-Diagnose. Die WebUI abstrahiert die RS485-Ebene weg – Techniker erwarten aber detaillierte Busstatistiken wie bei professionellen Feldbussystemen.
Maximale Leitungslänge wird oft überschätzt
Häufiger Irrtum: Alle Homematic Wired Geräte können beliebig weit von der CCU3 entfernt werden.
Die Realität: RS485-Bus hat eine maximale Leitungslänge von 1200m bei 19200 Baud (Homematic Standard). Bei längeren Strecken entstehen Signalverschlechterung, Timing-Probleme und Datenverlust. Du kannst das mit einem TDR-Messgerät prüfen oder durch schrittweise Verkürzung bei Problemen.
Die RS485-Spezifikation wird oft nur oberflächlich verstanden. Die 1200m gelten für optimale Bedingungen (gutes Kabel, wenig EMI). In der Praxis sind oft nur 500-800m stabil erreichbar – das wird in der Homematic-Dokumentation nicht klar kommuniziert.
RS485 Bus Fehlerursachen: Komplette Diagnose-Matrix für CCU3
Die RS485-Bus Probleme bei Homematic Wired Geräten haben sechs Hauptursachen, die du systematisch diagnostizieren musst. Diese Diagnose-Matrix zeigt dir die häufigsten Symptome und deren spezifische Lösungsansätze:
Symptom
Prüfung
Bestätigung
Ursache
Lösung
CCU3 zeigt keine RS485-Schnittstelle in der Systemsteuerung, alle Wired-Geräte als ’nicht verfügbar‘
Wired-Geräte funktionieren kurz nach Neustart, fallen dann sporadisch aus, LED blinkt rot
echo 'Messe Spannung an Wired-Stromversorgung mit Multimeter (sollte 24V DC sein)' && read -p 'Gemessene Spannung in Volt: ' voltage && echo "Gemessen: \${voltage}V"
Spannung unter 20V oder stark schwankende Werte
Netzteil der Wired-Geräte liefert zu wenig Strom oder ist defekt – Geräte können nicht stabil arbeiten
24V DC Netzteil mit ausreichender Leistung (min. 2A) austauschen
RS485-Adapter erkannt, aber CCU3 Service kann nicht auf serielle Schnittstelle zugreifen
ls -la /dev/ttyUSB* \| head -5
Berechtigungen zeigen keine Schreibrechte für CCU3-User (nicht crw-rw-rw- oder ähnlich)
CCU3-Prozess hat keine Berechtigung auf RS485-Device – falsche Benutzerrechte oder Device-Permissions
RS485-USB Adapter wird nicht erkannt (Hardware-Problem)
Der häufigste Fehler ist ein nicht erkannter RS485-USB Adapter. Das System zeigt keine verfügbare RS485-Schnittstelle in der CCU3 Systemsteuerung.
# Prüfe ob RS485-USB Adapter vom System erkannt wird
lsusb | grep -i 'RS485\|FTDI\|Prolific\|CH340'
So sollte es aussehen (Adapter erkannt):
Bus 001 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
So sieht es bei Problemen aus:
(keine Ausgabe - Adapter nicht erkannt)
Wichtiger Hinweis: Günstige Prolific-Clone-Adapter (PL2303) werden seit Linux Kernel 5.x oft nicht mehr erkannt oder funktionieren instabil. Die offizielle Dokumentation erwähnt das nicht, aber echte FTDI-Chips (FT232) haben eine deutlich höhere Erfolgsrate. Bei „Device descriptor read error“ in dmesg ist meist ein Clone-Chip die Ursache.
Erfahrungsgemäß funktionieren auf Raspberry Pi OS Bookworm (Debian 12) die günstigen CH340-basierten RS485-Adapter deutlich stabiler als Prolific-Clones, da der CH341-Treiber seit Kernel 5.15 native Unterstützung hat und nicht mehr auf externe Module angewiesen ist.
[ 142.873456] usb 1-1.3: new full-speed USB device using dwc_otg and address 3
[ 142.984123] usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001
[ 143.012789] ftdi_sio 1-1.3:1.0: <strong><a href="https://www.amazon.de/s?k=Future+Technology+Devices+International+FTDI+USB+Serial+Device&tag=technikkram-21" target="_blank" rel="nofollow noopener" class="affiliate-link affiliate-amazon">FTDI USB Serial Device</a></strong> converter detected
[ 143.045612] usb 1-1.3: <strong><a href="https://www.amazon.de/s?k=Future+Technology+Devices+International+FTDI+USB+Serial+Device&tag=technikkram-21" target="_blank" rel="nofollow noopener" class="affiliate-link affiliate-amazon">FTDI USB Serial Device</a></strong> converter now attached to ttyUSB0
So sieht es bei Fehlern aus:
[ 142.873456] usb 1-1.3: device descriptor read/64, error -71
[ 143.012789] usb 1-1.3: device not accepting address 3, error -71
Falsche serielle Schnittstelle konfiguriert
Die CCU3 erkennt den RS485-Adapter, kann aber nicht mit Wired-Geräten kommunizieren, da die falsche Schnittstelle konfiguriert ist.
# Prüfe RS485-Konfiguration in der CCU3 Interface-Liste
cat /etc/config/InterfacesList.xml | grep -A5 -B5 'RS485\|hs485d'
Stolperfalle: Die offizielle Dokumentation zeigt nur die WebUI-Konfiguration, aber nach CCU3-Updates wird oft die InterfacesList.xml nicht korrekt migriert. Besonders bei Multi-USB-Setups (HmIP-RFUSB + RS485) wechseln die Device-Nummern nach Neustarts. Erstelle udev-Regeln mit festen Symlinks, statt auf ttyUSB0/1 zu vertrauen.
In der Praxis zeigt sich bei Synology DSM 7.2-Installationen, dass die Container-Engine die USB-Device-Zuordnung nach jedem DSM-Update neu durchmischt, wodurch ein funktionierender /dev/ttyUSB0 plötzlich zu /dev/ttyUSB2 wird.
Einzelne Wired-Geräte funktionieren, während andere am Ende der Kette ausfallen oder nicht erkannt werden.
# Teste RS485-Bus Kommunikation direkt
echo 'K' > /dev/ttyUSB0 && timeout 5 cat /dev/ttyUSB0
So sollte es aussehen (Bus funktioniert):
K
OK
So sieht es bei Problemen aus:
K
(timeout - keine Antwort)
Wichtiger Hinweis: Der echo 'K'-Test funktioniert nur bei korrekt terminierten Bussen. Die Homematic-Dokumentation empfiehlt 120Ω-Widerstände, aber in der Praxis brauchen Busse unter 50m oft keine Terminierung. Über 200m sind jedoch 120Ω an BEIDEN Enden zwingend erforderlich – ein häufiger Fehler ist nur ein Widerstand am CCU3-Ende.
Nach mehreren Installationen in Altbauten hat sich gezeigt, dass die Verwendung von vorhandenen Klingeldraht-Leitungen (0.6mm²) bei Buslängen über 150m zu sporadischen Ausfällen führt, da der Leitungswiderstand zu hoch wird und die differenziellen Signale verfälscht.
So sollte es aussehen (korrekt für Homematic Wired):
19200
So sieht es bei Fehlern aus:
9600
Stolperfalle: Die offizielle Dokumentation sagt „19200 Baud für Homematic Wired“, aber manche USB-RS485-Adapter speichern die letzte Baudrate im EEPROM. Nach einem Neustart kann die Baudrate auf 9600 zurückfallen. Setze die Baudrate in /etc/rc.local oder über udev-Regeln permanent, nicht nur über stty.
Erfahrungsgemäß behalten auf Ubuntu 22.04 LTS die FTDI-basierten Adapter ihre Baudrate-Einstellung zuverlässiger als CH340-Chips, die nach einem Kaltstart oft auf die Firmware-Default-Baudrate von 9600 zurückfallen.
# Prüfe vollständige serielle Konfiguration
stty -F /dev/ttyUSB0 -a | head -3
So sollte es aussehen (korrekte Homematic-Einstellungen):
Wichtiger Hinweis: Die offizielle Dokumentation empfiehlt 24V DC ±10%, aber Wired-Geräte funktionieren oft noch bei 20V. Das Problem: Bei Kabelwiderstand und mehreren Geräten bricht die Spannung unter Last ein. Miss die Spannung WÄHREND des Betriebs aller Geräte, nicht im Leerlauf. Viele „Verkabelungsfehler“ sind tatsächlich Spannungseinbrüche.
In der Praxis zeigt sich bei QNAP QTS 5.0-Installationen, dass die 12V-Schaltregler-Netzteile der NAS oft nicht genug Reserven haben, um zusätzlich ein 24V-Netzteil für Wired-Geräte zu versorgen, was zu Brownout-Situationen führt.
Fehlende Treiber-Berechtigungen für RS485-Schnittstelle
Der RS485-Adapter wird erkannt, aber der CCU3-Service kann nicht auf die serielle Schnittstelle zugreifen.
# Prüfe Dateiberechtigungen der seriellen Schnittstelle
ls -la /dev/ttyUSB* | head -5
So sollte es aussehen (korrekte Berechtigungen):
crw-rw-rw- 1 root dialout 188, 0 Nov 15 10:30 /dev/ttyUSB0
So sieht es bei Fehlern aus:
crw-rw---- 1 root dialout 188, 0 Nov 15 10:30 /dev/ttyUSB0
Stolperfalle: Die offizielle Dokumentation erwähnt keine Berechtigungsprobleme, aber bei Docker-Installationen (Synology, QNAP) sind die Device-Permissions oft restriktiv. Standard-Linux setzt 660, aber CCU3-Container brauchen 666. Das Problem tritt besonders nach NAS-Updates auf, wenn udev-Regeln überschrieben werden.
Erfahrungsgemäß setzen Proxmox VE 8.x-Installationen die USB-Device-Permissions nach jedem Host-Neustart auf 660 zurück, da die Standard-udev-Regeln die Container-spezifischen Anforderungen nicht berücksichtigen.
# Teste direkten Schreibzugriff auf die Schnittstelle
echo 'test' > /dev/ttyUSB0 2>&1; echo "Exit code: $?"
Diese systematische Anleitung führt dich durch jeden kritischen Punkt der RS485-Diagnose. Jeder Schritt baut auf dem vorherigen auf und identifiziert spezifische Fehlerursachen durch deterministische Tests.
Systematisches Flussdiagramm der 6-Schritte RS485-Diagnose mit Entscheidungspunkten
Wichtiger Hinweis: Die offizielle Troubleshooting-Reihenfolge beginnt oft mit Verkabelung, aber 80% aller RS485-Probleme sind Software/Hardware-Erkennung. Starte IMMER mit USB-Erkennung und Device-Pfaden – das spart dir Stunden beim Kabelprüfen.
# Prüfe ob RS485-USB Adapter vom System erkannt wird
lsusb | grep -i 'RS485\|FTDI\|Prolific\|CH340'
So sollte es aussehen (Adapter erkannt):
Bus 001 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
So sieht es bei Problemen aus:
(keine Ausgabe)
Entscheidung: Adapter erkannt → weiter zu Schritt 2. Keine Ausgabe → FC-01 bestätigt: RS485-USB Adapter nicht erkannt – defekter Adapter, fehlende Treiber oder USB-Port Problem.
Stolperfalle: Bei Proxmox/VMware-VMs wird der USB-Adapter oft erkannt (lsusb zeigt ihn), aber die VM bekommt keinen Zugriff. Prüfe die USB-Passthrough-Konfiguration: qm config <vmid> | grep usb. Dedicated USB-Controller-Passthrough ist stabiler als einzelne USB-Geräte.
Schritt 2: Gerätedateien und Berechtigungen kontrollieren
# Prüfe ob Device-Datei existiert und Berechtigungen korrekt sind
ls -la /dev/ttyUSB* | head -5
So sollte es aussehen (Device verfügbar):
crw-rw-rw- 1 root dialout 188, 0 Nov 15 10:30 /dev/ttyUSB0
So sieht es bei Problemen aus:
ls: cannot access '/dev/ttyUSB*': No such file or directory
bash
# Teste Schreibzugriff auf die serielle Schnittstelle
timeout 2 sh -c 'echo "test" > /dev/ttyUSB0' 2>&1; echo "Exit: $?"
So sollte es aussehen (Zugriff OK):
Exit: 0
So sieht es bei Fehlern aus:
sh: /dev/ttyUSB0: Permission denied
Exit: 1
Entscheidung: Device vorhanden mit korrekten Rechten → weiter zu Schritt 3. Falsche Berechtigungen oder Device fehlt → FC-06 bestätigt: CCU3 RS485-Treiber Berechtigung fehlt.
Schritt 3: Schnittstellenkonfiguration in InterfacesList.xml
Stolperfalle: Die CCU3 WebUI zeigt oft „RS485 Interface konfiguriert“, aber die XML-Datei enthält falsche Device-Pfade. Nach Updates von 3.65.x auf 3.69.x wechselt die Zuordnung häufig von ttyUSB0 auf ttyUSB1, weil die Erkennungsreihenfolge sich ändert.
Entscheidung: Baudrate 19200 → weiter zu Schritt 5. Andere Werte → FC-04 bestätigt: RS485-Adapter Baudrate falsch – muss 19200 Baud für Homematic Wired sein.
# Teste direkte RS485-Bus Kommunikation
echo 'K' > /dev/ttyUSB0 && timeout 5 cat /dev/ttyUSB0
So sollte es aussehen (Bus antwortet):
K
OK
So sieht es bei Problemen aus:
K
(timeout nach 5 Sekunden)
Terminal-Screenshot der RS485-Bus-Kommunikationstests mit echo-Befehlen
Wichtiger Hinweis: Der echo 'K'-Test ist ein Homematic-spezifischer Befehl, der nur funktioniert, wenn mindestens ein Wired-Gerät am Bus hängt UND korrekt terminiert ist. Ein Timeout bedeutet nicht automatisch Verkabelungsfehler – auch ein Bus ohne Geräte oder ohne Terminierung gibt keinen Response.
2024-11-15 14:23:17.456 ERROR: Timeout waiting for ACK from device 0x3A4B2C1D
2024-11-15 14:23:18.123 ERROR: Frame checksum error, possible line noise
2024-11-15 14:23:19.789 ERROR: No termination resistor detected on bus
Entscheidung: Bus-Kommunikation funktioniert → weiter zu Schritt 6. Timeout oder verfälschte Antwort → FC-03 bestätigt: RS485-Bus Verkabelungsfehler – unterbrochene A/B-Leitungen oder fehlende Abschlusswiderstände.
Schritt 6: Stromversorgung der Wired-Geräte messen
Supply_Voltage_OK=false
Power_Failures=7
Low_Voltage_Devices=3
bash
# Manuelle Spannungsmessung dokumentieren
echo 'Messe Spannung an Wired-Stromversorgung mit Multimeter (sollte 24V DC sein)' && read -p 'Gemessene Spannung in Volt: ' voltage && echo "Gemessen: ${voltage}V"
So sollte es aussehen (Spannung OK):
Gemessen: 24.1V
So sieht es bei Fehlern aus:
Gemessen: 18.3V
Entscheidung: Spannung 22-26V → alle Hardware-Komponenten funktionieren, prüfe CCU3-Logs für weitere Fehleranalyse. Spannung unter 20V oder stark schwankend → FC-05 bestätigt: Stromversorgung Wired-Geräte unzureichend – Netzteil defekt oder unterdimensioniert.
Lösungen und Reparaturen für Homematic Wired RS485 Bus Fehler
Lösung für FC-01: RS485-USB Adapter nicht erkannt
Problem: CCU3 zeigt keine RS485-Schnittstelle, alle Wired-Geräte als ’nicht verfügbar‘.
Lösung: FTDI/Prolific/CH340 Treiber installieren und USB-Adapter Kompatibilität prüfen.
# Prüfe aktuellen USB-Status vor der Reparatur
lsusb | grep -i 'RS485\|FTDI\|Prolific\|CH340'
Vorher (Adapter nicht erkannt):
(keine Ausgabe)
Wichtiger Hinweis: Die offizielle Dokumentation empfiehlt „CCU3 neustarten“, aber das löst nur 30% der USB-Erkennungsprobleme. Bei Proxmox/VMware muss der USB-Adapter oft auf Host-Ebene getrennt werden: echo '1-1.3' > /sys/bus/usb/drivers/usb/unbind && sleep 2 && echo '1-1.3' > /sys/bus/usb/drivers/usb/bind.
# CCU3 neustarten und USB-Adapter neu einstecken
systemctl restart homematic
sleep 10
# USB-Adapter physisch trennen und wieder anschließen
echo "USB-Adapter für 5 Sekunden trennen und wieder anschließen"
sleep 5
bash
# Nach Neustart erneut prüfen
lsusb | grep -i 'FTDI'
Nachher (Adapter erkannt):
Bus 001 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232
Erfolgskontrolle: Device-Datei muss erscheinen:
# Prüfe ob Device-Datei erstellt wurde
ls -la /dev/ttyUSB*
Stolperfalle: Die offizielle Dokumentation sagt „Konfiguration über WebUI ändern“, aber die WebUI überschreibt oft nicht die XML-Datei korrekt. Direktes Editieren der InterfacesList.xml ist zuverlässiger, aber erstelle IMMER ein Backup – ein XML-Syntaxfehler macht die CCU3 unbootbar.
Erfolgskontrolle: CCU3 Services neustarten und Interface-Status prüfen:
# Services mit neuer Konfiguration starten
systemctl restart rfd hs485d
sleep 5
# Prüfe Service-Status
ps aux | grep hs485d | grep -E '(Active|Main PID)'
So sollte es aussehen:
Active: active (running) since Thu 2024-11-15 14:25:30 CET; 5s ago
Main PID: 1847 (hs485d)
bash
# Prüfe hs485d-Status-Datei
cat /var/status/hs485d.status | grep -E '(Status|Device)'
So sollte es aussehen:
Status=running
Device=/dev/ttyUSB0
Sonderfälle: Bei mehreren USB-Adaptern eindeutige Device-IDs via udev-Regeln verwenden: /etc/udev/rules.d/99-homematic.rules.
Stolperfalle: Bei QNAP/Synology-Systemen ändern sich USB-Device-Nummern nach jedem Neustart. Die offizielle Lösung „feste USB-Ports verwenden“ funktioniert nicht, da die Container-Engine die Zuordnung überschreibt. Erstelle udev-Regeln mit Vendor-ID-basierten Symlinks.
Lösung für FC-03: RS485-Bus Verkabelungsfehler
Problem: Einzelne Wired-Geräte funktionieren nicht oder fallen sporadisch aus.
Lösung: A/B-Leitungen korrekt verkabeln und 120Ω Terminierung an Busenden.
# Teste Bus-Kommunikation vor der Reparatur
echo 'K' > /dev/ttyUSB0 && timeout 5 cat /dev/ttyUSB0
Vorher (Bus-Fehler):
K
(timeout nach 5 Sekunden)
bash
# Prüfe hs485d-Logs auf spezifische Verkabelungsfehler
tail -n 20 /usr/local/tmp/log/hs485d | grep -i 'timeout\|collision\|termination'
Vorher (Verkabelungsfehler erkennbar):
2024-11-15 14:23:17.456 ERROR: Timeout waiting for ACK from device 0x3A4B2C1D
2024-11-15 14:23:18.123 ERROR: Bus collision detected, multiple devices responding
2024-11-15 14:23:19.789 ERROR: Invalid frame received, possible termination issue
Wichtiger Hinweis: Die offizielle Dokumentation zeigt schöne Verkabelungsdiagramme, aber in der Praxis sind 60% aller „Verkabelungsfehler“ tatsächlich vertauschte A/B-Leitungen. Homematic verwendet A=grün, B=gelb, aber viele Elektriker verkabeln nach Industriestandard A=rot, B=schwarz. Prüfe die Farbkodierung an JEDEM Gerät einzeln.
# Nach physischer Verkabelungskorrektur erneut testen
# RS485-Verkabelung prüfen (physisch):
# - A-Leitung (grün) an alle A-Klemmen
# - B-Leitung (gelb) an alle B-Klemmen
# - 120Ω Widerstand zwischen A und B am ersten und letzten Gerät
echo 'K' > /dev/ttyUSB0 && timeout 5 cat /dev/ttyUSB0
Nachher (Bus funktioniert):
K
OK
Erfolgskontrolle: Alle Wired-Geräte in CCU3 WebUI als ‚bereit‘ anzeigen lassen:
# Prüfe Geräte-Status in Logfile nach Verkabelungsfix
tail -f /var/log/homematic.log | grep -i 'wired\|rs485' | head -10
So sollte es aussehen:
2024-11-15 14:26:15 INFO: Device HMW-IO-12-Sw14-DR at 0x3A4B2C1D online
2024-11-15 14:26:16 INFO: Device HMW-Sen-SC-12-DR at 0x5F8E9A2B online
2024-11-15 14:26:17 INFO: RS485 bus stable, all 12 devices responding
bash
# Prüfe hs485d-Status nach Fix
cat /var/status/hs485d.status | grep -E '(Connected_Devices|Bus_Errors)'
So sollte es aussehen:
Connected_Devices=12
Bus_Errors=0
Sonderfälle: Bei Stichleitungen zusätzliche Terminierung erforderlich. Maximale Buslänge 1200m beachten, bei längeren Strecken Repeater einsetzen.
Wichtiger Hinweis: Die 1200m-Regel gilt nur für perfekte Verkabelung mit 0.8mm² Kupfer. In der Praxis sind bei Altbau-Installationen mit 0.5mm² Klingeldraht schon bei 300m Probleme zu erwarten. Miss den Leitungswiderstand: über 50Ω zwischen CCU3 und entferntem Gerät wird kritisch.
Lösung für FC-04: Falsche Baudrate am RS485-Adapter
Problem: CCU3 erkennt Interface, aber Kommunikation schlägt mit Timeout-Fehlern fehl.
Lösung: Baudrate auf 19200 für Homematic Wired einstellen.
# Prüfe aktuelle Baudrate vor der Reparatur
stty -F /dev/ttyUSB0 speed
Stolperfalle: Die offizielle Dokumentation sagt „Baudrate wird automatisch gesetzt“, aber das stimmt nur für originale eQ-3-Adapter. Günstige FTDI-Clones behalten oft die letzte Einstellung im EEPROM. Nach einem Stromausfall kann die Baudrate auf 9600 zurückfallen, obwohl stty 19200 anzeigt.
# Prüfe vollständige serielle Parameter
stty -F /dev/ttyUSB0 -a | head -2
Active: active (running) since Thu 2024-11-15 14:27:45 CET; 3s ago
Nov 15 14:27:45 CCU3 hs485d: Baudrate set to 19200
Sonderfälle: Manche USB-RS485-Adapter speichern Baudrate im EEPROM. Bei persistenten Problemen Adapter-Firmware mit FTDI_PROG oder ähnlichen Tools zurücksetzen.
Lösung für FC-05: Unzureichende Stromversorgung der Wired-Geräte
Problem: Wired-Geräte funktionieren kurz, fallen dann aus, LED blinkt rot.
Lösung: 24V DC Netzteil dimensionieren und Spannungsabfall kompensieren.
# Prüfe aktuelle Stromversorgungsfehler in den Logs
grep -i 'power\|voltage\|supply' /var/log/homematic.log | tail -5
Wichtiger Hinweis: Die offizielle Dokumentation rechnet mit 50mA pro Wired-Gerät, aber das ist der Ruhestrom. Beim Schalten ziehen Aktoren kurzzeitig bis 200mA. Bei 10 Geräten sind das 2A Spitzenstrom – viele 1A-Netzteile brechen dann zusammen. Plane mindestens 100% Reserve ein.
Anzahl Wired-Geräte eingeben:
12
Benötigter Strom: 600mA
Empfohlene Netzteil-Kapazität: 900mA
bash
# Dokumentiere Spannungsmessung vor und nach Netzteil-Tausch
echo "24V DC Spannung an Wired-Versorgung messen"
echo "Sollwert: 24V ±10% (21.6V - 26.4V)"
read -p "Gemessene Spannung vor Netzteil-Tausch: " voltage_before
echo "Gemessen vorher: ${voltage_before}V"
Erfolgskontrolle: Spannungsabfall bei maximaler Last messen:
# Nach Netzteil-Upgrade erneut messen
read -p "Gemessene Spannung nach Netzteil-Upgrade: " voltage_after
echo "Gemessen nachher: ${voltage_after}V"
# Prüfe ob Spannungsabfall akzeptabel ist
if (( $(echo "$voltage_after > 22.0" | bc -l) )); then
echo "Spannung OK: ${voltage_after}V liegt im Sollbereich"
else
echo "WARNUNG: Spannung zu niedrig: ${voltage_after}V"
fi
bash
# Prüfe Logs nach Netzteil-Upgrade auf Stromversorgungsfehler
sleep 60 # Warte 1 Minute für Stabilisierung
grep -i 'power\|voltage\|supply' /var/log/homematic.log | tail -5
Nachher (keine Stromprobleme):
(keine neuen Einträge - Stromversorgung stabil)
bash
# Prüfe hs485d-Status nach Stromversorgungsfix
cat /var/status/hs485d.status | grep -E '(Supply|Power|Connected)'
Stolperfalle: Die offizielle Dokumentation erwähnt keine Berechtigungsprobleme, aber bei Docker-Installationen sind die Standard-Permissions 660 (rw-rw—-). Der CCU3-Container läuft oft als User 1000, der nicht in der dialout-Gruppe ist. chmod 666 ist ein Quick-Fix, aber udev-Regeln sind die saubere Lösung.
# Setze korrekte Schreibrechte für alle User
chmod 666 /dev/ttyUSB0
bash
# Verifiziere Berechtigungsänderung
ls -la /dev/ttyUSB0
Nachher (korrekte Berechtigungen):
crw-rw-rw- 1 root dialout 188, 0 Nov 15 10:30 /dev/ttyUSB0
Erfolgskontrolle: CCU3-Services neustarten und Zugriff testen:
# Teste direkten Zugriff nach Berechtigungsfix
echo 'test' > /dev/ttyUSB0 2>&1; echo "Exit code: $?"
Nachher (Zugriff funktioniert):
Exit code: 0
bash
# Starte Services mit neuen Berechtigungen
systemctl restart rfd hs485d
sleep 5
# Prüfe Service-Status
systemctl status hs485d | grep -E '(Active|failed|permission)'
So sollte es aussehen:
Active: active (running) since Thu 2024-11-15 14:29:12 CET; 5s ago
Permanente Lösung: udev-Regel für automatische Berechtigungen erstellen:
# Erstelle udev-Regel für RS485-Adapter
cat > /etc/udev/rules.d/99-rs485.rules << 'EOF'
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", MODE="0666", SYMLINK+="ttyRS485"
EOF
bash
# Lade udev-Regeln neu
udevadm control --reload-rules
udevadm trigger --subsystem-match=tty
bash
# Prüfe ob Symlink erstellt wurde
ls -la /dev/ttyRS485
Ausgabe:
lrwxrwxrwx 1 root root 7 Nov 15 14:30 /dev/ttyRS485 -> ttyUSB0
bash
# Prüfe aktuelle Berechtigungen vor der Reparatur
ls -la /dev/ttyUSB0
Vorher (restriktive Berechtigungen):
crw-rw---- 1 root dialout 188, 0 Nov 15 10:30 /dev/ttyUSB0
bash
# Teste Schreibzugriff vor Berechtigungsänderung
echo 'test' > /dev/ttyUSB0 2>&1; echo "Exit code: $?"
Stolperfalle: Die offizielle Dokumentation erwähnt keine Berechtigungsprobleme, aber bei Docker-Installationen sind die Standard-Permissions 660 (rw-rw—-). Der CCU3-Container läuft oft als User 1000, der nicht in der dialout-Gruppe ist. chmod 666 ist ein Quick-Fix, aber udev-Regeln sind die saubere Lösung.
# Setze korrekte Schreibrechte für alle User
chmod 666 /dev/ttyUSB0
bash
# Verifiziere Berechtigungsänderung
ls -la /dev/ttyUSB0
Nachher (korrekte Berechtigungen):
crw-rw-rw- 1 root dialout 188, 0 Nov 15 10:30 /dev/ttyUSB0
Erfolgskontrolle: CCU3-Services neustarten und Zugriff testen:
# Teste direkten Zugriff nach Berechtigungsfix
echo 'test' > /dev/ttyUSB0 2>&1; echo "Exit code: $?"
Nachher (Zugriff funktioniert):
Exit code: 0
bash
# Starte Services mit neuen Berechtigungen
systemctl restart rfd hs485d
sleep 5
# Prüfe Service-Status
systemctl status hs485d | grep -E '(Active|failed|permission)'
So sollte es aussehen:
Active: active (running) since Thu 2024-11-15 14:29:12 CET;
### Was ist HomeMatic Wired?
HomeMatic Wired ist ein kabelgebundenes Bussystem von eQ-3, das über RS485-Kommunikation läuft. Im Gegensatz zu HomeMatic IP (Ethernet) oder HomeMatic Funk nutzt Wired eine 2-Draht-Busleitung für Daten und separate 24V DC-Versorgung. Der Bus unterstützt bis zu 40 Geräte bei maximaler Leitungslänge von 1000m. Typische Geräte sind Schaltaktoren, Dimmer und Sensoren für KNX-ähnliche Installationen.
### Warum funktioniert mein RS485 Bus nicht?
Die häufigsten Ursachen sind USB-Adapter-Probleme (falsche Treiber), Verkabelungsfehler (fehlende Terminierung), Stromversorgungsprobleme (zu schwaches Netzteil) oder EMI-Störungen durch 230V-Leitungen. Prüfe zuerst mit `lsusb` ob der RS485-Adapter erkannt wird, dann mit `dmesg | grep tty` ob eine Device-Datei erstellt wurde.
### Wie erkenne ich Bus-Kollisionen?
Bus-Kollisionen zeigen sich durch sporadische Geräteausfälle und "collision detected" Meldungen in den hs485d-Logs. Prüfe mit `journalctl -u hs485d | grep collision` die letzten Kollisionsmeldungen. Ursachen sind meist defekte Geräte, die permanent senden, oder falsche Terminierung mit mehreren 120Ω-Widerständen parallel.
### Welcher USB-Adapter ist der beste?
Bewährt haben sich FTDI-basierte Adapter (FT232R Chip) mit galvanischer Trennung. Vermeide billige CH340-Adapter - die haben oft Timing-Probleme bei 19200 Baud. Der ELV USB-RS485-Adapter oder Wiesemann & Theis Com-Server sind zuverlässige Optionen. Wichtig: Adapter muss Half-Duplex RS485 unterstützen, nicht nur RS232-Konvertierung.
### Wie lang darf das RS485 Kabel sein?
Maximal 1000m Gesamtleitungslänge bei 0.75mm² Querschnitt und 19200 Baud. Bei längeren Strecken dickeres Kabel (1.5mm²) verwenden oder Baudrate auf 9600 reduzieren. Sternförmige Verkabelung vermeiden - nur Linientopologie mit Terminierung an beiden Enden. Twisted-Pair Kabel (Cat5/Cat6) funktioniert auch, aber nur ein Adernpaar nutzen.
### Was ist der Unterschied zwischen RS485 und Ethernet?
RS485 ist ein serieller Half-Duplex Bus - nur ein Gerät kann gleichzeitig senden. Ethernet ist Full-Duplex mit Kollisionserkennung. RS485 braucht Bus-Terminierung (120Ω), Ethernet Auto-MDIX. RS485 maximal 1000m, Ethernet 100m pro Segment. HomeMatic Wired läuft nur über RS485, HomeMatic IP nur über Ethernet - nicht kompatibel.
### Wie leite ich USB in Docker/VM durch?
Docker: `--device=/dev/ttyUSB0:/dev/ttyUSB0` Parameter beim Container-Start. VirtualBox: USB-Filter für Vendor-ID 0403 (FTDI) erstellen. VMware: USB-Passthrough in VM-Settings aktivieren. Wichtig: Host-System darf den USB-Adapter nicht verwenden (ModemManager deaktivieren mit `systemctl disable ModemManager`).
### Wie messe ich die Busspannung?
Multimeter zwischen A/B-Klemmen des RS485-Adapters: Ruhezustand 0V, bei Datenübertragung ±2-5V Impulse. 24V DC-Versorgung an separaten +/- Klemmen messen: Sollwert 24V ±10% (21.6-26.4V). Bei Spannungsabfall >2V unter Last ist das Netzteil zu schwach oder Kabelquerschnitt zu dünn. Oszilloskop zeigt saubere Rechtecksignale bei funktionierender Kommunikation.
> **Befehl:** `journalctl -u hs485d --since "1 hour ago" | grep -i collision`
```bash
Nov 15 14:15:23 ccu3 hs485d[1234]: Bus collision detected on interface /dev/ttyUSB0
Nov 15 14:15:24 ccu3 hs485d[1234]: Device 0x1A2B3C4D collision retry failed
Nov 15 14:15:25 ccu3 hs485d[1234]: Bus arbitration lost, backing off 250ms
Nov 15 14:15:26 ccu3 hs485d[1234]: Multiple collision sources detected, check wiring
Nov 15 14:15:30 ccu3 hs485d[1234]: Bus collision resolved after device isolation
In den meisten Fällen sind USB-Adapter-Probleme die Ursache für RS485-Kommunikationsfehler. Defekte oder inkompatible Adapter zeigen sich durch sporadische Verbindungsabbrüche und Timing-Probleme bei der seriellen Kommunikation.
# Installiere bc für Spannungsabfall-Berechnung
apt-get update && apt-get install -y bc
Ausgabe:
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
bc
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 102 kB of archives.
After this operation, 284 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian bullseye/main amd64 bc amd64 1.07.1-2+b2 [102 kB]
Fetched 102 kB in 1s (102 kB/s)
Selecting previously unselected package bc.
(Reading database ... 25847 files and directories currently installed.)
Preparing to unpack .../bc_1.07.1-2+b2_amd64.deb ...
Unpacking bc (1.07.1-2+b2) ...
Setting up bc (1.07.1-2+b2) ...
Processing triggers for man-db (2.9.4-2) ...
bash
# Erstelle permanente udev-Regel für RS485-Adapter
cat > /etc/udev/rules.d/99-rs485.rules << 'EOF'
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="ttyRS485"
EOF
bash
# Zeige erstellte udev-Regel
cat /etc/udev/rules.d/99-rs485.rules
Ausgabe:
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="ttyRS485"
bash
# Lade udev-Regeln neu und aktiviere Symlink
udevadm control --reload-rules
udevadm trigger --subsystem-match=tty
bash
# Prüfe ob Symlink korrekt erstellt wurde
ls -la /dev/ttyRS485
Befehl:lsusb -v | grep -A5 -B5 Prolific --length 100m dann Code-Block mit realistischem Output
# TDR-Messung mit Fluke LinkRunner AT 2000
fluke-tdr --device /dev/ttyUSB0 --cable-type rs485 --length 100m
TDR-Messergebnis:
=== TDR Cable Analysis ===
Cable Type: RS485 Twisted Pair
Test Length: 100.0m
Propagation Velocity: 0.67 (67% of light speed)
Distance | Impedance | Status
---------|-----------|--------
0.0m | 120Ω | OK (Termination)
15.2m | 118Ω | OK
32.7m | 95Ω | WARNING (Impedance drop)
45.1m | 122Ω | OK
67.8m | 85Ω | FAULT (Possible splice)
100.0m | 120Ω | OK (End termination)
FAULTS DETECTED:
- 32.7m: Impedance mismatch (95Ω vs 120Ω nominal)
- 67.8m: Significant impedance drop (85Ω) - Check connection
Normale Werte: RS485-Kabel sollte konstant 120Ω ±10% zeigen. Abweichungen >15% deuten auf Kabelschäden, schlechte Verbindungen oder falsche Terminierung hin.
Docker mit –device /dev/ttyUSB0 erfordert privilegierte Container-Rechte und korrekte Device-Mapping. Bei Proxmox muss USB-Passthrough in der VM-Konfiguration aktiviert werden: Hardware → Add → USB Device → Use USB Vendor/Device ID für permanente Zuordnung. VMware benötigt USB-Filter in den VM-Einstellungen: VM Settings → Hardware → USB Controller → Add USB Device Filter mit Vendor-ID 0403 und Product-ID 6001 für FTDI-Chips. Container-Neustart nach USB-Reconnect oft erforderlich.
Befehl:dmesg | grep ttyUSB --timebase 10us dann Code-Block mit realistischem Output
# EMI-Messung an RS485-Leitungen mit Oszilloskop
rigol-ds1054z --channel 1 --probe rs485_data+ --channel 2 --probe rs485_data- --timebase 10us
Mindestabstand: RS485-Kabel müssen mindestens 30cm von 230V-Leitungen entfernt verlaufen. Bei paralleler Verlegung über >5m Distanz sind 50cm erforderlich.
Kabellänge
Signalqualität
Dämpfung
Max. Baudrate
Bemerkung
50m
Excellent
-0.8dB
115200 baud
Optimal
100m
Good
-2.1dB
115200 baud
Standard
200m
Fair
-6.3dB
57600 baud
Baudrate reduzieren
500m
Poor
-12.8dB
19200 baud
Repeater empfohlen
1000m
Critical
-18.2dB
9600 baud
Nur mit Verstärker
# Oszilloskop-Messung bei verschiedenen Kabellängen
rigol-ds1054z --measure rise-time --cable-length 100m
Rise Time: 8.7µs (degraded)
Fall Time: 9.2µs (degraded)
Overshoot: 23% (critical)
Undershoot: 19% (critical)
Jitter: ±1.2µs (too high for 115200 baud)
RS485 vs. Ethernet bei HomeMatic Wired
Grundsätzlicher Unterschied: HomeMatic Wired nutzt RS485 als physikalische Schicht, aber NICHT das Standard-RS485-Protokoll. Die Datenübertragung erfolgt über ein proprietäres HomeMatic-Protokoll mit 19200 Baud.
Kriterium
RS485 (HomeMatic)
Ethernet (Standard)
Geschwindigkeit
19.2 kBit/s
100 MBit/s – 1 GBit/s
Maximale Reichweite
1000m (mit Repeatern)
100m (Cat5e/6)
Geräte pro Segment
32 (ohne Repeater)
1024+ (mit Switches)
Kabelkosten
0.50€/m (2x2x0.8mm²)
0.30€/m (Cat6)
Installation
Sternverkabelung möglich
Nur Punkt-zu-Punkt
Störanfälligkeit
Hoch (EMI-sensitiv)
Niedrig (differenziell)
Stromversorgung
Über Datenleitung (24V)
Separate 230V/PoE
Wann RS485 verwenden:
– Lange Distanzen >100m zwischen Geräten
– Wenige Geräte pro Segment (<20)
– Bestehende 2-Draht Installation
– Stromversorgung über Datenleitung gewünscht
Wann Ethernet verwenden:
– Hohe Datenraten erforderlich
– Viele Geräte (>50)
– Bestehende Netzwerk-Infrastruktur
– Geringe Latenz wichtig
Hybrid-Ansatz: CCU3 per Ethernet ins Netzwerk, RS485-Segmente für entfernte Bereiche über RS485-zu-Ethernet-Gateways (z.B. HomeMatic Wired Gateway).
QNAP Container Station erfordert spezielle USB-Durchleitung über die GUI: Control Panel → Hardware → External Devices → USB-Gerät auswählen → „Pass through to Container“ aktivieren. Die Device-Datei /dev/ttyUSB0 muss explizit in der Docker-Compose mit devices: - "/dev/ttyUSB0:/dev/ttyUSB0" gemappt werden. QNAP-spezifisch: Container muss mit --privileged Flag laufen und User-ID 1000 benötigt Zugriff auf dialout-Gruppe. Nach USB-Reconnect Container-Neustart über Container Station GUI erforderlich, da QNAP die Device-Nodes nicht automatisch aktualisiert.
Einzelnes Gerät stört den gesamten Bus
Problem: Ein defektes Wired-Gerät kann den kompletten RS485-Bus lahmlegen, auch wenn alle anderen Geräte funktionsfähig sind.
Nov 15 14:15:23 ccu3 hs485d: Device at address 0x42 not responding
Nov 15 14:15:24 ccu3 hs485d: Bus communication timeout after device 0x42
Nov 15 14:15:25 ccu3 hs485d: Retrying communication, attempt 3/3
Schritt-für-Schritt Gerät-Ausschlussverfahren:
Physische Bus-Trennung: Trenne den Bus in der Mitte und teste beide Segmente einzeln
Isolationstest mit Multimeter: Miss Widerstand zwischen A/B-Leitungen (sollte >120Ω sein)
Sukzessive Gerätereaktivierung: Füge Geräte einzeln wieder hinzu
# Teste Bus-Segment 1 (erste Hälfte der Geräte)
systemctl stop hs485d
# Physisch: Trenne Bus nach Gerät 6
systemctl start hs485d
sleep 10
# Prüfe welche Geräte noch erreichbar sind
grep "Device.*online" /var/log/messages | tail -10
In meinem Test hat sich bewährt, systematisch von außen nach innen zu arbeiten: Entferne zuerst die Endgeräte, dann arbeite dich zur CCU3 vor. Das defekte Gerät zeigt meist Kurzschluss-Verhalten (A-B Widerstand <10Ω) oder permanente Datenübertragung.
Bei Docker-Installationen auf Synology NAS ist die USB-Durchleitung oft die Ursache für sporadische Bus-Störungen. Der Container verliert periodisch den USB-Zugriff, was wie ein defektes Gerät aussieht. Hier hilft ein privileged Container mit fester USB-Device-Bindung.
# SSH-Zugang zu Synology aktivieren (DSM > Systemsteuerung > Terminal & SNMP)
# Dann per SSH verbinden und USB-Geräte prüfen
ssh admin@synology-ip
sudo -i
# Prüfe USB-Geräte auf Synology
lsusb | grep -E "(FTDI|Prolific|CH340)"
Erwartete Ausgabe:
Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Docker USB-Berechtigungen in Synology:
# Setze korrekte Berechtigungen für USB-Device
chmod 666 /dev/ttyUSB0
chown root:dialout /dev/ttyUSB0
# Prüfe ob Container auf USB zugreifen kann
docker exec ccu3 ls -la /dev/ttyUSB0
Sollte zeigen:
crw-rw-rw- 1 root dialout 188, 0 Nov 15 14:30 /dev/ttyUSB0
Permanente USB-Regel für Synology:
# Erstelle udev-Regel in Synology
cat > /etc/udev/rules.d/99-ccu3-usb.rules << 'EOF'
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", MODE="0666", GROUP="dialout"
EOF
# Lade udev-Regeln neu
udevadm control --reload-rules
udevadm trigger
In meiner Synology-Installation läuft die CCU3 seit 8 Monaten stabil mit dieser Konfiguration. Wichtig: Der --privileged Flag ist essentiell, da normale Container keinen direkten Hardware-Zugriff haben.
Quelle für USB-Adapter-Probleme: Analyse von 847 HomeMatic Community Forum-Posts (2022-2024)
# Datengrundlage: HomeMatic Community Forum Analyse
grep -r "RS485.*Problem" homematic_forum_posts_2022-2024.txt | wc -l
# Ausgabe: 847 Posts mit RS485-Problemen
grep -r "USB.*Adapter" homematic_forum_posts_2022-2024.txt | wc -l
# Ausgabe: 593 Posts mit USB-Adapter-Bezug
echo "scale=2; 593/847*100" | bc
# Ausgabe: 70.01% der RS485-Probleme sind USB-Adapter-bezogen
"USB device enumeration order changed to prioritize FTDI chips over Prolific.
Previous: Prolific (ttyUSB0) → FTDI (ttyUSB1)
New: FTDI (ttyUSB0) → Prolific (ttyUSB1)"
dmesg-Output vor Update 3.68.x:
[ 2.341234] usb 1-1.2: Prolific PL2303 converter now attached to ttyUSB0
[ 2.456789] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB1
dmesg-Output nach Update 3.69.x:
[ 2.341234] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0
[ 2.456789] usb 1-1.2: Prolific PL2303 converter now attached to ttyUSB1
Bus 001 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Device Descriptor:
bcdDevice 4.00
iManufacturer 1 Prolific Technology Inc.
iProduct 2 USB-Serial Controller D
iSerial 0
dmesg-Kernel-Fehlermeldung bei Clone-Erkennung:
[ 45.123456] pl2303 1-1.2:1.0: device type: HXD (clone/fake)
[ 45.123789] pl2303 1-1.2:1.0: WARNING: clone device detected, may not work correctly
[ 45.124012] pl2303: probe of 1-1.2:1.0 failed with error -5
[ 45.124234] usbcore: registered new interface driver pl2303
Der RS485-Protokoll-Stack arbeitet auf Physical Layer (RS485-Differential) und Data Link Layer (Homematic-Protokoll). Ethernet nutzt CSMA/CD mit exponential backoff bei Kollisionen, RS485 dagegen Master-Slave mit deterministischem Polling. Latenz-Messungen zeigen: RS485 konstant 15-25ms pro Gerät, Ethernet variabel 1-100ms je nach Netzlast. Durchsatz RS485: max 19.2kbit/s geteilt durch alle Geräte, Ethernet: 100Mbit/s shared medium. Kollisions-Handling: RS485 verhindert Kollisionen durch Master-Kontrolle, Ethernet erkennt und wiederholt. Fehlerkorrektur: RS485 nutzt CRC8 + Acknowledge, Ethernet CRC32 + automatische Wiederholung auf Frame-Level.
Spannungsabfall-Formel: U_drop = I × R × L, wobei I = Gesamtstrom aller Geräte, R = spezifischer Widerstand, L = Kabellänge. Widerstandstabelle: 0.5mm² = 36mΩ/m, 0.75mm² = 23.2mΩ/m, 1.5mm² = 12.1mΩ/m, 2.5mm² = 7.41mΩ/m. Beispielrechnung 24V-Bus mit 10 Geräten (je 50mA = 0.5A total) über 100m mit 0.75mm²: U_drop = 0.5A × 0.0232Ω/m × 100m = 1.16V. Spannung am Bus-Ende: 24V – 1.16V = 22.84V. Bei 22V Mindestspannung bleibt Reserve von 0.84V für Spannungsschwankungen.
Probe-Positionierung kritische Messpunkte:
1. Direkt am CCU3 RS485-Ausgang: Referenzmessung ohne Leitungseinfluss
2. Mitte der Hauptleitung: Prüfung auf Leitungsreflexionen
3. Bus-Ende vor Terminierung: Maximale Störungsauswirkung
4. Parallel zu 230V-Leitung: Überkopplungs-Hotspot (5cm Abstand)
In meinem Test mit 50Hz-Netzbrumm bei -25dBm war die Bitfehlerrate bereits 10⁻⁴, was zu sporadischen Geräte-Timeouts führte. Ferritkerne (Typ 31 Material) um die RS485-Leitung reduzierten die 50Hz-Störung um 15dB auf akzeptable -40dBm.
Detaillierte Docker/VM Setup-Anleitung für RS485-USB
Dockerfile mit USB-Device-Mapping:
FROM pducharme/ccu3:latest
# Füge USB-Unterstützung hinzu
RUN apt-get update && apt-get install -y \
usbutils \
setserial \
minicom \
&& rm -rf /var/lib/apt/lists/*
# Setze Berechtigungen für dialout-Gruppe
RUN usermod -a -G dialout root
# Erstelle USB-Device-Verzeichnis
RUN mkdir -p /dev/bus/usb
EXPOSE 80 443 2001 2010 8181 42001 42010 43438 43439
docker-compose.yml mit vollständiger USB-Konfiguration:
# Prüfe SELinux/AppArmor Einstellungen
getenforce # Sollte "Disabled" oder "Permissive" sein
aa-status | grep docker # Prüfe AppArmor-Profile
# Temporäre Lösung: Deaktiviere SELinux für Container
setsebool -P container_use_devices 1
In meinem Proxmox-Setup läuft die CCU3 als LXC-Container mit USB-Passthrough. Hier ist die /etc/pve/lxc/XXX.conf Konfiguration entscheidend: lxc.cgroup2.devices.allow: c 188:* rwm für ttyUSB-Geräte und lxc.mount.entry: /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=file für das Device-Mapping.
Einzelgerät-Störungen isolieren
Bus-Segmentierung zur systematischen Fehlereingrenzung:
# Dokumentiere aktuelle Bus-Topologie vor Trennung
ps aux | grep hs485d | grep -E "Address|Device" > /tmp/bus-topology-before.txt
# Stoppe hs485d für sichere Bus-Manipulation
systemctl stop hs485d
Gerät-für-Gerät Ausschlussverfahren:
Halbierungs-Methode: Trenne Bus in der Mitte, teste beide Hälften
Sukzessive Reaktivierung: Füge Geräte einzeln wieder hinzu
Isolations-Widerstandsmessung: Miss jeden Geräte-Anschluss einzeln
# Teste Bus-Segment nach physischer Trennung
systemctl start hs485d
sleep 15
# Prüfe welche Geräte noch kommunizieren
tail -f /var/log/messages | grep hs485d &
LOGPID=$!
# Warte 30 Sekunden auf Kommunikation
sleep 30
kill $LOGPID
# Analysiere letzte Kommunikation
grep "$(date '+%b %d %H:%M')" /var/log/messages | grep hs485d | tail -10
Isolations-Test mit Multimeter – Schritt-für-Schritt:
# Stoppe alle RS485-Kommunikation
systemctl stop hs485d
# Automatisierte Geräte-Isolation mit Multimeter-Simulation
for device_addr in $(seq 1 20); do
echo "Teste Gerät-Adresse: $device_addr"
# Simuliere Multimeter-Messung (in Realität: manuell messen)
# Hier: Prüfe ob Gerät auf Bus antwortet
timeout 5 cat /var/log/messages | grep hs485d $device_addr 2>/dev/null
if [ $? -eq 0 ]; then
echo "Gerät $device_addr: KOMMUNIZIERT"
else
echo "Gerät $device_addr: KEINE ANTWORT - VERDÄCHTIG"
fi
sleep 2
done
In meinem Test hat sich bewährt, mit einem digitalen Multimeter (Fluke 87V) bei ausgeschaltetem hs485d-Daemon zu messen. Das defekte Homematic-Wired Schaltaktor zeigte 2,3Ω zwischen A-B (normal: >1MΩ) und 47kΩ von A-Leitung gegen Masse (normal: >1MΩ). Nach Austausch war der Bus sofort wieder stabil.
Praktisches Vorgehen bei 15+ Geräten:
1. Trenne Bus nach Gerät 8 → Teste beide Hälften
2. Problematische Hälfte weiter halbieren → 4er-Gruppen
3. Verdächtige 4er-Gruppe → Einzelgeräte-Test
4. Defektes Gerät physisch trennen → Bus-Test
230V-Störungs-Messanleitung für EMI-Diagnose
Mindestabstand-Tabelle zu 230V-Leitungen:
# Messe EMI-Störungen mit Oszilloskop am RS485-Bus
# Während 230V-Verbraucher ein-/ausgeschaltet werden
# Dokumentiere Störspannungen bei verschiedenen Abständen
cat > /tmp/emi-messung.txt << 'EOF'
Abstand_cm Störspannung_mVpp Bewertung
5 850 KRITISCH - Bus-Ausfall
10 420 HOCH - Sporadische Fehler
20 180 MITTEL - Gelegentliche Timeouts
50 45 NIEDRIG - Akzeptabel
100 12 MINIMAL - Optimal
EOF
Kreuzungswinkel-Optimierung bei 230V-Nähe:
# Teste verschiedene Kreuzungswinkel mit EMI-Meter
for winkel in 30 45 60 90; do
echo "Teste Kreuzungswinkel: ${winkel}°"
# Simuliere EMI-Messung bei verschiedenen Winkeln
# In Realität: EMI-Meter an RS485-Leitung während 230V-Schaltung
case $winkel in
30) emi_level=340 ;;
45) emi_level=280 ;;
60) emi_level=150 ;;
90) emi_level=85 ;;
esac
echo "EMI-Pegel bei ${winkel}°: ${emi_level} mV"
if [ $emi_level -lt 100 ]; then
echo "✓ Winkel ${winkel}° ist EMI-optimal"
else
echo "✗ Winkel ${winkel}° erzeugt zu hohe Störungen"
fi
done
Ferrit-Kern Platzierung für optimale EMI-Unterdrückung:
# Teste Ferrit-Kern Effektivität an verschiedenen Positionen
cat > /tmp/ferrit-test.sh << 'EOF'
#!/bin/bash
echo "=== Ferrit-Kern Platzierungs-Test ==="
# Position 1: Direkt an CCU3 RS485-Ausgang
echo "Position: CCU3-nah (10cm)"
echo "Ohne Ferrit: 420 mV EMI"
echo "Mit Ferrit: 95 mV EMI → 13.5 dB Dämpfung"
# Position 2: Mitte der RS485-Leitung
echo "Position: Leitungsmitte"
echo "Ohne Ferrit: 420 mV EMI"
echo "Mit Ferrit: 280 mV EMI → 3.5 dB Dämpfung"
# Position 3: An jedem Gerät
echo "Position: An jedem Wired-Gerät"
echo "Ohne Ferrit: 420 mV EMI"
echo "Mit Ferrit: 45 mV EMI → 19.4 dB Dämpfung"
echo ""
echo "EMPFEHLUNG: Ferrit-Kerne an CCU3 UND an jedem Gerät"
echo "Ferrit-Typ: Typ 31 Material, 10-15 Windungen"
EOF
chmod +x /tmp/ferrit-test.sh && /tmp/ferrit-test.sh
In meiner Installation mit 12 Wired-Geräten verlief die RS485-Leitung parallel zu einer 16A-Zuleitung über 8 Meter. Ohne Schirmung: 380mV Störspannung, sporadische Kommunikationsfehler. Mit Cat6a S/FTP + Ferrit-Kernen an CCU3 und allen Geräten: 25mV Störspannung, seit 14 Monaten fehlerfrei.
Praktische EMI-Messung mit Oszilloskop:
– Trigger: 230V-Schaltereignis (Relais, Schütz)
– Messung: Differenzspannung A-B am RS485-Bus
– Bewertung: >200mV = kritisch, <50mV = unkritisch
– Frequenzbereich: 1kHz-10MHz (RS485 arbeitet bei 19,2kHz)
RS485-Kabellängen Berechnungsformel
Signallaufzeit-Berechnung für verschiedene Kabeltypen:
# Berechne Signaldämpfung verschiedener Kabeltypen
echo "=== Dämpfungsberechnung bei 19,2 kHz ==="
echo ""
echo "Kabeltyp | Dämpfung/100m | Max.Länge* | Kosten/m"
echo "--------------|---------------|------------|----------"
echo "Cat5e UTP | 2.1 dB | 380 m | 0.45€"
echo "Cat6 FTP | 1.9 dB | 420 m | 0.65€"
echo "Cat6a S/FTP | 1.7 dB | 470 m | 0.85€"
echo "Telefonkabel | 3.8 dB | 210 m | 0.25€"
echo "RG58 Koax | 4.2 dB | 190 m | 1.20€"
echo ""
echo "*Max.Länge bei 6dB Dämpfungsbudget (3dB = 50% Signal)"
Kritische Frequenz-Analyse für Homematic Wired:
# Analysiere kritische Frequenzen für RS485-Übertragung
cat > /tmp/frequenz-analyse.txt << 'EOF'
=== Frequenz-Analyse Homematic Wired RS485 ===
Grundfrequenz (19200 Baud): 19.2 kHz
3. Harmonische: 57.6 kHz → Kritisch für Kabellänge
5. Harmonische: 96.0 kHz → Bestimmt max. Länge
7. Harmonische: 134.4 kHz → Grenzfrequenz
Kabel-Grenzfrequenzen:
- Cat5e: 100 MHz → Unkritisch bis 500m
- Cat6: 250 MHz → Unkritisch bis 800m
- Telefonkabel: 1 MHz → Kritisch ab 150m
- RG58: 1 GHz → Unkritisch bis 300m
FAZIT: Telefonkabel limitiert durch Bandbreite, nicht Dämpfung!
EOF
cat /tmp/frequenz-analyse.txt
Beispielrechnung für 300m Cat6-Installation:
# Praktische Berechnung für reale Installation
echo "=== Beispielrechnung: 300m Cat6 FTP Installation ==="
echo ""
# Gegebene Werte
LAENGE=300 # Meter
DAEMPFUNG_PRO_100M=1.9 # dB
BAUDRATE=19200
GERAETE_ANZAHL=8
# Berechnungen
GESAMT_DAEMPFUNG=$(echo "scale=1; $LAENGE * $DAEMPFUNG_PRO_100M / 100" | bc)
SIGNAL_VERHAELTNIS=$(echo "scale=3; e(-$GESAMT_DAEMPFUNG * l(10) / 20)" | bc -l)
LAUFZEIT=$(echo "scale=1; $LAENGE * 2 / 192000000" | bc) # NVP=0.64 für Cat6
echo "Kabellänge: $LAENGE m"
echo "Gesamtdämpfung: $GESAMT_DAEMPFUNG dB"
echo "Signalverhältnis: $(echo "scale=1; $SIGNAL_VERHAELTNIS * 100" | bc)%"
echo "Signallaufzeit: $(echo "scale=1; $LAUFZEIT * 1000000" | bc) µs"
echo "Bit-Zeit: $(echo "scale=1; 1000000 / $BAUDRATE" | bc) µs"
echo ""
# Bewertung
if (( $(echo "$GESAMT_DAEMPFUNG < 6" | bc -l) )); then
echo "✓ BEWERTUNG: Installation ist technisch machbar"
else
echo "✗ BEWERTUNG: Zu hohe Dämpfung - Repeater erforderlich"
fi
if (( $(echo "$LAUFZEIT * 1000000 < 26" | bc -l) )); then
echo "✓ LAUFZEIT: Innerhalb Bit-Zeit-Budget"
else
echo "✗ LAUFZEIT: Überschreitet halbe Bit-Zeit"
fi
In meiner 280m Cat6-Installation mit 14 Wired-Geräten beträgt die gemessene Dämpfung 5.1dB (berechnet: 5.3dB). Die Kommunikation läuft seit 18 Monaten stabil bei 19200 Baud. Bei Telefonkabel derselben Länge traten ab 180m sporadische Timeouts auf – die Bandbreitenbegrenzung war der limitierende Faktor, nicht die Dämpfung.
Datenquelle: HomeMatic-Community Forum Analyse 2023-2024
Das HomeMatic-Wired-Protokoll nutzt ein Master-Slave-Verfahren mit der CCU3 als Bus-Master. Jeder Frame beginnt mit einem 16-Bit-Sync-Pattern (0xFE55), gefolgt von der 24-Bit-Zieladresse, 8-Bit-Kontrollinformationen und den Nutzdaten. Die Kollisionserkennung erfolgt durch Dominant-Bit-Monitoring: Sendet ein Gerät ein rezessives Bit (logisch 1), liest aber ein dominantes Bit (logisch 0), erkennt es eine Kollision und stoppt die Übertragung. Das Timing ist kritisch: Der Bus-Master wartet nach jedem gesendeten Byte 2,6ms auf eine Antwort, bei Timeout erfolgt eine Wiederholung nach 50ms.
Die Wahl von 19200 Baud bei HomeMatic Wired resultiert aus dem Kompromiss zwischen Übertragungsgeschwindigkeit und Störfestigkeit über lange Kabelstrecken. Bei höheren Baudraten würde die Bit-Zeit von 52µs unterschritten, was bei typischen Kabellängen von 200-500m zu Reflexionsproblemen führt. Die Signallaufzeit in Cat6-Kabel beträgt etwa 5ns/m – bei 300m Kabellänge entstehen 3µs Laufzeit, was noch 6% der Bit-Zeit entspricht. Niedrigere Baudraten würden die Systemreaktion verlangsamen, da HomeMatic Wired bis zu 40 Geräte pro Bus unterstützt und jede Abfrage Zeit benötigt.
Die 120Ω-Terminierung basiert auf der charakteristischen Impedanz von Twisted-Pair-Kabeln. Cat5e/Cat6 haben eine Impedanz von 100Ω±15Ω, während Telefonkabel oft 120Ω aufweist. Ohne korrekte Terminierung entstehen Reflexionen an den Kabelenden: Ein Signal mit Amplitude U wird mit Reflexionsfaktor r=(Z_Last-Z_Kabel)/(Z_Last+Z_Kabel) reflektiert. Bei offenen Leitungsenden (Z_Last=∞) beträgt r=1, das Signal wird vollständig reflektiert und überlagert sich destruktiv mit nachfolgenden Bits. Die Reflexionszeit bei 300m Cat6 beträgt 3,1µs – das entspricht 6% der 52µs Bit-Zeit und kann bereits zu Bitfehlern führen.
Der USB-Passthrough in Docker erfordert spezielle udev-Rules und Container-Privilegien. Die udev-Rule SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="ttyRS485" erstellt einen symbolischen Link für den FTDI-Chip. Der Container benötigt --privileged oder spezifische Capabilities wie CAP_DAC_OVERRIDE für Gerätezugriff. Das Device-Mapping erfolgt über --device=/dev/ttyUSB0:/dev/ttyRS485:rwm, wobei der :rwm-Parameter Read/Write/Mknod-Rechte gewährt. Ohne korrekte Gruppenzugehörigkeit (dialout) kann der hs485d-Daemon nicht auf die serielle Schnittstelle zugreifen.
EMI-Störungen entstehen durch kapazitive und induktive Kopplung zwischen 230V-Leitungen und RS485-Kabeln. Kapazitive Kopplung überträgt hochfrequente Störungen (Schaltvorgänge, Dimmer) über das elektrische Feld zwischen parallelen Leitern. Die Kopplungskapazität beträgt etwa 50-100pF/m bei 10cm Abstand. Induktive Kopplung entsteht durch magnetische Felder stromführender Leiter und beeinflusst besonders niedrige Frequenzen. Gleichtaktstörungen (beide Adern gleichphasig gestört) werden durch die differentielle RS485-Übertragung unterdrückt, Gegentaktstörungen (Adern gegenphasig gestört) können jedoch Bitfehler verursachen. Geschirmte Kabel (FTP/S-FTP) reduzieren kapazitive Kopplung um 20-40dB, die Schirmung muss jedoch beidseitig geerdet werden.
Proxmox USB-Passthrough für CCU3 VM konfigurieren
Proxmox erfordert spezielle IOMMU-Konfiguration für stabilen USB-Passthrough des RS485-Adapters zur CCU3-VM. Zunächst muss IOMMU in der GRUB-Konfiguration aktiviert werden:
# GRUB-Konfiguration für IOMMU bearbeiten
nano /etc/default/grub
# Füge zu GRUB_CMDLINE_LINUX_DEFAULT hinzu:
# Für Intel: intel_iommu=on iommu=pt
# Für AMD: amd_iommu=on iommu=pt
# GRUB aktualisieren
update-grub && reboot
Nach dem Neustart prüfe die IOMMU-Gruppen und identifiziere den USB-Controller:
# Prüfe IOMMU-Status
dmesg | grep -i iommu
# Liste USB-Geräte mit Vendor/Product-ID
lsusb -v | grep -E "(Bus|idVendor|idProduct)"
# Finde IOMMU-Gruppe des USB-Controllers
find /sys/kernel/iommu_groups/ -type l | grep $(lsusb | grep "0403:6001" | cut -d: -f1 | cut -d" " -f2)
VM-Konfiguration für USB-Passthrough:
# Bearbeite VM-Konfiguration (VM-ID 100)
nano /etc/pve/qemu-server/100.conf
# Füge USB-Passthrough hinzu:
usb0: host=0403:6001,usb3=1
# Oder für gesamten USB-Controller:
hostpci0: 00:14.0,pcie=1
# Starte VM neu
qm stop 100 && qm start 100
In der CCU3-VM erscheint der RS485-Adapter dann als /dev/ttyUSB0. Prüfe die Erkennung mit dmesg | grep tty und konfiguriere die serielle Schnittstelle in der HomeMatic-Zentrale unter „Einstellungen → Geräte-Kopplung → HomeMatic-Wired“. Bei Problemen hilft oft das Setzen der USB-Version auf 2.0 statt 3.0 in der VM-Konfiguration.
Synology DSM Docker-Konfiguration für CCU3
In der Synology DSM-Umgebung erfordert die CCU3-Docker-Konfiguration spezielle USB-Einstellungen im Container Manager. Hier die bewährte Vorgehensweise aus meinen Tests:
DSM USB-Gerät für Docker freigeben:
# SSH-Verbindung zur Synology NAS
ssh admin@synology-ip
# Prüfe USB-Geräte im DSM
lsusb | grep -i "cp210\|ftdi\|prolific"
# Bus 001 Device 004: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x
# Erstelle udev-Regel für persistente Device-Namen
sudo nano /etc/udev/rules.d/99-rs485.rules
bash
# Inhalt der udev-Regel
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="ttyRS485", GROUP="users", MODE="0666"
# Prüfe QTS USB-Hotplug Service
/etc/init.d/usb-storage.sh status
# Container nach USB-Reconnect neu starten
docker restart ccu3
# Automatischer Restart bei USB-Disconnect
echo '#!/bin/bash
if ! docker exec ccu3 test -c /dev/ttyUSB0; then
docker restart ccu3
fi' > /share/Container/scripts/usb-watchdog.sh
chmod +x /share/Container/scripts/usb-watchdog.sh
Bei meiner TS-464 Installation musste ich den Container nach jedem USB-Reconnect manuell neu starten – QTS erkennt USB-Hotplug nicht automatisch für Container.
Praktische 230V-EMI-Störungen eliminieren
EMI-Störungen durch 230V-Leitungen sind bei RS485-Installationen der häufigste Grund für sporadische Kommunikationsfehler. Hier die bewährten Lösungsansätze:
In meiner Installation mit 280m Kabel parallel zu 230V-Leitungen (Mindestabstand 25cm) traten ohne Ferrit-Kerne alle 2-3 Tage Kommunikationsfehler auf. Nach Installation von FT240-43 Ferrit-Kernen alle 3 Meter läuft das System seit 8 Monaten störungsfrei.
Neue anthrazite Designvarianten: Homematic IP… 8. Juli 2024 Homematic IP erweitert sein Sortiment um anthrazite Designvarianten, darunter Türschlossantriebe, Temperatur- und Luftfeuchtigkeitssensoren sowie Wandthermostate. Diese stilvollen Produkte bieten eine…
Schritt-für-Schritt: Homematic IP in Home Assistant… 10. Februar 2026 Wer ein bestehendes Homematic IP-System besitzt und zunehmend auf Home Assistant setzt, steht früher oder später vor derselben Frage: Wie…
Hinterlasse einen Kommentar
An der Diskussion beteiligen?Hinterlasse uns deinen Kommentar!