Software-update: Home Assistant 2026.2.0

Home Assistant logo Versie 2026.2.0 van Home Assistant is uitgebracht. Dit opensourceplatform voor domotica is gemaakt in Python 3 en ondersteunt het detecteren van apparaten zoals Philips Hue, Belkin, Mr. Coffee-koffiezetapparaten, WeMo-schakelaars, de slimme schakelaars van IKEA en het MQTT-protocol. Daarnaast kan het waar mogelijk deze apparaten aansturen en automatisering toepassen. Voor meer informatie over Home Assistant verwijzen we naar deze pagina en ons eigen forum. De volledige releasenotes voor deze uitgave zijn hier te vinden. Dit is de aankondiging daaruit:

2026.2: Home, sweet overview

The new Home Dashboard is now the official default for all new installations. If you’ve been using Home Assistant for a while and never customized your default view, you’ll get a suggestion to switch; give it a try! I also need your help! The Open Home Foundation device database is being built as a community-powered resource to help everyone make informed decisions about smart home devices. Head to Home Assistant Labs to opt in and contribute your anonymized device data.

Add-ons are now called Apps! After a lot of community discussion, it was time to use terminology that everyone understands. Your TV has apps, your phone has apps, and now Home Assistant has apps too. My personal favorite this release? The completely redesigned Quick search! If you’re like me and navigate Home Assistant using your keyboard, you’re going to love this one. Press + K (or Ctrl + K on Windows/Linux) and you have instant access to everything.

Home Assistant Core

Versienummer 2026.2.0
Releasestatus Final
Besturingssystemen Scripttaal
Website Home Assistant
Download https://home-assistant.io/getting-started/
Licentietype GPL

Door Bart van Klaveren

Downloads en Best Buy Guide

04-02-2026 • 22:00

47

Submitter: Frenck

Bron: Home Assistant

Reacties (47)

Sorteer op:

Weergave:

Ugh ze blijven alles overhoop halen. Nu moet ik weer 30+ template sensors omkatten in de YAML omdat de manier van configureren weer overhoop moest. Ik wou dat ze dingen eens een beetje op zijn beloop lieten.

Dat nieuwe home screen ziet er wel grappig uit, ik moet het nog eens proberen maar het bestaande (lovelace?) werkt prima.

[Reactie gewijzigd door Llopigat op 4 februari 2026 22:57]

Maar wat doe je in die yamls waardoor het een probleem is/blijft?

Ik draai HA nu een jaar (na 4 jaar homey), doe haast alles via de interface en heb met 80+ devices en extreem veel automations nog nooit update problemen gehad met welk device dan ook (en het zijn een heeeeele hoop verschillende)
Het gaat specifiek om template-sensors. Daar hadden ze een tijdje terug een aanpassing op gedaan. Als je daar dus geen gebruik van maakt, loop je er niet tegen aan.

Ik heb er zelf ook een aantal moeten aanpassen een tijdje terug. Je krijgt ook netjes 6 maanden de tijd om het te doen.
Is gelukkig gewoon een HACS plugin voor die ze automatisch voor je kan omzetten naar het nieuwe formaat. Je krijgt ook nog eens 8 maanden om het op te lossen. Als het je binnen 8 maanden niet lukt, dan is Home Assistant misschien niet het product voor jou.

https://github.com/Petro31/hass-migrate-template

Edit: Perongeluk gereageerd op lenwar. Is bedoeld voor Llopigat

[Reactie gewijzigd door paulbenard op 5 februari 2026 08:55]

Als het je binnen 8 maanden niet lukt, dan is Home Assistant misschien niet het product voor jou.
Dat is een beetje chargeren natuurlijk.Het aanpassen van werkende automations om ze werkend te houden is geen waardetoevoegende activiteit.

Forward en backward compatibility van API's is een vrij standard practice waardoor tijd besteed kan worden aan nuttige zaken.

