Home Assistant stopt ondersteuning van 32bit-, Core- en Supervised-installaties

Home Assistant is in de toekomst alleen nog te gebruiken op 64bit-systemen. 32bit-systemen, waaronder oude Raspberry Pi's zoals de Pi 2, worden niet meer ondersteund. Ook krijgen de Home Assistant Core- en Supervised-installatiemethoden over enige tijd geen support meer.

De makers van Home Assistant waarschuwen dat installaties van het smarthomebesturingssysteem binnenkort niet meer worden ondersteund op oudere cpu-architecturen. Het gaat specifiek om de 32bit-versies van drie architecturen: i386, armhf en armv7. Die laatste twee zijn de Arm-architecturen waarop de originele Raspberry Pi en de Pi 2 zijn gebaseerd. Volgens Home Assistant gebruikt minder dan een procent van de gebruikers dergelijke installaties.

Vanaf versie 2025.6 van de software, die in juni verschijnt, krijgen gebruikers van deze systemen een waarschuwing te zien. De ondersteuning loopt nog een half jaar door. Vanaf versie 2025.12 kunnen gebruikers het beste migreren naar een nieuwer systeem, zeggen de makers. Het gaat overigens om ondersteuning van nieuwe features, maar de besturingssystemen krijgen een 'deprecated'-status. Daarmee werken ze mogelijk nog wel, maar kan de installatie problemen opleveren. "Binnenkort zijn installaties via Home Assistant OS en Home Assistant Container de enige ondersteunde methoden", zeggen de makers.

Home Assistant geeft ook twee installatiemethoden die deprecated-status. Dat zijn de installaties via Home Assistant Core waarbij een systeem in een Python-omgeving draait en Home Assistant Supervised waarbij gebruikers zelf een besturingssysteem installeren en daar de Supervisor en andere Home Assistant-onderdelen bovenop draaien. Ook die worden over een half jaar niet meer ondersteund. Home Assistant zegt dat die installaties maar door weinig gebruikers werden gebruikt.

Reacties (98)

[aequitas]

