Home Assistant OS als VM: USB-Passthrough, Thread und Matter auf dem Heimserver

Wenn man sich mit Home Assistant beschäftigt, kommt früher oder später die Frage: Auf welcher Hardware und in welcher Form soll das Ding eigentlich laufen? Raspberry Pi, fertige Box, Docker-Container oder virtuelle Maschine? Ich habe mich für die VM entschieden – genauer gesagt für Home Assistant OS (HAOS) als KVM-VM auf meinem Linux-Heimserver. In diesem Artikel erzähle ich euch, warum, wie ich die Funk-Sticks in die VM bekomme und über welche Stolpersteine ich dabei gefallen bin.

Warum überhaupt eine VM?

Mein Heimserver macht deutlich mehr als nur Smart Home. Da laufen diverse kleine Dienste, Docker-Container, Skripte und ein paar Cronjobs. Home Assistant wollte ich trotzdem als vollwertiges Home Assistant OS betreiben und nicht nur als Container. Der Grund ist simpel: Nur mit HAOS bekommt ihr den Supervisor und damit die Add-ons (in der Oberfläche heißen sie inzwischen „Apps“), die eingebauten Voll-Backups und die Updates des Betriebssystems aus einer Hand.

Die VM ist für mich der Kompromiss aus beiden Welten:

• Der Server bleibt ein normales Linux, auf dem ich machen kann, was ich will.
• Home Assistant bekommt sein eigenes, von Home Assistant gepflegtes Betriebssystem.
• Wenn in der VM etwas schiefgeht, bleibt der Rest des Servers unberührt – und umgekehrt.

Technisch läuft das über KVM/QEMU mit libvirt. Home Assistant stellt dafür ein fertiges qcow2-Image bereit, das man als Festplatte einbindet. Wichtig: Die VM muss mit UEFI booten, sonst startet HAOS nicht.

Vergleich: VM, Bare Metal oder Docker

Ganz ehrlich, keine Variante ist perfekt. So sehe ich die Unterschiede nach einiger Zeit im Betrieb:

Bare Metal (HAOS direkt auf eigener Hardware) ist am einfachsten. USB-Sticks funktionieren einfach, es gibt keine zusätzliche Schicht. Der Nachteil: Die Hardware gehört dann ausschließlich Home Assistant. Wer einen kleinen Mini-PC wie einen Lenovo ThinkCentre Tiny nur für HA nutzen will, ist damit bestens bedient.

Docker (Home Assistant Container) ist schlank und flexibel, aber ohne Supervisor. Add-ons wie der OpenThread Border Router oder der Matter-Server müsst ihr dann selbst als eigene Container pflegen. Das geht, ist aber mehr Handarbeit – und genau da habe ich mir früher selbst ein Bein gestellt (dazu gleich mehr).

VM gibt euch den vollen HAOS-Komfort und lässt den Server trotzdem für andere Dinge frei. Der Preis ist etwas mehr Komplexität, vor allem bei allem, was mit USB-Hardware zu tun hat.

USB-Passthrough: Wie die Sticks in die VM kommen

Bei mir hängen zwei Sonoff-Sticks am Server: ein älterer ZBDongle-P mit TI-Chip für Zigbee (läuft in ZHA) und ein SONOFF ZBDongle-E, der als Thread-Funkmodul für den Border Router arbeitet. Beide werden per USB-Passthrough komplett an die VM übergeben. Für die VM sieht es dann so aus, als würden die Sticks direkt in ihr stecken, und in HAOS tauchen sie ganz normal unter /dev/serial/by-id/… auf.

Zigbee- und Thread-Stick hängen per Passthrough direkt an der VM.

In libvirt sieht so eine Zuweisung grob so aus:

<hostdev mode='subsystem' type='usb' managed='yes'>
  <source>
    <address bus='1' device='5'/>
  </source>
</hostdev>

Üblich ist eigentlich die Zuordnung über Hersteller- und Produkt-ID. Bei mir melden sich beide Sticks aber mit demselben USB-Seriell-Chip, also derselben Kennung – libvirt kann sie darüber nicht auseinanderhalten. Deshalb nutze ich die Adresse aus Bus und Gerätenummer. Der Haken daran: Die Gerätenummer kann sich ändern, wenn ein Stick abgezogen und neu eingesteckt wird. Wer das nutzt, sollte also im Hinterkopf behalten, dass nach einem Umstecken die Konfiguration angepasst werden muss.

In HAOS selbst verwende ich immer die by-id-Pfade und nie /dev/ttyUSB0 und Co. Die Nummerierung kann sich nach einem Neustart vertauschen, die by-id-Pfade enthalten dagegen die Seriennummer des Sticks und bleiben stabil.

Der Stolperstein: Wenn der Host die Sticks klaut

