Die CCU2 zu CCU3 Migration erfordert eine systematische Herangehensweise, um Geräteverluste zu vermeiden

Die Homematic CCU2 zu CCU3 Migration kaufen scheitert in Häufige Probleme bei der Migration sind daran, dass nach dem Backup-Restore alle Geräte als „nicht erreichbar“ angezeigt werden. Das Problem liegt nicht an defekter Hardware, sondern an kritischen Konfigurationsfehlern während des Migrationsprozesses. Mit der richtigen Schritt-für-Schritt Anleitung und entsprechenden Backup-Strategien lassen sich diese Probleme vollständig vermeiden.

RaspberryMatic CCU2 Migration: Komplette Anleitung

Die Migration von CCU2 auf RaspberryMatic bietet eine kostengünstige Alternative zur CCU3. Der Prozess unterscheidet sich grundlegend von der CCU3-Migration, da RaspberryMatic ein anderes Betriebssystem verwendet.

Vorbereitung der RaspberryMatic-Installation:

# Image auf SD-Karte schreiben (Linux/macOS)
sudo dd if=RaspberryMatic-3.69.7.20230625-rpi4.img of=/dev/sdX bs=4M status=progress
sync

CCU2 Backup für RaspberryMatic vorbereiten:

# Auf CCU2: Erweiterte Backup-Erstellung
cd /usr/local
tar -czf /tmp/homematic-backup-full.tar.gz addons etc firmware www

Migration durchführen:
1. RaspberryMatic booten und WebUI aufrufen
2. Unter „Einstellungen > Sicherheit > Systemsicherung“ das CCU2-Backup hochladen
3. Wichtig: RaspberryMatic konvertiert automatisch CCU2-spezifische Pfade

Post-Migration Verifikation:

# SSH auf RaspberryMatic
ssh root@raspberrymatic-ip

# Geräte-Status prüfen
/bin/eq3configcmd update-lgw-firmware -p /dev/ttyAMA0 -t HM-LGW-O-TW-W-EU -c -se 2>&1

Die RaspberryMatic-Migration ist oft stabiler als CCU3-Migrationen, da weniger Hardware-abhängige Komponenten betroffen sind.

Homematic CCU3 VM Proxmox Migration Angebot von CCU2

Die Migration einer CCU2 auf eine CCU3-VM in Proxmox erfordert spezielle Netzwerk- und Hardware-Konfigurationen. Diese Methode bietet maximale Flexibilität bei der Hardware-Wahl.

Proxmox VM-Konfiguration für CCU3:

# VM erstellen (Proxmox CLI)
qm create 103 --name ccu3-homematic --memory 1024 --cores 2 --net0 virtio,bridge=vmbr0
qm set 103 --scsi0 local-lvm:8,format=raw
qm set 103 --boot order=scsi0

CCU3 OVA in Proxmox importieren:

# OVA extrahieren und konvertieren
tar -xvf CCU3-3.69.7.ova
qm importdisk 103 CCU3-3.69.7-disk001.vmdk local-lvm --format raw
qm set 103 --scsi0 local-lvm:vm-103-disk-0

USB-Funkmodul Passthrough konfigurieren:

# USB-Geräte identifizieren
lsusb | grep -i homematic
# Ausgabe: Bus 001 Device 003: ID 1b1f:c020 <strong><a href="https://www.amazon.de/s?k=Corsair+HM-CFG-USB-2&tag=technikkram-21" target="_blank" rel="nofollow sponsored noopener" class="affiliate-link affiliate-amazon">Corsair HM-CFG-USB-2 Preis prüfen</a></strong>

# USB-Passthrough in VM-Config
qm set 103 --usb0 host=1b1f:c020

CCU2 Migration in Proxmox-VM:
1. CCU2-Backup wie gewohnt erstellen
2. CCU3-VM starten und Backup einspielen
3. Kritisch: USB-Funkmodul erst nach erfolgreichem Backup-Restore aktivieren

Netzwerk-Troubleshooting:

# In CCU3-VM: Interface-Status prüfen
ip addr show
# Proxmox Host: Bridge-Status
brctl show vmbr0

CCU3 Factory Reset vor Migration: Wann notwendig?

Ein Factory Reset der CCU3 vor Migration ist nicht grundsätzlich erforderlich, kann aber bei bestimmten Problemen die Erfolgsrate erhöhen. Die Entscheidung hängt vom Zustand der Ziel-CCU3 ab.

Wann Factory Reset durchführen:
– CCU3 war bereits in Betrieb mit anderen Geräten
– Vorherige Migrationsversuche sind fehlgeschlagen
– Netzwerk-Konfigurationsprobleme bestehen
– Firmware-Version ist deutlich neuer als CCU2

Factory Reset durchführen:

# Via WebUI: Einstellungen > Sicherheit > Factory Reset
# Oder via SSH:
ssh root@ccu3-ip
/etc/init.d/S61rfd stop
rm -rf /usr/local/etc/config/*
rm -rf /usr/local/addons/*
/sbin/reboot

Verifikation nach Factory Reset:

# Leere Konfiguration bestätigen
ls -la /usr/local/etc/config/
# Sollte nur Basis-Verzeichnisse zeigen

# Interface-Status prüfen
/bin/eq3configcmd update-lgw-firmware -p /dev/ttyAMA0 -t HM-LGW-O-TW-W-EU -c -se

Wann KEIN Factory Reset nötig:
– Neue, unbenutzte CCU3
– Gleiche Firmware-Version wie CCU2
– Nur Test-Migration geplant

Nach Factory Reset Migration:
1. CCU3 komplett hochfahren lassen (je nach Hardware-Konfiguration (Pi 4, 4GB RAM, Class 10 SD: ~3-5 Min))
2. WebUI erreichbarkeit prüfen
3. Erst dann CCU2-Backup einspielen

Der Factory Reset eliminiert potenzielle Konflikte, verlängert aber den Migrationsprozess um 15-20 Minuten.

RaspberryMatic vs CCU3 Hardware Migration: Entscheidende Unterschiede

Die Wahl zwischen RaspberryMatic und CCU3 beeinflusst den Migrationsprozess erheblich. Beide Systeme haben unterschiedliche Hardware-Anforderungen und Migrationseigenarten.

Hardware-Unterschiede:

# CCU3 Hardware-Info
cat /proc/cpuinfo
# Ausgabe: ARMv7 Processor rev 4 (v7l), BCM2835

# RaspberryMatic auf Pi4
cat /proc/cpuinfo
# Ausgabe: ARMv8 Processor rev 3 (v8l), BCM2711

Funkmodul-Kompatibilität:
– CCU3: Integriertes Funkmodul, keine externe Hardware nötig
– RaspberryMatic: Benötigt HM-MOD-RPI-PCB oder USB-Funkstick

Migration-Performance Vergleich:

# CCU3: Backup-Restore Geschwindigkeit
time tar -xzf backup.tar.gz -C /usr/local/
# Typisch: je nach Backup-Größe (Pi 4, 4GB RAM: ~45-90 Sek für 50MB) für 50MB Backup

# RaspberryMatic Pi4: Deutlich schneller
time tar -xzf backup.tar.gz -C /usr/local/
# Typisch: bei Standard-Hardware (Pi 4, Class 10 SD: ~30-45 Sek) für gleiches Backup

Spezifische Migrationsprobleme:

CCU3-spezifisch:
– Seriennummer-Binding an Hardware
– Begrenzte CPU-Leistung bei großen Konfigurationen
– Firmware-Updates nur über eQ-3

RaspberryMatic-spezifisch:
– GPIO-Konfiguration für Funkmodul erforderlich
– SD-Karten-Lebensdauer beachten
– Mehr Hardware-Varianten = mehr Fehlerquellen

Empfehlung basierend auf Systemgröße:
– < 50 Geräte: Beide Systeme gleichwertig
– 50-150 Geräte: RaspberryMatic wegen besserer Performance
– > 150 Geräte: RaspberryMatic auf Pi4 mit SSD empfohlen

Homematic Zentrale wechseln Preis prüfen: Tinkerboard Migration

Der Tinkerboard bietet eine leistungsstarke Alternative für RaspberryMatic mit x86-ähnlicher Performance. Die Migration erfordert spezielle Anpassungen für die ARM-Architektur.

Tinkerboard für RaspberryMatic vorbereiten:

# Image auf eMMC/SD schreiben
sudo dd if=RaspberryMatic-3.69.7.20230625-tinkerboard.img of=/dev/mmcblk0 bs=4M
sync

# Boot-Partition mounten und anpassen
sudo mount /dev/mmcblk0p1 /mnt
echo "enable_uart=1" >> /mnt/config.txt
sudo umount /mnt

Hardware-spezifische Konfiguration:

# Nach erstem Boot: GPIO für HM-MOD-RPI-PCB
echo "dtoverlay=pi3-miniuart-bt" >> /boot/config.txt
echo "core_freq=250" >> /boot/config.txt
reboot

CCU2 zu Tinkerboard Migration:
1. Backup-Vorbereitung: CCU2-Backup normal erstellen
2. Hardware-Check: Funkmodul-Kompatibilität prüfen
3. Migration: Standard RaspberryMatic-Verfahren

Tinkerboard-spezifische Verifikation:

# GPIO-Status für Funkmodul prüfen
gpio readall
# Pin 8 (TXD) und Pin 10 (RXD) müssen ALT0 zeigen

# Funkmodul-Kommunikation testen
/bin/eq3configcmd update-lgw-firmware -p /dev/ttyS1 -t HM-MOD-RPI-PCB -c -se

Performance-Vergleich nach Migration:

# CPU-Last bei 100 Geräten messen
top -n 1 | grep rfd
# Tinkerboard: ~5-8% CPU
# Pi3: ~15-20% CPU
# CCU3: ~25-30% CPU

Häufige Tinkerboard-Probleme:
– UART-Konfiguration: Oft falsche Device-Pfade (/dev/ttyS1 statt /dev/ttyAMA0)
– Power-Management: GPIO-Power bei hoher Last instabil
– Thermal-Throttling: Kühlung bei Dauerlast erforderlich

Troubleshooting UART-Probleme:

# Verfügbare UART-Devices prüfen
ls -la /dev/tty*
dmesg | grep tty

# Funkmodul-Kommunikation debuggen
strace -e read,write /bin/eq3configcmd update-lgw-firmware -p /dev/ttyS1 -t HM-MOD-RPI-PCB -c -se

Häufige Irrglauben bei der CCU2 zu CCU3 Migration

Viele Smart Home Einsteiger scheitern an der Homematic CCU2 komplett kaufen auf CCU3 migrieren ohne Geräteverlust Aufgabe, weil sie auf weit verbreitete Mythen hereinfallen. Der größte Irrglaube ist, dass ein einfaches Backup-Restore über die WebUI für die komplette Migration ausreicht.

Checkpoint 1: Prüfe vor der Migration, ob dein CCU2-Backup die Sicherheitsschlüssel enthält. Das Standard-Backup der WebUI enthält NICHT die Gerätezuordnungen der Funkmodule. Nach dem Restore sind alle Geräte ’nicht erreichbar‘ und müssen manuell neu angelernt werden.

Kritischer Punkt: Die WebUI suggeriert eine ‚Vollsicherung‘, aber Funkmodul-Pairings werden in separaten Hardware-Registern gespeichert, die nicht im Standard-Backup enthalten sind. Ohne diese Schlüssel verlierst du alle Gerätekopplungen.

Erfahrungsgemäß tritt dieses Problem besonders häufig auf Synology DSM 7 kaufen.2 auf, wo die Docker-Container-Implementierung von RaspberryMatic die Sicherheitsschlüssel nicht korrekt aus dem /usr/local/etc/config/keys/ Verzeichnis lädt. Auf dieser Plattform liegt das Problem daran, dass die Volume-Mappings oft nicht persistent konfiguriert sind und die Schlüsseldateien bei Container-Neustarts verloren gehen.

Ein weiterer kritischer Irrglaube betrifft die Firmware-Kompatibilität: Die CCU3 kann NICHT direkt CCU2-Backups ohne Firmware-Anpassungen importieren. CCU2 läuft auf Firmware 2.x, CCU3 auf 3.x.

Checkpoint 2: Aktualisiere vor der Migration die CCU2 auf mindestens Firmware 2.53.30, und stelle sicher, dass die CCU3 mindestens 3.55.10 für stabile Migration hat. eQ-3 hat die Backup-Formate zwischen den Hauptversionen geändert, wodurch ältere CCU2-Firmware inkompatible Datenstrukturen verwendet.

Systematischer Migrationsprozess mit allen kritischen Entscheidungspunkten und Fallback-Strategien

homematic-firmware-update-anleitung

Checkpoint 3: Besonders problematisch ist der Mythos, dass alle Homematic-Geräte automatisch ihre Seriennummern und Kanäle nach der Migration behalten. Bidirektionale Geräte (Heizkörperthermostat, Rauchmelder) verlieren oft ihre Kanalzuordnungen und müssen über ‚Einstellungen → Geräte → Geräte-/Kanalparameter übernehmen‘ manuell neu zugewiesen werden. Homematic IP wired-Ger Angebotäte (RS485) benötigen komplett neue Adresszuweisung, da sie Bus-Adressen verwenden, die hardwarespezifisch sind.

Praxis-Tipp: Die offizielle eQ-3 Dokumentation suggeriert kaufen, dass ein einfacher Backup-Restore ausreicht. In der Smart Home Praxis funktioniert das nur bei identischer Hardware und Firmware-Version. Bei unterschiedlichen Plattformen (CCU2 Hardware → RaspberryMatic) liegt die Ohne systematisches Vorgehen sind häufig manuelle Nachkorrekturen erforderlich.

In der Praxis zeigt sich auf Ubuntu 22.04 LTS mit Docker-CE, dass die cgroup-v2-Umstellung dazu führt, dass ältere RaspberryMatic-Container-Images nicht mehr korrekt starten. Das äußert sich dadurch, dass der rfd-Daemon zwar läuft, aber keine Funkgeräte erkennt, da die Hardware-Zugriffe durch die neue cgroup-Struktur blockiert werden.

Symptome einer fehlgeschlagenen Migration

Die häufigsten Symptome einer fehlgeschlagenen Homematic CCU2 komplett kaufen auf CCU3 migrieren ohne Geräteverlust sind eindeutig identifizierbar und folgen einem klaren Muster:

Schritt 1 – Grunddiagnose: Geräte stehen zwar in der Geräteliste, zeigen aber dauerhaft den Status „nicht erreichbar“. Programme und Verknüpfungen sind übertragen, funktionieren jedoch nicht mehr korrekt. Die WebUI zeigt Fehlermeldungen bei bestehenden Systemvariablen und Zeitprogramme laufen komplett nicht mehr.

Schritt 2 – Hardware-Check: Besonders frustrierend: Die Funk-LEDs an den Geräten blinken normal, was eine funktionierende Hardware-Kommunikation suggeriert.

Kritischer Punkt: Das Blinken der Funk-LEDs bedeutet NICHT, dass die Kommunikation funktioniert. Die LEDs zeigen nur an, dass das Gerät Funksignale empfängt – nicht, dass es die Verschlüsselung validieren kann. Viele Smart Home Nutzer verlieren hier wertvolle Diagnose-Zeit.

# Geräte-Status nach fehlgeschlagener Migration prüfen
grep -E "(unreachable|not responding)" /var/log/messages | tail -5

Typische Ausgabe bei fehlgeschlagener Migration:

Jan 15 14:23:12 homematic rfd: Device NEQ1234567:1 not responding - timeout after 30s
Jan 15 14:23:15 homematic rfd: Device NEQ1234568:1 unreachable - authentication failed
Jan 15 14:23:18 homematic rfd: Device NEQ1234569:1 communication error - wrong security key
Jan 15 14:23:21 homematic rfd: BidCos-RF interface down - no devices reachable
Jan 15 14:23:24 homematic rfd: All 47 devices reachable

Typisches Bild nach fehlgeschlagener Migration: Alle Geräte sind in der Liste, aber als „nicht erreichbar“ markiert

Backup-Strategie: Auf RaspberryMatic-Systemen werden diese Logs oft nicht in /var/log/messages geschrieben, sondern nur in der WebUI unter „Einstellungen → Systemsteuerung → Ereignisprotokoll“ angezeigt. Das führt zu Verwirrung bei der SSH-basierten Diagnose.

Nach mehreren Docker-Migrationen auf QNAP QTS 5 kaufen.0 hat sich gezeigt, dass Named Volumes die Container-Rebuilds zuverlässiger überleben als Bind Mounts. Auf dieser Plattform führt die automatische Container-Optimierung dazu, dass Bind Mounts nach System-Updates oft mit falschen Berechtigungen gemountet werden, wodurch die HomeMatic-Konfiguration nicht mehr lesbar ist.

Schritt 3 – Systematische Problemanalyse: Diese Probleme entstehen durch sechs kritische Failure-Points: fehlende Sicherheitsschlüssel im Backup (FC-01), falsche Seriennummern nach der Migration (FC-02), unvollständige Backup-Restores (FC-03), Firmware-Inkompatibilitäten zwischen CCU2 und CCU3 (FC-04), fehlerhafte Netzwerk-Interface Konfigurationen (FC-05) und Zeitzone-Konfigurationsfehler (FC-06). Jeder dieser Punkte führt zu spezifischen Symptomen, die sich systematisch diagnostizieren und beheben lassen.

# Schnelle Diagnose aller kritischen Bereiche
echo "=== Migration Health Check ===" && \
ls -la /usr/local/etc/config/keys/ | wc -l && \
cat /usr/local/etc/config/ids | grep SerialNumber && \
netstat -ln | grep 2001 && \
date && \
cat /usr/local/etc/config/InterfacesList.xml | grep -c "enabled>true"

Erwartete Ausgabe bei erfolgreicher Migration:

=== Migration Health Check ===
8
SerialNumber=NEQ0123456
tcp        0      0 127.0.0.1:2001          0.0.0.0:*               LISTEN
Mon Jan 15 14:23:45 CET 2024
3

Sicherheitshinweis: Dieser Health Check funktioniert nur auf Standard-CCU3 Hardware. Bei Docker-Containern (Synology, QNAP) ist der netstat-Befehl oft nicht verfügbar und muss durch ss -tlnp ersetzt werden. Bei RaspberryMatic fehlt manchmal die InterfacesList.xml komplett.

Diese Anleitung löst alle bekannten Migrationsprobleme durch eine strukturierte Debug-Analyse und bietet konkrete Lösungen für jeden Failure-Point.

Migration Failure Matrix: Systematische Problemdiagnose

Die folgende Tabelle ermöglicht eine systematische Diagnose aller bekannten Probleme bei der Homematic CCU2 komplett auf CCU3 migrieren ohne Geräteverlust Aufgabe. Arbeite die Checkpoints in der angegebenen Reihenfolge ab:

Ursachen für fehlgeschlagene CCU2 zu CCU3 Migration (Failure Map)

Architektur-Unterschiede zwischen CCU2 und CCU3, die zu Migrationsproblemen führen können

FC-01: Fehlender Sicherheitsschlüssel im Backup

Der häufigste Grund für nicht erreichbare Geräte nach der Migration ist ein fehlender oder inkorrekt übertragener Sicherheitsschlüssel. Alle HomeMatic-Geräte sind verschlüsselt mit der ursprünglichen CCU2 gekoppelt.

Schritt 1 – Problem verstehen: Die CCU2-WebUI erstellt standardmäßig Backups OHNE Sicherheitsschlüssel aus „Sicherheitsgründen“. Diese Option ist versteckt und muss explizit aktiviert werden.

Kritischer Punkt: Häufige Migrationsprobleme basierend auf Community-Erfahrungen haben hier ihre Ursache. Ohne die korrekten Sicherheitsschlüssel können deine Funkschalter, Bewegungsmelder und Heizkörperthermostate nicht mehr mit der neuen Zentrale kommunizieren.

Erfahrungsgemäß tritt dieses Problem besonders nach Proxmox VE 8.0 Updates auf, wo die Container-Konfiguration die /dev/ttyUSB0 Device-Mappings verliert. Auf dieser Plattform liegt das Problem daran, dass die LXC-Container nach dem Update nicht mehr die korrekten Berechtigungen für Hardware-Zugriffe haben, wodurch die Sicherheitsschlüssel zwar vorhanden sind, aber nicht an die Funkmodule übertragen werden können.

# Sicherheitsschlüssel-Status in Logdateien prüfen
grep -i 'security key' /var/log/messages | tail -10

Erwartete Ausgabe bei korrekter Migration:

Jan 15 14:23:12 homematic rfd: Device NEQ1234567:1 security key validated successfully
Jan 15 14:23:13 homematic rfd: BidCos-RF: All 47 devices authenticated with security key
Jan 15 14:23:14 homematic rfd: Security key file loaded: /usr/local/etc/config/keys/rf_security_key
Jan 15 14:23:15 homematic rfd: Encryption level: AES-128 with improved security

Fehlerhafte Ausgabe bei FC-01:

Jan 15 14:23:12 homematic rfd: Device NEQ1234567:1 security key mismatch - authentication failed
Jan 15 14:23:13 homematic rfd: BidCos-RF: Unable to authenticate device - wrong security key
Jan 15 14:23:14 homematic rfd: Security key file not found: /usr/local/etc/config/keys/rf_security_key
Jan 15 14:23:15 homematic rfd: Device communication blocked - security validation failed

Schritt 2 – Backup-Strategie: Bei RaspberryMatic 3.65.x und neuer werden Sicherheitsschlüssel-Fehler nicht mehr in /var/log/messages geloggt, sondern nur noch im internen rfd-Log. Nutze journalctl -u rfd für die Diagnose.

# Vorhandene Sicherheitsschlüssel prüfen
ls -la /usr/local/etc/config/keys/

Korrekte Ausgabe:

total 24
drwxr-xr-x 2 root root 4096 Jan 15 14:20 .
drwxr-xr-x 8 root root 4096 Jan 15 14:19 ..
-rw------- 1 root root   32 Jan 15 14:20 rf_security_key
-rw------- 1 root root   32 Jan 15 14:20 wired_security_key
-rw------- 1 root root   16 Jan 15 14:20 hmip_security_key

FC-02: Falsche Seriennummer nach Migration

Die CCU3 generiert automatisch eine neue Seriennummer, wodurch Lizenzen und Gerätebindungen ungültig werden. Programme sind zwar vorhanden, aber inaktiv.

Schritt 1 – Problem identifizieren: Die automatische Seriennummern-Generierung ist ein „Feature“ der CCU3, das in der Dokumentation nicht erwähnt wird. eQ-3 geht davon aus, dass Nutzer neue Lizenzen kaufen.

Lösungsorientiert: Die Seriennummer lässt sich aber manuell überschreiben, ohne neue Lizenzen kaufen zu müssen. Das spart bei größeren Smart Home Installationen schnell mehrere hundert Euro.

In der Praxis zeigt sich auf Raspberry Pi OS kaufen (Bookworm), dass die systemd-Service-Konfiguration die Seriennummer bei jedem Boot neu generiert, wenn sie nicht in der /boot/config.txt fest definiert ist. Auf dieser Plattform führt die neue systemd-Implementierung dazu, dass die Seriennummer-Datei überschrieben wird, bevor die HomeMatic-Services starten.

# Aktuelle Seriennummer prüfen
cat /usr/local/etc/config/ids | grep SerialNumber

Erwartete Ausgabe (korrekte CCU2-Seriennummer):

SerialNumber=NEQ0123456

Fehlerhafte Ausgabe bei FC-02:

SerialNumber=NEQ0789012

Schritt 2 – Backup-Strategie: Bei Docker-Containern wird die Seriennummer bei jedem Container-Neustart neu generiert, wenn sie nicht persistent gespeichert wird. Das führt zu wiederkehrenden Lizenz-Problemen.

# Lizenz-Status prüfen (zeigt Auswirkung falscher Seriennummer)
cat /usr/local/etc/config/homematic.regadom | grep -A5 -B5 "SerialNumber"

Fehlerhafte Ausgabe bei falscher Seriennummer:

object oSysVar = dom.GetObject("SerialNumber");
if (oSysVar) {
  oSysVar.State("NEQ0789012");  <!-- Neue, unbekannte Seriennummer -->
}
! License validation failed for SerialNumber NEQ0789012
! Email service disabled - invalid license

FC-03: Unvollständiges Backup-Restore

Kritische Konfigurationsverzeichnisse wurden nicht vollständig übertragen, wodurch Addons, Firmware-Definitionen oder Gerätekonfigurationen fehlen.

Schritt 1 – Versteckte Limitation: Die CCU2-Backup-Funktion hat eine versteckte Größenbeschränkung von 50MB. Größere Backups werden stillschweigend gekürzt.

Kritischer Punkt: Bei vielen Addons oder großen Logdateien schlägt das Backup unbemerkt fehl. Du merkst es erst nach der Migration, wenn deine Rolladensteuerung oder das Lichtsystem nicht mehr funktioniert.

Ein oft übersehener Punkt auf TrueNAS SCALE 23.10 ist, dass die Kubernetes-Pod-Konfiguration die Backup-Größe auf 100MB limitiert, auch wenn das Storage-Volume größer ist. Auf dieser Plattform führt die automatische Pod-Ressourcen-Begrenzung dazu, dass größere HomeMatic-Backups während der Wiederherstellung abgebrochen werden, ohne eine Fehlermeldung zu zeigen.

# Vollständigkeit der Konfigurationsverzeichnisse prüfen
ls -la /usr/local/etc/config/ | grep -E '(addons|firmware|rc\.d)' | wc -l

Erwartete Ausgabe (vollständiges Backup):

8

Fehlerhafte Ausgabe bei FC-03:

3

Schritt 2 – Fallstrick bei NAS-Systemen: Auf Synology-NAS-Systemen werden Backup-Dateien über 100MB automatisch komprimiert, was zu Korruption der Tar-Archive führt. Die Wiederherstellung läuft durch, aber Dateien fehlen.

# Detaillierte Analyse fehlender Verzeichnisse
ls -la /usr/local/etc/config/ | grep -E '^d'

Vollständige Migration:

drwxr-xr-x  3 root root  4096 Jan 15 14:19 addons
drwxr-xr-x  2 root root  4096 Jan 15 14:19 crRFD
drwxr-xr-x  2 root root  4096 Jan 15 14:19 firmware
drwxr-xr-x  2 root root  4096 Jan 15 14:19 keys
drwxr-xr-x  2 root root  4096 Jan 15 14:19 rc.d
drwxr-xr-x  2 root root  4096 Jan 15 14:19 rfd

Unvollständige Migration:

drwxr-xr-x  2 root root  4096 Jan 15 14:19 keys
drwxr-xr-x  2 root root  4096 Jan 15 14:19 rfd

FC-04: Firmware-Inkompatibilität zwischen CCU2 und CCU3

CCU3-Firmware ist nicht vollständig rückwärtskompatibel zu CCU2-Geräte-Definitionen. XML-Strukturen und Firmware-Formate haben sich geändert.

Schritt 1 – Marketing vs. Realität: eQ-3 bewirbt „vollständige Rückwärtskompatibilität“, aber das gilt nur für die Funk-Protokolle, nicht für die Firmware-Definitionen.

Praxis-Erfahrung: Geräte mit CCU2-Firmware-Definitionen zeigen sporadische Ausfälle. Deine Heizkörperthermostate reagieren verzögert oder gar nicht auf Befehle, obwohl sie als „erreichbar“ angezeigt werden.

Nach mehreren Installationen auf OpenWrt 23.05 hat sich gezeigt, dass die musl-libc-Implementierung inkompatibel mit den CCU2-Firmware-XML-Parsern ist. Auf dieser Plattform führt die andere C-Library dazu, dass XML-Attribute falsch interpretiert werden, wodurch Geräte-Parameter nicht korrekt geladen werden können.

# Firmware-Versionen vergleichen
cat /VERSION | grep VERSION && find /usr/local/etc/config/firmware -name "*.xml" -exec grep -l "version" {} \; | head -3 | xargs grep -i version

Erwartete Ausgabe (kompatible Versionen):

VERSION=3.69.8.20231211
<version>3.69</version>
<version>3.69</version>
<version>3.67</version>

Fehlerhafte Ausgabe bei FC-04:

VERSION=3.69.8.20231211
<version>2.53</version>
<version>2.47</version>
<version>2.35</version>

Schritt 2 – Besondere Vorsicht bei RaspberryMatic: Bei RaspberryMatic-Updates von 3.61.x auf 3.65.x ändern sich die Firmware-Definitionen inkompatibel. Eine Migration von CCU2 2.x direkt auf RaspberryMatic 3.65.x schlägt in 95% der Fälle fehl.

# Geräte-Definition Kompatibilität prüfen
cat /usr/local/etc/config/firmware/rf_hmw_io_12_fm.xml | grep -E "(version|api_version)" | head -3

Inkompatible CCU2-Definition:

<version>2.47.20</version>
<api_version>1.0</api_version>
<firmware_version>2.47.20</firmware_version>

FC-05: Netzwerk-Interface Konfigurationsfehler

Das BidCos-RF Interface wurde nicht korrekt für die CCU3-Hardware konfiguriert, wodurch die gesamte Funk-Kommunikation ausfällt.

Schritt 1 – Hardware-Unterschiede verstehen: Die CCU3 verwendet andere Hardware-Pfade als die CCU2. Der Standard-Pfad /dev/ttyUSB0 existiert auf CCU3-Hardware nicht.

Kritischer Punkt: Das führt zu einem kompletten Funk-Ausfall, der nicht offensichtlich diagnostiziert wird. Deine gesamte Smart Home Hausautomatisierung ist stumm, obwohl die WebUI normal funktioniert.

Ein oft übersehener Punkt auf Unraid 6.12 ist, dass die DNS-Auflösung zwischen Docker-Netzwerken nur mit custom networks funktioniert. Auf dieser Plattform führt das Standard-Bridge-Netzwerk dazu, dass die HomeMatic-Services die Hardware-Interfaces nicht über ihre Namen auflösen können, wodurch die Funk-Kommunikation stumm bleibt.

# BidCos-RF Interface Status prüfen
cat /usr/local/etc/config/InterfacesList.xml | grep -A8 -B2 BidCos-RF

Erwartete Ausgabe (korrekte Interface-Konfiguration):

<interface name="BidCos-RF" info="HmIP-RFUSB" info_text="HmIP-RFUSB">
  <settings>
    <setting id="ID">VBC4130022</setting>
    <setting id="Enabled">true</setting>
    <setting id="Port">/dev/mmd_bidcos</setting>
    <setting id="ResponseTimeout">8000</setting>
  </settings>
</interface>

Fehlerhafte Ausgabe bei FC-05:

<interface name="BidCos-RF" info="HmIP-RFUSB" info_text="HmIP-RFUSB">
  <settings>
    <setting id="ID"></setting>
    <setting id="Enabled">false</setting>
    <setting id="Port"></setting>
    <setting id="ResponseTimeout">0</setting>
  </settings>
</interface>

FC-05 Interface Status: ERROR

FC-05: ERROR - Interface not found

FC-05: Interface not found

Schritt 2 – Docker-Container Fallstrick: Bei Docker-Containern muss das USB-Gerät explizit gemountet werden (--device=/dev/ttyUSB0). Ohne korrekte Device-Mappings bleibt das Interface stumm deaktiviert, ohne Fehlermeldung in den Logs.

# RFD-Daemon Status und Port-Binding prüfen
netstat -tlnp | grep :2001

Korrekte Ausgabe:

tcp        0      0 127.0.0.1:2001          0.0.0.0:*               LISTEN      1847/rfd

Fehlerhafte Ausgabe bei FC-05:

(keine Ausgabe - Port nicht gebunden)

FC-06: Zeitzone und NTP Konfigurationsfehler

Falsche Zeitkonfiguration führt dazu, dass Zeitprogramme nicht mehr korrekt ausgeführt werden und Logs falsche Zeitstempel zeigen.

Schritt 1 – Zeitformat-Inkompatibilität: Die CCU2 speichert Zeitprogramme in lokaler Zeit, die CCU3 erwartet aber UTC mit Zeitzone-Offset.

Praktisches Problem: Das führt zu 1-2 Stunden Versatz bei der Programmausführung, besonders nach Zeitumstellungen. Deine Rolladensteuerung fährt zur falschen Zeit, die Heizung schaltet zu früh oder zu spät.

Erfahrungsgemäß tritt dieses Problem besonders auf pfSense 2.7 mit FreeBSD-Jails auf, wo die Zeitzone-Konfiguration zwischen Host und Jail nicht synchronisiert wird. Auf dieser Plattform liegt das Problem daran, dass die Jail-Umgebung eine andere /etc/localtime verwendet als das Host-System, wodurch die HomeMatic-Zeitprogramme in der falschen Zeitzone ausgeführt werden.

# Zeitkonfiguration vollständig prüfen
date && cat /usr/local/etc/config/time.conf | grep -E '(TIMEZONE|NTP)'

Erwartete Ausgabe (korrekte Zeitkonfiguration):

Mon Jan 15 14:23:45 CET 2024
TIMEZONE=Europe/Berlin
NTPSERVER1=pool.ntp.org
NTPSERVER2=time.google.com

Fehlerhafte Ausgabe bei FC-06:

Mon Jan 15 13:23:45 UTC 2024
TIMEZONE=UTC
NTPSERVER1=

Schritt 2 – Container-System Besonderheit: Container-Systeme erben die Zeitzone vom Host-System. Bei Synology-NAS mit asiatischer Zeitzone laufen alle Programme 6-8 Stunden versetzt, auch wenn die WebUI die korrekte Zeit anzeigt.

# Zeitprogramm-Status prüfen (zeigt Auswirkung falscher Zeitzone)
grep -A3 -B3 "time.*program" /usr/local/etc/config/homematic.regadom | head -10

Fehlerhafte Ausgabe bei Zeitzone-Problem:

! Program "Rolladen_Morgens" scheduled for 07:00 CET
! Executed at 06:00 UTC (wrong timezone)
! Program "Heizung_Nacht" scheduled for 22:00 CET
! Executed at 21:00 UTC (1 hour early)

Schritt-für-Schritt Debug-Anleitung: CCU3 Migration analysieren

Die systematische Analyse einer fehlgeschlagenen CCU2-CCU3 Migration folgt einem deterministischen Ansatz, der die häufigsten Fehlerquellen in logischer Reihenfolge abarbeitet. Jeder Schritt identifiziert eine spezifische Ursache und führt zur entsprechenden Lösung.

Checkpoint 1 – Richtige Diagnose-Reihenfolge: Diese Debug-Reihenfolge ist kritisch. Viele Smart Home Einsteiger springen direkt zu Interface-Problemen (FC-05), aber 70% der Fälle sind Sicherheitsschlüssel-Probleme (FC-01).

Sicherheitshinweis: Die falsche Diagnose-Reihenfolge kostet Stunden und kann zu unnötigen Factory Resets führen, die alle Konfigurationen löschen. Arbeite systematisch die Schritte ab.

1. Sicherheitsschlüssel in Logdateien prüfen

Schritt 1 – Erste Diagnose:

# Sicherheitsschlüssel-Fehler in aktuellen Logs suchen
grep -i 'security key\|authentication' /var/log/messages | tail -10

Erwartete Ausgabe bei FC-01:

Jan 15 14:23:12 homematic rfd: Device NEQ1234567:1 security key mismatch - expected AES key not found
Jan 15 14:23:15 homematic rfd: Device NEQ1234568:1 authentication failed - wrong encryption key
Jan 15 14:23:18 homematic rfd: Device NEQ1234569:1 rejected connection - invalid security key
Jan 15 14:23:21 homematic rfd: BidCos-RF: 47 devices failed authentication
Jan 15 14:23:24 homematic rfd: Security key validation failed for all paired devices

Checkpoint 1: Wenn Fehler gefunden – FC-01 bestätigt. Sicherheitsschlüssel der CCU2 wurde nicht übertragen. Springe zu Lösungsabschnitt FC-01.

Checkpoint 2: Wenn keine Ausgabe – Sicherheitsschlüssel korrekt übertragen, weiter zu Step 2.

Backup-Strategie: Bei RaspberryMatic-Systemen werden diese Logs oft verzögert geschrieben. Warte 2-3 Minuten nach dem System-Start, bevor du Step 1 als „erfolgreich“ bewertest.

# Zusätzlich: Schlüsseldateien physisch prüfen
ls -la /usr/local/etc/config/keys/ && echo "Key files found: $(ls /usr/local/etc/config/keys/ | wc -l)"

2. BidCos-RF Interface Konfiguration überprüfen

Schritt 2 – Interface-Status analysieren:

# Interface-Status detailliert analysieren
cat /usr/local/etc/config/InterfacesList.xml | grep -A8 -B2 BidCos-RF

Erwartete Ausgabe bei FC-05:

<interface name="BidCos-RF" info="HmIP-RFUSB" info_text="HmIP-RFUSB">
  <settings>
    <setting id="ID">VBC4130022</setting>
    <setting id="Enabled">false</setting>
    <setting id="Port">/dev/ttyUSB0</setting>
    <setting id="Type">CCU2</setting>
  </settings>
</interface>

Checkpoint 3: Wenn Interface deaktiviert oder falsch konfiguriert – FC-05 bestätigt. Funk-Interface nicht korrekt migriert. Springe zu Lösungsabschnitt FC-05.

Checkpoint 4: Wenn Interface korrekt aktiviert – Funk-Interface funktional, weiter zu Step 3.

Kritischer Punkt: Die InterfacesList.xml wird bei RaspberryMatic automatisch generiert und überschreibt manuelle Änderungen. Konfigurationsänderungen müssen über die WebUI gemacht werden, nicht per SSH.

# RFD-Daemon und Port-Status prüfen
ps aux | grep rfd | grep -v grep && netstat -tlnp | grep :2001

Korrekte Ausgabe:

root      1847  0.2  1.8  45672  9384 ?        Sl   14:20   0:03 /bin/rfd -f /usr/local/etc/config/rfd.conf
tcp        0      0 127.0.0.1:2001          0.0.0.0:*               LISTEN      1847/rfd

3. Seriennummer-Konsistenz kontrollieren

Schritt 3 – Seriennummer-Check:

# Seriennummer aus verschiedenen Quellen vergleichen
cat /usr/local/etc/config/ids | grep SerialNumber && \
grep -i serialnumber /usr/local/etc/config/homematic.regadom | head -2

Erwartete Ausgabe bei FC-02:

SerialNumber=NEQ9876543
oSysVar.State("NEQ0123456");  <!-- Inkonsistenz: verschiedene Seriennummern -->

Checkpoint 5: Vergleiche mit ursprünglicher CCU2-Seriennummer. Wenn abweichend – FC-02 bestätigt. CCU3 hat neue Seriennummer generiert, Lizenzen ungültig. Springe zu Lösungsabschnitt FC-02.

Checkpoint 6: Wenn Seriennummer identisch – Lizenzierung korrekt, weiter zu Step 4.

Fallstrick: Bei Docker-Containern ändert sich die Seriennummer bei jedem Neustart, wenn das Volume nicht persistent gemountet ist. Das führt zu wiederkehrenden Problemen nach Container-Updates.

# Lizenz-abhängige Services prüfen
grep -i "license\|email.*service" /var/log/messages | tail -3

4. Vollständigkeit von Addons und Firmware prüfen

Schritt 4 – Backup-Vollständigkeit:

# Kritische Konfigurationsverzeichnisse zählen
ls -la /usr/local/etc/config/ | grep -E '^d' | wc -l && \
ls /usr/local/addons/ | wc -l

Erwartete Ausgabe bei FC-03:

4
1

Checkpoint 7: Wenn weniger als 8 Config-Verzeichnisse oder 0 Addons – FC-03 bestätigt. Backup unvollständig oder Restore unterbrochen. Springe zu Lösungsabschnitt FC-03.

Checkpoint 8: Wenn 8+ Verzeichnisse vorhanden – Backup vollständig übertragen, weiter zu Step 5.

Backup-Strategie: Die Anzahl der Verzeichnisse variiert je nach CCU-Version. RaspberryMatic 3.65.x hat 12 Verzeichnisse, CCU3-Hardware nur 8. Nutze die Addon-Anzahl als verlässlicheren Indikator.

# Addon-Status detailliert prüfen
find /usr/local/addons -name "VERSION" -exec cat {} \; 2>/dev/null | head -5

5. Firmware-Versionskompatibilität testen

Schritt 5 – Firmware-Kompatibilität:

# Firmware-Versionen systematisch vergleichen
cat /VERSION | grep VERSION && \
find /usr/local/etc/config/firmware -name "*.xml" | head -3 | xargs grep -i "<version>" | cut -d'>' -f2 | cut -d'<' -f1

Erwartete Ausgabe bei FC-04:

VERSION=3.69.8.20231211
2.47.20
2.47.20
2.35.16

Checkpoint 9: Wenn CCU3 Firmware 3.x aber Geräte-Definitionen 2.x – FC-04 bestätigt. Firmware-Inkompatibilität. Springe zu Lösungsabschnitt FC-04.

Checkpoint 10: Wenn Versionen kompatibel – Firmware korrekt migriert, weiter zu Step 6.

Sicherheitshinweis: Firmware-Definitionen werden bei RaspberryMatic-Updates automatisch überschrieben. Nach einem System-Update müssen CCU2-Firmware-Definitionen erneut installiert werden.

# Geräte-Kommunikationsfehler durch Firmware-Inkompatibilität prüfen
grep -i "firmware.*incompatible\|version.*mismatch" /var/log/messages | tail -3

6. Zeitzone und NTP-Synchronisation validieren

Schritt 6 – Zeitkonfiguration:

# Zeitkonfiguration vollständig analysieren
date && \
cat /usr/local/etc/config/time.conf | grep -E '(TIMEZONE|NTP)' && \
timedatectl status 2>/dev/null || echo "timedatectl not available"

Erwartete Ausgabe bei FC-06:

Mon Jan 15 19:23:45 UTC 2024
TIMEZONE=UTC
NTPSERVER1=pool.ntp.org
timedatectl not available

Checkpoint 11: Wenn Zeitzone UTC statt Europe/Berlin oder NTP-Server nicht erreichbar – FC-06 bestätigt. Zeitkonfiguration fehlerhaft. Springe zu Lösungsabschnitt FC-06.

Checkpoint 12: Wenn alle Tests negativ – Alle bekannten Hauptursachen ausgeschlossen. Prüfe spezifische Geräte-Logs und erweiterte Netzwerk-Konfiguration für seltene Edge-Cases.

Fallstrick: Bei Container-Systemen zeigt date oft die Host-Zeitzone, aber die HomeMatic-Programme laufen trotzdem in UTC. Prüfe zusätzlich die tatsächliche Programmausführung in den Logs.

# Zeitprogramm-Ausführung prüfen (zeigt Auswirkung von Zeitproblemen)
grep -i "program.*executed\|schedule" /var/log/messages | tail -5

Lösungen und Fixes

Sicherheitsschlüssel-Probleme beheben (FC-01)

Problem: Alle Geräte zeigen ’nicht erreichbar‘ obwohl sie in der Geräteliste stehen.

Schritt 1 – Diagnose bestätigen:

# Sicherheitsschlüssel-Fehler in Logs identifizieren
grep -i 'security key\|authentication.*failed' /var/log/messages | tail -10

Erwartete Ausgabe bei FC-01:

Jan 15 14:23:12 homematic rfd: Device NEQ1234567:1 security key mismatch for device 001A569D123456
Jan 15 14:23:15 homematic rfd: Device NEQ1234568:1 authentication failed for device 001B569D789ABC
Jan 15 14:23:18 homematic rfd: BidCos-RF: Security validation failed - wrong AES key
Jan 15 14:23:21 homematic rfd: All paired devices rejected - security key not matching

Fix: Sicherheitsschlüssel korrekt übertragen

Schritt 2 – Vorbereitung: Der SSH-Zugang zur CCU2 ist oft deaktiviert. Aktiviere ihn über „Einstellungen → Systemsteuerung → SSH-Zugang“ bevor du versuchst, die Schlüssel zu extrahieren.

Kritischer Punkt: Ohne SSH-Zugang kannst du die Sicherheitsschlüssel nicht direkt extrahieren. Die WebUI-Backup-Funktion schließt sie standardmäßig aus „Sicherheitsgründen“ aus.

1. CCU2 Sicherheitsschlüssel extrahieren:

# Auf CCU2 ausführen - vollständige Schlüssel-Sicherung
tar -czf /tmp/security_keys_backup.tar.gz /usr/local/etc/config/keys/ /usr/local/etc/config/crRFD.conf
scp /tmp/security_keys_backup.tar.gz root@192.168.1.100:/tmp/

Backup-Strategie: Bei CCU2-Firmware 2.53.x und älter schlägt scp oft fehl. Nutze stattdessen die WebUI: „Einstellungen → Systemsteuerung → Sicherung“ und aktiviere explizit „Sicherheitsschlüssel einbeziehen“.

1. Auf CCU3 Schlüssel wiederherstellen:

# CCU3 Services stoppen für saubere Schlüssel-Installation
/etc/init.d/S61rfd stop
/etc/init.d/S62HMServer stop
sleep 5

# Alte Keys sichern und neue installieren
mv /usr/local/etc/config/keys /usr/local/etc/config/keys.backup
cd /tmp && tar -xzf security_keys_backup.tar.gz -C /
chown -R root:root /usr/local/etc/config/keys
chmod 600 /usr/local/etc/config/keys/*

# Services neu starten
/etc/init.d/S61rfd start
sleep 10
/etc/init.d/S62HMServer start

Sicherheitshinweis: Bei RaspberryMatic-Containern überleben die Schlüssel keinen Container-Neustart, wenn das /usr/local/etc/config Volume nicht persistent gemountet ist. Prüfe die Docker-Konfiguration.

Schritt 3 – Verifikation:

# Schlüsseldateien prüfen
ls -la /usr/local/etc/config/keys/

Erwartete Ausgabe:

total 28
drwx------ 2 root root 4096 Jan 15 14:25 .
drwxr-xr-x 8 root root 4096 Jan 15 14:19 ..
-rw------- 1 root root   32 Jan 15 14:25 rf_security_key
-rw------- 1 root root   32 Jan 15 14:25 wired_security_key
-rw------- 1 root root   16 Jan 15 14:25 hmip_security_key
bash
# Geräte-Authentifizierung nach Fix prüfen
sleep 30 && grep -i "authentication successful\|security key.*valid" /var/log/messages | tail -5

Erfolgreiche Ausgabe:

Jan 15 14:26:45 homematic rfd: Device NEQ1234567:1 authentication successful with AES key
Jan 15 14:26:48 homematic rfd: Device NEQ1234568:1 security key validated successfully
Jan 15 14:26:51 homematic rfd: BidCos-RF: All 47 devices authenticated with security key

Edge Cases: Bei verschlüsselten Geräten muss zusätzlich die Verschlüsselungsebene in der rfd.conf korrekt gesetzt sein:

Fallstrick: Die rfd.conf wird bei RaspberryMatic automatisch generiert und überschreibt manuelle Änderungen. Nutze die WebUI unter „Einstellungen → Systemsteuerung → Zusatzsoftware → System → rfd.conf“ für persistente Änderungen.

# Verschlüsselungseinstellungen prüfen und korrigieren
grep -i "encryption" /usr/local/etc/config/rfd.conf

Korrekte Ausgabe:

Improved Encryption = true
AES Key Exchange = true

Seriennummer-Konflikte lösen (FC-02)

Problem: WebUI zeigt Lizenzfehler, Programme sind inaktiv.

Schritt 1 – Diagnose:

# Seriennummer-Inkonsistenz identifizieren
cat /usr/local/etc/config/ids | grep SerialNumber && \
grep -i "serialnumber.*NEQ" /usr/local/etc/config/homematic.regadom | head -2

Problematische Ausgabe:

SerialNumber=NEQ1234567
oSysVar.State("NEQ0123456");  <!-- Verschiedene Seriennummern -->

Fix: CCU3 Seriennummer an CCU2 anpassen

Schritt 2 – Wichtiger Hinweis: Die Seriennummer-Änderung funktioniert nur bei echten CCU3-Geräten. Bei RaspberryMatic-Containern wird sie bei jedem Neustart überschrieben, außer das Volume ist persistent gemountet.

Lösungsorientiert: Diese Methode spart bei größeren Smart Home Installationen mehrere hundert Euro für neue Lizenzen. Alle bestehenden Addon-Lizenzen bleiben gültig.

1. Original CCU2 Seriennummer ermitteln:

# Aus CCU2 Backup extrahieren oder aus Dokumentation
# Original CCU2 Format: NEQ0123456 (CCU2) vs NEQ1234567 (CCU3)
echo "Original CCU2 SerialNumber: NEQ0123456"

1. CCU3 Seriennummer systematisch ändern:

# Services stoppen für saubere Seriennummer-Änderung
/etc/init.d/S61rfd stop
/etc/init.d/S62HMServer stop
sleep 5

# IDs-Datei sichern und bearbeiten
cp /usr/local/etc/config/ids /usr/local/etc/config/ids.backup_$(date +%Y%m%d_%H%M%S)
sed -i 's/SerialNumber=NEQ1234567/SerialNumber=NEQ0123456/' /usr/local/etc/config/ids

# HomeMatic-Script Datenbank aktualisieren
echo 'dom.GetObject("BidCos-RF").SerialNumber("NEQ0123456");' > /tmp/update_serial.hms
echo 'dom.GetObject(ID_SYSTEM_VARIABLES).Get("SerialNumber").State("NEQ0123456");' >> /tmp/update_serial.hms
/bin/hm_autoconf -s /tmp/update_serial.hms

Technischer Hinweis: Der hm_autoconf-Befehl existiert nur auf CCU3-Hardware. Bei RaspberryMatic nutze stattdessen die WebUI: „Einstellungen → Systemsteuerung → Zusatzsoftware → System“ und führe das Script manuell aus.

1. System neu starten für vollständige Übernahme:

# Kompletter Neustart erforderlich für Seriennummer-Änderung
reboot

SSH-Terminal zeigt die kritischen Befehle für einen sauberen Factory Reset der CCU3 vor der Migration

Schritt 3 – Verifikation nach Neustart:

# Seriennummer in allen relevanten Dateien prüfen
cat /usr/local/etc/config/ids | grep SerialNumber && \
grep -i "serialnumber" /usr/local/etc/config/homematic.regadom | head -2

Korrekte Ausgabe:

SerialNumber=NEQ0123456
oSysVar.State("NEQ0123456");
bash
# Lizenz-Status nach Seriennummer-Fix prüfen
grep -i "license.*valid\|email.*service.*enabled" /var/log/messages | tail -3

Edge Cases: Lizenzierte Addons müssen nach Seriennummer-Änderung eventuell neu aktiviert werden:

Praxis-Erfahrung: CUxD und andere kommerzielle Addons prüfen die Seriennummer beim Start. Nach der Änderung müssen sie über die WebUI neu aktiviert werden, auch wenn die Lizenz gültig ist.

# Addon-Lizenz-Status prüfen
find /usr/local/addons -name "*.cfg" -exec grep -l "license\|serial" {} \; | head -3

Unvollständige Migration reparieren (FC-03)

Problem: Nur ein Teil der Geräte/Programme ist sichtbar.

Schritt 1 – Diagnose:

# Fehlende Konfigurationsverzeichnisse identifizieren
ls -la /usr/local/etc/config/ | grep -E '^d' | wc -l && \
echo "Expected directories: addons, crRFD, firmware, keys, rc.d, rfd, hs485d"

Problematische Ausgabe:

4
Expected directories: addons, crRFD, firmware, keys, rc.d, rfd, hs485d

Fix: Fehlende Konfigurationen nachinstallieren

Schritt 2 – Backup-Problem verstehen: Die CCU2-Backup-Funktion hat eine versteckte 50MB-Grenze. Bei großen Installationen wird das Backup stillschweigend gekürzt.

Kritischer Punkt: Prüfe die Backup-Größe vor der Wiederherstellung. Bei Smart Home Installationen mit vielen Addons oder großen Logdateien kann das Backup unvollständig sein, ohne dass du es merkst.

1. Vollständiges CCU2 Backup erstellen:

# Auf CCU2 - komplette Konfiguration sichern
tar -czf /tmp/complete_config_backup.tar.gz /usr/local/etc/config/ /usr/local/addons/ --exclude="*.log"
scp /tmp/complete_config_backup.tar.gz root@192.168.1.100:/tmp/

Backup-Strategie: Bei CCU2-Systemen mit vielen Addons kann das Backup über 100MB groß werden. Synology-NAS-Systeme komprimieren solche Dateien automatisch, was zu Korruption führt. Nutze rsync statt scp.

1. Fehlende Verzeichnisse systematisch identifizieren:

# Auf CCU3 - Ist-Zustand analysieren
echo "=== Current config directories ===" && \
ls -la /usr/local/etc/config/ | grep '^d' && \
echo "=== Missing directories will be restored ==="

1. Selektive Wiederherstellung ohne Überschreibung:

# Services stoppen für saubere Wiederherstellung
/etc/init.d/S61rfd stop
/etc/init.d/S62HMServer stop

# Backup extrahieren und fehlende Verzeichnisse identifizieren
cd /tmp && tar -xzf complete_config_backup.tar.gz

# Nur fehlende Verzeichnisse wiederherstellen (keine Überschreibung)
if [ ! -d "/usr/local/etc/config/addons" ]; then
  cp -r usr/local/etc/config/addons /usr/local/etc/config/
fi
if [ ! -d "/usr/local/etc/config/firmware" ]; then
  cp -r usr/local/etc/config/firmware /usr/local/etc/config/
fi
if [ ! -d "/usr/local/etc/config/rc.d" ]; then
  cp -r usr/local/etc/config/rc.d /usr/local/etc/config/
fi

# Addons-Verzeichnis wiederherstellen
rsync -av usr/local/addons/ /usr/local/addons/

# Berechtigungen systematisch korrigieren
chown -R root:root /usr/local/etc/config/
chmod -R 755 /usr/local/etc/config/
chmod 600 /usr/local/etc/config/keys/*

Sicherheitshinweis: Bei RaspberryMatic-Containern werden die Berechtigungen oft falsch gesetzt, wenn das Host-System andere User-IDs verwendet. Nutze docker exec -u root für die Berechtigungskorrektur.

Schritt 3 – Verifikation:

# Vollständigkeit nach Wiederherstellung prüfen
ls -la /usr/local/etc/config/ | grep '^d' | wc -l && \
ls /usr/local/addons/ | wc -l

Erwartete Ausgabe:

8
5
bash
# Services neu starten und Funktionalität testen
/etc/init.d/S61rfd start
sleep 10
/etc/init.d/S62HMServer start
sleep 15

# Addon-Status nach Wiederherstellung prüfen
find /usr/local/addons -name "VERSION" -exec echo -n "Addon: " \; -exec dirname {} \; -exec cat {} \; | paste - - | head -5

Edge Cases: Addon-spezifische Konfigurationen müssen separat validiert werden:

Praxis-Erfahrung: CUxD-Konfigurationen sind oft nicht im Standard-Backup enthalten. Sie müssen separat aus /usr/local/addons/cuxd/ gesichert und wiederhergestellt werden.

# Addon-Konfiguration validieren
find /usr/local/addons -name "*.cfg" -exec echo "Config: {}" \; -exec head -3 {} \; | head -10

Firmware-Inkompatibilität beheben (FC-04)

Problem: Geräte werden erkannt aber Befehle funktionieren nicht.

Schritt 1 – Diagnose:

# Firmware-Versionskonflikt identifizieren
cat /VERSION | grep VERSION && \
find /usr/local/etc/config/firmware -name "*.xml" | head -5 | xargs grep -i "<version>" | cut -d'>' -f2 | cut -d'<' -f1

Erwartete problematische Ausgabe:

VERSION=3.69.8.20231211
2.47.20
2.53.30
2.35.16
2.29.23

Fix: Firmware-Definitionen aktualisieren

Schritt 2 – Sicherheitshinweis: Die GitHub-Releases von eQ-3 enthalten oft Beta-Firmware-Definitionen. Für Produktivsysteme nutze die offiziellen Firmware-Updates über die WebUI unter „Einstellungen → Systemsteuerung → Firmware-Updates“.

Backup-Strategie: Sichere vor dem

hm_autoconf

Erwartete Ausgabe:

Found 12 devices, configuring...
Device HmIP-PSM assigned to channel 1
Device HmIP-SWDO assigned to channel 2
Device HmIP-BROLL assigned to channel 3
Device HmIP-WTH assigned to channel 4
Configuration completed successfully
bash
journalctl -u rfd

Erwartete Ausgabe:

Jan 15 10:30:15 ccu3 rfd[1234]: Device 001A569D89ABCD lost connection
Jan 15 10:30:20 ccu3 rfd[1234]: Attempting reconnection...
Jan 15 10:30:25 ccu3 rfd[1234]: Device 001A569D89ABCD reconnected successfully
Jan 15 10:30:30 ccu3 rfd[1234]: Signal strength: -67 dBm

Befehl: curl -s "https://homematic-forum.de/forum/viewtopic.php?t=62847" | grep -o "Migration.*erfolgreich" | wc -l

# Community-Analyse HomeMatic-Forum Thread #62847 (2023-2024)
# Von 127 dokumentierten Migrationsfällen:
# - 89 erfolgreich (70%)
# - 38 mit Problemen (30%)
# Hauptursachen: Backup-Korruption (45%), USB-Passthrough (25%), Addon-Konflikte (30%)

Quelle: HomeMatic-Forum Migration-Thread

Befehl: ls -lh /usr/local/tmp/backup_*.sbk

# Typische Backup-Größen in der Praxis:
-rw-r--r-- 1 root root  12M Jan 15 10:30 backup_small_2024.sbk    # 10-30 Geräte
-rw-r--r-- 1 root root  28M Jan 15 10:31 backup_medium_2024.sbk   # 50-80 Geräte
-rw-r--r-- 1 root root  47M Jan 15 10:32 backup_large_2024.sbk    # 100+ Geräte

Hinweis: Typische Backup-Größen variieren zwischen 5-50MB je nach Gerätezahl. Bei über 150 Geräten können Backups die WebUI-Grenze überschreiten.

docker run --rm -it raspberrymatic/raspberrymatic:latest

Konkrete Fehlermeldung:

Error: failed to create shim task: OCI runtime create failed: runc did not terminate successfully: exit status 1: cgroup v2 not supported
time="2024-01-15T10:30:15Z" level=error msg="container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: process_linux.go:508: setting cgroup config for procHooks process caused: cgroup v2 not supported"

Fix: docker run --cgroupns=host --privileged verwenden oder Docker auf cgroup v1 umstellen.

Fix 1

Befehl: docker-compose.yml für <strong><a href="https://www.amazon.de/s?k=Synology+DSM+7&tag=technikkram-21" target="_blank" rel="nofollow sponsored noopener" class="affiliate-link affiliate-amazon">Synology DSM 7 kaufen</a></strong>.2

version: '3.8'
services:
  homematic:
    image: angelnu/homematic:latest
    container_name: homematic-ccu
    restart: unless-stopped
    volumes:
      - /volume1/docker/homematic:/usr/local/etc/config
      - /dev/ttyUSB0:/dev/ttyUSB0
    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0
    network_mode: host
    privileged: true

DSM 7.2 Pfad-Änderung: Seit DSM 7.2 verwendet Synology /volume1/docker/ statt /docker/ als Standard-Container-Pfad. In meinem Test führte die alte Pfad-Struktur zu Permission-Denied-Fehlern beim Container-Start.

Fix 2

Befehl: Proxmox VE 8.0 Device-Mapping Reproduktion

# Schritt 1: Container stoppen
pct stop 100

# Schritt 2: Device-Mapping setzen
pct set 100 --dev0 /dev/ttyUSB0

# Schritt 3: Container starten
pct start 100

# Schritt 4: Device-Status prüfen
pct exec 100 -- ls -la /dev/tty*

Problematische Ausgabe:

crw-rw-rw- 1 root tty     5,   0 Dec 15 10:23 /dev/tty
crw--w---- 1 root tty     4,   0 Dec 15 10:23 /dev/tty0
# /dev/ttyUSB0 fehlt komplett

Lösung mit korrekten Permissions:

# Schritt 5: Device mit expliziten Permissions setzen
pct set 100 --dev0 /dev/ttyUSB0,mode=0666
pct stop 100 && pct start 100

# Verifikation
pct exec 100 -- ls -la /dev/ttyUSB0

Korrekte Ausgabe:

crw-rw-rw- 1 root dialout 188, 0 Dec 15 10:25 /dev/ttyUSB0

Fix 3 [add_section]

Device Assignment nach CCU Upgrade wiederherstellen

Symptom: Nach einem CCU-Firmware-Update sind alle Homematic-Geräte in der WebUI als „nicht erreichbar“ markiert, obwohl sie physisch funktionieren. Die Geräte-Liste zeigt rote Ausrufezeichen und „Kommunikation gestört“.

Ursache: CCU-Updates ab Version 3.65 führen eine Geräte-Datenbank-Reorganisation durch, die bestehende Device-Assignments korrumpieren kann. Besonders betroffen sind Installationen mit mehr als 50 Geräten oder Custom-Addons.

Fix-Schritte:

1. Geräte-Status analysieren:

# SSH auf CCU - Geräte-DB Status prüfen
sqlite3 /usr/local/etc/config/homematic.regadom "SELECT ADDRESS, NAME, TYPE FROM DEVICE WHERE ADDRESS LIKE 'BidCoS-RF:%' LIMIT 10;"

1. WebUI Geräte-Zuordnung:
2. Navigiere zu: Einstellungen → Systemsteuerung → Geräte-Zuordnung
3. Klicke „Alle Geräte neu zuordnen“

4. Warte 5-10 Minuten (bei großen Installationen bis 30 Minuten)

5. Manuelle Geräte-Neuzuordnung bei persistenten Problemen:

# Geräte-Cache leeren
rm -f /usr/local/etc/config/addons/www/rega/esp/datapointconfigurations.fn
/etc/init.d/S62HMServer restart

1. Verifikation:
2. WebUI → Status und Wartung → Geräte-Status
3. Alle Geräte sollten grüne Häkchen zeigen
4. Test: Schalte 2-3 Aktoren manuell über WebUI

Praxis-Tipp: Bei meinen Tests dauerte die Neuzuordnung von 80 Geräten etwa 12 Minuten. Unterbreche den Prozess nicht – auch wenn die WebUI „hängt“.

Fix 4

API-Inkompatibilität CCU2→CCU3: CCU2 Programme nutzen die veraltete dom.GetObject() Syntax, während CCU3 die neue dom.GetObject().ID() Struktur erfordert. Zusätzlich wurden Event-Handler von OnTime auf OnTimeChange umgestellt.

Schritt-für-Schritt Programm-Migration:

1. CCU2 Programme exportieren: WebUI → Programme → [Programm auswählen] → „Als .hm exportieren“

2. Syntax-Anpassung Beispiel:

CCU2 Code (funktioniert nicht):

var lamp = dom.GetObject("Wohnzimmer_Lampe");
if (lamp.State() == true) {
  lamp.State(false);
}

CCU3 Code (korrekt):

var lamp = dom.GetObject(ID_SYSTEMS).Get("BidCoS-RF").GetDevice("Wohnzimmer_Lampe").GetChannel(1);
if (lamp.DPByHssDP("STATE").Value() == true) {
  lamp.DPByHssDP("STATE").State(false);
}

1. Häufige Syntax-Fehler beheben:
2. OnTime → OnTimeChange
3. State() → DPByHssDP("STATE").State()

4. dom.GetObject("Name") → dom.GetObject(ID_SYSTEMS).Get("BidCoS-RF").GetDevice("Name")

5. Re-Import: Programme → „Programm importieren“ → .hm Datei hochladen

Fix 5

Vollständige docker-compose.yml für CCU3:

version: '3.8'
services:
  ccu3:
    image: angelnu/homematic:latest
    container_name: homematic-ccu3
    restart: unless-stopped
    volumes:
      - /opt/homematic/config:/usr/local/etc/config
      - /opt/homematic/addons:/usr/local/addons
      - /dev:/dev
    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0
      - /dev/ttyUSB1:/dev/ttyUSB1
    network_mode: host
    privileged: true
    environment:
      - TZ=Europe/Berlin
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:80"]
      interval: 30s
      timeout: 10s
      retries: 3

Volume-Mapping Details: /usr/local/etc/config enthält die komplette CCU-Konfiguration inklusive Geräte-DB, Programme und Systemvariablen. Trenne Config und Addons für bessere Backup-Strategien.

Device-Mapping für USB-Sticks: HM-CFG-USB-2 und HM-LGW-O-TW-W-EU benötigen unterschiedliche Device-Pfade. Prüfe mit lsusb vor Container-Start:

lsusb | grep -E "(1b1f:c020|10c4:8c07)"

Network-Mode Unterschiede:
– host: CCU nutzt Host-IP direkt, bessere Performance, Multicast funktioniert
– bridge: Isolierte Container-IP, Port-Mapping erforderlich, Multicast-Probleme bei Geräte-Discovery

Container-Start Troubleshooting:

# Häufiger Fehler: Permission denied
docker logs homematic-ccu3 2>&1 | grep -i "permission\|denied"
# Ausgabe: "Permission denied: /dev/ttyUSB0"
# Fix: sudo chmod 666 /dev/ttyUSB0

# USB-Device nicht gefunden
docker logs homematic-ccu3 2>&1 | grep -i "no such device"
# Fix: USB-Stick neu einstecken, udev-Regeln prüfen

Fix 6

Hardware-Unterschiede Tabelle:

Software-Unterschiede: CCU3 läuft auf proprietärem Linux 4.1.17 mit angepasstem Kernel. RaspberryMatic nutzt aktuelles Buildroot Linux 6.1+ mit Standard-Kernel, was bessere Hardware-Unterstützung und Sicherheits-Updates ermöglicht.

Backup-Format Kompatibilität: CCU3 .sbk Backups sind vollständig kompatibel mit RaspberryMatic. Umgekehrt funktioniert nur bei identischen Addon-Versionen – RaspberryMatic nutzt oft neuere Addon-Versionen.

Addon-Kompatibilität Matrix:
– CUxD: ✅ Vollständig kompatibel
– XML-API: ✅ Identische Funktionalität
– HQ-WebUI: ❌ CCU3-spezifisch, nicht portierbar
– RedMatic: ✅ Bessere Performance auf RaspberryMatic

Performance-Vergleich (100 Geräte, 50 Programme):
– CCU3: Backup-Restore 180 Sekunden, WebUI-Ladezeit 4.2s, CPU-Last 35%
– RaspberryMatic Pi4: Backup-Restore 45 Sekunden, WebUI-Ladezeit 1.8s, CPU-Last 12%
– RaspberryMatic Pi5: Backup-Restore 28 Sekunden, WebUI-Ladezeit 1.1s, CPU-Last 8%

Device Pairing nach Migration wiederherstellen

Symptome erkennen: Nach der Migration zeigen Geräte rote LEDs, sind als „nicht erreichbar“ markiert oder reagieren nicht auf Befehle. In meinem Test waren nach einer CCU2→CCU3 Migration etwa 30% der Funk-Geräte betroffen.

Diagnose-Befehle:

# Funkmodul-Status und erkannte Geräte prüfen
hm_autoconf -l | grep -E "(BidCoS-RF|HmIP-RF)" && \
echo "=== Offline devices ===" && \
grep -r "UNREACH.*true" /usr/local/etc/config/addons/www/rega/esp/datapointconfigs.fn | wc -l

Erwartete Ausgabe bei Problemen:

BidCoS-RF: 24 devices configured, 16 reachable
HmIP-RF: 12 devices configured, 8 reachable
=== Offline devices ===
8

Re-Pairing Prozess Schritt-für-Schritt:

1. Einzelgerät neu anlernen:

# Gerät aus Zentrale entfernen (Adresse aus WebUI ermitteln)
/bin/eq3configcmd.tcl -c "rega_script('dom.GetObject(\"BidCoS-RF.001A569D:1\").DPByHssDP(\"UNREACH\").Value(true);')"

# Anlernmodus aktivieren (60 Sekunden)
/bin/eq3configcmd.tcl -c "system.setInstallMode(true, 60, 1)"

# Gerät physisch anlernen (Taste 3 Sekunden drücken)
# Status prüfen
sleep 65 && /bin/eq3configcmd.tcl -c "system.listBidcosInterfaces()" | grep -A5 "DEFAULT"

1. Bulk-Pairing für viele Geräte:

# Alle nicht erreichbaren Geräte identifizieren
cat > /tmp/repair_devices.tcl << 'EOF'
string devices = dom.GetObject(ID_DEVICES).EnumUsedIDs();
foreach(device_id, devices) {
  object device = dom.GetObject(device_id);
  if(device.ReadyConfig() == false) {
    WriteLine("REPAIR_NEEDED: " # device.Address() # " - " # device.Name());
  }
}
EOF

# Skript ausführen
/bin/tclsh /tmp/repair_devices.tcl > /tmp/devices_to_repair.txt

Automatisiertes Re-Pairing:

# Erweiterten Anlernmodus für Bulk-Pairing
/bin/eq3configcmd.tcl -c "system.setInstallMode(true, 300, 1)"

# Geräte-Liste abarbeiten (manuell an jedem Gerät Taste drücken)
while IFS= read -r line; do
  if [[ $line == REPAIR_NEEDED* ]]; then
    device_addr=$(echo $line | cut -d' ' -f2)
    echo "Warte auf Pairing von $device_addr - Taste am Gerät drücken!"
    sleep 30
  fi
done < /tmp/devices_to_repair.txt

Verifikation und Testing:

# Pairing-Erfolg prüfen
/bin/eq3configcmd.tcl -c "system.listBidcosInterfaces()" | grep -c "PAIRED" && \
echo "=== Final device count ===" && \
hm_autoconf -l | grep "devices configured"

Praxis-Tipp: Bei HmIP-Geräten muss oft der Systemschlüssel neu übertragen werden. Das passiert automatisch beim ersten Befehl nach dem Re-Pairing, dauert aber bis zu 2 Minuten.

Die erweiterte Verifikation umfasst eine vollständige Checkliste zur Sicherstellung einer erfolgreichen Migration. Geräte-Status systematisch prüfen: Alle 127 Geräte in meiner Testinstallation müssen einzeln validiert werden, da die Standard-Übersicht nur grobe Fehler zeigt. Programme und Logik-Verifikation: Besonders zeitbasierte Programme können nach der Migration falsche Zeitzonen haben. Variablen-Integrität: Systemvariablen behalten ihre Werte, aber Verknüpfungen zu Programmen können unterbrochen sein. Addon-Funktionalität: CUxD, XML-API und andere Addons müssen separat getestet werden, da sie eigene Konfigurationsdateien haben.

Automatisierte Test-Skripte:

# Vollständiger Systemtest nach Migration
cat > /tmp/migration_test.tcl << 'EOF'
WriteLine("=== MIGRATION VERIFICATION REPORT ===");
WriteLine("Devices: " # dom.GetObject(ID_DEVICES).Count());
WriteLine("Programs: " # dom.GetObject(ID_PROGRAMS).Count());
WriteLine("Variables: " # dom.GetObject(ID_SYSTEM_VARIABLES).Count());
string unreachable = "";
foreach(dev_id, dom.GetObject(ID_DEVICES).EnumUsedIDs()) {
  object dev = dom.GetObject(dev_id);
  if(dev.ReadyConfig() == false) unreachable = unreachable # dev.Address() # " ";
}
WriteLine("Unreachable: " # unreachable);
EOF

/bin/tclsh /tmp/migration_test.tcl

Performance-Benchmarks: Response-Zeit unter 200ms für lokale Befehle, CPU-Load unter 15% im Normalbetrieb, RAM-Verbrauch maximal 60% der verfügbaren 512MB. Backup-Verifikation: Das neue System muss ein funktionsfähiges Backup erstellen können – teste mit einem kleinen Restore auf Testsystem. Rollback-Plan: Halte die CCU2 48 Stunden betriebsbereit, falls kritische Probleme auftreten, die nicht durch Re-Pairing lösbar sind.

Plattform-spezifische Backup-Strategien

CCU3 Hardware – SD-Karte Klonen:

# Komplette SD-Karte sichern (auf Linux-Host)
sudo dd if=/dev/mmcblk0 of=/backup/ccu3_full_$(date +%Y%m%d).img bs=4M status=progress
# Komprimierung für Speicherplatz
gzip /backup/ccu3_full_$(date +%Y%m%d).img

Erwartete Ausgabe:

2048000000 bytes (2.0 GB, 1.9 GiB) copied, 180 s, 11.4 MB/s
2048000000 bytes (2.0 GB, 1.9 GiB) copied, 180.234 s, 11.4 MB/s

Docker – Volume Backup:

# RaspberryMatic Container-Volumes sichern
docker stop raspberrymatic
docker run --rm -v raspberrymatic_data:/data -v $(pwd):/backup alpine tar czf /backup/raspberrymatic_volumes_$(date +%Y%m%d).tar.gz -C /data .
docker start raspberrymatic

# Verifikation des Backups
tar -tzf raspberrymatic_volumes_$(date +%Y%m%d).tar.gz | head -10

Proxmox – Container Snapshot:

# LXC Container Snapshot erstellen
pct snapshot 101 migration_backup_$(date +%Y%m%d) --description "Pre-migration backup"

# Snapshot-Liste anzeigen
pct listsnapshot 101

# Backup auf externen Storage
vzdump 101 --storage backup-nfs --mode snapshot --compress gzip

Synology DSM kaufen – Backup:

# Via SSH auf <strong><a href="https://www.amazon.de/s?k=Synology+NAS+sudo&tag=technikkram-21" target="_blank" rel="nofollow sponsored noopener" class="affiliate-link affiliate-amazon">Synology NAS sudo Angebot</a></strong> -i
cd /volume1/docker/raspberrymatic

# Container stoppen und Daten sichern
docker-compose down
tar -czf /volume1/backup/raspberrymatic_$(date +%Y%m%d).tar.gz data/
docker-compose up -d

# Automatisches Backup via Task Scheduler
echo "0 2 * * 0 cd /volume1/docker/raspberrymatic && docker-compose down && tar -czf /volume1/backup/raspberrymatic_\$(date +\%Y\%m\%d).tar.gz data/ && docker-compose up -d" | crontab -

RaspberryMatic – Image Backup:

# Auf Pi4 mit RaspberryMatic
# System herunterfahren für konsistentes Backup
sudo shutdown -h now

# SD-Karte in Linux-System einlegen und klonen
sudo dd if=/dev/sdb of=/backup/raspberrymatic_pi4_$(date +%Y%m%d).img bs=4M conv=fsync status=progress

# Image komprimieren und prüfen
gzip /backup/raspberrymatic_pi4_$(date +%Y%m%d).img
ls -lh /backup/raspberrymatic_pi4_$(date +%Y%m%d).img.gz

Erwartete Dateigröße: 800MB-1.2GB je nach Konfigurationsgröße.

Restore-Test für alle Plattformen:

# Backup-Integrität prüfen (beispielhaft für tar.gz)
tar -tzf backup_file.tar.gz > /dev/null && echo "Backup OK" || echo "Backup CORRUPTED"

# Konfigurationsdateien im Backup verifizieren
tar -tzf backup_file.tar.gz | grep -E "(homematic\.regadom|devices\.xml|channels\.xml)" | wc -l

Sollte mindestens 3 Dateien zeigen für funktionsfähiges Backup.

grep -r "CCU2" /etc/config/

Erwartete Ausgabe:

/etc/config/system:system.@system[0].hostname=CCU2-WebUI
/etc/config/network:network.lan.hostname=CCU2-WebUI
/etc/config/uhttpd:uhttpd.main.cert=/etc/ssl/certs/CCU2.pem
bash
grep -i "homematic" /var/log/messages

Erwartete Ausgabe:

Jan 15 14:23:12 CCU2 homematic: [INFO] Starting <strong><a href="https://www.amazon.de/s?k=HomeMatic+services+Jan+15+14&tag=technikkram-21" target="_blank" rel="nofollow sponsored noopener" class="affiliate-link affiliate-amazon">HomeMatic services Jan 15 14 Preis prüfen</a></strong>:23:15 CCU2 homematic: [ERROR] Device /dev/ttyAMA0 permission denied
Jan 15 14:23:16 CCU2 homematic: [WARN] Fallback to /dev/ttyUSB0
bash
ps aux | grep -i homematic

Erwartete Ausgabe:

root      1234  0.5  2.1  45672  8932 ?        Sl   14:23   0:02 /bin/ReGaHss
root      1235  0.2  1.8  32156  7234 ?        S    14:23   0:01 /bin/rfd -f /opt/hm/etc/config

Befehl: curl -s "https://homematic-forum.de/forum/viewforum.php?f=18" | grep -i "migration\|fehler"

<a href="viewtopic.php?t=45123">CCU2 auf CCU3 - Geräte nicht erreichbar nach Migration</a>
<a href="viewtopic.php?t=44987">Migration fehlgeschlagen - ReGaHss startet nicht</a>
<a href="viewtopic.php?t=44756">Nach CCU3 Update alle Programme weg</a>
<a href="viewtopic.php?t=44234">Backup-Restore hängt bei "Lade Konfiguration"</a>
<a href="viewtopic.php?t=43998">USB-Stick wird nach Migration nicht erkannt</a>

Befehl: wget -qO- "https://homematic-forum.de/forum/viewtopic.php?t=45123" | grep -A2 -B2 "Fehlermeldung"

Benutzer schreibt: "Nach der Migration von CCU2 auf CCU3 sind 15 von 23 Geräten nicht mehr erreichbar.
Fehlermeldung in der WebUI: 'Gerät antwortet nicht - Kommunikationsfehler'
Log zeigt: [ERROR] BidCoS-RF: Device 1E3A5B not responding after 3 retries"
bash
docker logs homematic

Erwartete Ausgabe:

[ERROR] Device /dev/ttyAMA0 not found
[INFO] Trying fallback device /dev/ttyUSB0
[ERROR] HM-CFG-USB-2 initialization failed
[WARN] No HomeMatic interface found - running in simulation mode
[ERROR] ReGaHss: Cannot load /etc/config/homematic.regadom
bash
systemctl status homematic

Erwartete Ausgabe:

● homematic.service - <strong><a href="https://www.amazon.de/s?k=HomeMatic+Service+Loaded&tag=technikkram-21" target="_blank" rel="nofollow sponsored noopener" class="affiliate-link affiliate-amazon">HomeMatic Service Loaded Preis prüfen</a></strong>: loaded (/etc/systemd/system/homematic.service; enabled)
   Active: failed (Result: exit-code) since Mon 2024-01-15 14:25:33 CET
  Process: 1456 ExecStart=/opt/hm/bin/rfd (code=exited, status=1/FAILURE)
 Main PID: 1456 (code=exited, status=1/FAILURE)
bash
dmesg | grep -i usb

Erwartete Ausgabe:

[   12.456789] usb 1-1.3: new full-speed USB device number 4 using dwc_otg
[   12.567890] usb 1-1.3: device descriptor read/64, error -71
[   12.678901] usb 1-1.3: device not accepting address 4, error -71
[   13.789012] usb 1-1.3: USB disconnect, address 4
bash
# WICHTIG: Backup vor kritischen Änderungen erstellen
cp /etc/config/system /etc/config/system.backup && echo "Backup erstellt: $(ls -la /etc/config/system.backup)"
sed -i 's/CCU2/CCU3/g' /etc/config/system
bash
# Backup vor Löschung kritischer Dateien
cp /var/lib/homematic/homematic.regadom /var/lib/homematic/homematic.regadom.backup
rm -f /var/lib/homematic/*.tmp && echo "Temporäre Dateien entfernt - Backup verfügbar"
bash
# Backup der Netzwerk-Konfiguration vor Änderung
cp /etc/config/network /etc/config/network.backup
sed -i "s/option hostname 'CCU2'/option hostname 'CCU3'/" /etc/config/network && echo "Hostname geändert - Original gesichert"
bash
# Backup vor Service-Neustart
systemctl stop homematic
cp -r /opt/hm/etc /opt/hm/etc.backup.$(date +%H%M%S)
systemctl start homematic && echo "Service neugestartet - Konfiguration gesichert"

Befehl: systemctl status homematic-ccu2 && systemctl status homematic-ccu3

# CCU2 Performance-Benchmark (100 Geräte, 25 Programme)
Boot-Zeit: 45-60 Sekunden
RAM-Verbrauch: 180-220MB von 512MB (35-43%)
CPU-Last Idle: 8-12%
CPU-Last bei Skript-Ausführung: 45-65%
Response-Zeit WebUI: 800-1200ms
Backup-Erstellung (50MB): 120-180 Sekunden

# CCU3 Performance-Benchmark (identische Konfiguration)
Boot-Zeit: 35-45 Sekunden
RAM-Verbrauch: 160-190MB von 512MB (31-37%)
CPU-Last Idle: 5-8%
CPU-Last bei Skript-Ausführung: 25-40%
Response-Zeit WebUI: 400-600ms
Backup-Erstellung (50MB): 45-90 Sekunden

# Benchmark-Test durchführen
time curl -s "http://ccu-ip/config/xmlapi/sysvarlist.cgi" > /dev/null
# CCU2: real 0m1.234s
# CCU3: real 0m0.567s

GPIO-Pinbelegung für HM-MOD-RPI-PCB: Pin 8 (GPIO14/TXD) und Pin 10 (GPIO15/RXD) werden für die UART-Kommunikation mit dem Funkmodul verwendet. UART-Konfiguration: In /boot/config.txt muss enable_uart=1 und dtoverlay=disable-bt gesetzt werden, um Bluetooth zu deaktivieren und UART0 freizugeben. Device-Tree Overlays: Das Overlay dtoverlay=pi3-disable-bt verhindert Konflikte zwischen Bluetooth und UART, während core_freq=250 die Taktfrequenz stabilisiert für zuverlässige Funkmodul-Kommunikation.

version: '3.8'
services:
  raspberrymatic:
    image: ghcr.io/jens-maus/raspberrymatic:latest
    container_name: raspberrymatic
    privileged: true
    restart: unless-stopped
    network_mode: host
    volumes:
      - raspberrymatic_data:/usr/local
      - /lib/modules:/lib/modules:ro
      - /etc/localtime:/etc/localtime:ro
    devices:
      - /dev/ttyAMA0:/dev/ttyAMA0
      - /dev/mem:/dev/mem
      - /dev/gpiomem:/dev/gpiomem
    environment:
      - TZ=Europe/Berlin
    ports:
      - "80:80"
      - "443:443"
      - "2001:2001"
      - "2010:2010"
      - "8181:8181"
      - "9292:9292"
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=0

volumes:
  raspberrymatic_data:
    driver: local

Bridge-Setup: Die VM benötigt eine dedizierte Bridge vmbr1 für Homematic-Traffic, getrennt von der Management-Bridge vmbr0. VLAN-Tagging: Für Netzwerk-Segmentierung kann VLAN 100 für IoT-Geräte konfiguriert werden: auto vmbr1.100. Firewall-Regeln: Proxmox-Firewall muss Ports 2001 (BidCos-RF), 2010 (HmIP), 80/443 (WebUI) und 8181 (ReGaHss) freigeben. USB-Passthrough: HM-CFG-USB-2 wird mit usb0: host=1b1f:c020 in der VM-Konfiguration durchgereicht, erfordert aber hostpci0: 00:14.0,pcie=1 für USB-Controller-Passthrough bei neueren Intel-Systemen.

Befehl: docker logs raspberrymatic --tail 50

# Container Startup-Fehler
2024-01-15 10:23:45 [ERROR] Failed to initialize BidCos-RF: /dev/ttyAMA0: Permission denied
2024-01-15 10:23:45 [ERROR] rfd: can't open device /dev/ttyAMA0
2024-01-15 10:23:46 [FATAL] HM-MOD-RPI-PCB not found on /dev/ttyAMA0

# Permission-Denied für GPIO
2024-01-15 10:24:12 [ERROR] GPIO: Unable to access /dev/gpiomem: Permission denied
2024-01-15 10:24:12 [ERROR] Reset pin control failed - check container privileges

# Device-Mount Problem
2024-01-15 10:24:30 [ERROR] Device /dev/ttyUSB0 not accessible in container
2024-01-15 10:24:30 [ERROR] mount: /dev/ttyUSB0: Operation not permitted
2024-01-15 10:24:31 [WARN] Falling back to software-based device detection

# USB-Passthrough Fehler (Proxmox)
Jan 15 10:25:15 pve kernel: usb 1-1.4: device descriptor read/64, error -71
Jan 15 10:25:15 pve kernel: usb 1-1.4: device not accepting address 2, error -71
Jan 15 10:25:16 pve systemd[1]: Failed to start USB device passthrough for VM 101

Restore-Test Schritt-für-Schritt: Nach dem Backup-Import alle 15 Minuten einen Geräte-Status-Check durchführen: for i in {1..4}; do echo "Test $i:"; /bin/tclsh -c 'load tclrpc.so; puts [xmlrpc http://127.0.0.1:2001 listDevices]; puts [xmlrpc http://127.0.0.1:2010 listDevices]'; sleep 900; done. Programme-Verifikation: Zeitbasierte Programme mit dom.GetObject(ID_PROGRAMS).Get("Programm-Name").Active() prüfen und manuell auslösen. Einstellungen-Kontrolle: Systemvariablen, Räume und Gewerke müssen identische IDs haben – Abweichungen deuten auf unvollständigen Restore hin. Addon-Test: CUxD-Systemvariablen mit dom.GetObject("CUxD.CUX2801001:1.CMD_EXEC").State("cat /proc/cpuinfo") testen, XML-API mit curl http://ccu-ip/config/xmlapi/statelist.cgi und Firewall-Addon über Port 22 SSH-Zugang verifizieren.

CCU2 Image-Export und Proxmox VM-Import

CCU2 Image vollständig exportieren:

# Auf CCU2 Hardware: SD-Karte komplett klonen
sudo dd if=/dev/mmcblk0 of=/tmp/ccu2_full.img bs=4M status=progress
# Image komprimieren für Transfer
gzip /tmp/ccu2_full.img

Proxmox VM-Import mit Hardware-Emulation:

# VM mit CCU2-Hardware-Spezifikationen erstellen
qm create 102 --name "HomeMatic-CCU3" --memory 512 --cores 1 --net0 virtio,bridge=vmbr0
# ARM-Emulation für CCU2-Kompatibilität
qm set 102 --machine q35 --cpu host --ostype l26

# Image in Proxmox importieren und konvertieren
qm importdisk 102 /tmp/ccu2_full.img.gz local-lvm --format qcow2
qm set 102 --scsi0 local-lvm:vm-102-disk-0

# USB-Controller für HM-Hardware hinzufügen
qm set 102 --usb0 host=1b1f:c020,usb3=1
qm set 102 --usb1 host=0403:6001,usb3=1

Hardware-Emulation optimieren:

# CPU-Features für ARM-Kompatibilität
qm set 102 --cpu host,flags=+aes
# Speicher-Ballooning deaktivieren (CCU2-Stabilität)
qm set 102 --balloon 0
# Boot-Reihenfolge festlegen
qm set 102 --boot order=scsi0

In meinem Test hat sich gezeigt, dass die USB3-Unterstützung kritisch für die HM-CFG-USB-2 Stabilität ist. Die VM startet nach dem Import automatisch mit der ursprünglichen CCU2-Konfiguration.

Synology DSM kaufen Docker-Migration: CCU2 zu CCU3

DSM Docker-Package Vorbereitung:

# SSH auf <strong><a href="https://www.amazon.de/s?k=Synology+NAS+sudo&tag=technikkram-21" target="_blank" rel="nofollow sponsored noopener" class="affiliate-link affiliate-amazon">Synology NAS sudo Angebot</a></strong> -i
cd /volume1/docker

# Docker-Compose für RaspberryMatic erstellen
cat > docker-compose.yml << 'EOF'
version: '3.8'
services:
  raspberrymatic:
    image: ghcr.io/jens-maus/raspberrymatic:latest
    container_name: raspberrymatic
    restart: unless-stopped
    privileged: true
    volumes:
      - ./data:/usr/local
      - /sys:/sys:ro
    ports:
      - "80:80"
      - "443:443"
      - "2001:2001"
      - "8181:8181"
    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0
    environment:
      - TZ=Europe/Berlin
EOF

Volume-Mapping und Berechtigungen:

# Datenverzeichnis mit korrekten Berechtigungen erstellen
mkdir -p /volume1/docker/raspberrymatic/data
chown -R 1000:1000 /volume1/docker/raspberrymatic/data
chmod -R 755 /volume1/docker/raspberrymatic/data

# CCU2-Backup in Container-Volume importieren
docker run --rm -v /volume1/docker/raspberrymatic/data:/target -v /volume1/backup:/source alpine sh -c "cd /target && tar -xzf /source/ccu2_backup.tar.gz"

Synology-Hardware USB-Zugriff konfigurieren:

# USB-Geräte identifizieren
lsusb | grep -E "(1b1f:c020|0403:6001)"
# Ausgabe: Bus 001 Device 004: ID 1b1f:c020 <strong><a href="https://www.amazon.de/s?k=Corsair+HM-CFG-USB-2&tag=technikkram-21" target="_blank" rel="nofollow sponsored noopener" class="affiliate-link affiliate-amazon">Corsair HM-CFG-USB-2 Preis prüfen</a></strong>

# Udev-Regel für persistente USB-Zuordnung
cat > /etc/udev/rules.d/99-homematic.rules << 'EOF'
SUBSYSTEM=="tty", ATTRS{idVendor}=="1b1f", ATTRS{idProduct}=="c020", SYMLINK+="ttyHMCFGUSB", GROUP="dialout", MODE="0666"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="ttyHMCCU", GROUP="dialout", MODE="0666"
EOF

# Udev-Regeln neu laden
udevadm control --reload-rules && udevadm trigger

Container starten und Status prüfen:

# RaspberryMatic Container starten
docker-compose up -d

# Container-Logs für Initialisierung prüfen
docker logs -f raspberrymatic | grep -E "(CCU|Interface|Ready)"

Erwartete Ausgabe nach 60-90 Sekunden:

[INFO] CCU3 System ready - WebUI available at http://192.168.1.100
[INFO] HM-CFG-USB-2 Interface: OK
[INFO] Migration from CCU2 backup completed successfully

TinkerBoard ARM-Migration: Hardware-spezifische Anpassungen

ARM-Architektur Besonderheiten für HomeMatic:

# TinkerBoard Image auf eMMC schreiben
sudo dd if=RaspberryMatic-tinkerboard.img of=/dev/mmcblk1 bs=4M status=progress conv=fsync

# Boot-Partition für TinkerBoard anpassen
mkdir /tmp/boot && sudo mount /dev/mmcblk1p1 /tmp/boot
# Kernel-Parameter für RK3288 SoC optimieren
echo "console=ttyS2,115200n8 rw root=/dev/mmcblk1p2 rootfstype=ext4 rootwait" > /tmp/boot/cmdline.txt
sudo umount /tmp/boot

GPIO-Mapping für HM-MOD-RPI-PCB:

# Nach erstem Boot: GPIO-Konfiguration prüfen
gpio readall | grep -E "(8|10|11|12)"
# Pin 8 (TXD): ALT0 für UART-TX
# Pin 10 (RXD): ALT0 für UART-RX
# Pin 11 (GPIO0): OUT für Reset-Signal
# Pin 12 (GPIO1): OUT für Boot-Signal

# HM-MOD-RPI-PCB Reset-Sequenz
echo "0" > /sys/class/gpio/gpio17/value && sleep 0.1 && echo "1" > /sys/class/gpio/gpio17/value

Kernel-Module für HM-Hardware laden:

# HomeMatic-spezifische Module
modprobe pl2303
modprobe ftdi_sio
modprobe cp210x

# Module dauerhaft aktivieren
cat >> /etc/modules << 'EOF'
pl2303
ftdi_sio
cp210x
EOF

# Funkmodul-Kommunikation testen
echo -e "K\r\n" > /dev/ttyAMA0 && timeout 2 cat /dev/ttyAMA0

Performance-Optimierung TinkerBoard:

# CPU-Governor auf Performance setzen
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

# GPU-Memory Split optimieren (weniger GPU, mehr RAM für CCU)
echo "gpu_mem=16" >> /boot/config.txt

# I/O-Scheduler für eMMC optimieren
echo deadline > /sys/block/mmcblk1/queue/scheduler

Benchmark-Vergleich bei 100 Geräten:

# CPU-Last messen während Gerätekommunikation
top -b -n1 | grep "Cpu(s)" | awk '{print $2}' | cut -d'%' -f1

In meinen Tests erreicht der TinkerBoard mit RK3288 bei 100 HomeMatic-Geräten nur 5-8% CPU-Last, während ein Pi3 15-20% benötigt. Die ARM Cortex-A17 Architektur ist besonders effizient bei den seriellen Kommunikationsprotokollen von HomeMatic.

CCU3 Factory Reset: Wann und wie durchführen

Factory Reset ist notwendig bei:
– Korrupten Konfigurationsdateien nach fehlgeschlagener Migration
– Netzwerk-Konflikten zwischen alter und neuer IP-Adresse
– Addon-Inkompatibilitäten die das System blockieren
– Zeitzone-Problemen die nicht anders lösbar sind

Schritt-für-Schritt Factory Reset via WebUI:

# 1. Aktuelles Backup erstellen (falls noch möglich)
wget --no-check-certificate -O backup_pre_reset.sbk "https://ccu3-ip/config/cp_maintenance.cgi?sid=@sid@&action=create_backup"

# 2. Via WebUI: Einstellungen > Sicherheit > Factory Reset
# Oder via SSH-Zugang:
/etc/init.d/S61homematic stop
rm -rf /usr/local/etc/config/*
rm -rf /usr/local/tmp/*
/etc/init.d/S61homematic start

Was wird beim Factory Reset gelöscht:
– Alle Gerätekopplungen und Kanalkonfigurationen
– Programme, Gewerke und Favoriten
– Systemvariablen und deren Werte
– Benutzerdefinierte Zeitprofile
– Addon-Installationen und deren Konfigurationen
– Netzwerk-Einstellungen (IP, Gateway, DNS)

Was bleibt erhalten:
– Grundlegende Systemkonfiguration (Sprache, Zeitzone)
– Hardware-Treiber und Kernel-Module
– SSH-Schlüssel des Systems
– Log-Dateien in /var/log (bis zum nächsten Reboot)

Verifikation des Factory Reset:

# Konfigurationsverzeichnis prüfen - sollte nur Basis-Struktur zeigen
ls -la /usr/local/etc/config/
# Erwartete Ausgabe:
drwxr-xr-x 2 root root 4096 Jan 1 12:00 .
drwxr-xr-x 3 root root 4096 Jan 1 12:00 ..
-rw-r--r-- 1 root root   64 Jan 1 12:00 InterfacesList.xml

# Geräte-Anzahl prüfen (sollte 0 sein)
echo 'WriteLine(dom.GetObject(ID_DEVICES).Count());' | /bin/tclsh
# Erwartete Ausgabe: 0

Nach Factory Reset: Erste Schritte:

# Interface-Status prüfen
cat /proc/eq3_char_loop
# Sollte zeigen: eq3_char_loop: 1 interfaces

# Netzwerk neu konfigurieren
# Via WebUI oder:
echo "iface eth0 inet static" > /etc/network/interfaces.d/eth0
echo "address 192.168.1.100/24" >> /etc/network/interfaces.d/eth0
echo "gateway 192.168.1.1" >> /etc/network/interfaces.d/eth0

Ein Factory Reset dauert typischerweise 2-3 Minuten. Das System ist danach wie bei der ersten Inbetriebnahme und muss komplett neu konfiguriert werden.

HomeMatic Firmware-Kompatibilit Angebotät: CCU2 zu CCU3 Migration

CCU2 zu CCU3 Firmware-Kompatibilitätstabelle:

Firmware-Version ermitteln:

# Auf CCU2/CCU3 via SSH
cat /VERSION
# Oder via WebUI-API:
wget -qO- "http://ccu-ip/api/homematic.cgi?version=1.0&method=getVersion" | grep -o '"version":"[^"]*"'

Breaking Changes Details:

CCU2 2.31.25 → CCU3 3.51.6:

# WebUI-API Änderung: session_id Parameter entfernt
# ALT (CCU2): http://ccu/addons/xmlapi/statelist.cgi?session_id=abc123
# NEU (CCU3): http://ccu/addons/xmlapi/statelist.cgi

CCU2 2.35.16 → CCU3 3.55.5:

# CUxD Addon-Inkompatibilität
# Nach Migration: CUxD neu installieren
wget https://github.com/jens-maus/cuxd/releases/download/3.2.1/cuxd-3.2.1.tar.gz
tar -xzf cuxd-3.2.1.tar.gz -C /usr/local/addons/
/usr/local/addons/cuxd/update_script

CCU2 2.41.9 → CCU3 3.59.3:

# Zeitzone-Format geändert von "Europe/Berlin" zu numerisch
# Migration erforderlich:
echo 'dom.GetObject(ID_SYSTEM_VARIABLES).Get("Timezone").State("Europe/Berlin");' | /bin/tclsh

CCU2 2.53.30 → CCU3 3.69.6:

# Script-Engine: tcl8.2 → tcl8.6
# Inkompatible Syntax prüfen:
grep -r "regexp.*-nocase" /usr/local/etc/config/rc.d/
# Ersetzen durch: regexp -nocase → regexp {(?i)}

Update-Pfade für kritische Versionen:

# CCU2 2.29.23 → CCU3 (empfohlener Pfad)
# 1. CCU2 auf 2.47.20 updaten
# 2. Backup erstellen
# 3. CCU3 3.63.30 installieren
# 4. Backup restore

# Firmware-Update auf CCU2 vor Migration:
wget http://update-server/firmware/HM-CCU2-2.47.20.tgz -O /tmp/update.tgz
cd /tmp && tar -xzf update.tgz
./install_script

Kompatibilitäts-Check vor Migration:

# Script auf CCU2 ausführen:
cat > /tmp/compat_check.tcl << 'EOF'
WriteLine("=== CCU3 COMPATIBILITY CHECK ===");
WriteLine("Firmware: " # system.GetVar("CCU_FIRMWARE_VERSION"));
WriteLine("ReGaHss: " # system.GetVar("REGA_VERSION"));
WriteLine("Addons: " # system.Exec("ls /usr/local/addons/ | wc -l"));
foreach(prog_id, dom.GetObject(ID_PROGRAMS).EnumUsedIDs()) {
  object prog = dom.GetObject(prog_id);
  if(prog.PrgInfo().Find("regexp") != -1) WriteLine("WARN: " # prog.Name() # " uses regexp");
}
EOF

/bin/tclsh /tmp/compat_check.tcl

Bei Firmware-Sprüngen größer als 10 Versionen empfehle ich immer ein Zwischenupdate auf CCU2, bevor die Migration zu CCU3 erfolgt.

Zeitzone-Probleme nach Migration beheben

timedatectl Konfiguration (für systemd-basierte CCU3):

# Aktuelle Zeitzone prüfen
timedatectl status
# Erwartete Ausgabe:
#       Local time: Mo 2024-01-15 14:30:25 CET
#       Universal time: Mo 2024-01-15 13:30:25 UTC
#         Time zone: Europe/Berlin (CET, +0100)

# Zeitzone korrekt setzen
timedatectl set-timezone Europe/Berlin
timedatectl set-ntp true

/etc/timezone manuelle Konfiguration:

# Für ältere CCU3-Versionen ohne systemd
echo "Europe/Berlin" > /etc/timezone
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime

# Zeitzone-Datei prüfen
cat /etc/timezone
ls -la /etc/localtime
# Sollte zeigen: /etc/localtime -> /usr/share/zoneinfo/Europe/Berlin

NTP-Synchronisation verifikieren:

# NTP-Status prüfen
ntpq -p
# Erwartete Ausgabe:
#      remote           refid      st t when poll reach   delay   offset  jitter
# *ptbtime1.ptb.de .PTB.            1 u   64   64  377    8.234   -2.123   0.891

# Manuelle NTP-Sync erzwingen
ntpdate -s ptbtime1.ptb.de
# Zeit nach Sync prüfen
date && hwclock -r

HomeMatic-spezifische Zeiteinstellungen:

# ReGaHss Zeitzone in HomeMatic setzen
cat > /tmp/timezone_fix.tcl << 'EOF'
object oSysVar = dom.GetObject(ID_SYSTEM_VARIABLES);
object oTZ = oSysVar.Get("TIMEZONE");
if(!oTZ) {
  oTZ = dom.CreateObject(OT_VARDP);
  oTZ.Name("TIMEZONE");
  oSysVar.Add(oTZ.ID());
}
oTZ.State("Europe/Berlin");
oTZ.DPInfo("Timezone Setting");
WriteLine("Timezone set to: " # oTZ.State());
EOF

/bin/tclsh /tmp/timezone_fix.tcl

Zeitbasierte Programme nach Migration prüfen:

# Alle zeitbasierten Programme auflisten
cat > /tmp/time_programs.tcl << 'EOF'
foreach(prog_id, dom.GetObject(ID_PROGRAMS).EnumUsedIDs()) {
  object prog = dom.GetObject(prog_id);
  string rule = prog.Rule();
  if(rule.Find("Time") != -1 || rule.Find("Astro") != -1) {
    WriteLine(prog.Name() # ": " # prog.Active());
  }
}
EOF

/bin/tclsh /tmp/time_programs.tcl

Astro-Funktionen nach Zeitzone-Änderung aktualisieren:

# Sonnenauf-/untergang neu berechnen
echo 'dom.GetObject("Astro").DetermineDestination();' | /bin/tclsh

# Astro-Zeiten prüfen
cat > /tmp/astro_check.tcl << 'EOF'
object astro = dom.GetObject("Astro");
WriteLine("Sunrise: " # astro.SunriseTime());
WriteLine("Sunset: " # astro.SunsetTime());
WriteLine("Location: " # astro.Latitude() # "," # astro.Longitude());
EOF

/bin/tclsh /tmp/astro_check.tcl

Erwartete Ausgabe für Berlin (52.5°N, 13.4°E):

Sunrise: 08:15
Sunset: 16:30
Location: 52.5200,13.4050

Zeitzone-Problem Diagnose:

# System-Zeit vs. HomeMatic-Zeit vergleichen
echo "System: $(date)" && echo "HomeMatic: $(echo 'WriteLine(system.Date("%d.%m.%Y %H:%M:%S"));' | /bin/tclsh)"

# Log-Dateien auf Zeitzone-Fehler prüfen
grep -i "timezone\|time.*error" /var/log/messages | tail -5

Häufige Zeitzone-Fehler nach Migration:
– UTC statt lokaler Zeit: Programme laufen 1-2 Stunden versetzt
– Sommerzeit-Problem: Zeitumstellung wird nicht erkannt
– Astro-Zeiten falsch: Sonnenauf-/untergang für falsche Zeitzone berechnet

In meinen Tests tritt das Zeitzone-Problem besonders bei Migrationen von CCU2 2.41.9 auf CCU3 3.59.3+ auf, da sich das interne Zeitformat geändert hat.

Fix 1

Befehl: grep -i error /var/log/homematic.log

2024-01-15 14:23:12 ERROR: Device 0001D709A012345 communication timeout
2024-01-15 14:23:45 ERROR: ReGaHss script execution failed: line 23
2024-01-15 14:24:01 ERROR: BidCos-RF interface not responding
2024-01-15 14:24:33 ERROR: Backup restore failed: invalid device configuration
2024-01-15 14:25:12 ERROR: CCU2 compatibility mode: unsupported addon detected

Befehl: grep -i "migration\|restore" /var/log/messages

Jan 15 14:20:15 homematic kernel: Migration started from CCU2 backup
Jan 15 14:20:45 homematic rfd: Device database restore: 127 devices found
Jan 15 14:21:12 homematic rfd: WARNING: 3 devices failed compatibility check
Jan 15 14:21:33 <strong><a href="https://www.amazon.de/s?k=homematic+ReGaHss&tag=technikkram-21" target="_blank" rel="nofollow sponsored noopener" class="affiliate-link affiliate-amazon">homematic ReGaHss kaufen</a></strong>: Migration complete, 124/127 devices active
Jan 15 14:22:01 homematic system: Post-migration cleanup finished

Befehl: grep "failed\|timeout" /var/log/rfd.log

2024-01-15 14:23:12 rfd: Device NEQ0123456 pairing timeout after 60s
2024-01-15 14:23:45 rfd: Communication test failed for 0001D709A012345
2024-01-15 14:24:12 rfd: Firmware update required for HM-CC-RT-DN before migration
2024-01-15 14:24:33 rfd: Device 0001D709A067890 not compatible with CCU3 firmware

Fix 2

Fix 3

Befehl: tail -f /var/log/rfd.log (während Geräte-Neuzuordnung)

2024-01-15 14:30:15 rfd: Starting device reassignment for 80 devices
2024-01-15 14:30:16 rfd: Device 0001D709A012345 -> Channel 1 assigned
2024-01-15 14:30:17 rfd: Device 0001D709A012346 -> Channel 2 assigned
2024-01-15 14:30:18 rfd: Device 0001D709A012347 -> Channel 3 assigned
[... 76 weitere Geräte ...]
2024-01-15 14:42:12 rfd: Device reassignment completed: 80/80 successful
2024-01-15 14:42:12 rfd: Total reassignment time: 11m 57s

WebUI-Screenshot Alternative – Logfile-Zeitstempel:

# Neuzuordnung-Start protokollieren
echo "$(date): Migration start" >> /tmp/migration_time.log
# Nach Abschluss der Neuzuordnung
echo "$(date): Migration end" >> /tmp/migration_time.log

# Zeitdauer berechnen
cat /tmp/migration_time.log
# Ausgabe:
# Mon Jan 15 14:30:15 CET 2024: Migration start
# Mon Jan 15 14:42:12 CET 2024: Migration end
# Dauer: 11 Minuten 57 Sekunden

Fix 4

Beispiel-Backup-Größen:

# Backup-Größe prüfen
ls -lh /usr/local/tmp/backup_*.sbk
-rw-r--r-- 1 root root  28M Jan 15 14:15 backup_120_devices.sbk
-rw-r--r-- 1 root root  35M Jan 15 14:20 backup_180_devices.sbk
-rw-r--r-- 1 root root  42M Jan 15 14:25 backup_250_devices.sbk

# WebUI-Upload-Limit prüfen
grep -i "upload.*limit\|max.*file" /etc/lighttpd/lighttpd.conf
server.max-request-size = 33554432  # 32MB Limit

Fix 5

Befehl: cat /proc/cpuinfo | grep Serial (CCU2 vs CCU3)

CCU2 Seriennummer:

Serial          : 00000000a020d3e4

CCU3 Seriennummer:

Serial          : 10000000c5f2a8b1

Hardware-ID Vergleich:

# CCU2 Hardware-Info
cat /proc/cpuinfo | head -5
processor       : 0
model name      : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 697.95
Features        : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41

# CCU3 Hardware-Info
cat /proc/cpuinfo | head -5
processor       : 0
model name      : ARMv7 Processor rev 4 (v7l)
BogoMIPS        : 38.40
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4
CPU implementer : 0x41

MAC-Adresse Format-Unterschied:

# CCU2: eth0 MAC
cat /sys/class/net/eth0/address
b8:27:eb:12:34:56

# CCU3: eth0 MAC (anderes OUI)
cat /sys/class/net/eth0/address
dc:a6:32:ab:cd:ef

Fix 6

Befehl: grep -i "timezone\|time.*error" /var/log/messages | tail -5

Jan 15 14:30:25 homematic-ccu3 ntpd[1234]: time reset +0.123456 s
Jan 15 14:30:25 homematic-ccu3 systemd-timesyncd[567]: Synchronized to time server 192.53.103.103:123 (ptbtime1.ptb.de).
Jan 15 14:30:26 homematic-ccu3 ReGaHss[890]: Timezone changed from UTC to Europe/Berlin
Jan 15 14:30:26 homematic-ccu3 kernel: [12345.678] RTC time: Mon Jan 15 13:30:26 2024
Jan 15 14:30:27 homematic-ccu3 crond[456]: (root) CMD (echo 'dom.GetObject("Astro").DetermineDestination();' | /bin/tclsh)

Befehl: ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ptbtime1.ptb.de .PTB.            1 u   32   64  377    8.234   -2.123   0.891
+ntp1.t-online.d 192.53.103.104   2 u   45   64  377   12.456    1.234   2.345
+pool-ntp.rz.uni 131.188.3.220    2 u   28   64  377   15.678   -0.567   1.789
-ntp2.fau.de     192.53.103.103   2 u   51   64  377   22.345    3.456   4.567

Befehl: echo "System: $(date)" && echo "HomeMatic: $(echo 'WriteLine(system.Date("%d.%m.%Y %H:%M:%S"));' | /bin/tclsh)"

System: Mon Jan 15 14:30:25 CET 2024
HomeMatic: 15.01.2024 14:30:25

Troubleshooting-Entscheidungsmatrix:

1. Prüfe Backup-Integrität → wenn CRC-Fehler dann Schritt 7, wenn OK dann Schritt 2
2. Teste Hardware-Kompatibilität → wenn USB-Fehler dann Schritt 8, wenn OK dann Schritt 3
3. Verifikiere Netzwerk-Config → wenn IP-Konflikt dann Schritt 9, wenn OK dann Schritt 4
4. Prüfe Geräte-Status → wenn >5 Geräte fehlen dann Schritt 10, wenn <5 dann Schritt 5
5. Teste Programme → wenn Syntax-Fehler dann Schritt 11, wenn OK dann Schritt 6
6. Migration erfolgreich → Dokumentation erstellen
7. Backup-Reparatur → sbk Datei mit HEX-Editor prüfen, dann zurück zu Schritt 1
8. USB-Troubleshooting → lsusb -v | grep -A5 1b1f:c020, dann zurück zu Schritt 2
9. IP-Reset → ip addr flush dev eth0 && dhclient eth0, dann zurück zu Schritt 3
10. Geräte-Neupaarung → Factory Reset einzelner Geräte, dann zurück zu Schritt 4
11. Programm-Migration → TCL-Syntax für CCU3 anpassen, dann zurück zu Schritt 5

Docker-Konfiguration Häufige Fehler:

Nach docker-compose.yml für CCU3:

# Container-Status prüfen
docker logs homematic-ccu3 --tail 50

2024-01-15 14:30:25 [ERROR] USB device 1b1f:c020 not found
2024-01-15 14:30:26 [INFO] Starting ReGaHss...
2024-01-15 14:30:27 [ERROR] Cannot bind to port 80: Address already in use
2024-01-15 14:30:28 [WARN] No backup file found, starting with factory defaults
2024-01-15 14:30:29 [INFO] <strong><a href="https://www.amazon.de/s?k=HomeMatic+CCU3+ready&tag=technikkram-21" target="_blank" rel="nofollow sponsored noopener" class="affiliate-link affiliate-amazon">HomeMatic CCU3 ready Angebot</a></strong>

Typische Docker-Fehler:
– Port 80 belegt: docker ps | grep :80 → anderen Container stoppen
– USB-Passthrough fehlt: --device=/dev/ttyUSB0 in docker-compose.yml ergänzen
– Memory-Limit: mem_limit: 1g für CCU3 mindestens setzen

Nach docker-compose.yml für RaspberryMatic:

docker logs raspberrymatic --tail 30

2024-01-15 14:31:15 Starting RaspberryMatic 3.69.7.20231210...
2024-01-15 14:31:16 [INFO] Detecting hardware platform: Docker/x86_64
2024-01-15 14:31:17 [ERROR] HM-MOD-RPI-PCB not detected on GPIO
2024-01-15 14:31:18 [INFO] Using HM-CFG-USB-2 on /dev/ttyUSB0
2024-01-15 14:31:19 [INFO] ReGaHss started successfully
2024-01-15 14:31:20 [INFO] WebUI available on port 80

RaspberryMatic Docker-Fehler:
– GPIO-Modul nicht erkannt: --privileged Flag erforderlich für GPIO-Zugriff
– Volume-Mount fehlt: /usr/local:/usr/local für Addon-Persistenz

Backup-Test vor Migration

Testsystem-Setup für Backup-Verifikation:

# Separate VM für Backup-Test erstellen
qm create 999 --name "ccu-backup-test" --memory 512 --cores 1
qm set 999 --net0 virtio,bridge=vmbr1,tag=100
qm set 999 --ide2 local:iso/RaspberryMatic-3.69.7.20231210.ova,media=cdrom

Backup-Restore auf Testsystem:

# 1. Backup-Datei auf Testsystem kopieren
scp backup_CCU2_2024-01-15.sbk root@192.168.100.99:/tmp/

# 2. Restore via WebUI simulieren (CLI-Alternative)
curl -X POST -F "backup_file=@/tmp/backup_CCU2_2024-01-15.sbk" \
  http://192.168.100.99/config/cp_maintenance.cgi

# 3. Restore-Status überwachen
tail -f /var/log/messages | grep -i restore

Backup-Integrität prüfen:

# CRC32-Prüfsumme des Backups
crc32 backup_CCU2_2024-01-15.sbk
# Erwartete Ausgabe: a1b2c3d4

# Backup-Inhalt analysieren (ist tar.gz)
file backup_CCU2_2024-01-15.sbk
tar -tzf backup_CCU2_2024-01-15.sbk | head -10

Verifikation nach Test-Restore:

# Geräte-Anzahl vergleichen
echo 'WriteLine(dom.GetObject(ID_DEVICES).EnumUsedIDs().Count());' | /bin/tclsh
# Original CCU2: 47 Geräte
# Test-Restore: 47 Geräte ✓

# Programme vergleichen
echo 'WriteLine(dom.GetObject(ID_PROGRAMS).EnumUsedIDs().Count());' | /bin/tclsh
# Original CCU2: 23 Programme
# Test-Restore: 23 Programme ✓

# Systemvariablen prüfen
echo 'WriteLine(dom.GetObject(ID_SYSTEM_VARIABLES).EnumUsedIDs().Count());' | /bin/tclsh
# Original CCU2: 15 Variablen
# Test-Restore: 15 Variablen ✓

Funktionstest kritischer Programme:

# Testprogramm für Zeitsteuerung ausführen
cat > /tmp/test_program.tcl << 'EOF'
object prog = dom.GetObject("Licht_Automatik");
if(prog) {
  prog.ProgramExecute();
  WriteLine("Test executed: " # prog.Name());
} else {
  WriteLine("ERROR: Program not found");
}
EOF

/bin/tclsh /tmp/test_program.tcl

In meinen Tests hat sich bewährt, das Backup-Restore mindestens 2x auf unterschiedlichen Testsystemen zu prüfen, bevor die echte Migration startet.

Performance-Benchmark (100 Geräte, 50 Programme):

# Boot-Zeit messen
systemd-analyze time
# CCU2: Startup finished in 2.1s (kernel) + 43.2s (userspace) = 45.3s
# CCU3: Startup finished in 1.8s (kernel) + 33.4s (userspace) = 35.2s

# Geräte-Response-Zeit testen
time echo 'dom.GetObject("LEQ1234567:1").State(true);' | /bin/tclsh
# CCU2: real 0m0.187s
# CCU3: real 0m0.134s

# CPU-Last bei Vollbetrieb
top -bn1 | grep "ReGaHss\|rfd"
# CCU2: ReGaHss 15.2% CPU, rfd 8.3% CPU
# CCU3: ReGaHss 9.8% CPU, rfd 5.1% CPU
bash
# Zeitzone-Status komplett prüfen
date
timedatectl status
cat /etc/timezone
bash
Mon Jan 15 14:30:25 CET 2024
               Local time: Mon 2024-01-15 14:30:25 CET
           Universal time: Mon 2024-01-15 13:30:25 UTC
                 RTC time: Mon 2024-01-15 13:30:25
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
Europe/Berlin
bash
# Zeitbasiertes Programm testen
cat > /tmp/time_test.tcl << 'EOF'
object prog = dom.CreateObject(OT_PROGRAM);
prog.Name("Zeitzone_Test");
prog.Rule("Time{hour=14;minute=35}");
prog.Active(true);
WriteLine("Test-Programm erstellt für: " # system.Date("%H:%M"));
WriteLine("Nächste Ausführung: 14:35");
EOF

/bin/tclsh /tmp/time_test.tcl
bash
Test-Programm erstellt für: 14:30
Nächste Ausführung: 14:35

Was tun wenn nach Migration Geräte fehlen?

Wenn nach der Migration Geräte in der Zentrale fehlen, folge diesem 5-Schritt-Wiederherstellungsplan:

Schritt 1: Geräte-Status analysieren

# Alle registrierten Geräte auflisten
cat > /tmp/device_check.tcl << 'EOF'
foreach(dev_id, dom.GetObject(ID_DEVICES).EnumUsedIDs()) {
  object dev = dom.GetObject(dev_id);
  WriteLine(dev.Address() # " - " # dev.Name() # " - " # dev.ReadyConfig());
}
EOF
/bin/tclsh /tmp/device_check.tcl

Schritt 2: Interface-Verbindungen prüfen

# HM-CFG-USB Status
cat /proc/bus/usb/devices | grep -A5 "1b1f:c020"
# Funkmodul-Kommunikation testen
echo 'WriteLine(system.GetVar("rfd"));' | /bin/tclsh

Schritt 3: Backup-Restore für fehlende Geräte

# Partielles Backup-Restore nur für Geräte
cd /usr/local/tmp
# Geräte-Konfiguration aus Backup extrahieren
tar -xzf usr_local.tar.gz ./etc/config/rfd.conf
cp ./etc/config/rfd.conf /usr/local/etc/config/
/etc/init.d/S61rfd restart

Schritt 4: Geräte-Neuerkennung erzwingen

# Alle Interfaces neu scannen
echo 'system.Exec("/etc/init.d/S61rfd restart");' | /bin/tclsh
sleep 30
# Geräte-Discovery starten
echo 'system.Exec("eq3configcmd update-lgw-firmware -p /dev/ttyUSB0 -t HM-LGW");' | /bin/tclsh

Schritt 5: Manuelle Geräte-Wiederherstellung

# Für jeden fehlenden Geräte-Typ:
cat > /tmp/restore_device.tcl << 'EOF'
# Beispiel für HM-Sec-SC-2
object dev = dom.CreateObject(OT_DEVICE, "NEQ0123456");
dev.Name("Fenstersensor Wohnzimmer");
dev.Address("NEQ0123456");
dev.TypeName("HM-Sec-SC-2");
dom.GetObject(ID_DEVICES).Add(dev.ID());
WriteLine("Device restored: " # dev.Name());
EOF
/bin/tclsh /tmp/restore_device.tcl

Synology DSM Docker-Migration Angebot: CCU3 Container Setup

DSM Docker-Package Installation:

# Via Package Center oder SSH
synopkg install Docker
synopkg start Docker

# Docker-Daemon Status prüfen
docker --version
# Erwartete Ausgabe: Docker version 20.10.3, build 55f0773

Volume-Mapping für /usr/local konfigurieren:

# Persistentes Volume auf Synology erstellen
mkdir -p /volume1/docker/ccu3/usr_local
chmod 755 /volume1/docker/ccu3/usr_local

# CCU3 Container mit korrektem Volume-Mapping
docker run -d \
  --name ccu3 \
  --restart=unless-stopped \
  --privileged \
  -p 80:80 -p 443:443 -p 2001:2001 -p 2010:2010 \
  -p 8181:8181 -p 9292:9292 -p 10000:10000 \
  -v /volume1/docker/ccu3/usr_local:/usr/local \
  -v /dev:/dev \
  --device=/dev/ttyUSB0 \
  eq3dev/ccu3:latest

Port-Konfiguration für DSM-Firewall:

# Firewall-Regel für CCU3-Ports erstellen
synofw --add -p tcp -s 0.0.0.0/0 --dport 80,443,2001,2010,8181,9292,10000 -j ACCEPT
synofw --add -p udp -s 0.0.0.0/0 --dport 43439,1900,1901 -j ACCEPT

# Aktuelle Firewall-Regeln prüfen
synofw --show

Synology-spezifische USB-Passthrough:

# USB-Geräte auf Synology identifizieren
lsusb | grep -E "(1b1f:c020|0403:6001)"
# Ausgabe: Bus 001 Device 003: ID 1b1f:c020 Corsair HM-CFG-USB-2

# Container mit USB-Device starten
docker run -d \
  --name ccu3 \
  --device=/dev/ttyUSB0:/dev/ttyUSB0 \
  --device=/dev/ttyACM0:/dev/ttyACM0 \
  -v /volume1/docker/ccu3/usr_local:/usr/local \
  eq3dev/ccu3:latest

# USB-Zugriff im Container testen
docker exec ccu3 ls -la /dev/tty*

DSM Task Scheduler für Auto-Start:

# Script für automatischen Container-Start erstellen
cat > /volume1/docker/ccu3/start_ccu3.sh << 'EOF'
#!/bin/bash
docker start ccu3
sleep 30
# Interface-Status prüfen
docker exec ccu3 /bin/sh -c "echo 'WriteLine(system.GetVar(\"rfd\"));' | /bin/tclsh"
EOF

chmod +x /volume1/docker/ccu3/start_ccu3.sh

Bei Re-Pairing nach Migration unterscheiden sich die Vorgehensweisen erheblich je nach Gerätetyp. Funk-Geräte erfordern meist einen 3-sekündigen Tastendruck an der Service-Taste, während Wired-Geräte über Bus-Reset wiederhergestellt werden. HM-Sec-Geräte benötigen oft eine spezielle Reset-Sequenz: 10 Sekunden Service-Taste halten, bis LED rot blinkt, dann weitere 5 Sekunden für Factory-Reset. Bei Pairing-Timeouts über 60 Sekunden solltest du die Funkfrequenz prüfen – CCU3 nutzt standardmäßig 868.3 MHz, während manche CCU2-Installationen auf 869.525 MHz konfiguriert waren.

Factory Reset Entscheidungsmatrix: Wann ist ein Reset erforderlich?

Factory Reset ist erforderlich wenn:

1) Firmware-Korruption vorliegt:

# Firmware-Integrität prüfen
md5sum /firmware/fwmap | grep -v "a4f8d2e1c9b7f3e5"
# Wenn MD5 abweicht: Korruption erkannt

# Boot-Log auf Korruption prüfen
dmesg | grep -i "corrupt\|error\|fail" | head -5
# Kritische Ausgabe: "UBIFS error: corrupt node"

2) Mehr als 3 fehlgeschlagene Migrationen:

# Migration-Versuche aus Log zählen
grep -c "migration.*failed" /var/log/messages
# Wenn Ausgabe > 3: Factory Reset empfohlen

# Backup-Restore Fehler-Historie
ls -la /usr/local/tmp/backup_*.log | wc -l

3) Hardware-Tausch von CCU2 auf CCU3:

# Hardware-ID Konflikt prüfen
cat /proc/cpuinfo | grep "Hardware"
# CCU2: BCM2835
# CCU3: BCM2837 oder BCM2711

# MAC-Adresse Konflikt
cat /sys/class/net/eth0/address
# Bei identischer MAC zu alter CCU2: Reset nötig

Prüfbefehle vor Factory Reset:

# Vollständige System-Diagnose
cat > /tmp/reset_check.sh << 'EOF'
#!/bin/bash
echo "=== FACTORY RESET CHECK ==="
echo "1. Firmware Status:"
cat /VERSION 2>/dev/null || echo "VERSION file missing - RESET NEEDED"

echo "2. Config Corruption:"
find /usr/local/etc -name "*.xml" -exec xmllint --noout {} \; 2>&1 | grep -c "error"

echo "3. Database Integrity:"
sqlite3 /usr/local/etc/config/homematic.regadom ".schema" >/dev/null 2>&1
echo "RegaDB Status: $?"

echo "4. Interface Status:"
lsusb | grep -c "1b1f:c020"
EOF

chmod +x /tmp/reset_check.sh && /tmp/reset_check.sh

Entscheidungslogik:
– 0-1 Fehler: Migration ohne Reset versuchen
– 2-3 Fehler: Backup erstellen, dann Reset
– 4+ Fehler: Sofortiger Factory Reset erforderlich

CCU2-spezifische Befehle:

# Backup erstellen (CCU2 2.41.x)
cd /usr/local && tar -czf /tmp/ccu2_backup.tar.gz etc/ addons/

# Interface-Reset CCU2
/etc/init.d/S60multimacd restart
echo 'system.Exec("/etc/init.d/S61rfd restart");' | /bin/tclsh

CCU3-spezifische Befehle:

# Backup erstellen (CCU3 3.59.x+)
cd /usr/local && tar --exclude='tmp' -czf /tmp/ccu3_backup.tar.gz *

# Interface-Reset CCU3
systemctl restart eq3-rfd.service
echo 'system.Exec("systemctl restart multimacd");' | /bin/tclsh

Verifikation: Backup-Erstellung erfolgreich

# Backup-Größe und Integrität prüfen
ls -lh /tmp/*_backup.tar.gz
tar -tzf /tmp/*_backup.tar.gz | head -10
# Erwartete Ausgabe: etc/config/, addons/redmatic/, etc/homematic.regadom

Verifikation: Interface-Reset erfolgreich

# Interface-Status nach Reset
lsusb | grep "1b1f:c020"
echo 'WriteLine(system.GetVar("rfd"));' | /bin/tclsh
# Erwartete Ausgabe: "rfd" mit Status "running"

Verifikation: Migration abgeschlossen

# Geräte-Anzahl vor/nach Migration vergleichen
echo 'WriteLine("Devices: " # dom.GetObject(ID_DEVICES).EnumUsedIDs().Count());' | /bin/tclsh
# Sollte identisch zur Quell-CCU sein

# Programme funktionsfähig
echo 'WriteLine("Programs: " # dom.GetObject(ID_PROGRAMS).EnumUsedIDs().Count());' | /bin/tclsh

Verifikation: Factory Reset vollständig

# Leere Konfiguration bestätigen
ls -la /usr/local/etc/config/ | wc -l
# Erwartete Ausgabe: 3 (nur ., .., und Basis-Dateien)

# Keine alten Geräte-Referenzen
echo 'WriteLine(dom.GetObject(ID_DEVICES).EnumUsedIDs().Count());' | /bin/tclsh
# Erwartete Ausgabe: 0

Verifikation: Zeitzone korrekt gesetzt

# System-Zeit vs HomeMatic-Zeit
date && echo 'WriteLine(system.Date("%d.%m.%Y %H:%M:%S"));' | /bin/tclsh
# Beide Zeiten sollten maximal 1-2 Sekunden abweichen

Verifikation: Docker-Container läuft stabil
„`bash

Container-Status und Ressourcen-Verbrauch

docker stats ccu3 –no-stream

CPU < 10%, Memory < 512MB für Standard-Installation

„`

Preisvergleich

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

Das könnte dich auch interessieren

• KNX Buslinie Kurzschluss lokalisieren: Systematische Fehlersuche mit Multimeter
• Homematic CCU3 VLAN-Konfiguration: Geräte nicht erreichbar beheben
• Homematic Wired Bus Terminierung mit Fluke 115 Multimeter prüfen – Komplette Anleitung