Ik schrok even, want Core blijft toch wel de favoriete installatie methode voor mijn eigen setup en development. Maar als je onderin de FAQ kijkt (https://www.home-assistan...requently-asked-questions) dan zeggen ze dat je Core nog wel kan gebruiken, maar dat het alleen niet meer gedocumenteerd wordt of support krijgt. Je kan op eigen risico gewoon de Python packages blijven installeren en ook installaties zoals https://wiki.nixos.org/wiki/Home_Assistant blijven mogelijk.

Ik hoop dat hier later geen verandering in komt. Dat destijds support voor een pure YAML configuratie gedropped is was wel zuur. Vooral omdat het binnen Home assistant niet altijd een kwestie was van 'niet supporten' maar soms gewoon actief tegenwerken van andere open source projecten https://news.ycombinator.com/item?id=27505277, hopelijk zijn ze daar nu overheen gestapt.

[Gizz]

Uit nieuwsgierigheid: wat maakt HA Core in jouw situatie beter geschikt dan HA Container? Wat raak je kwijt aan functionaliteit als je naar Container overstapt?

[BasilFX]

Ik draai sinds het begin Core, omdat containers (of een OS dat containers host, zoals HAOS) toch vaak de nodige overhead met zich meebrengen. Het is niet veel, maar wel genoeg om de CPU (in mijn geval een Intel) minder in diepere C-States te krijgen, dus meer verbruik.

En soms is het niet de container, maar de bijbehorende daemons. Laatst nog een bug gerapporteerd voor sysbox, bijvoorbeeld.

[Reactie gewijzigd door BasilFX op 23 mei 2025 10:59]

[Travelan]

Het hele ding van containers is dat het vrijwel geen overhead heeft. Welke 'overhead' vind je zo erg dat je je in bochten wil blijven wringen? Heb je gemeten dat er meer verbruik is? Ik denk dat het eerder een configuratie issue is dan dat het aan containerization zelf ligt.

[Reactie gewijzigd door Travelan op 23 mei 2025 11:43]

[BasilFX]

Mijn server doet wel meer dan alleen Home Assistant draaien. Het zelf draaien van Core vind valt dus wel mee, ten opzichte van de andere dingen.

Waar containers goed in zijn, is isolatie. Maar in de orchestratie van zaken over de hele linie niet. Ik kan met een paar commando’s zo een aantal kopieën van een hele stack van iets draaien, ieders met eigen database, logging en andere faciliteiten. Maar die starten ieders hun eigen init.d, flushen allemaal hun logs op hun moment naar schijf, draaien op hun momenten de dagelijkse cronjobs of doen op hun momenten de database cleanups. Ja, hier is een hoop aan te tunen. En met ‘goede’ containers kun je een hoop configureren (centrale DB, centrale logging, etc.) Tot je op het punt komt dat je je realiseert dat die (community) containers niet zo makkelijk meer zijn, je alle containers zelf opnieuw aan het bouwen bent, en je isolatie toch niet meer zo strict is. Dat was voor mij de reden om daar vanaf te stappen, lange tijd terug.

Het is dus niet zo zeer de overhead van extra cycles of memory van de container (runtime) zelf, maar meer de extra cycles door de inhoud van de containers zelf. Los daarvan zijn er genoeg benchmarks te vinden die wel verschil laten zien tussen ‘bare metal’ en containers, en in veel gevallen is er wel sprake van overhead, al dan niet verwaardsloosbaar. Hier een voorbeeld.

In energieverbruik zie ik dit terug in zaken zoals package C-States, aantal spin-ups van schijven, en algeheel verbruik aan de stekker. Doel van mijn server is zo idle mogelijk te blijven, dus elke watt meer of minder zie ik wel.

Voor HAOS is de opzet perfect. De genoemde problemen van duplicatie heb je daar in mindere mate, geniet je van stabiliteit, heb je meer security en zal de overhead beperkt zijn.

[Reactie gewijzigd door BasilFX op 23 mei 2025 15:43]

[BasilFX]

Orchestratie is een breed begrip. Mijn reactie stelt duidelijk dat ik het niet heb over container-orchestratie maar orchestratie onder processen onderling. En fancy terms zoals C-states, spin-ups en cycles zijn in mijn optiek niet zo fancy. Er wordt mij gevraagd of ik dit meet, en dat doe ik aan de hand van dat soort zaken.

Wil je het zelf ook eens meten? In veel Linux-distributies is het een kwestie van `sudo apt install powertop` en daarna `sudo powertop`. Kun je ook eens zien wat je server wakker houd.

Ieder z'n ding.

[The Realone]

Maar in alle eerlijkheid, nu haal je wel enterprise toepassingen en thuisgebruik door elkaar heen. Containers zijn juist bij uitstek geschikt voor exacte, voorspelbare en consistente orchestratie. Maar zoals je al zegt hangt één en ander af van de kwaliteit van de image die je gebruikt. Maar is dat nu echt iets wat je wenst bij een thuisomgeving? Ik scrape voor de lol mijn stdout en stderr met promtail naar Loki, maar dat is enkel omdat ik dat voor mijn werk ook zo doe. Die zeldzame keer dat ik iets wil troubleshooten in mijn homelab kan ik prima af met de logs in de container.
De win voor mijn homelab bij het gebruik van containers is juist die consistentie en portabiliteit.

[BasilFX]

Iedereen zal zijn wensen hebben met zijn of haar homelab. Voor mij is het een sport een energiezuinige server te maken, en er is een reden dat we daar een actief topic van hebben op het forum.

Die voorspelbaarheid en consistente orchestratie komt mede door die isolatie, dat ontken ik ook niet. Mijn punt is vooral dat als ik een X aantal containers draai, daar de nodige overhead in zit omdat die containers onderling niet afspreken van "Goh, laten we alle disk gezamenlijk orchestreren, zodat we maar 1x per 24 uur die schijven hoeven wakker te maken." En dat is allemaal wel te configureren, maar dan is het niet meer een kwestie van `docker run <image name>` meer. Ik hoop dat je m'n punt hiermee snapt.

Voor thuisgebruik is het fijn dat je in een add-on library een applicatie kan starten. Dat het op de achtergrond een container is met z'n eigen database server et cetera, zal voor de gemiddelde gebruiker niet uitmaken.

[Reactie gewijzigd door BasilFX op 23 mei 2025 16:34]

[koekemannetje]

Ik denk je meer energie uitgeven op energie besparing dan je bespaar geen containers gebruik 🫣

[air2]

Als ik dit allemaal lees zou dat prima kunnen, maar daar is het hier ook tweakers voor. Dit is juist HET voorbeeld van tweaken. De sport zit vooral in het twerken natuurlijk! Ja dat kost tijd en energie, dat is de hobby. Die tijd en energie stopt een ander in muziek maken, of lego bouwen etc. Ik vind het fantastisch dat mensen zo op de watt weten te optimaliseren.

[mvn23]

De sport zit vooral in het twerken natuurlijk! Ja dat kost tijd en energie, dat is de hobby.

Bij deze, nominatie voor typo van de week!
[/offtopic]

[air2]

Hahah stomme autocorrect. Ik had dat al een keer gecorrigeerd. Maar windows blijft er koppig twerken van maken.

[Jeanpaul145]

Wat een container suboptimaal doet is dat het alle dependencies (minus mss glibc) bevat, en daarmee dus packages dupliceert.
Maar toegegeven, hetzelfde kan gezegd worden over de meeste OSes überhaupt.

Het enige OS dat ik ken dat dat echt anders doet is NixOS, dat alle pkgs in een zogeheten nix store (gewoon een directory, standaard onder `/nix/store/`) opslaat. Wanneer je dan een nieuwe pkg installeert die een dependency heeft die al in de Nix store staat, dan wordt die dependency gewoon hergebruikt, wat dus ruimte bespaart op je hard drive of NVMe disk.

[Concept8]

Dat packages bij containers (of venvs zoals in Python) meerdere keren zouden kunnen bestaan is één van de grote voordelen van containerisation, toch? Dat geeft juist de garantie dat de juiste versies van dependencies beschikbaar zijn. Bij gedeelde packages is het maar afwachten of handmatig heel goed opletten of alle dependents van een package met een nieuwe versie overweg kunnen. Dat is de schijfruimte meer dan waard vind ik.

In het geval van de HA Docker container is het stukje dat mogelijk dubbel op je schijf staat echt beperkt. De hele image op de repo is 1.8 GB. Geen idee hoeveel daarvan HA zelf is en wat de dependencies zijn, maar dat kan niet meer dan een GB zijn, toch?

[Jeanpaul145]

Bij gedeelde packages is het maar afwachten of handmatig heel goed opletten of alle dependents van een package met een nieuwe versie overweg kunnen

Dit is dus niet het geval bij NixOS. Daar is elke versie van elke dependency een aparte package (met een andere hash om ze verschillende packages gegarandeerd uit elkaar te kunnen houden). Door dit te doen wordt het probleem dat je noemt (dat ook wel het DLL-hell probleem wordt genoemd) vanutt de wortel opgelost, zonder daar consessies op te hoeven doen.
Daarnaqst definieert elke package (een derivation in de Nix wereld) exact welke dependencies het nodig heeft, wat dus het "maar werkt het met deze versie van de dependency?" aspect oplost door te garanderen dat als je NixOS rebuild / update slaagt, het programma in kwestie net zo zal werken als op elke andere Linux distro.

[Travelan]

Nix is echt nice! Én Nederlands! Mag gezegd worden toch ;-)

