Home Assistant stellt Core- und Supervised-Installation sowie 32-Bit-Systeme ein
von caschy | 21 Kommentare
Home Assistant macht Nägel mit Köpfen und bekannt, dass ab sofort zwei Installationsmethoden und drei ältere CPU-Architekturen nicht mehr offiziell unterstützt werden. Diese Entscheidung, die ab Home Assistant 2025.6 greift, ist notwendig, um die Weiterentwicklung des Projekts voranzutreiben, und weil sie nur einen kleinen Teil der Nutzergemeinschaft betrifft. Ab der Version 2025.6 erhalten betroffene Systeme eine Benachrichtigung, die auf das Support-Ende in sechs Monaten (mit Release 2025.12) hinweist und eine Migration auf ein unterstütztes System empfiehlt.
Installationsmethoden vor dem Aus
Konkret betroffen sind die Installationsmethoden Home Assistant Core und Home Assistant Supervised. Home Assistant Core, bei der das System in einer Python-Umgebung läuft, ist nicht mit der Container-Installation (z. B. Docker) zu verwechseln. Bei Home Assistant Supervised wird ein eigenes Betriebssystem verwendet, auf dem der Supervisor und weitere Komponenten installiert werden.
Diese beiden Methoden sind als fortgeschrittene Installationswege bekannt und wurden nur von einem geringen Prozentsatz der Community gewählt. Wer diese Methoden weiterhin nutzt, kann dies tun und auch Updates einspielen. Nach Ablauf der sechsmonatigen Frist wird jedoch kein Support mehr geleistet. Verweise auf diese Installationsmethoden werden nach dem nächsten Release (2025.6) aus der Dokumentation entfernt. Zukünftig werden Home Assistant OS und Home Assistant Container die einzigen unterstützten Installationsmethoden sein.
Abschied von alten Architekturen
Zusätzlich werden drei ältere 32-Bit-Architekturen nicht mehr unterstützt: i386 (32-Bit x86), armhf (32-Bit ARM hard-float) und armv7 (32-Bit ARM). i386 wurde hauptsächlich vor 2003 von Intel und AMD genutzt, armhf und armv7 kamen bei sehr frühen Single-Board-Computern zum Einsatz, darunter die ersten Raspberry Pi Modelle. Nutzer dieser Architekturen erhalten ebenfalls eine Benachrichtigung nach dem Update auf 2025.6 mit Hinweisen zur Migration. Nach sechs Monaten wird der Support eingestellt, was bedeutet, dass keine weiteren Updates für diese Systeme mehr bereitgestellt werden.
Für weitere sechs Monate (bis Release 2025.12) wird die Funktionsfähigkeit dieser Installationsarten gewährleistet, um Nutzern Zeit zur Migration auf Home Assistant OS oder Container zu geben. Danach fallen sie in den Status „Unsupported“, was bedeutet, dass Fehlerberichte nicht mehr akzeptiert werden. Obwohl technische Updates weiterhin möglich sind, wird eine Migration empfohlen.
Für die i386, armhf und armv7 Architekturen bedeutet das Support-Ende ab Release 2025.12, dass keine Distributionen oder Container mehr für diese Plattformen erstellt oder veröffentlicht werden. Es wird keine Updates mehr geben, und Nutzer erhalten keinen Support von den Home Assistant Maintainern.
Die Gründe für die Entscheidung
Die Entscheidung, Core und Supervised nicht mehr zu unterstützen, basiert auf Daten der optionalen Analysen. Diese Installationsmethoden sind nicht nur für Nutzer komplexer in Installation und Wartung, sondern auch für das Home-Assistant-Team aufwendiger im Support. Während es früher gute Gründe für diese Methoden gab, sind diese für die meisten Anwender nicht mehr relevant. Home Assistant OS ist leistungsfähig, bietet zahlreiche Add-ons und lässt sich gut in einer virtuellen Maschine betreiben. Die Akzeptanz von Containern ist gestiegen, und Systeme verfügen über mehr Ressourcen. Der Anteil der Core- und Supervised-Installationen ist stetig gesunken und liegt derzeit bei 2,5 % bzw. 3,3 %.
Die Komplexität dieser Methoden führe zu mehr und schwerer zu lösenden Problemen, was das ehrenamtliche Supportsystem überproportional belastet. Dies bindet Ressourcen, die der Mehrheit der Nutzer mit einfacheren Installationsmethoden zugutekämen. Durch die Konzentration des Supports und der Dokumentation auf OS und Container soll das Onboarding für neue Nutzer deutlich verbessert werden.
Bei der Entscheidungsfindung wurde die Community aktiv miteinbezogen. Die ursprünglichen Vorschläge zur Einstellung des Supports wurden in Foren, auf GitHub, Discord und anderen Kanälen diskutiert. Dabei zeigte sich, dass die Begrifflichkeiten „Core“ und „Supervisor“ für Komponenten des Home Assistant OS und gleichzeitig für Installationsmethoden verwirrend sein können. Zudem wurden Installationen auf unerwartete Weisen genutzt, und viele Nutzer waren sich nicht bewusst, dass ihre Konfiguration bereits inoffiziell war.
Ein wichtiger Wunsch der Community war eine bessere Anleitung zur Migration. Viele wussten nicht, dass die Backup- und Wiederherstellungsfunktionen für alle Installationsmethoden erweitert wurden, was den Übergang erheblich vereinfacht. Für euch wichtig zu wissen: Es gibt Möglichkeiten zu überprüfen, welche Version ihr einsetzt, eine FAQ und Anleitung zur Migration. Das könnt ihr alles in der Ankündigung lesen.
Transparenz: In diesem Artikel sind Partnerlinks enthalten. Durch einen Klick darauf gelangt ihr direkt zum Anbieter. Solltet ihr euch dort für einen Kauf entscheiden, erhalten wir eine kleine Provision. Für euch ändert sich am Preis nichts. Partnerlinks haben keinerlei Einfluss auf unsere Berichterstattung.
Wird geladen ...
Danke für die Info
Da bin ich mit meinem Futro 930 für 20€ ja auf der sicheren Seite.
Ich fände es super, wenn die Docker-Version endlich Add-ons unterstützen würde.
Die Daten könnten dann ja auf einem zweiten permanenten Volume liegen?
Derzeit nutze ich UmbrelOS, weil dort einfacher Zugriff auf die Daten im Container möglich ist und der Matter-Server ebenfalls einfach installierbar ist.
Naja aber die Addons sind halt auch „nur“ andere Docker-Container – würde als eher schwierig werden. „Parallel“ den HA- und weitere Docker-Container betreiben ist ja kein Problem.
Wäre gut wenn es da eine Lösung geben würde ich nutze allerlei Addons. Ein Grund der mich abhält komplett auf Docker zu setzen.
ich nutze HA OS und setze trotzdem alles als weiteren docker container auf. da ist man deutlich flexibler. Ist bei der HA Dockerversion ebenfalls möglich und man muss auf kein Feature verzichte.
Diese „add-ons“ sind doch einfach nur Fremdprodukte wie MQTT oder Grafana, die nichts mit HA zu tun haben. Die kann man auf jeder Maschine installieren, es gibt keine Abhängigkeit zu HA.
Finde ich nicht gut. Nun ist man gezwungen eine zweite Hardware zu nutzen oder muss eine VM einrichten, oder auf Add-ons verzichten und Docker nutzen.
HA OS lässt keine andere Container zu, also wäre die Hardware nur für HA.
Wenn ich es in einer virtuellen Machine laufen lasse habe ich zwei Nachteile. Ich verschwende doppelt Ressourcen. Doppelt Linux und ich muss fix Kerne und RAM zuweisen. Mit Docker wäre es dynamisch.
Docker supporten sie aber keine Add-ons.
Käse. Habe frisch HA supervised auf einem Intel NUC Mini PC mit Debian eingerichtet und dann Docker Container für Nextcloud und Paperless dazu. Auf meinem Raspberry 3B mit 1GB RAM ist HA inzwischen leider regelmäßig abgestürzt.
Dann hast du aufs falsche Pferd gesetzt. komme von einer Dockerumgebung und bin bei gleicher Hardware. Intel 4105 auf Proxmox gewechselt. meine Anwendungen laufen jetzt entweder als VM oder als LXC Container. Ich muss sagen, obwohl ich kaum Ahnung habe, war es viel einfacher und schneller und intuitiver als Docker. Das System ist (komischerweise) weniger ausgelastet und stabiler. Ich kann es nur empfehlen. Am besten fand ich, das mein Backup aus dem Docker Container ohne Probleme geschluckt wurde und es sofort auf Anhieb lief. Also, trau dich…
Eine HA OS VM kann ich ja auch auf Debian einrichten..
Wenn ich richtig recherchiert habe ist der Vorteil bei Proxmox, dass ich die CPU Kerne nicht dauerhaft binde. Nice.
Die Zuweisung von Peripherie empfinde ich bei VMs als stressiger. Scheint als käme ich bald nicht drumherum.
Was meinst Du mit Zuweisung von Peripherie ist stressig bei VMs. Falls Du bspw. das Durchreichen von USB-Devices vom Host zur VM meinst: Unter Proxmox geht das per Klick in der Proxmox-Oberfläche. Die Zeiten in denen man so etwas per Config-Dateien oder gar auf der Command-Line machen musste, sind schon recht lange vorbei.
Das ist der Vorteil jeder Virtualisierungslösung. CPU und RAM fest an eine VM binden ist immer eine vom Standard abweichende Einstellung. Und hat nichts mit Container vs. VM zu tun.
Eine virtuelle Maschine mit HA OS benötigt nur sehr wenig Ressourcen. Damit ist man bestens bedient: one click Updates funktionieren und Add-On sind auch kein Problem. Auf der gleichen Hardware kann dann auch noch was anderes laufen. Probier es aus. Ich habe es auch nicht bereut, läuft super und fühlt sich seit dem auch „runder“ an.
„Doppelt Linux und ich muss fix Kerne und RAM zuweisen.“ Hä? Kerne muss man nicht zuweisen, und auch das RAM kann man variabel halten (nennt sich Balooning). Mini-PC, Proxmox (oder auch was anderes) drauf und HA als VM laufen lassen. Läuft stabil wie ein Panzer bei mir seit Jahren und die Backups mit Proxmox Backup Server gehen ruckzuck. Also auf jedem N100 Mini-PC läuft das wie eine Rakete und man hat noch viel Ressourcen für andere Sachen übrig.
Dann fährst Du aber doppelt „blöd“ (sorry, nicht anmassend gemeint!). Du machst das, was Du machen solltest, nämlich entweder Docker und weitere Docker-Container im Sinne von Add-on, oder eben HA-OS und dann Add-ons.
Im Grunde ja ohnehin fast gleich, und es gibt ja kaum Add-ons, die man nicht auch als Docker-Container einsetzen könnte.
Unabhängig davon würde ich dringend empfehlen, sich auf HA-OS einzuschiessen und HA wirklich für sich laufen zu lassen. Je mehr man mit HA macht, umso unangenehmer werden Ausfälle, und die „züchtest“ Du quasi selbst, in dem Du mit eigenen Container arbeitest.
Ich hab echt schon sehr viele Installationen begleitet und gemacht, und ich kann eins definitiv sagen: am stabilsten ist seit längerer Zeit HA-OS mit Add-ons. Allerdings sind 1GB Ram auch wirklich sehr wenig (mittlerweilen).
Wenn ich von jemanden gefragt werde, wie man HA installieren soll, wäre meine Empfehlung kleiner PC (gerne gebraucht), Proxmox und eine eigene VM. So hab ich das selbst seit Jahren laufen, und ich kann nicht von Problemen berichten. 🙂
Ich finde es auch schade und werde wohl dann offiziell ein unsupoorted System betreiben müssen:
Ich habe einen Pi 4 mit 8GB RAM, der neben HA Supervised auch das MagicMirror Projekt laufen hat, somit ist mein Mirror auch gleichzeitig die Zentrale fürs Smarthome. lief super mit den Ressourcen…
Man kann ja weiterhin HA Core benutzen. Bei Problemen hilft nur niemand vom HA-Team weiter.
hallo in die Runde,
also ich habe auch vor Proxmox als Unterbau zu nutzen.
War bisher immer auf Trichter, wenn möglich nur LXC’s für die einzelnen Anwendungen etc. zu verwenden. Ja teilweise ist VM notwendig…
also hier nochmal ganz klar meine Frage dazu:
auf Proxmox gehostetes HA als VM oder LXC?
vielen Dank und Grüße M
VM!
LXC wird vom HA Team ausdrücklich nicht empfohlen.
Als VM. Läuft problemlis.
Wenn sie meinen Home Assistant Supervised einzustellen wird auf jeden Fall der Cloud Abo gekündigt nutze den Home Assistent auf einen 13100 mit 32 GB RAM auf Arch Linux. Dann geht’s eben notfalls zurück zu iobroker
Weil? Was ist das Alleinstellungsmerkmal von der supervised Installation, was du mit keiner der zahlreichen anderen Installationsarten hast? Ich wage zu behaupten bei 32GB Ram, kannst du das locker auch aus VM unter KVM laufen lassen ohne einen spürbaren Nachteil zu haben. Oder per Docker.