Ik ben zelf na een aantal breaks een beetje huiverig geworden om mijn hoeveelheid automations uit te breiden omdat dat het risico alleen maar zal vergroten.
De nieuwe template sensoren YAML bestaat al 2 of 3 jaar. Beide varianten hebben dus echt al heeeel lang prima naast elkaar gewerkt en "theoretisch" had je dus ook al al die tijd om ze te migreren (als je wist dat het een oude variant was). Blijkbaar vinden ze het nu tijd om de oude code daadwerkelijk te verwijderen. Lijkt mij an zich niet gek dat je niet, Windows style, backwards compatibility wilt houden met iets van ~20 jaar terug.
En ~7 maanden met een waarschuwing om te migreren, incl al daadwerkelijk de YAML die je maar hoeft te knippen/plakken, lijkt mij dan niet heel slecht. En ja, natuurlijk is het zuur als je tientallen templates hebt die je moet "migreren" (/knippen plakken uit de melding), maar verwachten dat ze twee varianten jaren / decennia blijven ondersteunen is ook onrealistisch.
Je focust nu heel erg op 1 voorbeeld, maar als je kijkt naar de release notes heeft vrijwel iedere release breaking of niet backward-compatible changes.
Maar die breaking changes zijn wel vaak relatief klein. Deze release zijn er een stuk of 5? Waarvan er maar 1 in iets "generieks" zit (de rest zijn er voor specifieke integraties) en dat is dat een group net iets anders reageert v.w.b. unavailable (is nu alleen unavailable als alle onderliggende entities unavailable zijn). Dat lijkt nu niet het eind van de wereld te zijn zeg maar.

En wat "vroeger" bv vaak het geval was dat als je ZWave gebruikte met de (heel erg) nieuwe ZWave JS "server" dat je regelmatiger een up-to-date ZWave JS versie moest draaien. Dat was dus zo simpel als gewoon even een update doen van andere software (/toen een addon (nu een app) updaten). Maar uiteraard is dat met de tijd allemaal gestabiliseerd en is ZWave niet meer zo "experimenteel" / wordt niet meer zo hard aan ontwikkeld waardoor HA steeds nieuwe features vereist.

En daarnaast volgen breaking changes dus regelmatiger ook pas na een depreciation maanden eerder (en deze oude template variant zal tzt ook als breaking change vermeld staan). En soms zijn zaken ineens breaking omdat een afhankelijkheid stuk is. Lees: een cloud integratie waarvan de cloud offline is gehaald / dusdanig gewijzigd is dat het niet meer werkt. Iets waar ze bij Home Assistant dus geen invloed op hebben. Ook dat vermelden ze dan als breaking change, terwijl oude versies net zo goed ineens stuk waren. (Enige verschil is dat in die nieuwe versie dan de integratie volledig verwijderd kan zijn. Maar wil je dan backwards compatibility hebben door een kapotte integratie, die ook niet gefixt gaat worden, als dummy te behouden?)

Edit:
Pak ik de lijst van deze release even erbij:
* Sentey: geldt alleen voor diegene die "iets" self-hosten, én dan alleen voor diegene die een versie van vóór juni 2020 draaien (dan draai je dus 5,5 jaar oude software?)
* Tractive: wijzigingen door de API aanbieder, kan HA dus niks aan doen
* Tuya en VeSync aanpassing aan HA kant, om iets te verbereren/verduidelijken? Waarbij een service call aangepast moet worden. Geen idee of daar al een overgangsperiode op is geweest waarin de nieuwe variant al werkte naast de oude en nu de oude verwijderd is. Of dat je nu pas de aanpassing kunt en moet doen.

[Reactie gewijzigd door RobertMe op 5 februari 2026 13:11]

Ik dacht al 😄

(( ik was overigens niet op de hoogte van die HACS-integratie. Ik was gewoon om gaan zetten naar de GUI waar mogelijk ))
Ik gebruik HA nog niet zo lang, maar ik vind het wel lastig dat ze de boel lang backwards compatible proberen te houden en dat me vaak niet duidelijk is wat nu de nieuwe manier is om dingen te schrijven.

ChatGPT haalt service en action bijvoorbeeld steevast door elkaar. Ik vermoed dat actions -> action de nieuwe manier is want zo staat het in de YAML als je het via de GUI in elkaar klikt. Maar bij actions -> service krijg je geen waarschuwing dat de ene deprecated is of iets dergelijks.

Zo zijn er nog meer maar deze kom ik vaak tegen. Van mij mag hij wel iets harder pushen om de boel in de nieuwe stijl te schrijven, bijvoorbeeld een geel lijntje onder deprecated keys. Zo doet VSCodium het ook bij bijvoorbeeld nodeJS.
Misschien gelijk een mooi moment om ze om te zetten naar de GUI? daar ben ik zelf al enige tijd mee bezig. (Eens in de zoveel tijd ‘migreer’ ik er een aantal.) daar zou ze meer future-proof moeten maken. (Afhankelijk van hoe de wijzigingen zijn.)
Ik merk dat ik inderdaad ook vooral dingen migreer van de yaml naar de GUI, enige dat ik nog niet gevonden heb in de GUI maar wel in de yaml is het aanpassen van het icoon aan de hand van de status van een sensor. Daarvoor blijven dus nog template sensors in de yaml staan
Inderdaad. Was me nooit opgevallen dat je dat niet op dat niveau kunt doen. Ik pas altijd m’n icoontjes aan op m’n dashboards, maar het is eigenlijk logischer om dat daar te doen.