[jurroen]

Ik gebruik zelf HA core, in plaats van een andere methode, omdat ik het dan op mijn OpenBSD en/of HardenedBSD machines kan uitvoeren. Als (gedeeltelijk) Python dev voel ik mij ook super comfortabel in venv's en is dat een stuk makkelijker te doorgronden voor mij dan een container - of nog erger, een heel OS.

Dat gezegd hebbende, bij elke update moet ik wel een patch toepassen omdat het anders weigert te draaien. De core doet een check of de host Windows, Mac of Linux is en doet anders een exit. Mijn patch om het te veranderen naar een waarschuwing was niet echt heel positief ontvangen Het is wat het is, ik had mijn patch zelf al geautomatiseerd.

Maar goed, misschien toch maar eens migreren naar Home Assistant OS dan. Want de home automation is gewoon keiharde kritieke infrastructuur binnen ons huishoudem.

[koekemannetje]

Het is goed nieuws voor jouw, FreeBSD is altijd "not supported" dus geen verandering voor jou.

[Joostlek]

We gebruiken core ook voor development, dus die zal niet zo snel verdwijnen!

[Gizz]

De ondersteuning loopt nog een half jaar door. Vanaf versie 2025.12 kunnen gebruikers het beste migreren naar een nieuwer systeem, zeggen de makers. Het gaat overigens om ondersteuning van nieuwe features, maar de besturingssystemen krijgen een 'deprecated'-status.

Dit klopt volgens mij maar half. Vanaf 2025.6 zijn ze deprecated, vanaf 2025.12 zijn ze unsupported.

Unsupported heeft niet alleen met nieuwe features te maken; je kunt ook geen issue inschieten op github als je ergens een probleem mee hebt. De community gaat je via de reguliere route niet meer helpen:

However, after those six months have elapsed, these methods will become unsupported, which means issue reports will no longer be accepted

[Joostlek]

Dat verhaal rondom issues zal vooral opgaan voor issues die voortvloeien uit je installatie type. Want als jij een terechte bug indient omdat Home Assistant een waarde verkeerd uitleest heeft dat natuurlijk niks te maken met hoe jij het draait.

[incapable]

Nou, nee niet echt.
Als je vanaf een oude unsupported omgeving komt met een "terechte" bug, is het alsnog een zoektocht of het überhaupt nog een ding is op de nieuwe wel supported omgeving.

Als jij update naar een nieuwe home assistant versie op die omgevingen en iets werkt niet meer, is dat echt jammer maar helaas

[Joostlek]

Ik probeer vooral aan te geven dat niet alle bugs daaruit voortkomen.

Het is niet de bedoeling dat deze deprecation een heksenjacht teweegbrengt waarbij wij alle issues sluiten die niet uit een supported systeem komen.

[incapable]

Snap ik, en daar heb je zeker gelijk

Maar lijkt me dat voor openstaande issues simpelweg gekeken moet worden of het nog voor komt op nieuwe platformen, zo ja, oplossen, zo nee, sluiten.