Mein größtes Problem hatte nichts mit Home Assistant zu tun, sondern mit dem Host. Irgendwann hatte ich auf dem Server einen kleinen Dienst eingerichtet, der die Sticks beim Start an den cp210x-Treiber binden sollte – ein Überbleibsel aus der Zeit, als Home Assistant und der Border Router noch als Docker-Container liefen und die Sticks direkt auf dem Host brauchten.

Mit der VM war das fatal: Sobald der Host-Treiber zugreift, verliert QEMU das Gerät. Zigbee in ZHA war plötzlich weg, der Border Router meldete Fehler, und ich habe eine ganze Weile in Home Assistant nach der Ursache gesucht, obwohl das Problem eine Ebene tiefer lag.

Meine Lehre daraus, die ich euch mitgeben will:

1. Bei USB-Passthrough darf auf dem Host kein Treiber an die Sticks gebunden sein.
2. Wenn auf dem Host plötzlich /dev/ttyUSB*-Geräte auftauchen, obwohl die Sticks an die VM gehen sollten, ist genau das passiert.
3. Alte Dienste und udev-Regeln aus früheren Setups gründlich aufräumen.

Nachdem ich den Dienst deaktiviert und die Sticks per virsh neu an die VM gehängt hatte, lief alles wieder. Zum Glück hatte ich ein Netzwerk-Backup von ZHA, das ich danach nur noch einspielen musste.

OpenThread Border Router und Matter-Server als Add-on

In HAOS laufen bei mir der OpenThread Border Router und der Matter-Server als offizielle Add-ons. Die Thread-Integration findet den Border Router automatisch, und neue Matter-Geräte binde ich ganz normal über die Companion-App ein.

Zwei Dinge musste ich dabei in der VM beachten:

• Backbone-Interface: Im Border-Router-Add-on habe ich das Netzwerk-Interface der VM explizit als Backbone eingetragen. Damit weiß der Border Router sicher, über welche Schnittstelle er mit dem Heimnetz spricht.
• IPv6: Thread und Matter leben von IPv6. Bei mir musste IPv6-Forwarding in der VM aktiv sein, damit die Thread-Geräte sauber aus dem Heimnetz erreichbar waren. Wenn Matter-over-Thread-Geräte zwar gekoppelt, aber ständig „nicht verfügbar“ sind, lohnt sich hier ein Blick.

Und dann noch eine Falle, die ich mir selbst gebaut hatte: Auf dem Host liefen noch alte Docker-Container mit einem zweiten Border Router und einem zweiten Matter-Server aus der Testphase. Die hatten mit der echten Instanz nichts zu tun, haben aber beim Debuggen für ordentlich Verwirrung gesorgt. Inzwischen sind sie gelöscht. Mein Rat: Doppelte Border Router und Matter-Server im selben Netz vermeiden, solange ihr nicht genau wisst, warum ihr sie braucht.

Was ihr bei einer HA-VM sonst noch einplanen solltet

Autostart: Die VM muss nach einem Neustart des Servers von selbst hochfahren. Klingt selbstverständlich, war bei mir aber anfangs nicht eingestellt – aufgefallen ist es erst nach einem Stromausfall. Mit virsh autostart ist das in einer Sekunde erledigt. Zusätzlich habe ich einen kleinen Watchdog, der prüft, ob Home Assistant nach dem Boot erreichbar ist, und mir sonst eine Push-Nachricht schickt.

Ressourcen: Home Assistant braucht nicht viel, aber gebt der VM genug Arbeitsspeicher und Speicherplatz für Datenbank und Backups. Knapp bemessener Speicher rächt sich spätestens beim nächsten großen Update.

Strom: Wenn alles auf einem Server läuft, hängt das ganze Haus an diesem einen Gerät. Eine kleine USV wie die APC Back-UPS BX750MI-GR überbrückt kurze Aussetzer und verhindert, dass die VM mitten im Schreibvorgang hart ausgeht.

Backups: Die HAOS-Backups sichern alles innerhalb der VM. Die VM-Definition mit den USB-Zuweisungen liegt aber auf dem Host – die solltet ihr separat sichern oder zumindest dokumentieren.

Fazit

Für mich ist Home Assistant OS in einer KVM-VM genau der richtige Weg: Ich habe den vollen Komfort mit Add-ons und Backups und kann den Server trotzdem für alles andere nutzen. Der einzige wirklich heikle Punkt ist USB-Passthrough. Wenn ihr einmal verstanden habt, dass der Host die Finger von den Sticks lassen muss, läuft das stabil. Wer dagegen nur Home Assistant betreiben will und keinen Server für andere Dinge braucht, fährt mit Bare Metal auf einem kleinen Mini-PC einfacher.