Ik vraag me af of hier al een feature-request voor is.
Ik doe ook nog dingen dat icoontjes op een plek wijzigen aan de hand van de status van een sensor. Een voorbeeld is de status van de ketel, als de ketel niets doet staat er een radiator met streep erdoor, als de ketel brandt voor de verwarming is het een radiator zonder streep en als er warm wordt gemaakt een kraantje.
Dat heb ik ook, maar ik doe dat op het dashboard en niet op de entity. (Ik heb een algemene status-pagina. Alle lampen uit grijs, 1 of 2 lampen aan, geel, 3 of meer aan, amber. En inderdaad ook voor de verwarming enzo, met andere icoontjes.)

Maar zoals ik al schreef is het eigenlijk logischer om dit soort zaken (ook) op entity-niveau te kunnen doen.
Stond al lang aangekondigd.


Hier is een integration die je helpt alles om te zetten

https://github.com/Petro31/hass-migrate-template
Ik volg de community niet, met name niet omdat die vooral op Discord zit. Maar zoiets als dit moet ook gewoon zijn werk doen, het is geen hobby van me om alles bij te houden. Maar bedankt voor die addon, zal ik proberen.
Nee, het is een custom integration, dus noch een addon noch een app ;) (en dus iets dat ook in HA Container werkt en niet alleen in HAOS)
Ja, dit herken ik wel. Hoe vaak ik ondertussen wel niet alles heb aangepast. Het wordt steeds beter, zeker. Maar ik heb al tijden niet meer geüpdate omdat ik het een beetje zat werd.
Ja precies, ik heb ook al maanden niet geupdate omdat er steeds van die dingen zijn en nu kwam dit dus weer met deze update naar voren. Deze change van de template sensors kan dus ook in een eerdere update gezeten hebben.
Die change zat inderdaad in 2025.12 en is niet van deze.

Ik update elke keer en heel sporadische moet er wat geupdate worden.
Vaak gaat het automatisch en soms (zoals met de template sensors) moet het handmatig.

Je hebt tot 2026.06
https://community.home-assistant.io/t/deprecation-of-legacy-template-entities-in-2025-12/955562
ik ken je setup natuurlijk niet, maar dat is bij mij toch al lang geleden en al zeker met zulke hoeveelheden.

Ik probeer net zoveel mogelijk up-to-date te blijven, net om te vermijden dat je na een tijd plots je halve huis opnieuw moet gaan configureren.
Ik heb dat even gemist... wat, waarom en hoe?
dan heb je al een tijdje niet geupdate, daar kwam die in december al mee, maar je hebt een half jaar ervoor ;)
Het is een evolutie van een applicatie voor techneuten naar een applicatie voor een breder publiek. Ik verwacht dat dat nog wel een paar keer zal gebeuren, hoewel ik er weinig last van heb en ook aardig wat template sensors gebruik.
Home Assistant is heel erg van de move fast and break things. Daarom ben ik lang bij OpenHAB gebleven. Maar op een gegeven moment kost het toch wel veel tijd om alles te bouwen. Home Assistant heeft gewoon een veel grotere community en bijna alles heeft iemand anders al eerder gedaan. Dat is wel erg waardevol.

Ze proberen uiteraard geen dingen te breken en doen moeite om oude configuraties zo lang mogelijk te ondersteunen, maar toch heb ik in twee jaar HA meer dingen moeten repareren dan in 5 jaar OpenHAB daarvoor.

[Reactie gewijzigd door Sando op 5 februari 2026 10:57]

De constante wijzigingen zijn inderdaad niet altijd verbeteringen, meestal wel trouwens. Maar desondanks voor mij wel reden om in de regel niet de .0 versie te installeren maar te wachten op .3 of .4.
De minor-releases zijn vrijwel alleen maar updates van upstream-zaken, die semi-los staan van de major-release.

Het gebeurd niet vaak dat er (grote) zaken gepatched worden die ‘nieuw’ in de major release zijn gekomen.
Zoals ik hierboven al aangeef de meeste bugs zijn er bij een .4 versie er wel uit of workaround. Wat er nog bij komt dat zaken die niet zo duidelijk uit de release notes blijken dan inmiddels wel bekend zijn. Of als er geen workaround is weet je dan dat je moet wachten met updaten.
En zoals ik hierboven aangeef klopt dat niet volledig. De inhoud van de minor releases veelal weinig met de major release te maken. Kijk naar de updates van de minors van een willekeurige major release, en het gebeurd zelden dat er grotere bugs eisen opgelost die in de major zijn geïntroduceerd. (Uitzonderingen linksom en rechtsom zijn er altijd.)
Ik moet Synoniem wel gelijk geven voor wat betreft de .0 releases. Ik heb alleen in het afgelopen jaar toch al een aantal malen meegemaakt dat het behoorlijk mis ging met als dieptepunt in afgelopen november, dat m'n hele installatie om zeep werd geholpen en rebootte elke paar minuten. Voordat duidelijk was wat het was heeft het me behoorlijk wat tijd en frustratie gekost.