Ik denk dat dat de enige reële manier is om er mee om te gaan

[sniker]

tja dan heb je wel een probleem als het een lastig te reproduceren issue is, dan krijg je de opdracht installeer eens HAOS of container ipv core/supervised.

Dus in theorie klopt je antwoord in de praktijk is het aan jou om te bewijzen dat je probleem niet aan je installatie ligt. En dat moet dan meestal door alsnog een supported installatie te doen en het probleem daarop te reproduceren.

[vrow]

Meestal krijg je ook wel bijval (of juist niet) van andere mensen die ook even proberen wat jij meldt. Dan weet je al heel snel of meerdere mensen er last van hebben en dan komt de oplossing ook vaak snel.

Het zijn allemaal enthousiaste users en developers die, deel vrijwillig, deels betaald, proberen om een mooi systeem te maken. En jij werkt daaraan mee door een bug zo uitgebreid mogelijk te omschrijven zodat ze er snel wat mee kunnen. En wat ik zeg: andere gebruikers gaan heel vaak ook dat testen wat jij meldt en dan ben je echt wel snel achter waar het aan ligt.

[Dennism]

Die bug kan dan wel terecht zijn, maar het zal maar de vraag zijn of men die in behandeling zal nemen als je bijvoorbeeld alleen logs of een reproductie manier hebt via een unsupported installatie.

Bij veel software boeren zal dan toch echt het eerste antwoord op zo'n ticket zijn 'upgrade naar versie X die wel supported is, en als het dan nog te reproduceren is horen we het graag'.

[Joostlek]

Bij Home Assistant zijn we er aardig goed in geworden om te zien wat de aard van de bug is. Dus tenzij jij met iets super obscuurs aankomt zal dit best meevallen.

Om als voorbeeld te nemen, supervised draait in principe de container. Dus als iemand een issue opent omdat een entity de verkeerde waarde geeft, is de kans miniem dat dit te maken heeft met je installatie.

Maar stel jij report een issue wegens netwerk issues, ja dan is de kans groter dat het aan je installatie methode ligt en dan ben je op jezelf aangewezen.

[jjanssen]

In de tabel op de pagina https://www.home-assistant.io/installation/ kun je precies zien waarom ik Supervised draai op een Pi5 waar ik ook andere software op heb draaien:

• mogelijkheid voor addons
• one-click-updates*

Om die mogelijkheden te behouden moet ik over op HAOS, maar ik wil juist een eigen OS draaien voor alle andere zaken. Blijkbaar moet ik dan HAOS in een VM gaan draaien maar dat vind ik overkill t.o.v. een container. En het betekent denk ik weer veel uitzoekwerk, onder andere over remote benaderen van config-files en media... Jammer.

*Ik weet niet precies wat dat is want ik weet niet beter.. moet je in de andere versies allerlei updates handmatig doen? Ook jammer.

[Robsato]

Als je naar de vereisten van Supervisor kijkt dan kom je bij ADR-0014 uit.

Daarin staat bij "supported conditions" dat je geen additionele software mag installeren. Dus je huidige setup is al unsupported.

Een VM is zichtbaar als een losse machine op het netwerk (als je bridge mode kiest). Als je op HAOS de Samba addon installeert dan kan je via een share bij je files. Ik denk dat een VM opzetten makkelijker is dan supervisor installeren. Enige complexe is soms gebruik van hardware dongles. Je kan trouwens een backup maken van je huidige install en die terug zetten op HAOS.

One click upgrade is denk ik gewoon dat je in HA een update notificatie krijgt en je daar op klikt om je HAOS te updaten ipv met apt get ofzo aan de slag moet.

[i-chat]

persoonlijk zou ik liever supervised in docker draaien, met dus de voordelen van supervised maar niet de nadelen van een vm, het enige probleem zou zijn dat je DiD werkende moet krijgen maar op courante hardware is dat zeker geen groot issue.

[jjanssen]

Nou ja Supervised installeren was ook niet meer dan één file downloaden en één commando uitvoeren. Maar goed, ik hoop dat het meevalt. Dank voor de info over bridge mode.

[Mars Warrior]

Het zijn allemaal Docker containers.

Ze zouden dus ook alles netjes als een compose stack kunnen uitleveren, maar dat is nog nooit gedaan.

Op die manier zou je namelijk én een "gecertificeerde" HA Stack kunnen draaien in zijn eigen netwerk, én je eigen docker containers.

Maar dat zal wel geen tijd aan besteed worden. De meeste gebruikers willen een simpele rechttoe-rechtaan installatie, en dan is Docker denk ik veels te technisch.

[i-chat]

dat vind ik eigenlijk niet eens zo'n gek idee, nextcloud doet dat met nextcloud-AIO ook heel lekker,
phpfpm redis, postgres apache en eventuele addons draaien netjes in een eigen stack en het is via de mastercontainer super-easy te onderhouden.

