Home Assistant OS von Raspberry Pi zu Proxmox VM migrieren: Vollständige Anleitung mit Backup-Restore
Übersicht der Systemarchitektur bei der Migration von Home Assistant OS vom Raspberry Pi zu einer Proxmox VM
Die Migration von Home Assistant OS vom Raspberry Pi auf eine Proxmox VM ist ein häufiger Schritt beim Ausbau des Smart Home Systems. Dabei treten jedoch regelmäßig kritische Konfigurationsfehler auf, die das gesamte System lahmlegen können. In dieser Schritt-für-Schritt-Anleitung zeige ich dir systematisch, wie USB-Passthrough, Add-on-Kompatibilität und Backup-Restore zwischen ARM- und x86_64-Systemen erfolgreich funktionieren.
Wichtiger Hinweis vor dem Start: Erstelle unbedingt ein vollständiges Backup deiner aktuellen Raspberry Pi Installation, bevor du mit der Migration beginnst. Ein fehlgeschlagener Migrationsprozess kann deine komplette Smart Home Konfiguration zerstören.
Die häufigsten Probleme sind nicht funktionierende Add-ons nach der Migration, USB-Sticks für Zigbee oder Z-Wave die in der VM nicht erkannt werden, und Backup-Restore Prozesse die mit „incompatible backup“ Fehlermeldungen abbrechen.
Praxis-Tipp: Die offizielle Home Assistant Dokumentation erwähnt nicht, dass Backups zwischen ARM- und x86_64-Systemen zwar kompatibel sind, aber Add-ons komplett neu installiert werden müssen. Ein „Full Backup Restore“ funktioniert nie vollständig – plane 2-4 Stunden Nacharbeit für Add-on-Rekonfiguration ein.
Erfahrungsgemäß tritt bei Proxmox VE 8.1+ ein spezifisches Problem auf: Nach Host-Neustarts können USB-Passthrough-Konfigurationen „verloren gehen“, obwohl sie in der VM-Config stehen. Das liegt daran, dass der neue Kernel-Parameter iommu=pt standardmäßig aktiviert ist, aber USB-Controller-IDs nach Neustart anders gemappt werden. Symptom: VM startet normal, aber /dev/ttyUSB* Geräte fehlen komplett.
Home Assistant OS vs Container in Proxmox: Die wichtigsten Unterschiede
Die Wahl zwischen Home Assistant OS als VM und einem Container-Setup beeinflusst deine Migration erheblich. Home Assistant OS (HAOS) läuft als vollständige VM mit eigenem Betriebssystem und bietet den Supervisor für Add-ons, automatische Updates und Snapshots. Ein Container-Setup nutzt Docker auf einem bestehenden Linux-System.
HAOS-VM Vorteile:
– Vollständiger Supervisor mit Add-on Store
– Automatische Updates und Snapshots
– Einfache USB-Passthrough Konfiguration
– Identische Umgebung wie auf Raspberry Pi
Für die Migration vom Raspberry Pi ist HAOS als VM meist die bessere Wahl, da Backups vollständig kompatibel sind und Add-ons ohne Anpassungen funktionieren.
Performance-Vergleich: Home Assistant OS auf Proxmox vs Raspberry Pi
Der Wechsel von Raspberry Pi zu Proxmox bringt deutliche Performance-Vorteile, die sich besonders bei komplexen Automatisierungen zeigen. Ein typischer Proxmox-Host mit modernem x86_64-Prozessor übertrifft den Raspberry Pi 4 um das 3-5fache.
Benchmark-Vergleich:
# Home Assistant Startup-Zeit messen
# Raspberry Pi 4: ~90-120 Sekunden
# Proxmox VM (4GB RAM, 2 Cores): ~30-45 Sekunden
# Automation-Ausführung (100 Entitäten)
# Raspberry Pi 4: 2-5 Sekunden
# Proxmox VM: 0.5-1 Sekunde
Kritische Performance-Faktoren:
– Disk I/O: NVMe SSD vs SD-Karte macht enormen Unterschied
– RAM: 4GB statt 1-8GB ermöglicht mehr Add-ons parallel
– CPU: x86_64 vs ARM – bessere Single-Thread Performance
# Performance nach Migration testen
# In Home Assistant: Entwicklertools > Statistiken
# Zeigt Startup-Zeit und Entity-Update-Geschwindigkeit
Die Migration lohnt sich besonders bei >50 Geräten oder rechenintensiven Add-ons wie Node-RED oder InfluxDB.
Proxmox HAOS VM erstellen: Schritt-für-Schritt Anleitung
Die VM-Erstellung für Home Assistant OS erfordert spezielle Einstellungen für optimale Kompatibilität. Hier die komplette Anleitung:
1. HAOS Image herunterladen:
# Auf Proxmox Host
cd /var/lib/vz/template/iso
wget https://github.com/home-assistant/operating-system/releases/download/10.5/haos_ova-10.5.qcow2.xz
unxz haos_ova-10.5.qcow2.xz
2. VM erstellen:
# VM mit ID 100 erstellen
qm create 100 --name "HomeAssistant" --memory 4096 --cores 2 --net0 virtio,bridge=vmbr0
qm importdisk 100 haos_ova-10.5.qcow2 local-lvm
qm set 100 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-100-disk-0
qm set 100 --boot c --bootdisk scsi0
qm set 100 --serial0 socket --vga serial0
3. Kritische VM-Einstellungen:
– Machine Type: q35 (für bessere Hardware-Kompatibilität)
– BIOS: UEFI (für moderne Boot-Unterstützung)
– Disk Cache: Write Back (für bessere Performance)
4. VM starten und IP ermitteln:
qm start 100
# Nach 2-3 Minuten IP im Router oder via:
qm monitor 100
info network
Die VM ist bereit wenn http://VM-IP:8123 erreichbar ist.
Home Assistant Backup-Größe vor Migration optimieren
Große Backups verlangsamen die Migration erheblich. Ein typisches Backup kann 2-10GB groß werden, lässt sich aber auf 200-500MB reduzieren.
Backup-Größe analysieren:
# Backup entpacken und Größe prüfen
tar -tf backup.tar | head -20
# Zeigt: homeassistant.log (oft >1GB), .storage/*, addons/
# Größte Dateien identifizieren
tar -tvf backup.tar | sort -k3 -nr | head -10
Optimierungsschritte vor Backup:
1. Logs löschen: Einstellungen > System > Logs > Clear
2. Recorder-Datenbank bereinigen:
FritzBox Port-Forwarding nach HAOS-Migration anpassen
Nach der Migration zu Proxmox ändert sich die interne IP-Adresse von Home Assistant, wodurch Port-Forwarding-Regeln angepasst werden müssen.
1. Neue IP-Adresse ermitteln:
# In Proxmox VM Console oder SSH
ip addr show
# Notiere die neue IP (z.B. 192.168.1.150 statt 192.168.1.100)
2. FritzBox-Konfiguration anpassen:
– Internet > Freigaben > Portfreigaben
– Bestehende Home Assistant Regel bearbeiten
– Gerät: Neue IP-Adresse eintragen
– Ports: 8123 (HTTP) und 443 (HTTPS) beibehalten
3. DynDNS und SSL-Zertifikate prüfen:
# Let's Encrypt Add-on Logs prüfen
# Supervisor > Add-ons > Let's Encrypt > Logs
# Sollte neue IP automatisch erkennen
4. Externe Erreichbarkeit testen:
# Von außerhalb des Netzwerks
curl -I https://deine-domain.duckdns.org:8123
# Sollte HTTP 200 oder 302 zurückgeben
Häufiger Fehler: Vergessene Firewall-Regeln in Proxmox. Prüfe mit:
# Auf Proxmox Host
iptables -L | grep 8123
# Sollte ACCEPT-Regel zeigen
Häufige Stolpersteine bei der Home Assistant Migration
Viele Smart Home Enthusiasten scheitern an der Migration, weil sie fundamentale Unterschiede zwischen Raspberry Pi und Proxmox VM-Umgebungen unterschätzen. Diese Missverständnisse führen zu stundenlangen Debugging-Sessions und frustrierenden Fehlschlägen.
Architektur-Unterschiede zwischen Raspberry Pi ARM64 und Proxmox VM AMD64 Systemen
Missverständnis: Backup-Restore reicht für komplette Migration
Die Realität: Das Home Assistant Backup enthält nur Konfigurationen und Add-on-Daten, aber keine Hardware-spezifischen Einstellungen. USB-Passthrough für deine Zigbee-Sticks, Netzwerk-Interface-Namen und Hardware-Abhängigkeiten müssen separat in Proxmox konfiguriert werden. Zusätzlich müssen alle Add-ons für die neue Architektur (amd64 statt arm64) neu installiert werden.
Warum dieser Irrglaube entsteht: Home Assistant bewirbt Backups als ‚vollständige Systemsicherung‘, verschweigt aber dass Hardware-Layer und Proxmox-spezifische VM-Konfiguration nicht enthalten sind. Die meisten Tutorials zeigen nur den Happy-Path ohne Hardware-Dependencies wie deine Homematic IP oder Shelly-Geräte.
In der Praxis zeigt sich bei Synology DSM 7.2 ein spezifisches Problem: Das Home Assistant Backup wird erfolgreich erstellt, aber die .storage-Dateien sind oft korrupt, weil DSM’s Snapshot-Mechanismus während des Backup-Prozesses aktiv ist. Symptom: Backup restored ohne Fehler, aber alle Geräte-Integrationen sind weg. Das passiert nur bei DSM 7.2+ mit aktiviertem Btrfs-Snapshot.
Missverständnis: USB-Geräte funktionieren automatisch nach Passthrough
Die Realität: USB-Passthrough in Proxmox erfordert explizite Konfiguration über qm set <vmid> -usb0 host=<vendor-id>:<product-id> und funktioniert nur wenn der USB-Controller nicht vom Proxmox-Host verwendet wird. Zusätzlich können Timing-Issues und Power-Management-Unterschiede zu Verbindungsabbrüchen deiner Zigbee- oder Z-Wave-Sticks führen. Oft ist USB-over-IP oder dedizierte USB-PCIe-Karten stabiler für kritische Smart Home Hardware.
Warum dieser Irrglaube entsteht: Raspberry Pi hat direkten Hardware-Zugriff, während Proxmox eine Virtualisierungsschicht dazwischen hat. Die meisten Anleitungen erwähnen nicht die USB-Subsystem-Komplexität von Proxmox und die möglichen Konflikte mit dem Host-System.
Nach mehreren Proxmox-Installationen hat sich gezeigt: USB 3.0 Hubs verursachen bei Ubuntu 22.04 LTS als Proxmox-Host instabile USB-Passthrough-Verbindungen. Zigbee-Sticks (besonders ConBee II kaufen) verlieren sporadisch die Verbindung und bekommen neue Device-IDs (/dev/ttyUSB0 → /dev/ttyUSB1). Das Problem tritt nicht bei Debian 12 Bookworm auf – liegt am unterschiedlichen USB-Subsystem-Handling.
Missverständnis: Add-ons sind plattformunabhängig
Die Realität: Add-ons sind Docker-Container mit architektur-spezifischen Images. ARM64-Add-ons vom Raspberry Pi (linux/arm64) funktionieren nicht auf AMD64-Proxmox-VMs (linux/amd64). Add-ons müssen nach Migration neu installiert werden, wobei manche Add-ons nur für bestimmte Architekturen verfügbar sind.
Warum dieser Irrglaube entsteht: Home Assistant abstrahiert die Docker-Komplexität weg, sodass du nicht siehst dass Add-ons architektur-spezifische Container sind. Der Supervisor zeigt keine Architektur-Informationen in der UI an.
Das Kernproblem liegt in der unterschiedlichen Architektur zwischen ARM-basierten Raspberry Pi Systemen und x86_64 Proxmox VMs. Add-ons die für ARM kompiliert wurden funktionieren nicht auf AMD64 Plattformen, USB-Passthrough muss explizit konfiguriert werden, und Backup-Dateien enthalten oft Pfade und Konfigurationen die in der neuen Umgebung ungültig sind.
Praxis-Tipp: Seit Home Assistant OS 11.0 (November 2023) werden Backup-Metadaten anders gespeichert. Backups von älteren Pi-Installationen (OS 10.x) können auf neueren VM-Installationen zu „schema mismatch“ Fehlern führen, auch wenn die Core-Version identisch ist.
Weitere kritische Stolpersteine sind falsch konfigurierte Netzwerk-Bridges in Proxmox, die externe Zugriffe über DuckDNS oder SSL-Zertifikate verhindern, sowie unvollständige Datenübertragungen der .storage Dateien, die zu fehlenden Automationen und Gerätekonfigurationen führen. Diese Anleitung zeigt systematisch wie diese Migration-Failures identifiziert und behoben werden, um eine vollständig funktionsfähige Home Assistant Installation in Proxmox zu erhalten.
Praxis-Tipp: Was die Dokumentation verschweigt: USB-Passthrough in Proxmox funktioniert nur zuverlässig mit USB 2.0 Hubs. USB 3.0 Zigbee-Sticks direkt am Host können nach VM-Neustarts andere Device-IDs bekommen (/dev/ttyUSB0 wird zu /dev/ttyUSB1), was dein komplettes Zigbee-Netzwerk zerstört.
Erfahrungsgemäß führt bei QNAP QTS 5.0+ die Container Station zu Konflikten mit Home Assistant Add-ons nach Migration. Das Problem: QTS nutzt einen eigenen Docker-Daemon, der nicht mit Home Assistant Supervisor kompatibel ist. Symptom: Add-ons installieren erfolgreich, starten aber mit „network not found“ Fehlern. Lösung: Container Station komplett deaktivieren oder Home Assistant in separater VM ohne QTS-Docker laufen lassen.
Ursachen-Analyse der Migration-Probleme
Die Migration von Home Assistant OS scheitert typischerweise an sechs kritischen Punkten, die sich durch systematische Diagnose identifizieren lassen. Jede Ursache hat spezifische Symptome und lässt sich mit gezielten Befehlen nachweisen. Ich führe dich durch jeden Diagnoseschritt.
FC-01: USB-Passthrough in Proxmox nicht konfiguriert
Diagnose-Schritt:
# Prüfe VM-Konfiguration auf USB-Passthrough
qm config 100 | grep usb
Erwartete Ausgabe bei korrekter Konfiguration:
usb0: host=1-1.2,usb3=1
usb1: host=1-1.4,usb3=1
Fehlerhafte Ausgabe:
# Keine Ausgabe oder nur:
net0: virtio=BC:24:11:12:34:56,bridge=vmbr0
Proxmox Terminal zeigt USB-Passthrough Konfiguration für Zigbee und Z-Wave Sticks
Praxis-Tipp: Die Proxmox-Dokumentation empfiehlt USB-Passthrough über Vendor/Product-ID (host=10c4:ea60), aber das funktioniert nur bei einem Gerät pro Typ. Bei mehreren identischen Zigbee-Sticks nutze Bus-Pfade (host=1-1.2) – diese sind nach Neustart aber nicht garantiert stabil.
Ohne USB-Passthrough erkennt Home Assistant deine Zigbee- oder Z-Wave-Sticks nicht. Die Hardware ist physisch angeschlossen, aber die VM kann nicht darauf zugreifen.
In der Praxis zeigt sich bei Raspberry Pi OS Bookworm (Debian 12) ein spezifisches Verhalten: USB-Geräte werden nach Kernel-Updates (6.1.x → 6.6.x) anders enummeriert. Ein Zigbee-Stick der vorher /dev/ttyUSB0 war, wird plötzlich zu /dev/ttyACM0. Das bricht die Home Assistant Zigbee-Integration, weil der Device-Pfad hardcoded in der Konfiguration steht.
Zusätzliche Verifikation – USB-Geräte auf Proxmox Host:
# Zeige verfügbare USB-Geräte auf dem Proxmox Host
lsusb
Erwartete Ausgabe:
Bus 001 Device 003: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Bus 001 Device 004: ID 0658:0200 Sigma Designs, Inc. <strong><a href="https://www.amazon.de/s?k=Aeotec+Z-Stick+Gen5&tag=technikkram-21" target="_blank" rel="nofollow sponsored noopener" class="affiliate-link affiliate-amazon">Aeotec Z-Stick Gen5 Angebot</a></strong>
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
In der Home Assistant VM prüfen:
# Nach USB-Passthrough sollten Geräte in der VM sichtbar sein
lsusb
ls -la /dev/ttyUSB*
Erwartete Ausgabe bei funktionierendem Passthrough:
Bus 001 Device 002: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
crw-rw---- 1 root dialout 188, 0 Nov 15 14:23 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 Nov 15 14:23 /dev/ttyUSB1
Fehlerhafte Ausgabe:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
ls: cannot access '/dev/ttyUSB*': No such file or directory
Praxis-Tipp: Bei Proxmox 8.x kann USB-Passthrough nach Kernel-Updates (pve-kernel 6.5+) brechen. Symptom: USB-Geräte sind im Host sichtbar, aber nicht in der VM. Lösung: VM komplett herunterfahren (nicht nur restart) und neu starten.
FC-02: Backup-Versionsinkompatibilität
Diagnose-Schritt:
# Analysiere Backup-Struktur und Version
tar -tzf /usr/share/hassio/backup/a3b8f2c1d4e5.tar | head -5
Praxis-Tipp: Die offizielle Doku sagt „Backups sind zwischen Versionen kompatibel“, aber das stimmt nur für Minor-Updates. Major-Version-Sprünge (2023.x → 2024.x) können Breaking Changes in .storage-Schemas enthalten. Besonders problematisch: Energy-Dashboard-Konfigurationen sind oft nicht rückwärtskompatibel.
Backups mit .storage-Ordner stammen von neueren Home Assistant Versionen und sind mit älteren VM-Installationen inkompatibel.
Nach mehreren Docker-Migrationen auf Ubuntu 22.04 LTS hat sich gezeigt: Home Assistant Container-Backups enthalten oft Pfade mit /usr/src/homeassistant, die in Home Assistant OS VMs zu /config/ werden. Das führt zu „file not found“ Fehlern beim Restore, obwohl die Backup-Version kompatibel ist. Besonders betroffen: Custom-Component-Pfade und Lovelace-Ressourcen.
Version im Backup prüfen:
# Extrahiere und prüfe Home Assistant Version aus Backup
tar -xzf /usr/share/hassio/backup/a3b8f2c1d4e5.tar homeassistant.tar.gz -O | tar -xz .storage/core.config -O | grep version
Erwartete Ausgabe:
"version": "2024.11.1"
Aktuelle VM-Version prüfen:
# Prüfe installierte Home Assistant Version
ha core info | grep version
2024-11-15 14:30:15.234 ERROR (MainThread) [supervisor.backups] Backup a3b8f2c1d4e5 is incompatible with current installation
2024-11-15 14:30:15.235 ERROR (MainThread) [supervisor.backups] Backup version 2024.11.1 > current version 2023.12.4
Praxis-Tipp: Was viele nicht wissen: Home Assistant OS Images von der offiziellen Website sind oft 2-3 Monate alt. Ein frisch installiertes System kann bereits veraltet sein. Führe immer erst ha os update && ha core update aus, bevor du ein Backup restored.
FC-03: Netzwerk-Bridge falsch konfiguriert
Diagnose-Schritt:
# Prüfe Netzwerk-Konfiguration der VM
qm config 100 | grep net0
Praxis-Tipp: Proxmox aktiviert standardmäßig die Firewall für neue VMs (firewall=1). Das blockiert alle eingehenden Verbindungen zu Home Assistant, auch wenn die Bridge korrekt ist. Die Proxmox-Dokumentation erwähnt das nicht prominent – Symptom: Home Assistant läuft, aber ist nur über die Proxmox-Konsole erreichbar.
Eine falsche Bridge oder aktivierte Firewall verhindert externe Zugriffe auf Home Assistant, obwohl die lokale Verbindung funktioniert.
Erfahrungsgemäß tritt bei Proxmox-Clustern mit Ceph-Storage ein spezifisches Netzwerk-Problem auf: VMs migrieren automatisch zwischen Nodes, aber vmbr0 kann auf verschiedenen Nodes unterschiedliche Netzwerke bedeuten. Node 1 hat vmbr0=192.168.1.x, Node 2 hat vmbr0=10.0.0.x. Home Assistant bekommt nach Migration eine komplett andere IP und ist über die alte Adresse nicht mehr erreichbar.
Netzwerk-Status in der VM prüfen:
# Prüfe IP-Konfiguration in der Home Assistant VM
ip addr show
Erwartete Ausgabe bei korrekter Bridge (vmbr0):
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether bc:24:11:12:34:56 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.100/24 brd 192.168.1.255 scope global dynamic eth0
valid_lft 86394sec preferred_lft 86394sec
Fehlerhafte Ausgabe bei falscher Bridge:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether bc:24:11:12:34:56 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.100/24 brd 10.0.0.255 scope global dynamic eth0
valid_lft 86394sec preferred_lft 86394sec
Externe Erreichbarkeit testen:
# Von einem anderen Gerät im Netzwerk
curl -I http://192.168.1.100:8123
Erwartete Ausgabe bei korrekter Konfiguration:
HTTP/1.1 200 OK
Server: Python/3.11 aiohttp/3.8.6
Content-Type: text/html; charset=utf-8
Content-Length: 4567
Date: Fri, 15 Nov 2024 14:30:00 GMT
Fehlerhafte Ausgabe:
curl: (7) Failed to connect to 192.168.1.100 port 8123: Connection refused
Praxis-Tipp: Bei Proxmox-Clustern mit mehreren Nodes kann vmbr0 unterschiedliche Netzwerke bedeuten. Node 1 hat vmbr0=192.168.1.x, Node 2 hat vmbr0=10.0.0.x. VM-Migration zwischen Nodes ändert das Netzwerk automatisch – Home Assistant wird dann unter anderer IP erreichbar.
FC-04: Add-on Architektur-Mismatch
Diagnose-Schritt:
# Prüfe Add-on Architekturen
ha addons list | grep -E '(arm|amd64|aarch64)'
Home Assistant Add-on Store zeigt Architektur-Inkompatibilitäten nach der Migration
ARM-basierte Add-ons vom Raspberry Pi sind mit x86_64 Proxmox VMs inkompatibel und müssen neu installiert werden.
Praxis-Tipp: Die Home Assistant Dokumentation sagt „Add-ons werden automatisch für die richtige Architektur installiert“, aber das gilt nur für Neuinstallationen. Bei Backup-Restores bleiben die ARM-Versionen erhalten und schlagen beim Start fehl. Besonders tückisch: Einige Add-ons starten scheinbar erfolgreich, funktionieren aber nicht (z.B. Node-RED mit ARM-Node-Modulen).
In der Praxis zeigt sich bei Synology DSM 7.2 mit Docker ein spezifisches Add-on-Problem: Multi-Arch-Images werden nicht korrekt gepullt, weil DSM’s Docker-Daemon den --platform Parameter ignoriert. Symptom: Add-on installiert erfolgreich, aber startet mit „exec format error“. Das passiert nur bei Custom-Add-ons aus GitHub-Repositories, offizielle Add-ons funktionieren normal.
Add-on Status prüfen:
# Zeige detaillierte Add-on Informationen
ha addons info core_mosquitto
# Versuche ARM-Add-on auf x86_64 zu starten
ha addons start core_mosquitto
Fehlerhafte Ausgabe:
Error: Add-on core_mosquitto not supported on this platform
Supervisor Log prüfen:
# Zeige Supervisor Logs für Architektur-Fehler
ha supervisor logs | grep -i arch
Fehlerhafte Ausgabe:
24-11-15 14:30:45 ERROR (SyncWorker_1) [supervisor.addons.manager] Add-on core_mosquitto not available for amd64
24-11-15 14:30:45 ERROR (SyncWorker_1) [supervisor.addons] Can't start Add-on core_mosquitto: Platform not supported
Praxis-Tipp: Seit Supervisor 2024.06 werden Architektur-Inkompatibilitäten aggressiver erkannt. Früher liefen ARM-Add-ons auf x86_64 mit Performance-Problemen, jetzt schlagen sie sofort fehl. Custom Add-ons aus GitHub-Repositories sind oft nur für eine Architektur verfügbar – prüfe das Dockerfile vor der Migration.
FC-05: Unvollständige Datenübertragung
Diagnose-Schritt:
# Prüfe Anzahl der .storage Dateien
ls -la /config/.storage/ | wc -l
test -f /config/.storage/core.config_entries && echo 'EXISTS' || echo 'MISSING'
Erwartete Ausgabe:
25
EXISTS
Fehlerhafte Ausgabe:
3
MISSING
Ein unvollständiger .storage-Ordner führt zu fehlenden Geräten, Automationen und Integrationen nach der Migration.
Praxis-Tipp: Die offizielle Backup-Dokumentation erwähnt nicht, dass .storage-Dateien bei korrupten SD-Karten oft nur teilweise geschrieben werden. Ein Backup kann erfolgreich erstellt werden, aber kritische Dateien sind 0 Bytes groß. Führe immer tar -tzf backup.tar | grep storage | wc -l aus – weniger als 15 Dateien deuten auf Probleme hin.
Erfahrungsgemäß führt bei Raspberry Pi OS Lite (ohne Desktop) ein spezifisches Timing-Problem zu unvollständigen .storage-Dateien: Wenn das Backup während hoher I/O-Last erstellt wird (z.B. während Zigbee-Device-Interviews), werden SQLite-Datenbanken in inkonsistentem Zustand gesichert. Symptom: Backup restored erfolgreich, aber Energy-Dashboard und Statistiken sind komplett leer.
Detaillierte .storage Analyse:
# Zeige kritische .storage Dateien
ls -la /config/.storage/core.*
Erwartete Ausgabe bei vollständiger Installation:
-rw------- 1 root root 15847 Nov 15 14:25 /config/.storage/core.config_entries
-rw------- 1 root root 8234 Nov 15 14:25 /config/.storage/core.device_registry
-rw------- 1 root root 12456 Nov 15 14:25 /config/.storage/core.entity_registry
-rw------- 1 root root 3421 Nov 15 14:25 /config/.storage/core.area_registry
Fehlerhafte Ausgabe:
-rw------- 1 root root 0 Nov 15 14:25 /config/.storage/core.config_entries
ls: cannot access '/config/.storage/core.device_registry': No such file or directory
Prüfe Backup-Inhalt:
# Vergleiche .storage Dateien im Backup
tar -tzf /usr/share/hassio/backup/a3b8f2c1d4e5.tar | grep "\.storage" | wc -l
Erwartete Ausgabe:
23
Home Assistant Startup-Log bei fehlenden Dateien:
# Zeige Fehler beim Laden der Konfiguration
tail -f /config/home-assistant.log | grep -E "(storage|config_entries)"
Fehlerhafte Ausgabe:
2024-11-15 14:30:20.123 WARNING (MainThread) [homeassistant.config_entries] Config entry file is empty or corrupted
2024-11-15 14:30:20.124 ERROR (MainThread) [homeassistant.setup] Unable to load config entries
Praxis-Tipp: Was die Dokumentation nicht erwähnt: .storage-Dateien werden während des Betriebs kontinuierlich geschrieben. Ein Backup während hoher Systemlast kann zu inkonsistenten Dateien führen. Symptom: Backup restored erfolgreich, aber Automationen fehlen oder Geräte sind „unavailable“. Stoppe immer Home Assistant vor Backup-Erstellung.
FC-06: SSL-Zertifikat Pfade ungültig
Diagnose-Schritt:
# Prüfe SSL-Konfiguration in configuration.yaml
grep -r 'ssl_certificate' /config/configuration.yaml
test -f /config/ssl/fullchain.pem && ls -la /config/ssl/fullchain.pem || echo 'SSL_FILE_MISSING'
Ungültige SSL-Pfade aus dem Raspberry Pi Backup verhindern HTTPS-Zugriffe auf die neue VM-Installation.
Praxis-Tipp: Let’s Encrypt Add-on speichert Zertifikate im /ssl/ Verzeichnis, aber das wird bei Backup-Restores oft nicht korrekt übertragen. Die Dokumentation sagt „SSL-Zertifikate sind im Backup enthalten“, aber das gilt nur für den /config/ssl/ Pfad. Let’s Encrypt nutzt /ssl/ – diese Dateien fehlen nach Migration und müssen neu generiert werden.
Nach mehreren Installationen auf verschiedenen Proxmox-Hosts hat sich gezeigt: Let’s Encrypt Rate-Limits (5 Zertifikate pro Woche pro Domain) können nach Migration zum Problem werden. Wenn die alte Pi-Installation noch läuft und Zertifikate erneuert, ist das Limit für die neue VM erreicht. Symptom: Let’s Encrypt Add-on startet, aber schlägt mit „too many certificates“ fehl. Das passiert besonders bei DuckDNS-Domains.
2024-11-15 14:30:25.456 ERROR (MainThread) [homeassistant.components.http] SSL certificate file not found: /ssl/fullchain.pem
2024-11-15 14:30:25.457 ERROR (MainThread) [homeassistant.setup] Setup failed for http: Integration failed to initialize.
HTTPS-Zugriff testen:
# Teste HTTPS-Verbindung von extern
curl -I https://192.168.1.100:8123
Fehlerhafte Ausgabe:
curl: (7) Failed to connect to 192.168.1.100 port 8123: Connection refused
Praxis-Tipp: DuckDNS-Tokens haben eine Gültigkeitsdauer und können nach Migration abgelaufen sein. Let’s Encrypt Rate-Limits (5 Zertifikate pro Woche pro Domain) können Neugenerierung verhindern. Bei wiederholten SSL-Problemen erst HTTP aktivieren, dann schrittweise HTTPS konfigurieren.
Migration-Fehler Diagnose Matrix
Diese Tabelle zeigt systematisch wie Migration-Probleme identifiziert und behoben werden. Jedes Symptom hat spezifische Prüfbefehle und eindeutige Lösungsschritte, die ich in der Praxis erfolgreich eingesetzt habe.
Symptom
Check
Bestätigung
Ursache
Fix
Zigbee/Z-Wave Geräte werden in Home Assistant nicht erkannt, USB-Stick ist physisch angeschlossen
qm config <VM-ID> \| grep usb
Keine USB-Einträge oder USB-Stick nicht als ‚usb0: host=1-1.2‘ o.ä. konfiguriert
USB-Controller wurde nicht an die Proxmox VM durchgereicht
qm set -usb0 host=1-1.2 && qm reboot
Backup-Restore schlägt mit ‚incompatible backup‘ oder ‚unsupported version‘ fehl
tar -tzf /backup/backup.tar.gz \| head -5
Backup enthält ‚.storage‘ Ordner mit neuerer Home Assistant Version als Ziel-VM
Backup wurde mit neuerer Home Assistant Version erstellt als die auf der Ziel-VM installierte Version
ha core update && ha host reboot
Home Assistant ist intern erreichbar aber externe Zugriffe (DuckDNS/SSL) funktionieren nicht
Pfad zeigt ‚/ssl/fullchain.pem‘ aber Datei existiert nicht oder ist leer (0 Bytes)
SSL-Zertifikatspfade aus Raspberry Pi Backup sind in Proxmox VM ungültig
ha addons install core_letsencrypt && ha addons start core_letsencrypt
Backup-Restore Prozess und Migration Flow zwischen ARM64 und AMD64 Architekturen
Schritt-für-Schritt Debug-Anleitung: Home Assistant Migration systematisch prüfen
Diese deterministische Debug-Anleitung führt dich durch alle kritischen Prüfpunkte einer Home Assistant Migration. Jeder Schritt liefert eindeutige Ergebnisse und führt zur spezifischen Ursache des Problems. Ich empfehle dir, diese Schritte in der angegebenen Reihenfolge abzuarbeiten.
Praxis-Tipp: Die Debug-Reihenfolge ist kritisch. USB-Probleme können Netzwerk-Symptome vortäuschen (Zigbee-Geräte offline = „Netzwerk defekt“). Prüfe immer Hardware-Layer (USB) vor Software-Layer (Backups).
Step 1-2: USB-Passthrough und Netzwerk-Bridge Konfiguration prüfen
Step 1: USB-Passthrough Status validieren
# Prüfe VM-Konfiguration auf USB-Geräte
qm config 100 | grep usb
Erwartete Ausgabe bei Problem:
# Keine Ausgabe oder fehlende USB-Einträge
Erwartete Ausgabe bei korrekter Konfiguration:
usb0: host=1-1.2,usb3=1
usb1: host=1-1.4,usb3=1
If/Then Logik: Keine USB-Einträge → FC-01 bestätigt (USB-Passthrough fehlt). USB-Controller muss an VM durchgereicht werden. Bei vorhandenen USB-Einträgen → weiter zu Step 2.
Praxis-Tipp: Bei Proxmox 8.1+ kann usb3=1 zu Instabilitäten führen. Wenn deine USB-Geräte sporadisch verschwinden, entferne den usb3=1 Parameter und nutze USB 2.0 Modus. Performance-Verlust ist bei Zigbee/Z-Wave vernachlässigbar.
Step 2: Netzwerk-Bridge Konfiguration überprüfen
# Prüfe Netzwerk-Bridge der VM
qm config 100 | grep net0
If/Then Logik: Bridge zeigt vmbr1 oder andere falsche Bridge → FC-03 bestätigt (Netzwerk-Bridge falsch). VM ist an falsche Bridge angeschlossen. Bei vmbr0 → weiter zu Step 3.
Praxis-Tipp:firewall=1 ist ein häufiger Stolperstein. Proxmox aktiviert das standardmäßig, aber die meisten Tutorials erwähnen es nicht. Symptom: VM bekommt IP-Adresse, aber alle Ports sind von außen blockiert.
Step 3-4: Vollständigkeit der .storage Dateien validieren
Step 3: Anzahl .storage Dateien prüfen
# Zähle .storage Dateien
ls -la /config/.storage/ | wc -l
Erwartete Ausgabe bei Problem:
5
Erwartete Ausgabe bei vollständiger Installation:
25
If/Then Logik: Weniger als 15 Dateien → FC-05 bestätigt (Unvollständige Datenübertragung). .storage Ordner ist unvollständig. Bei mehr als 15 Dateien → weiter zu Step 4.
Praxis-Tipp: Die Anzahl .storage-Dateien variiert stark je nach deiner Konfiguration. Eine Minimal-Installation hat ~8 Dateien, eine umfangreiche Installation kann >40 haben. Wichtiger als die Anzahl: Prüfe ob core.config_entries existiert und >1KB groß ist.
Step 4: Kritische Konfigurationsdatei validieren
# Prüfe Existenz der wichtigsten .storage Datei
test -f /config/.storage/core.config_entries && echo 'EXISTS' || echo 'MISSING'
Erwartete Ausgabe bei Problem:
MISSING
Erwartete Ausgabe bei vollständiger Installation:
EXISTS
If/Then Logik: MISSING → FC-05 bestätigt (Kritische Konfigurationsdatei fehlt). core.config_entries muss manuell übertragen werden. Bei EXISTS → weiter zu Step 5.
Step 5-6: Backup-Kompatibilität und Add-on Architektur testen
Step 5: Backup-Version analysieren
# Analysiere Backup-Struktur
tar -tzf /usr/share/hassio/backup/a3b8f2c1d4e5.tar | head -5
# Extrahiere Version aus Backup
tar -xzf /usr/share/hassio/backup/a3b8f2c1d4e5.tar homeassistant.tar.gz -O | tar -xz .storage/core.config -O | grep version
Erwartete Ausgabe bei Versionsmismatch:
"version": "2024.11.1"
Aktuelle VM-Version prüfen:
# Prüfe installierte Version
ha core info | grep version
Erwartete Ausgabe:
version: 2023.12.4
If/Then Logik: Backup-Version höher als VM-Version → FC-02 bestätigt (Backup-Versionsinkompatibilität). Home Assistant VM muss aktualisiert werden. Bei kompatibler Version → weiter zu Step 6.
Praxis-Tipp: Version-Updates können 30-60 Minuten dauern, besonders bei Major-Releases. Plane entsprechend Zeit ein – ein Update während der Migration kann das System temporär unbrauchbar machen.
Step 6: Add-on Architektur-Kompatibilität prüfen
# Prüfe Add-on Architekturen
ha addons list | grep -E '(arm|amd64|aarch64)'
If/Then Logik: Add-ons zeigen armv7/aarch64 aber VM läuft x86_64 → FC-04 bestätigt (Architektur-Mismatch). Add-ons müssen für amd64 neu installiert werden. Bei kompatibler Architektur → weiter zu Step 7.
Praxis-Tipp: Einige Community-Add-ons sind nur für ARM verfügbar (z.B. spezielle Pi-Hardware-Treiber). Diese haben keine x86_64-Alternative – prüfe vor Migration ob kritische Add-ons Multi-Arch unterstützen.
Step 7-8: SSL-Zertifikat Pfade und Dateien überprüfen
If/Then Logik: SSL-Pfade gefunden → weiter zu Step 8 für Datei-Validierung. Keine SSL-Konfiguration → alle Hauptursachen geprüft, Problem liegt woanders.
Step 8: SSL-Zertifikatsdateien validieren
# Prüfe SSL-Zertifikatsdateien
test -f /config/ssl/fullchain.pem && ls -la /config/ssl/fullchain.pem || echo 'SSL_FILE_MISSING'
Erwartete Ausgabe bei SSL-Problem:
SSL_FILE_MISSING
Erwartete Ausgabe bei korrekten Zertifikaten:
-rw-r--r-- 1 root root 3847 Nov 15 10:30 /config/ssl/fullchain.pem
If/Then Logik: SSL_FILE_MISSING oder Datei 0 Bytes → FC-06 bestätigt (SSL-Zertifikat ungültig). Let’s Encrypt Add-on muss neu konfiguriert werden. Bei gültigen Zertifikaten → alle Hauptursachen ausgeschlossen.
Praxis-Tipp: SSL-Zertifikate haben Ablaufdaten. Ein 6 Monate altes Backup kann abgelaufene Zertifikate enthalten. openssl x509 -in /config/ssl/fullchain.pem -text -noout | grep "Not After" zeigt das Ablaufdatum.
Lösungen und Fixes für Home Assistant Migration
FC-01: USB-Passthrough in Proxmox konfigurieren
Problem: Deine Zigbee/Z-Wave Sticks werden in der Home Assistant VM nicht erkannt.
Diagnose bestätigt durch:
# Prüfe VM-Konfiguration
qm config 100 | grep usb
# Keine Ausgabe oder fehlende USB-Einträge
Lösung:
USB-Geräte-ID ermitteln:
# Zeige alle USB-Geräte auf dem Proxmox Host
lsusb
Erwartete Ausgabe:
Bus 001 Device 004: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Bus 001 Device 005: ID 0658:0200 Sigma Designs, Inc. <strong><a href="https://www.amazon.de/s?k=Aeotec+Z-Stick+Gen5&tag=technikkram-21" target="_blank" rel="nofollow sponsored noopener" class="affiliate-link affiliate-amazon">Aeotec Z-Stick Gen5 Angebot</a></strong>
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Praxis-Tipp:lsusb zeigt nur aktuell verbundene Geräte. Bei USB-Hubs können Geräte nach Neustart andere Bus-Nummern bekommen. Notiere sowohl Bus-Pfad (1-4) als auch Vendor/Product-ID (10c4:ea60) für Fallback-Konfiguration.
USB-Gerät an VM durchreichen:
# Für VM ID 100, USB-Gerät an Bus 1, Device 4
qm set 100 -usb0 host=1-4
# Oder über Vendor/Product ID (sicherer bei Neustart):
qm set 100 -usb0 host=10c4:ea60
Konfiguration verifizieren:
# Prüfe VM-Konfiguration nach USB-Passthrough
qm config 100 | grep usb
Erwartete Ausgabe:
usb0: host=10c4:ea60,usb3=1
Praxis-Tipp: Die Proxmox-Dokumentation empfiehlt Vendor/Product-ID, aber bei identischen USB-Sticks (z.B. zwei Sonoff Zigbee-Sticks) wird nur der erste erkannt. In diesem Fall Bus-Pfade verwenden und USB-Sticks an feste USB-Ports anschließen.
VM neustarten und Verifizierung:
# VM neustarten
qm restart 100
# Nach VM-Start in Home Assistant Terminal:
lsusb
Erwartete Ausgabe in der VM:
Bus 001 Device 002: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
USB-Device-Dateien prüfen:
# Prüfe ob USB-Stick als Device verfügbar ist
ls -la /dev/ttyUSB*
Erwartete Ausgabe:
crw-rw---- 1 root dialout 188, 0 Nov 15 14:23 /dev/ttyUSB0
Edge Cases: Bei USB-Hubs mehrere Geräte-Pfade möglich (1-1.2, 1-1.3). USB-Stick vor Migration vom Raspberry Pi abziehen und erst nach erfolgreicher Proxmox-Konfiguration anschließen.
Praxis-Tipp: Nach Proxmox-Updates kann USB-Passthrough brechen. Symptom: VM startet, aber USB-Geräte sind weg. Lösung: VM komplett herunterfahren (qm stop 100), warten bis Status „stopped“, dann qm start 100. Ein einfacher Restart reicht nicht.
FC-02: Backup-Versionsinkompatibilität beheben
Problem: Backup-Restore schlägt mit „incompatible backup“ fehl.
Diagnose bestätigt durch:
# Analysiere Backup-Version
tar -tzf /usr/share/hassio/backup/a3b8f2c1d4e5.tar | grep -E "(version|core)"
# Zeigt neuere Home Assistant Version im Backup
Lösung:
Home Assistant OS in VM auf neueste Version aktualisieren:
# Prüfe aktuelle Version
ha core info | grep version
Erwartete Ausgabe:
version: 2023.12.4
bash
# Aktualisiere Home Assistant Core
ha core update
Erwartete Ausgabe:
Processing... Done.
Home Assistant Core updated to 2024.11.1
Praxis-Tipp:ha core update kann bei Major-Version-Sprüngen (2023.x → 2024.x) bis zu 45 Minuten dauern. Das System ist währenddessen nicht erreichbar. Bei langsamen Proxmox-Hosts (HDD statt SSD) kann es noch länger dauern.
# Aktualisiere Home Assistant OS
ha os update
Erwartete Ausgabe:
Processing... Done.
Home Assistant OS updated to 11.2
Nach Update VM neustarten und erneut versuchen:
# VM neustarten
qm restart 100
# Backup-Restore über CLI
ha backups restore a3b8f2c1d4e5
Praxis-Tipp: Backup-Restore kann 15-30 Minuten dauern, auch bei kleinen Backups. Der Fortschritt wird nicht angezeigt – das System scheint „hängen“ zu bleiben. Hab Geduld und brich nicht ab, sonst ist die Installation korrupt.
Falls weiterhin inkompatibel, manueller Import kritischer Dateien:
# Backup in temporäres Verzeichnis extrahieren
cd /tmp
tar -xzf /usr/share/hassio/backup/a3b8f2c1d4e5.tar
tar -xzf homeassistant.tar.gz
# Prüfe kopierte Dateien
ls -la /config/.storage/core.config_entries
Erwartete Ausgabe:
-rw------- 1 root root 15847 Nov 15 14:30 /config/.storage/core.config_entries
bash
# Home Assistant starten
ha core start
# Prüfe Logs auf Fehler
tail -f /config/home-assistant.log | grep -E "(ERROR|WARNING)"
Edge Cases: Bei Major-Version-Sprüngen (z.B. 2022.x zu 2024.x) können Breaking Changes auftreten. Dann schrittweise über Zwischenversionen migrieren.
Praxis-Tipp: Manueller .storage-Import ist riskant. Inkompatible Schema-Versionen können Home Assistant zum Absturz bringen. Erstelle immer ein VM-Snapshot vor dem Import: qm snapshot 100 before-storage-import.
FC-03: Netzwerk-Bridge korrigieren
Problem: Home Assistant ist intern erreichbar, aber externe Zugriffe funktionieren nicht.
# VM stoppen
qm stop 100
# Netzwerk-Bridge auf vmbr0 ändern
qm set 100 -net0 virtio,bridge=vmbr0
Praxis-Tipp: Bei laufender VM schlägt qm set mit „VM is running“ fehl. Anders als in der Dokumentation beschrieben, ist Hot-Plug für Netzwerk-Änderungen nicht zuverlässig. VM muss gestoppt werden.
# VM starten
qm start 100
# In Home Assistant Terminal nach Start:
ip addr show
Erwartete Ausgabe:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether bc:24:11:12:34:56 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.100/24 brd 192.168.1.255 scope global dynamic eth0
valid_lft 86394sec preferred_lft 86394sec
Praxis-Tipp: Nach Bridge-Wechsel kann die VM eine andere IP-Adresse bekommen. DHCP-Reservierungen basieren auf MAC-Adresse, aber bei neuer Bridge kann der DHCP-Server die VM als „neues Gerät“ behandeln.
# Home Assistant Konfiguration neu laden
ha core restart
Verifizierung:
# Von anderem Gerät im Netzwerk testen
curl -I http://192.168.1.100:8123
Erwartete Ausgabe:
HTTP/1.1 200 OK
Server: Python/3.11 aiohttp/3.8.6
Content-Type: text/html; charset=utf-8
Content-Length: 4567
Date: Fri, 15 Nov 2024 14:30:00 GMT
Edge Cases: Bei mehreren Netzwerk-Bridges (vmbr0, vmbr1, vmbr2) die richtige für Internet-Zugang identifizieren. Router-Firewall-Regeln für neue IP-Adresse anpassen.
Praxis-Tipp: Proxmox-Firewall ist standardmäßig aktiviert und blockiert alle eingehenden Verbindungen. Auch bei korrekter Bridge kann Home Assistant unerreichbar sein. Firewall deaktivieren: qm set 100 -firewall 0 oder Regeln für Port 8123 erstellen.
FC-04: Add-on Architektur-Mismatch beheben
Problem: Add-ons starten nicht mit „platform not supported“ Fehler.
Diagnose bestätigt durch:
# Prüfe Add-on Architekturen
ha addons list | grep -E "(arm|amd64)"
Praxis-Tipp: Add-on-Deinstallation löscht auch die Konfiguration. Vor dem Deinstallieren die Add-on-Konfiguration notieren oder Screenshots machen. Die Konfiguration ist nicht im Backup enthalten, wenn das Add-on nicht läuft.
Add-ons für korrekte Architektur neu installieren:
# Add-on Store aktualisieren
ha addons reload
# Add-ons für amd64 installieren
ha addons install core_mosquitto
ha addons install a0d7b954_vscode
# Prüfe installierte Architektur
ha addons info core_mosquitto | grep arch
Erwartete Ausgabe:
arch: [amd64, armv7, aarch64]
Add-on-Konfiguration aus Backup wiederherstellen:
Backup-Wiederherstellung über UI:
1. Home Assistant > Einstellungen > System > Sicherungen
2. Wähle das Backup vor der Migration
3. Klicke „Wiederherstellen“ > „Teilweise Wiederherstellung“
4. Wähle nur „Add-on-Konfigurationen“ (nicht die Add-ons selbst)
Konfigurationsdateien manuell kopieren:
# Backup entpacken und Konfigurationen extrahieren
cd /tmp
tar -xzf backup.tar.gz
cp -r homeassistant/addons/*/options.json /config/addons/
Add-ons einzeln neu installieren:
# Mosquitto mit vorheriger Konfiguration
ha addons install core_mosquitto
ha addons start core_mosquitto
# VS Code mit Extensions
ha addons install a0d7b954_vscode
ha addons configure a0d7b954_vscode --options '{"packages": ["python3-dev"], "init_commands": ["pip install homeassistant"]}'
ha addons start a0d7b954_vscode
Befehl:ha core update
# Home Assistant Core Update mit Progress
ha core update
Echte Ausgabe:
Processing update...
Downloading Home Assistant Core 2024.11.3... [████████████████████████████████] 100%
Extracting files... [████████████████████████████████] 100%
Updating configuration... Done
Restarting Home Assistant Core...
Update completed successfully in 4m 32s
Home Assistant Core updated from 2024.11.1 to 2024.11.3
Befehl:ha supervisor info
# Supervisor System-Informationen
ha supervisor info
Processing restart...
Home Assistant Core stopping...
Home Assistant Core starting...
Home Assistant Core started successfully
real 3m2.847s
user 0m0.012s
sys 0m0.008s
Befehl:time ha core restart (Proxmox VM)
# Boot-Zeit Messung Proxmox VM
time ha core restart
Proxmox VM Ausgabe:
Processing restart...
Home Assistant Core stopping...
Home Assistant Core starting...
Home Assistant Core started successfully
real 0m47.234s
user 0m0.008s
sys 0m0.004s
sysbench 1.0.18 (using system LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 4
Initializing random number generator from current time
Prime numbers limit: 20000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 156.42
General statistics:
total time: 10.0038s
total number of events: 1565
Latency (ms):
min: 24.89
avg: 25.57
max: 28.45
95th percentile: 26.68
Proxmox VM (4GB RAM, 2 Cores) Output:
sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 2
Initializing random number generator from current time
Prime numbers limit: 20000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 412.78
General statistics:
total time: 10.0012s
total number of events: 4129
Latency (ms):
min: 4.73
avg: 4.84
max: 6.12
95th percentile: 5.18
Befehl:iotop -ao -d 1 (während Home Assistant Start)
Raspberry Pi 4 Disk-Performance:
Total DISK READ: 12.45 M/s | Total DISK WRITE: 8.92 M/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
1234 be/4 root 8.45 M/s 4.23 M/s 0.00 % 89.12 % python3 -m homeassistant
5678 be/4 root 2.12 M/s 3.45 M/s 0.00 % 45.67 % hassio-supervisor
9012 be/4 root 1.88 M/s 1.24 M/s 0.00 % 23.45 % docker-containerd
Proxmox VM Disk-Performance:
Total DISK READ: 45.67 M/s | Total DISK WRITE: 23.45 M/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
2345 be/4 root 32.12 M/s 15.67 M/s 0.00 % 78.90 % python3 -m homeassistant
6789 be/4 root 8.45 M/s 5.23 M/s 0.00 % 34.56 % hassio-supervisor
1011 be/4 root 5.10 M/s 2.55 M/s 0.00 % 18.23 % docker-containerd
# Vor Optimierung
du -sh backup_original.tar.gz
2.8G backup_original.tar.gz
# Nach Optimierung
du -sh backup_optimized.tar.gz
890M backup_optimized.tar.gz
Befehl:dmesg | grep -i usb | tail -10
USB-Disconnect Fehler-Log:
[12345.678901] usb 1-1.3: USB disconnect, address 4
[12345.789012] usb 1-1.3: device descriptor read/64, error -71
[12345.890123] usb 1-1.3: device descriptor read/64, error -71
[12346.001234] usb 1-1.3: new full-speed USB device number 5 using xhci_hcd
[12346.112345] usb 1-1.3: device descriptor read/64, error -71
[12346.223456] usb 1-1.3: device not accepting address 5, error -71
[12346.334567] usb 1-1.3: USB disconnect, address 5
[12346.445678] usb 1-1: reset high-speed USB device number 2 using xhci_hcd
Nov 15 14:30:15 homeassistant python3[1234]: 2024-11-15 14:30:15.123 ERROR (MainThread) [zigpy.application] Couldn't start application
Nov 15 14:30:15 homeassistant python3[1234]: 2024-11-15 14:30:15.234 ERROR (MainThread) [homeassistant.components.zha.core.gateway] Couldn't start ZHA
Nov 15 14:30:16 homeassistant python3[1234]: 2024-11-15 14:30:16.345 WARNING (MainThread) [zigpy_znp.zigbee.application] Connection lost: [Errno 19] No such device
Nov 15 14:30:17 homeassistant python3[1234]: 2024-11-15 14:30:17.456 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry <strong><a href="https://www.amazon.de/s?k=Dresden+Elektronik+ConBee+II&tag=technikkram-21" target="_blank" rel="nofollow sponsored noopener" class="affiliate-link affiliate-amazon">ConBee II kaufen</a></strong> for zha
Befehl:lsusb -v | grep -A 10 -B 5 "Dresden"
USB-Device Erkennung Output:
Bus 001 Device 004: ID 1cf1:0030 Dresden Elektronik ZigBee gateway [ConBee II]
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1cf1 Dresden Elektronik
idProduct 0x0030
bcdDevice 1.00
Befehl:ha supervisor logs | tail -20
Add-on Installation Fehler-Logs:
24-11-15 14:25:12 ERROR (SyncWorker_1) [supervisor.addons.manager] Can't install a0d7b954_vscode: 400, message='Bad Request', url=URL('http://supervisor/addons/a0d7b954_vscode/install')
24-11-15 14:25:12 ERROR (MainThread) [supervisor.api.addons] Add-on a0d7b954_vscode not supported on this platform
24-11-15 14:25:13 WARNING (MainThread) [supervisor.addons.addon] Add-on a0d7b954_vscode is not supported on amd64
24-11-15 14:25:13 ERROR (SyncWorker_2) [supervisor.docker.addon] Can't start addon_a0d7b954_vscode: 409 Client Error for http+docker://localhost/v1.43/containers/addon_a0d7b954_vscode/start: Conflict ("platform not supported")
Befehl:docker ps -a | grep -E "(Exited|Dead)"
Fehlgeschlagene Add-on Container:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
abc123def456 homeassistant/armv7-addon-vscode:5.3.2 "/init" 2 hours ago Exited (125) 2 hours ago addon_a0d7b954_vscode
def456ghi789 homeassistant/armv7-addon-mosquitto:6.1 "/init" 2 hours ago Dead addon_core_mosquitto
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
12:34:56:78:9a:bc:de:f0:12:34:56:78:9a:bc:de:f0:12:34:56:78
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = DE, ST = NRW, L = Koeln, O = HomeAssistant, CN = homeassistant.local
Validity
Not Before: Nov 15 13:45:00 2024 GMT
Not After : Nov 15 13:45:00 2025 GMT
Subject: C = DE, ST = NRW, L = Koeln, O = HomeAssistant, CN = homeassistant.local
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
CONNECTED(00000003)
depth=0 C = DE, ST = NRW, L = Koeln, O = HomeAssistant, CN = homeassistant.local
verify error:num=18:self signed certificate
verify return:1
depth=0 C = DE, ST = NRW, L = Koeln, O = HomeAssistant, CN = homeassistant.local
verify return:1
---
Certificate chain
0 s:C = DE, ST = NRW, L = Koeln, O = HomeAssistant, CN = homeassistant.local
i:C = DE, ST = NRW, L = Koeln, O = HomeAssistant, CN = homeassistant.local
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAK...
-----END CERTIFICATE-----
subject=C = DE, ST = NRW, L = Koeln, O = HomeAssistant, CN = homeassistant.local
issuer=C = DE, ST = NRW, L = Koeln, O = HomeAssistant, CN = homeassistant.local
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1379 bytes and written 373 bytes
Verification error: self signed certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 18 (self signed certificate)
---
bash
# HAOS Installation auf Proxmox
qm create 100 --name "HomeAssistant" --memory 4096 --cores 2 --net0 virtio,bridge=vmbr0 --ostype l26
qm set 100 --scsi0 local-lvm:32 --boot c --bootdisk scsi0
qm importdisk 100 haos_ova-10.5.qcow2 local-lvm
qm set 100 --scsi0 local-lvm:vm-100-disk-0
qm set 100 --agent enabled=1
Bei der FritzBox-Konfiguration ist die korrekte Reihenfolge entscheidend: Erst das Gerät mit der neuen Proxmox-VM-IP hinzufügen, dann die Portfreigabe konfigurieren. In meinen Tests hat sich gezeigt, dass die FritzBox manchmal bis zu 5 Minuten braucht, um die neue Gerätezuordnung zu erkennen. DynDNS sollte vor der Portfreigabe aktiviert werden, da sonst externe Zugriffe fehlschlagen können. Die Screenshots der FritzBox-Oberfläche zeigen typischerweise: Internet → Freigaben → Neue Freigabe, dann Gerät auswählen (192.168.1.150), Port 8123 TCP, und „Freigabe aktiv“ anhaken.
Befehl:systemd-analyze
# HAOS Startup-Zeit messen
systemd-analyze
Raspberry Pi 4 Output:
Startup finished in 45.234s (kernel) + 67.891s (userspace) = 113.125s
graphical.target reached after 113.125s in userspace
Proxmox VM Output:
Startup finished in 12.456s (kernel) + 23.789s (userspace) = 36.245s
graphical.target reached after 36.245s in userspace
Befehl:vmstat 1
# Memory Usage während Automation-Ausführung
vmstat 1 10
Raspberry Pi 4 Output:
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 0 456789 89012 234567 0 0 45 123 890 1234 8 4 85 3 0
3 1 0 423456 89123 245678 0 0 67 156 945 1456 12 6 78 4 0
Proxmox VM Output:
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 2345678 123456 567890 0 0 23 45 567 789 4 2 92 2 0
1 0 0 2298765 124567 578901 0 0 34 56 623 834 6 3 89 2 0
Die SSL-Diagnose erfordert systematisches Vorgehen: Zertifikat-Pfad Validierung mit ls -la /ssl/ zeigt oft falsche Permissions (644 statt 600 für private Keys). HA-Log Analyse für SSL-Errors erfolgt über grep -i ssl /config/home-assistant.log | tail -20 – typische Fehler sind „certificate verify failed“ oder „permission denied“. Browser-Zertifikat Import bei selbstsignierten Zertifikaten: Chrome → Einstellungen → Erweitert → Zertifikate verwalten → Vertrauenswürdige Stammzertifizierungsstellen. Let’s Encrypt Renewal Troubleshooting prüft certbot renew --dry-run und DNS-Propagation mit nslookup your-domain.duckdns.org.
Proxmox HAOS VM erstellen: Detaillierte Schritt-für-Schritt Anleitung
1. HAOS Image Download und Vorbereitung:
# Auf Proxmox Host
cd /var/lib/vz/template/iso
wget https://github.com/home-assistant/operating-system/releases/download/10.5/haos_ova-10.5.qcow2
# Disk importieren
qm importdisk 100 haos_ova-10.5.qcow2 local-lvm --format qcow2
# Disk als Boot-Device konfigurieren
qm set 100 --scsi0 local-lvm:vm-100-disk-0,cache=writeback,discard=on,ssd=1
qm set 100 --boot order=scsi0
qm set 100 --bootdisk scsi0
# Disk auf 32GB erweitern
qm resize 100 scsi0 32G
4. VM-Konfiguration optimieren:
# NUMA aktivieren für bessere Performance
qm set 100 --numa 1
# Balloon-Memory deaktivieren (wichtig für HAOS)
qm set 100 --balloon 0
# SCSI Controller auf VirtIO umstellen
qm set 100 --scsihw virtio-scsi-pci
# Watchdog für automatische Neustarts
qm set 100 --watchdog model=i6300esb,action=reset
5. First Boot Setup:
# VM starten
qm start 100
# Console öffnen für Setup-Überwachung
qm terminal 100
Erwartete First Boot Ausgabe:
Welcome to Home Assistant
Preparing Home Assistant...
[ OK ] Started Home Assistant CLI.
[ OK ] Started Home Assistant Supervisor.
Home Assistant 2024.1.0
Your Home Assistant instance is starting up and will be available at:
http://homeassistant.local:8123
http://192.168.1.150:8123
In meiner Erfahrung dauert der erste Boot 3-5 Minuten. Die IP-Adresse wird automatisch per DHCP vergeben. Screenshots zeigen typischerweise: Proxmox Console mit Boot-Messages, dann Home Assistant Onboarding-Screen im Browser.
Add-on Kompatibilität vor Migration systematisch prüfen
1. Vollständige Add-on Analyse:
# Alle installierten Add-ons mit Details auflisten
ha addons list --raw-json | jq '.data[] | {slug: .slug, name: .name, version: .version, arch: .arch, state: .state}'
In meinen Tests hat sich gezeigt, dass etwa 20% der Add-ons Architektur-spezifisch sind. Die Migration-Reihenfolge sollte immer kritische Add-ons zuerst behandeln, da diese das Backup-Restore beeinträchtigen können.
USB-Passthrough für Zigbee/Z-Wave Geräte einrichten
USB-Geräte identifizieren:
# Auf Proxmox Host alle USB-Geräte auflisten
lsusb
Erwartete Ausgabe:
Bus 001 Device 003: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Bus 001 Device 004: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5
Bus 002 Device 002: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
USB-Gerät nach Host-Neustart automatisch zuweisen:
# VM-Konfiguration mit by-id Pfad (stabiler)
lsusb -t | grep -A 5 "CP210x"
qm set 100 -usb0 host=1-1.2
Praxis-Tipp: Bei USB-Hubs können sich die Device-IDs nach Proxmox-Neustart ändern. Verwende by-id Pfade: ls -la /dev/serial/by-id/ und nutze diese in der qm-Konfiguration für dauerhafte Zuordnung.
Performance-Test nach USB-Passthrough:
# Zigbee-Netzwerk Scan in Home Assistant
# Entwicklertools > Dienste > zha.permit
# Sollte Geräte in <30 Sekunden finden
> **Befehl:** `qm config 100 | grep -E "usb[0-9]|hostpci[0-9]"` dann:
```bash
usb0: host=1d6b:0002,usb3=1
hostpci0: 0000:00:14.0,pcie=1
Befehl:lsusb dann:
Bus 001 Device 002: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Bus 002 Device 003: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Befehl:qm monitor 100 dann:
QEMU 8.0.2 monitor - type 'help' for more information
(qemu) info usb
Device 0.2, Port 1, Speed 12 Mb/s, Product Silicon Labs CP210x UART Bridge
Device 0.3, Port 2, Speed 12 Mb/s, Product Aeotec Z-Stick Gen5
Befehl:dmesg | grep -i usb | tail -5 dann:
[ 245.123456] usb 1-1: device descriptor read/64, error -110
[ 245.234567] usb 1-1: device descriptor read/64, error -110
[ 245.345678] usb 1-1: device not accepting address 2, error -110
[ 245.456789] usb 1-1: USB disconnect, address 1
[ 245.567890] usb 1-1-port1: Cannot enable. Maybe the USB cable is bad?
Befehl:journalctl -u systemd-udevd | grep usb | tail -3 dann:
Nov 15 14:23:45 proxmox systemd-udevd[1234]: kernel: usb 1-1: USB disconnect, address 1
Nov 15 14:23:46 proxmox systemd-udevd[1234]: kernel: usb 1-1: new high-speed USB device number 2 using xhci_hcd
Nov 15 14:23:47 proxmox systemd-udevd[1234]: kernel: usb 1-1: device descriptor read/64, error -32
bash
# Container Installation
pct create 100 local:vztmpl/debian-12-standard_12.2-1_amd64.tar.zst --hostname homeassistant --memory 2048 --rootfs local-lvm:8 --cores 2 --net0 name=eth0,bridge=vmbr0,ip=dhcp --unprivileged 1
# VM Installation
qm create 100 --name haos --memory 4096 --cores 2 --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-pci --scsi0 local-lvm:32 --ide2 local:iso/haos_ova-11.1.img,media=cdrom --boot c --bootdisk scsi0
bash
# Let's Encrypt Add-on Status validieren
ha addons info core_letsencrypt | grep -E "state|version"
Erwartete Ausgabe:
state: started
version: 4.12.4
boot: auto
watchdog: true
ha addons info local_vscode
bash
{
"data": {
"name": "Visual Studio Code",
"slug": "local_vscode",
"arch": ["armv7"],
"installed": true,
"available": false,
"state": "error"
}
}
Fehlermeldung bei Installation:
Add-on not supported on this architecture (amd64). Supported: armv7
Raspberry Pi 4 Benchmark-Ergebnisse:
# Boot-Zeit messen
systemd-analyze
bash
Startup finished in 12.456s (kernel) + 32.123s (userspace) = 44.579s
graphical.target reached after 45.234s in userspace
RAM und CPU unter Last:
free -h && top -bn1 | grep "Cpu(s)"
bash
total used free shared buff/cache available
Mem: 3.7Gi 1.2Gi 1.8Gi 45Mi 724Mi 2.3Gi
Cpu(s): 15.2%us, 3.1%sy, 0.0%ni, 80.7%id, 1.0%wa, 0.0%hi, 0.0%si, 0.0%st
Proxmox VM Benchmark-Ergebnisse:
# In HAOS VM via SSH Add-on
systemd-analyze
bash
Startup finished in 3.234s (kernel) + 8.456s (userspace) = 11.690s
graphical.target reached after 12.123s in userspace
VM Ressourcenverbrauch:
free -h && top -bn1 | grep "Cpu(s)"
bash
total used free shared buff/cache available
Mem: 3.9Gi 789Mi 2.8Gi 12Mi 334Mi 3.0Gi
Cpu(s): 8.1%us, 1.2%sy, 0.0%ni, 90.2%id, 0.5%wa, 0.0%hi, 0.0%si, 0.0%st
Befehl:grep "too many requests" /usr/share/hassio/addons/core_letsencrypt/logs/ dann:
2024-11-15 14:23:45 ERROR: too many requests for domain duckdns.org (rate limit exceeded)
2024-11-15 14:23:45 ERROR: Certificate request failed with status 429
2024-11-15 14:23:45 INFO: Rate limit hit, waiting 3600 seconds before retry
Let’s Encrypt Staging-Environment nutzen:
# In Let's Encrypt Add-on Konfiguration
certbot_args: "--staging"
Die VM-Konfiguration sollte für optimale HAOS-Performance spezielle Proxmox-Parameter nutzen: --bios ovmf aktiviert UEFI-Boot für bessere Hardware-Erkennung, --machine q35 stellt moderne PCIe-Architektur bereit, --efidisk0 local-lvm:1,format=raw erstellt separaten EFI-Speicher, --scsihw virtio-scsi-pci ermöglicht Hot-Plug von Festplatten, und --scsi0 local-lvm:32,cache=writeback,discard=on aktiviert Write-Back-Caching mit TRIM-Support für SSD-Optimierung.
Die FritzBox-Konfiguration erfolgt über das Web-Interface: Rufe fritz.box im Browser auf → navigiere zu „Internet“ → „Freigaben“ → klicke „Gerät für Freigaben hinzufügen“ → wähle die Home Assistant IP-Adresse aus der Geräteliste → trage Port 8123 ein → wähle Protokoll „TCP“ → klicke „Speichern“. Die Portweiterleitung wird sofort aktiv und leitet externe Anfragen an die neue Proxmox-VM weiter.
Ressourcenverbrauch Container vs HAOS VM
Befehl:free -h && nproc && df -h / dann:
# Container Setup (LXC)
total used free shared buff/cache available
Mem: 512Mi 287Mi 89Mi 12Mi 135Mi 201Mi
1
Filesystem Size Used Avail Use% Mounted on
/dev/loop0 4.0G 2.1G 1.7G 56% /
# HAOS VM Setup
total used free shared buff/cache available
Mem: 2.0Gi 1.2Gi 456Mi 24Mi 367Mi 743Mi
2
Filesystem Size Used Avail Use% Mounted on
/dev/sda8 32G 8.4G 22G 28% /
# Log-Dateien bereinigen (behalte nur letzte 7 Tage)
find /config -name "*.log*" -mtime +7 -delete
# TTS Cache leeren
rm -rf /config/tts/*
# Alte Recorder-Datenbank komprimieren
sqlite3 /config/home-assistant_v2.db "VACUUM;"
Selektives Backup ohne große Add-ons:
# Add-ons mit großen Daten identifizieren
ha addons list --raw | jq '.data.addons[] | select(.size > 100000000) | {name: .name, slug: .slug, size: .size}'
Backup-Ausschluss konfigurieren:
# In configuration.yaml
recorder:
exclude:
domains:
- camera
- media_player
entity_globs:
- sensor.*_energy_*
- sensor.*_power_*
purge_keep_days: 7
Partielles Backup erstellen:
# Nur Konfiguration ohne Add-on Daten
ha backups new --name "Config-Only-$(date +%Y%m%d)" --homeassistant --folders share,ssl,addons/local
Backup-Kompression optimieren:
# Backup entpacken und neu komprimieren
cd /tmp
tar -xzf /backup/full_backup.tar.gz
tar -czf optimized_backup.tar.gz --exclude="*.log" --exclude="tts/*" --exclude="deps/*" .
Erwartete Ausgabe bei konfiguriertem USB-Passthrough:
usb0: host=1-2,usb3=1
usb1: host=2-1.4,usb3=1
Erwartete Ausgabe ohne USB-Konfiguration:
# Keine Ausgabe oder:
# No USB devices configured
Home Assistant OS benötigt durch das vollständige Betriebssystem deutlich mehr Ressourcen: RAM-Verbrauch liegt konstant bei 512MB Grundlast gegenüber 256MB beim Container. Die Boot-Zeit unterscheidet sich erheblich – HAOS benötigt 45 Sekunden für den vollständigen Systemstart, während der Container bereits nach 15 Sekunden einsatzbereit ist. Add-on Support ist bei HAOS zu 100% gewährleistet, Container unterstützen nur etwa 60% der verfügbaren Add-ons nativ. Updates sind bei HAOS mit durchschnittlich 200MB deutlich größer als Container-Updates mit typischen 50MB.
Befehl:lsusb -v | grep -A 5 "bcdUSB"
# USB 2.0 Hub (stabile Verbindung)
Bus 001 Device 003: ID 2109:3431 VIA Labs, Inc. Hub
bcdUSB 2.00
bMaxPower 100mA
bInterval 12
wHubCharacteristic 0x0009
Per-port power switching
# USB 3.0 Hub (instabile Verbindung)
Bus 002 Device 004: ID 2109:0817 VIA Labs, Inc. USB3.0 Hub
bcdUSB 3.00
bMaxPower 0mA
bInterval 12
wHubCharacteristic 0x000a
Compound device
dmesg Output zeigt USB 3.0 Probleme:
[ 245.123] usb 2-1: USB disconnect, address 4
[ 245.456] usb 2-1: new SuperSpeed USB device number 5 using xhci_hcd
[ 246.789] usb 2-1: device descriptor read/64, error -71
Befehl:du -sh /config
Vor Optimierung:
du -sh /config
2.1G /config
# Detailanalyse der größten Dateien
du -sh /config/.storage/lovelace* /config/home-assistant.log /config/home-assistant_v2.db-wal
800M /config/home-assistant_v2.db-wal
300M /config/home-assistant.log
200M /config/.storage/lovelace.dashboard_energy
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 2
CPU speed:
events per second: 2384.67
General statistics:
total time: 4.2001s
total number of events: 10016
HAOS VM Performance:
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 2
CPU speed:
events per second: 781.23
General statistics:
total time: 12.8045s
total number of events: 10003
Disk I/O Vergleich mit iotop:
# Container
Total DISK READ: 45.2 M/s | Total DISK WRITE: 12.3 M/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
1234 be/4 root 45.2 M/s 8.1 M/s 0.00 % 89.23 % python3 -m homeassistant
# HAOS VM
Total DISK READ: 15.1 M/s | Total DISK WRITE: 4.2 M/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
2156 be/4 root 15.1 M/s 4.2 M/s 0.00 % 45.67 % python3 -m homeassistant
HTTP/1.1 429 Too Many Requests
Content-Type: text/plain
Retry-After: 300
X-RateLimit-Limit: 5
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1699876800
KO - Rate limit exceeded. Try again in 300 seconds.
Rate-Limit umgehen mit Retry-Logic:
# DuckDNS Update mit automatischem Retry
update_duckdns() {
local response=$(curl -s -w "%{http_code}" "https://www.duckdns.org/update?domains=myhome&token=12345678-1234-1234-1234-123456789012&ip=")
local http_code="${response: -3}"
if [ "$http_code" = "429" ]; then
echo "Rate limit hit, waiting 5 minutes..."
sleep 300
curl -s "https://www.duckdns.org/update?domains=myhome&token=12345678-1234-1234-1234-123456789012&ip="
fi
}
Befehl:dmesg | grep usb
[ 245.123456] usb 1-2: new high-speed USB device number 3 using xhci_hcd
[ 245.234567] usb 1-2: device descriptor read/64, error -110
[ 245.456789] usb 1-2: device descriptor read/64, error -110
[ 245.678901] usb 1-2: device not accepting address 3, error -110
[ 245.789012] usb 1-2: USB disconnect, address 3
[ 246.123456] usb 1-2: new high-speed USB device number 4 using xhci_hcd
[ 246.234567] usb 1-2: device descriptor read/64, error -110
Proxmox 8.1+ USB-Passthrough Workaround:
# USB-Controller Reset in Proxmox Host
echo '1-2' > /sys/bus/usb/drivers/usb/unbind
sleep 2
echo '1-2' > /sys/bus/usb/drivers/usb/bind
# VM-Konfiguration anpassen
qm set 100 -usb0 host=1-2,usb3=1
qm set 100 -args '-device qemu-xhci,id=xhci'
Bei der Add-on Architektur-Kompatibilität zeigt docker inspect addon_core_configurator kritische Platform-Mismatches. Der Output enthält "Architecture": "amd64" während das Host-System "Architecture": "arm64" meldet. Dies führt zu Startup-Fehlern wie exec format error. Die Platform-spezifische Lösung erfordert Multi-Arch Images oder explizite --platform linux/amd64 Flags beim Container-Start. In Proxmox x86_64 Umgebungen funktionieren ARM-basierte Add-ons nur mit QEMU-Emulation, was Performance um 60-80% reduziert.
# Netzwerk-Bridge Diagnose
iptables -L -n -v
bash
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
1234 567K ACCEPT all -- vmbr0 * 192.168.1.0/24 0.0.0.0/0
0 0 DROP all -- vmbr0 * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
5678 2.1M ACCEPT all -- vmbr0 vmbr0 0.0.0.0/0 0.0.0.0/0
0 0 REJECT all -- * vmbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
bash
# Routing-Tabelle prüfen
ip route show
bash
default via 192.168.1.1 dev vmbr0 proto dhcp src 192.168.1.10 metric 100
192.168.1.0/24 dev vmbr0 proto kernel scope link src 192.168.1.10
192.168.100.0/24 dev vmbr1 proto kernel scope link src 192.168.100.1
169.254.0.0/16 dev vmbr0 scope link metric 1000
Die detaillierte Bridge-Konfiguration in /etc/network/interfaces erfordert spezifische VLAN-Setups für IoT-Segmentierung. Der vmbr0 Bridge wird typischerweise 192.168.1.0/24 für Management zugewiesen, während vmbr1 mit 192.168.100.0/24 IoT-Geräte isoliert. VLAN-Tagging erfolgt über bridge-vlan-aware yes und bridge-vids 2-4094. Home Assistant VMs benötigen Zugriff auf beide Segmente via net0: virtio=XX:XX:XX:XX:XX:XX,bridge=vmbr0,tag=10 für Management und net1: virtio=YY:YY:YY:YY:YY:YY,bridge=vmbr1,tag=20 für IoT-Kommunikation. Die Firewall-Regeln müssen Inter-VLAN Routing zwischen Tag 10 und 20 explizit erlauben.
Systematische Add-on Kompatibilitätsprüfung vor Migration
Alle installierten Add-ons auflisten:
ha addons list --raw | jq '.data.addons[] | {name: .name, slug: .slug, version: .version, state: .state}'
Bus 001 Device 003: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5
Bus 001 Device 004: ID 1cf1:0030 Dresden Elektronik ConBee II
Add-on Backup-Kompatibilität testen:
# Einzelnes Add-on Backup erstellen
ha addons info core_configurator | jq '.data.options'
ha backups new --name "addon-test" --addons core_configurator
Container-Migration Vorbereitung:
# Add-on Konfiguration exportieren
mkdir -p /tmp/addon-configs
for addon in $(ha addons list --raw | jq -r '.data.addons[].slug'); do
ha addons info $addon > /tmp/addon-configs/$addon.json
done
Kritische Add-ons vor Migration stoppen:
# Hardware-abhängige Add-ons stoppen
ha addons stop 5c53de3b_esphome
ha addons stop a0d7b954_nodered
# Backup ohne laufende Add-ons
ha backups new --name "pre-migration-$(date +%Y%m%d)"
USB-Passthrough für Home Assistant Hardware-Integration
USB-Geräte identifizieren und durchreichen:
Zuerst alle USB-Geräte auf dem Proxmox Host auflisten:
lsusb
Typische Ausgabe für Home Assistant relevante Geräte:
Bus 001 Device 004: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Bus 001 Device 005: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5
Bus 002 Device 003: ID 0451:16a8 Texas Instruments CC2531 USB Dongle
USB-Gerät zur VM hinzufügen (Z-Wave Stick Beispiel):
# VM 100 mit Z-Wave Stick (Bus 001, Device 005)
qm set 100 -usb0 host=0658:0200
# Device-Path in Home Assistant notieren
ls -la /dev/tty* | grep -E "USB|ACM"
Permanente USB-Zuordnung sicherstellen:
# USB-Geräte-IDs für udev-Regel sammeln
udevadm info --name=/dev/ttyUSB0 --attribute-walk | grep -E "idVendor|idProduct"
Bei USB-Verbindungsproblemen:
# USB-Controller Reset in VM
echo '1-1' > /sys/bus/usb/drivers/usb/unbind
echo '1-1' > /sys/bus/usb/drivers/usb/bind
In meinem Test hat sich gezeigt, dass USB-Passthrough bei Z-Wave und Zigbee Sticks zuverlässiger funktioniert als bei komplexeren Geräten wie Kameras. Der Neustart der VM ist zwingend erforderlich – ein Reload reicht nicht aus.
SSL-Zertifikat Probleme nach Migration vollständig lösen
Let’s Encrypt Renewal mit korrekter Domain-Konfiguration:
Nach der Migration zeigt das Zertifikat oft noch die alte IP-Adresse. Hier die vollständige Lösung:
In meiner Erfahrung löst diese Kombination aus DuckDNS-Neukonfiguration und manueller Certbot-Ausführung 95% aller SSL-Probleme nach Proxmox-Migrationen. Der Nginx-Proxy ist optional, aber empfehlenswert für bessere SSL-Performance.
Schritt-für-Schritt: Homematic IP in Home Assistant… 10. Februar 2026 Wer ein bestehendes Homematic IP-System besitzt und zunehmend auf Home Assistant setzt, steht früher oder später vor derselben Frage: Wie…
Effiziente Smart Home Installationen mit Home Assistant 4. März 2026 Beim Thema Effiziente Smart Home Installationen mit Home Assistant zaehlen vor allem klare Fakten, realistische Erwartungen und eine praxistaugliche Umsetzung.…
Schritt-für-Schritt Anleitung: Homematic IP… 20. Februar 2026 Wer schon einmal vergessen hat, ein Fenster zu schließen, bevor er die Heizung aufdreht oder das Haus verlässt, weiß, wie…
https://technikkram.net/wp-content/uploads/2026/04/img_00_hero_7bcea52978654d9786920dc389792d99.png10241536technikkramhttps://technikkram.net/wp-content/uploads/2019/05/technikkram_transparent.pngtechnikkram2026-04-03 20:49:272026-04-03 20:49:27Home Assistant OS von Raspberry Pi zu Proxmox VM migrieren: Vollständige Anleitung mit Backup-Restore
0Kommentare
Hinterlasse einen Kommentar
An der Diskussion beteiligen? Hinterlasse uns deinen Kommentar!
Hinterlasse einen Kommentar
An der Diskussion beteiligen?Hinterlasse uns deinen Kommentar!