Maar ook andere problemen met bijvoorbeeld Bluetooth in september zorgen voor reboots van het systeem.

Vanaf nu klik ik dus op overslaan en installeer pas de .1 of .2.
Dit is nooit fijn hoor, maar had je wel een backup gemaakt en terug kunnen zetten?
Ik maak back-ups lokaal, in de cloud en lokaal op een NAS. Dus dat is het probleem niet. Het laatste probleem merkte ik echter pas na een tijdje en kon ik niet pinpointen.

Ik ging dus elke keer terug naar een back-up van begin november en vervolgens verschillende add-ons en integraties uitzetten. Veel trial en error, tot ik doorhad waar het zat. Toen waren we al met al bijna een maand verder.
In versie .4 zitten nog steeds dezelfde wijzigingen als in .0 dus dat is geen reden niet direct te updaten. Er zijn hoog uit nog een paar bugs uit gehaald.
De ervaring leert dat wijzigingen bij .0 versie de meeste bugs hebben en feitelijk een beta versie voor grootschalige test zijn. Bij de meeste .4 versies zijn die bugs wel geplet of workarounds bekend.
Herkenbaar. Op individueel niveau zie ik zeker verbeteringen in veranderingen die men doorvoert, echter, ik merk ook dat ik redelijk wat te beheren heb en dat er met regelmaat zaken omvallen. Al in al blijf ik fan van HASS, maar vind het wel (steeds meer) inspanningen vereisen. Wellicht dat de oplossing is om minder het pakket naar je eigen hand te zetten en mee te gaan in de defaults van de maker?
Recent heb ik met AI een command line tooltje gemaakt omdat ik iets in HA met geen mogelijkheid gedaan kreeg. Met HA zit ik vaak te kloten, dat yaml is zo ver van m'n dagelijkse programmeren (C#) dat ik het lastig vind daar wat in gedaan te krijgen.

Met AI een eigen tooltje bouwen ging dusdanig snel, dat ik nu sterk twijfel om HA er helemaal uit te gooien en alleen maar een eigen tool te gebruiken. Het is inmiddels makkelijker om AI even te vragen iets in die tool aan te passen, dan gaan zitten uitzoeken hoe dat in HA moet.

Is de AI code perfect? Nee verre van. Maar het draait toch al weer dagen stabiel, en heel eerlijk: ik kijk ook nooit hoe de assembly of intermediate code eruit ziet. Dus wat maakt het uit hoe de code eruit ziet, zolang de AI het maar snapt en doet wat het moet doen.
Je kan gewoon co pilot ofzo vragen om voor jou iets in yaml te schrijven.
Zo heb ik ooit een edcucational microbit controller gekoppeld aan home assistant die serieel communiceert over de usb poort. Doel was uitlezen van alle ingebouiwde sensors zoals, temperatuur, licht, magnetisme, versnelling, kompas, licht etc.
Gewoon omdat het kan en omdat er nog geen add-on app voor was

[Reactie gewijzigd door drakiesoft op 5 februari 2026 09:08]

Ja zover was ik al inderdaad. Maar had nu een modbus functie nodig, en dan blijkt dat HA modbus alleen als master implementeert. Dus HA als modbus slave gebruiken wil niet.

En als ik dan toch al andere tools moet hebben, kan ik net zo goed de hele logica in zo'n tool zetten.

Dat er op zo'n community dan nog heel groot "don't use AI" staat, denk ik dat ze de boot een beetje missen. Yaml en python zijn al niet m'n favoriet, maar met een goede AI integratie zou dat nog wel acceptabel zijn. Juist om het makkelijker te maken voor een grotere groep gebruikers.

Maar goed, die afkeer van AI merk ik hier bij Tweakers ook al wel. Had dat idee zelf ook, maar de laatste modellen kun je eigenlijk maar moeilijk blijven negeren.
Weet niet of er algemeen afkeer is tegen AI hier, maar je moet het gebruiken als tool en dan is het toch wel erg handig hoor. Ik gebruik het waar ik denk dat het mij tijd scheelt. Voor yaml werkt het goed, maar niet als ze telkens wijzigingen toepassen in de structuur. Je moet wel checken of je yaml code correct is, maar dat lukt wel en moet ook wel aangezien je AI het toch niet precies doet wat jij wilt. Python heb ik me nog niet aan gewaagd, dat is nog net een stap verder als je bv integraties of blueprints dacht ik wil maken ofzo.