[daft_dutch]

Er is een officeel qcow image de pi5 arch64 dus libvirt installeren en je hebt supported HAOS

Helaas is er geen documentatie.
https://github.com/home-assistant/operating-system/releases

[MikeyMan]

Ja zo ben ik ook ooit in een supervised installatie terecht gekomen. De addons.

Vraag me vooral af hoe je nu naar een wel supported installatie type komt. Niet zo'n zin om weer from scratch te beginnen eerlijk gezegd.

[Amanoo]

Begrijpelijk. Sowieso begint Home Assistant wel enigszins RAM te vreten. Niet super veel, maar op een Pi 3A wilde het al niet meer lekker draaien omdat een halve GB RAM echt niet voldoet. Een Pi 2A zou qua RAM nog net kunnen. Moet je ook niet teveel met ESPHome klieren, want dat compileren duurt wel even. En een Pi 1 is hem gewoon echt niet meer.

Al die verschillende versies zijn verder ook wel erg lastig. Dan zit je je toch al gauw af te vragen wat je nu precies moet hebben. Container heeft alleen geen addon support, in tegenstelling tot supervised. Dat is wel een beetje jammer. Voor de volledige feature set blijft dan alleen OS over. Maar zelf draaide ik die toch al in een VM op mijn server.

[i-chat]

op een nuc (ex chromebox) met inel 30xx dual core en 4gb ram had ik met een paar plugins soms al behoorlijke lagg bij het uitvoeren van commando's dat kan wellicht deels hebben gelegen aan de opslag kaart maar zeker niet ten volle.

[Milt]

Ligt het aan mij of is naamgeving hier ook verwarrend? Ik draai HA op dedicated Odroid hardware en krijg iedere maand updates van o.a. Home Assistant Core. Dus ik schrok... Maar als ik dan ga kijken via Settings -> System -> Repairs en dan via het drie puntjes menu naar System Information dan blijk ik toch een installation type "Home Assistant OS" te hebben. En die blijft dus wel supported. Misschien is de naamgeving logisch als je deep into HA bent maar voor iedereen die net als ik schrok, check het even op bovenstaande manier.

[Kroesss]

Dat kan inderdaad verwarrend overkomen, eens.

HA OS is (zoals de naam doet vermoeden) een volledig OS. In dat OS zit HA Core al geinstalleerd. Wat nu unsupported gaat worden, is het installeren van alleen HA Core. Dat is gewoon om allerlei variabelen in het onderliggende OS uit te sluiten bij meldingen over bugs.

[verstrooid_prof]

hier mogen de HA-ontwikkelaars toch eens naar kijken:

het pad "settings => system => repairs" om het installatietype te bekijken is niet echt intuitief

die info hadedn ze toch gerust onder de "/config/info" kunnen steken (aka: "settings=>about")
daar staat nu toch al (ook) de versie. maar niet het installatietype

[kjeltonline]

Bedankt ik kreeg ook even de kriebels. Draai HA in een VM op mijn Synology NAS maar is inderdaad de HA OS.

[Exirion]

Jezus, wat waardeloos. Ik heb een Beelink met Debian 12 met een Supervised HA installatie draaien. Super stabiel en binnen Debian draaien ook nog andere zaken. Ik wil helemaal niet aan hun OS vast zitten.

[qpman]

👏👏👏👏

[ggvanleeuwen]

Vooral jammer dat Core installatie niet meer wordt ondersteund. Ik snap dat het voor veel mensen te ingewikkeld is, maar er is vaak nog wel wat processing power over op een device waar je hem dan makkelijk erbij kan plaatsen. Heb je geen extra hardware nodig.

Nou was ik laatst aan het proberen om te upgraden, maar dat verliep niet heel eenvoudig. Zolang het draait houden we het maar even op de huidige versie dan. Zoveel verandert er niet toch?

[Joostlek]

Onthoud ook dat het wel zal blijven werken, want als wij ontwikkelen aan home assistant doen wij dat ook via "core" in een omgeving met virtualenv. Echter voor support rondom onderhoud ben je op jezelf aangewezen.

[i-chat]

voor die setup kun je natuurlijk prima ook de docker versie draaien docker heeft nu ook weer niet zoveel overhead dat dat echt verschil zal maken.

persoonlijk vind ik het vooral jammer dat men de supervised instal nooit in docker heeft gezet. ik zou in de meeste gevallen liever supervised in docker draaien en onderhouden zodat het ook gewoon kan worden voor containers op andere platforms terwijl HASos eigenlijk alleen maar werkt op kale hardware of met behoorlijk wat overhead op een VM.

om diezelfde reden vind ik het bijvoorbeeld erg jammer dat nextcloudpi niet meer op docker draait. de netcloud -AIO vervanger maakt dingen toch behoorlijk wat complexer (vooral als de usecase eigenlijk heel beperkt is (maximaal 10 infrequente users)

[WoutervOorschot]

Klinkt als een goede reden om naar de container over te stappen, gewoon een docker (of podman etc) pull en je bent geupdated. Containers draaien op bijna alle apparaten en hebben nauwelijks overhead.

[Church of Noise]

Maar als ik het goed versta geen (obvious) ondersteuning voor add-ons.

Dan maar eens uitvissen als/hoe dat eventueel toch kan, of hoe het in zijn werk gaat om 'manueel' add-ons via docker toe te voegen.

Wat me niet duidelijk is, is hoe 'beschikbaar' updates zullen blijven in de toekomst voor Supervised. Ik heb er op zich geen probleem mee om er verder mee te doen als het unsupported is...
Maar eerst kijken als ik niet verder kan met supervised, want
1) ik wil het energieverbruik van mijn dedicated HA systeem minimaal houden (nu op 2.7W)
2) ik wil steunen op een solide, wijd-verspreid en -ondersteund OS (Debian), wegens sterk geloof in 'focus' en dat doen de HA ontwikkelaars terecht vnl op de HA functionaliteit. Schoenmaker blijf...
3) ik wil de add-ons blijven gebruiken op de meest makkelijke manier als dat even kan
4) ik heb geen zin in onnodige overhead van HAOS in een container (om punt 3 en 5 gedaan te krijgen)
5) ik apprecieer te kunnen controle hebben over het OS, wat met HAOS niet (volledig) kan - of je bent terug unsupported.

[Reactie gewijzigd door Church of Noise op 23 mei 2025 20:40]

[whiner]

Inderdaad. gewoon zelf de addons installeren via docker.
Sinds dat ik de docker versie gebruik heb ik nooit meer problemen met home assistent. Daarvoor gebruikte ik de supervised versie en daar moest je duimpje draaien bij elke update of home assistent nog wel op kwam.

[andru123]

Hebben toch overhead. Draaien als service is efficiëntste manier.

[florianschut]

Het is nog wel mogelijk om het als container te draaien. Lijkt me dat je in veel situaties daar het zelfde mee kan bereiken of zie ik iets over het hoofd?

[johanl79]

Helaas kwam ik er achter dat toen ik van een VM (HAOS is dat dan geloof ik?) naar Docker wilde, ik alle addons daarna weer moest installeren/configureren. Dat is niet zo fijn zeg maar.

[Gizz]

Hiervoor kun je gewoon Home Assistant Container voor gebruiken.

[poing]

Home Assistant virtueel draaien in Proxmox, dan kan je nog andere VMs en/of Containers draaien.

[Kroesss]

Die extra processing power is de reden dat ik ben overgestapt op Proxmox toen ik van een Pi4 naar een NUC overging. Het is gewoon HAOS, maar daarnaast kan ik dan ook nog andere zaken draaien.

[Glodenox]

Ergens begrijp ik het wel hoor. Het aantal Core installaties is enorm beperkt met 2,5% van alle installaties, maar er komen continu enorm veel vragen en problemen rond naar boven. Op een bepaald punt moet je dan gewoon vaststellen dat het eerder een last is voor de community. Niemand gaat mensen tegenhouden om Home Assistant als Core te blijven en ze zullen zelfs updates blijven krijgen. Maar als er problemen zijn, zullen ze dit zelf moeten oplossen.

Qua evoluties in Home Assistant: tja, hangt ervan af waar je interesse in hebt. Men is momenteel veel zaken aan de interface aan het verbeteren en vorig jaar is er veel gedaan rond lokale spraakassistenten. Als je dat niet belangrijk vindt, hoef je inderdaad niet naar een nieuwe versie te gaan. Maar meestal is dat een slecht idee, want op een bepaald punt ga je toch een nieuwe functie willen gebruiken en kan die enorme achterstand in updates die stap heel moeilijk maken.

[P1nGu1n]

Ze blijven de core versie nog steeds aanbieden, ze leveren er alleen geen ondersteuning meer op. Zoals ze in de blog post aangeven, gebruiken veel ontwikkelaars de core versie tijdens development, dus die zal wel blijven werken. Dus als het voor jou werkt zo, zou je het kunnen blijven gebruiken

[Dacuuu]

Dus de docker container gaat ook stoppen? What de ..? https://hub.docker.com/r/homeassistant/home-assistant/

[Chazler]

Dat lijkt me niet. Er zijn namelijjk 4 versies: HA OS, Container, Core en Supervised. Daarvan stoppen er nu 2 : Core en Supervised.

Hieronder te zien in hun eigenoverzicht.
https://www.home-assistan...nced-installation-methods

[Strebor]

Thanks voor het overzicht. Zelf schrok ik even, omdat Home Assistant de term Core op meerdere manieren gebruikt.