Zal eens kijken of ik mijn microbit app in een repository op github kan zetten.
De ontwikkeling gaat ook best snel nu, dus snap best dat er veel weerstand is om je manier van werken aan te passen als ontwikkelaar van HA. Maar zoals je zelf ook aangeeft: met AI kom je inmiddels gewoon heel erg ver. Veel van dat werk wat ze nu doen om het toegankelijker te maken zouden ze mijn inziens in één klap kunnen oplossen door er meer AI tegen aan te gooien. Een venster waarin je beschrijft wat je wil doen, en de AI zoekt wel uit wat past binnen de apparaten die je in gebruik hebt. En wat voor code daar dan onder water uitkomt maakt me niet uit.

Dat hele template en apps gedoe vind ik heel erg omslachtig. Doe mij maar scriptjes die wat API's gebruiken en klaar. En laat AI nou net heel goed zijn geworden in die relatief beperkte scriptjes bouwen.

Simpel venstertje: Joh AI! Ik heb weer wat nieuws. Hier is de API van dit nieuwe apparaat. Zorg ervoor dat die 's ochtends aan gaat als ik opsta. En 's avonds uitgaat als ik ga slapen. Als ik ga slapen ligt m'n telefoon op de lader. Gebruik dat signaal maar.

Nou dat is het. Niks geen gedoe met templates, entities, yaml of pythons.

[Reactie gewijzigd door barbarbar op 5 februari 2026 11:08]

Wellicht dat de oplossing is om minder het pakket naar je eigen hand te zetten en mee te gaan in de defaults van de maker?
Voor mij zeker geen optie, ik haat 'opinionated software' waarbij je je werkwijze moet omzetten. Software is er om de gebruiker te dienen, niet andersom. Daarom heb ik ook een hemel aan bijvoorbeeld een gnome of een iOS. Naar mijn hand kunnen zetten is essentieel.

Maar home assistant was in het begin niet zo, het was heel erg open. Het probleem begon eigenlijk toen ze een soort Homey wilden gaan worden.

[Reactie gewijzigd door Llopigat op 5 februari 2026 08:10]

Maar home assistant was in het begin niet zo, het was heel erg open. Het probleem begon eigenlijk toen ze een soort Homey wilden gaan worden.
Iets gechargeerd, maar ik snap wel wat je bedoelt. HA is heel erg aan het aansturen om alles naar de GUI te zetten. Dit maakt het toegankelijker, en voor veel dingen makkelijker, maar ook zeker voor veel dingen moeilijker. (Vaak de niche-dingetjes die we zo prettig vinden in onze individuele installaties, die makkelijker in yaml te regelen zijn dan de (niet altijd eventuele intuïtieve) interfaces.

Hetgeen wat je nu specifiek tegen aan loopt is voornamelijk een opmaak-verandering die al anderhalf jaar geleden was aangekondigd. De “oude methode” wordt nu stapsgewijs uitgefaseerd.

De communicatie er omheen is op zich goed geweest, maar je moet er wel bewust mee bezig zijn, en daar gaat het vaak mis. HA is een tool, en de tool zelf is niet het doel, waardoor die communicatie dus makkelijk gemist kan worden. Toen ze die templatesensoren hadden aangekondigd werd ook al gelijk gemeld dat we ruim 6 maanden hadden om het om te bouwen. Dat is best een redelijke termijn, gezien je niet alles tegelijk hoeft te doen. Maar het is wel lastig.
Ik ben inderdaad meer meegegaan in de standaard en heb in de kerst vakantie mijn yaml dashboards omgezet naar een standaard dashboard. Is een stuk makkelijker met bewerken (in diverse kaarten zit nog steeds veel yaml, dat kun je prima copy pasten). Heb toen ook alle template sensoren omgezet (veelal ook copy paste)
Jammer dat ctrl k al door chrome wordt gebruikt...
Weet iemand hoe je die sneltoets voor Home Assistant kunt aanpassen?
Geloof dat ik me weer een hoop ellende bespaard heb.. zou van de week net eens met HA gaan stoeien.. maar door omstandigheden mijn testsetup nog niet compleet gemaakt (alles in huis..) nou kunnen we meteen met deze build starten ipv prutsen en dan een update zien te doen ;-D

Om te kunnen reageren moet je ingelogd zijn