Ik gebruik op meerdere locaties op een XCP-ng VM hun Home Assistant OS installatie (de OVA image). Het verwarrende daaraan is, dat als je in de settings op about klikt, je dan de onderlinge onderdelen van de installatie ziet. In mijn geval nu:

Core (2025.5.1)
Supervisor (2025.05.1)
Operating System (15.2)
Frontend (20250411.0)

Ondanks dat er het onderdeel Core staat, moet de installatie kennelijk niet verward worden met de Core installatie methode, die geen Add-ons en One-click updates kent. Home Assistant OS installatie methode - en mijn Home Assistant VMs - kennen dit wel.

[Reactie gewijzigd door Strebor op 23 mei 2025 11:43]

[poktor]

Ik heb wel Supervised, ik draai al jaren HA op Debian, dat was tot nu toe een door hun supported configuration en draait al jaren probleemloos. Maar straks niet meer dus. Rijst meteen de vraag: ik heb nogal wat add-ons (14) en integrations (33) draaien. Kan dat allemaal naadloos overgeheveld worden naar HA OS?
EDIT: even het originele artikel gelezen, antwoord is ja.

[Reactie gewijzigd door poktor op 23 mei 2025 16:53]

[Glodenox]

Waar lees jij dat? Ze zeggen dat OS en Container ondersteund gaan blijven en men adviseert over te stappen naar een van deze twee methodes als men ondersteuning wilt hebben.

[Dacuuu]

Gelukkig! Ja in het originele artikel van Home-assistant staat het gelukkig duidelijker!

Home Assistant Core installation method, where you run your system in a Python environment, not to be confused with Container (for example, running your system in Docker).
Home Assistant’s Supervised installation method, which involves running your own operating system, then installing the Supervisor and other requirements on top of that.

[dof250]

Nee, de container stopt niet staat in het artikel.

[adjego]

We have deprecated the following installation methods:

Home Assistant Core installation method, where you run your system in a Python environment, not to be confused with Container (for example, running your system in Docker).
Home Assistant’s Supervised installation method, which involves running your own operating system, then installing the Supervisor and other requirements on top of that.

https://www.home-assistan...thods-and-32-bit-systems/

[Aloy]

Nee dat denk ik niet, Core is niet het zelfde als Container. Van de HomeAssistant blogpost:

We have deprecated the following installation methods:

Home Assistant Core installation method, where you run your system in a Python environment, not to be confused with Container (for example, running your system in Docker).
Home Assistant’s Supervised installation method, which involves running your own operating system, then installing the Supervisor and other requirements on top of that.

[To_Tall]

Ik zie dat nergens terug.

Home Assistant Core en supervised. Zijn twee hele verschillende systemen tov docker variant.

Ook op de docker pagina van hass staat niet dat docker niet meer ondersteund gaat worden.

[svenk91]

Nee, container installaties blijven wel mogelijk. Die worden ook expliciet genoemt als 1 van de 2 installatiemethodes die ondersteuning blijven krijgen (de andere is HAOS).

[arendvw]

https://www.home-assistant.io/installation/linux

Home assistant Core is the is de losse python module. Dit is in de praktijk best harig om te doen.
Home assistant container is de docker image en die blijft wel ondersteund.

[JvS68]

@Dacuuu

Zie: https://www.home-assistan...thods-and-32-bit-systems/

We have deprecated the following installation methods:

- Home Assistant Core installation method, where you run your system in a Python environment, not to be confused with Container (for example, running your system in Docker).
- Home Assistant’s Supervised installation method, which involves running your own operating system, then installing the Supervisor and other requirements on top of that.

Dus zo te zien blijft Docker (gelukkig) gewoon bestaan.

[joost00719]

Deze regel is best handig om in het artikel te verwerken:

Going forward Home Assistant OS and Home Assistant Container will become the only supported installation methods.

[Gizz]

@TijsZonderH inderdaad een goede suggestie om dit toe te voegen. Zoals zichtbaar hier in de reacties denken veel tweakers door dit bericht dat er allemaal dingen verdwijnen of niet meer mogelijk zijn, terwijl dat helemaal niet zo is

Wil je HA als OS draaien (als hoofd OS dan wel als VM): Home Assistant OS
Wil je HA als los pakketje draaien binnen een bestaand OS: Home Assistant Container.

Beide opties blijven gewoon mogelijk.

[TijsZonderH]

Staat er inmiddels bij!

[barbarbar]

Tijdje geleden al overgegaan naar HA OS, je bent er wel een dedicated apparaat voor nodig maar dat was juist m'n insteek. Soms reageerde er iets niet lekker, dat is nu opgelost. Qua onderhoud ook veel eenvoudiger, en herstarten van de NUC met HA OS is veel sneller. Snap wel dat ze die losse installaties niet meer willen ondersteunen, daar is de omgeving die ze gebruiken niet echt geschikt voor.

[Gizz]

Tijdje geleden al overgegaan naar HA OS, je bent er wel een dedicated apparaat voor nodig maar dat was juist m'n insteek

Dat hoeft niet. HA OS kun je ook prima als VM draaien, dan heb je geen dedicated apparaat nodig.

[barbarbar]

Uiteraard. Maar dan nog vergt dat weer extra onderhoud en updates, en als er iets anders op de pc druk bezig is dan reageert HA traag. Natuurlijk is dat allemaal in te stellen, maar dat zijn allemaal weer extra's die je na verloop van tijd weer vergeet hoe dat zat. Dan is 300 euro voor een simpele NUC met HA OS veel stabieler naar mijn ervaring. Inmiddels heb ik er aardig wat op draaien, zowel via zigbee als wifi en wat scripts, dashboard, aansturing van ventilatie en warmtepomp, dus dat moet wel betrouwbaar zijn. Heb geen zin om onder een koude douche te staan omdat de nuc een update heeft gedaan er daarom de vm niet meer wou starten bijvoorbeeld. Dan is de acceptatie hier in huis ook snel weg.

[Reactie gewijzigd door barbarbar op 23 mei 2025 10:03]

[Sharky]

Dat geldt voor elke service, als na een herstart iets niet meer start dan kan het zijn dat iets het niet doet. Dat is niet inherent aan je virtualisatie. Een VM biedt een hoop voordelen qua beheer en juist omdat je resources reserveert heb je geen last van andere processen. Juist de voordelen die jij noemt horen bij een VM, niet bij een platte installatie.

[barbarbar]

Die VM moet wel beheerd worden, als je dat verder nooit doet in een thuissituatie, dan ben je elke keer uitzoekwerk aan het doen. Ook die VM omgeving moet geüpdate worden, instellingen bijwerken e.d. Al met al extra werk wat je niet hebt met een platte installatie.

Technisch heb je gelijk, de praktijk is weerbarstiger. In die zin ben ik écht van het KISS principe. Liever een stukje extra hardware, dan draait dat ook door als er iets anders kapot is. Ik kan wel een thuisserver optuigen met allerlei VM's voor van alles en nog wat, maar als die server het begeeft na een paar jaar ben ik weer veel tijd kwijt om alles draaiend te krijgen. Terwijl ik dat niet wil. Voor thuis wil ik gewoon een apparaat kunnen vervangen en klaar. Router kapot? Nieuwe er in en klaar. HA box kapot? Nieuwe kopen, HA OS er op, backup er op en klaar. NAS kapot? Nieuwe kopen, schijven overzetten en klaar. Geen gedoe met allerlei uitzoek werk omdat na jaren van stabiel draaien er opeens dingen niet meer gesupport worden op nieuwe hardware. Gewoon stukje praktijk ervaring.

[Reactie gewijzigd door barbarbar op 23 mei 2025 10:28]

[computer1_up]

Ben het helemaal met je eens. Heb er ook weinig behoefte aan om een onnodige laag nog tussen mijn hardware en HAOS te duwen want in mijn usecase is dat gewoon echt niet nodig. Heb toch nog een stapel van die mini-pc’tjes liggen, dus eentje met HAOS erop is gewoon makkelijker en dan kan er minder misgaan. Geen gedoe met USB-devices door te zetten naar een VM, geen hypervisor die nog issues kan geven (minder componenten is minder kans op problematische componenten), gewoon lekker simpel. (Mij lukt ook een stuk minder sinds mijn burnout dus dat speelt ook een rol)

[barbarbar]

Ja, je merkt het hier in de reacties ook al. Oh, dat word niet meer ondersteund? Dan moet ik daar wat anders op verzinnen. Betekend dus dat je weer een dag bezig bent om wat al draaide, weer te laten draaien. "Vroegah" vond ik dat ook wel leuk, maar nu er meer aan hangt dan alleen een paar lampen, en ik er de tijd niet meer voor *wil* maken, is eenvoud en een oplossing die lang wordt ondersteund mij wel wat waard.

[Gizz]

Heb toch nog een stapel van die mini-pc’tjes liggen, dus eentje met HAOS erop is gewoon makkelijker en dan kan er minder misgaan.

Mooie kans om er een Proxmox high availability cluster van te maken Dan kunnen er zelfs mini-pc'tjes uitvallen en blijft de boel draaien.

[computer1_up]

Nee dankjewel nergens voor nodig, alleen maar werk en voegt niks toe voor me. Heb echt geen behoefte meer aan dat soort zaken, de kans dat de hardware faalt is veeeeeeel kleiner dan software. Ik begin er niet meer aan.
De kans dat dit soort dingen falen is gewoon veel groter want ik krijg het gewoon niet meer goed voor elkaar om het juist in te stellen terwijl wat ik nu heb lekker simpel is en ik er niet veel over na hoef te denken.

[Reactie gewijzigd door computer1_up op 23 mei 2025 13:00]