Homey wil nieuwe groep ontwikkelaars aantrekken met ondersteuning Python-apps

Athom Homey ondersteunt voortaan ook de programmeertaal Python met de Python Apps-softwaredevelopmentkit (sdk). Tot dusver konden ontwikkelaars alleen in JavaScript en TypeScript apps uitbrengen in de Homey App Store.

De Python Apps-sdk is beschikbaar voor apps voor Homey Cloud, Self-Hosted Server en fysieke Homey-apparaten, zoals de Homey Pro en Homey Pro mini. Volgens de fabrikant kan dankzij de bredere programmeertaalondersteuning een nieuwe groep ontwikkelaars bijdragen aan het Homey-ecosysteem.

In principe kan iedereen voortaan apps in Python maken voor Homey. Ontwikkelaars, hobbyisten en bedrijven kunnen apps gratis aanbieden via de Homey App Store. Als de app voor Homey Cloud bedoeld is, moeten ontwikkelaars wel geverifieerd zijn, wat geld kost.

Reacties (56)

[pk128934]

Toen ik nog een Homey had, heb ik Athom voorgesteld om hun Dyson integratie onder handen te nemen met dezelfde features als we onder Nodered wel hebben. Kostenloos met evt NDA geen probleem voor mij. Maar helaas, ze gaven aan geen interesse te hebben en het zelf wel zouden doen, ooit. Als het niet snel genoeg zou gaan, dan kon ik altijd een third party integratie maken zodat ze het daar van konden "lenen".
Rare snuiters.

Anno 2026 heb ik al lang geen Homey meer en zitten de functies er ook nog steeds niet in.
Beter dat iedereen kiest voor open source zodat de community echt vooruit kan.

[AJediIAm]

Home Assistant vertrouwt ook voornamelijk op de community voor integraties. Beide doen dat voor een rede. Het is lastig om garant te moeten staan voor de kwaliteit en onderhoud van honderden integraties. Als er geen community members is die wilt helpen kan je er beter niet aan beginnen.

Nu beide platformen Python ondersteunen hoop ik dat ook de community meer overlap krijgt en we integraties voor zowel Home Assistant en Homey naast elkaar kunnen ondersteunen. Het meeste werk zit namelijk is de communicatie met de backend terwijl de integratie met het platform relatief stabiel en eenvoudig is.

[Halfscherp]

Home Assistant is gratis en open. Homey kost €300-€500 per paar jaar.

[Osiummaster]

Home Assistant heeft recent besloten om de temperatuur van kleuren in "mireds" om te zetten naar Kelvin, dus de helft van mijn lamp automations waren plots kapot na een update. Ze doen niet even de moeite om het automatisch te converteren of de gebruiker op de hoogte te stellen, dus moest nota-bene een LLM vragen hier een script voor te schrijven. En dit soort zaken gebeuren wel vaker. Ik denk er serieus over na om over te stappen. Homey schijnt een stuk stabieler te zijn.

[lenwar]

Home Assistant heeft recent besloten om de temperatuur van kleuren in "mireds" om te zetten naar Kelvin, dus de helft van mijn lamp automations waren plots kapot na een update. Ze doen niet even de moeite om het automatisch te converteren of de gebruiker op de hoogte te stellen, dus moest nota-bene een LLM vragen hier een script voor te schrijven.

Het was in augustus 2021 gecommuniceerd dat ze van mireds af wilden stappen (Mireds waren initieel toegelaten voor compatibiliteit met Hue). In december 2024 was het formeel 'depricated' (en kreeg je dus sinds die tijd foutmeldingen (op niveau WARNING) als je mireds gebruikte), in maart 2026 was het verwijderd.

Automatisch omzetten had inderdaad netjes/handig geweest, en meestal doen ze dat ook wel als je ze via de GUI had ingesteld. (en dan weer niet als de waarden in templates zitten en zo.)

https://developers.home-assistant.io/blog/2026/02/23/remove-deprecate-light-features/

[landcross]

Het ging alsnog wel een beetje raar hoor. In mijn geval had ik een automation die plots niet meer werkte na de laatste update. Wat bleek: de automation zette een lamp aan op een specifieke temperatuur. Die gebruikte al wel netjes de attribute 'kelvin'. Echter na de recente update moest dat blijkbaar ook anders; dat moet 'color_temp_kelvin' zijn. De automatisering was ooit met de GUI aangemaakt, diezelfde GUI ging na de update kapot (liet rechtstreeks de YAML zien) en na het aanpassen van kelvin naar color_temp_kelvin werkte diezelfde GUI wel weer direct netjes...

Home Assistant is in mijn ervaring best goed met het zo veel mogelijk automatisch omzetten van configuratie en anders waarschuwingen voor geven. Maar deze wijziging ging niet automatisch, noch heb ik er een waarschuwing over gekregen.

[svenk91]

Dit is precies waar ik vandaag mee bezig was. Ik gebruikte ook ‘kelvin’, rechtstreeks dankzij de gui. Dat was nu niet goed meer zonder enige waarschuwing buiten de release notes. Gelukkig kon ik het probleem en de oplossing snel op Google vinden.

Maar ik til er niet zo zwaar aan. Shame on me dat ik de release notes niet even door skim. Van een betaalde oplossing als Homey of Hue zelf stel ik wel hogere eisen op dit gebied. Maar ik kies juist HA voor de tweakbaarheid en al het community werk.

[bytemaster460]

Home assistant is natuurlijk begonnen als een soort hobbyproject waarbij de verschillende ontwikkelaaras geen standaarden aanhielden. De afgelopen jaren is er heel veel aangepast naar standaarden met de juiste eenheden en benaderingen. Dat is toe te juichen, en ja dat betekent dat je als early adapter af en toe iets moet aanpassen. Meestal gebeurt dat wel automatisch via het installatiescript.

T.a.v. die mireds staat er al maanden lang een warning in de log files dat mireds "deprecated" worden.

[lenwar]

Precies. Home Assistant is als hobbyproject begonnen om meer uit Hue te kunnen halen tot de 'de facto standaard' van (semi-)toegankelijke en modulaire thuisautomatisering. Ze hebben echter nog steeds last van die legacy van dat 'hobbyproject'

Sinds alweer een aardig tijdje zijn ze heel erg aan het professionaliseren en veel voorspelbaarder geworden. Zo is bijvoorbeeld de 'migratie' van 'hacken van yaml-bestanden' naar de GUI er één van die alsmaar doorgaat. Stapje voor stapje. Ook wordt de interface stukken toegankelijker bij iedere release. Een ander mooi voorbeeld zijn de 'quality scales' en natuurlijk het 'works with Home Assistant'-programma. Recentelijk is er zelfs een fabrikant uit dat programma gehaald omdat ze er niet meer aan voldeden, en dus aantoont dat het niet alleen maar een momentopname en een inkomstenbron is.

En, we moeten ook eerlijk zijn. Home Assistant 'oogt' nog steeds als een systeem dat 'door techneuten, voor techneuten' is gemaakt. En dat is iets dat waarschijnlijk nog wel even zal duren. De Homey van LG is een heel stuk toegankelijker in de uitstraling. Het heeft uiteraard ook wel echte beperkingen t.o.v. Home Assistant, en het verschilt per huishouden/installatie hoe erg je daar wel of niet tegenaan loopt.

[AJediIAm]

Begrijp ik het goed dat je het een open source project (aka alle community members) kwalijk neemt dit niet te automatiseren? Het stond overigens gewoon in de patch notes onder breaking changes, maar die leest men natuurlijk niet. Er zijn ook tal van oplossingen beschikbaar in de community.

Het is vaak kiezen tussen innovatie en stabiliteit. Je mag blij zijn als je iets beters dan de standaard shitification kan vinden en wat dat betreft zit je bij Homey best goed.

[Osiummaster]

Home Assistant is gewoon een betaald project met een groot team. Niet een kleine groep amateurs. Ik heb er zelf ook geld aan uitegegeven. Het breken van licht automations is een basis functionaliteit.

Ik ga echt niet de breaking changes lezen elke keer voordat ik op update druk. Dit soort problemen hadden heel makkelijk voorkomen kunnen worden als Home Assistant een kleine popup gaf of ik de mireds om zou willen zetten in kelvin. Of het gewoon automatisch deed.

[MoonRaven]

Ik ga echt niet de breaking changes lezen elke keer voordat ik op update druk

Dat is wel erg makkelijk klagen dan. "Ja sorry agent, ik reed misschien door rood, maar ik ga niet elke keer naar het verkeerslicht kijken als ik over wil stekenh"

[Osiummaster]

Breaking changes wordt door competente developers voor gewaarschuwd. Als je Python gebruikt en je runt deprecated code dan krijg je een rode waarschuwing in je terminal dat je die code moet veranderen. Home Assistant geeft geen notificatie en besluit dat je naar hun website moet gaan om de patch notes te lezen iedere keer dat je op update drukt? lol.

[TheMaxMan]

Mijn log stond het afgelopen jaar vol met waarschuwingen elke keer een automation of script het gebruikte:

Got kelvin argument in turn_on service, which is deprecated and will break in Home Assistant 2026.1, please use color_temp_kelvin argument

[Reactie gewijzigd door TheMaxMan op 11 maart 2026 14:04]

[Bor]

Breaking changes wordt door competente developers voor gewaarschuwd.

Er is dan ook voor gewaarschuwd, zowel op het niveau warning als een melding bij de breaking changes. Kortom, precies wat jij aangeeft te willen volgens mij. Dat je waarschuwingen niet bekijkt of moedwillig negeert levert je bij welk systeem dan ook vroeg of laat issues op; zowel bij HA als Homey.

[D4NG3R]

Tjah.. anderzijds lezen competente gebruikers ook de documentatie en negeren ze niet moedwillig de waarschuwingen welke al een dik jaar in de (change)logs stonden. Kleurtemperatuur in Mireds werd al sinds december 2024 niet meer in de GUI aangeboden.

Bij de major updates is het sterk aan te raden om de backwards incompatible changes te lezen voordat je op updaten klikt.

Zelf in het verleden ook een keer mee tegen de lamp gelopen door argeloos te updaten.

Dat men er in deze situatie beter mee om had kunnen gaan ben ik overigens met je eens. Het had niet misstaan als automations, scripts, e.d. gemaakt vanuit de GUI automatisch bijgewerkt werden.

[Reactie gewijzigd door D4NG3R op 11 maart 2026 14:36]

[emoeloe]

Er zijn gewoon meldingen voor deprecated functies, dus die heb je dan mogelijk gemist. Kan gebeuren, maar de competentie van de developers er bij halen is meteen wel weer heel hard in de aanval vind je ook niet?


En daarnaast zijn de patch notes toch communicatie? Dat is de plek waar ze aangeven wat er niet meer werkt, dus ik vind het niet gek om te verwachten dat iemand daar naar kijkt. Uiteindelijk is dat het 'nadeel' van Home Assistant, als je iets wilt waarbij je volledige support hebt en iemand kan bellen om te roepen hoe incompetent ze zijn dan moet je een volledig IKEA of Hue systeem hebben. Al geldt ook daar dat er dingen kunnen veranderen (denk aan het Hue account wat verplicht werd) waar je zelf actie voor zult moeten ondernemen.

[Osiummaster]

Het feit dat een LLM slop bash scriptje het voor mij op kon lossen betekent dat de devs dit zelf ook hadden kunnen doen bij de update. Iets deprecated maken is okee maar dit is allemaal via de "officiele" HA interface aangemaakt. Zorgen dat gebruikers de patch notes moeten lezen om handmatig alle individuele scripts te updaten (ik heb er een scriptje voor ge genereerd) is van de zotten voor basisfunctionaliteit.

[RobertMe]

Home Assistant is gewoon een betaald project met een groot team. Niet een kleine groep amateurs.

Je haalt dingen door elkaar. Home Assistant is een open source project waar veel door hobbyisten aan gewerkt wordt. Nabu Casa is een relatief nieuw (~2 jaar oud) bedrijf dat een aantal commerciële producten aanbiedt voor Home Assistant (zoals de "cloud" en de ZWA-2 en ZBT-2 sticks). Waarbij Nabu Casa vervolgens developers in dienst heeft die bijdragen aan Home Assistant. Als je bij iemand wilt klagen dat je betaalt en de support prut is moet je dus bij Nabu Casa zijn, die heb je betaald, niet Home Assistant.
En ja, Nabu Casa is opgericht door Paulus Schoutsen de "bedenker" van Home Assistant, en ja, een aantal van de "bekende gezichten" zijn ook in dienst van Nabu Casa. Maar dat betekent niet dat Nabu Casa direct verantwoordelijk is voor jou probleem. En daarnaast magsinds kort ook Apollo Automations producten uitbrengen onder de Home Assistant naam (anders dus dan het "Works with Home Assistant" programma). Waarbij je als je iets van Apollo koopt met een Home Assistant naam ook niet direct bij hun kunt aankloppen voor algemene HA support.

Ik ga echt niet de breaking changes lezen elke keer voordat ik op update druk.

Tsja, dat is jouw keuze. Voldoende zaken waarbij of gewerkt wordt met breaking changes of bv een lijst met known issues. Als je die niet wilt lezen dan is dat gedeeltelijk ook een eigen keuze en dus probleem. Daar kun je niet alleen Home Assistant op aankijken.

[Osiummaster]

Ik klaag ook over Nabu Casa. Dit hadden ze heel simpel kunnen voorkomen door automatisch mired waardes om te zetten naar Kelvin waardes bij de update. Slechte keuzes in het verleden zijn begrijpelijk, maar zulke simpele problemen niet oplossen en de last bij de gebruiker neerleggen is onbegrijpelijk

[RobertMe]

Ik klaag ook over Nabu Casa. Dit hadden ze heel simpel kunnen voorkomen door automatisch mired waardes om te zetten naar Kelvin waardes bij de update.

Waarom zou Nabu Casa dit moeten doen? Is deze deprecation => verwijderen ondersteuning gedaan door een Nabu Casa medewerker? En dan nog zou je kunnen stellen dat diegene dat (potentieel) in zijn eigen tijd gedaan heeft aangezien dit niks te maken heeft met iets dat Nabu Casa verkoopt. Ze verkopen geen lampen (bv). Als de HA Cloud (integratie) stuk is kun je bij Nabu Casa klagen omdat je hun ervoor betaalt. Maar als iets stuk gaat in de light integratie terwijl dat geen Nabu Casa "product" is?

Hetzelfde dus dat als je bv Red Hat betaalt oor hun Linux distributie dat je, vermoed ik, ook niet voor elk wissewasje naar Red Hat kunt wijzen als "hun fout want ik betaal ze er voor". En dan zul je bij Red Hat ook nog een (duur!) support contract hebben. Terwijl Nabu Casa je geen ondersteuning voor HA verkoopt (wel ondersteuning voor de producten die ze zelf verkopen, het cloud abo, de sticks, ... mag ik aannemen / uberhaupt onder Europees consumentenrecht).

[Osiummaster]

Nabu Casa is het bedrijf dat Home Assistant ontwikkelt. Dit wordt betaald van de hardware en software die ze verkopen. Ga nou niet doen alsof dit een stel altruisten op hun zolder zijn.

[smesjz]

Nope. Open Home Foundation ontwikkelt Home Assistant en developers zijn in dienst van die stichting, niet meer bij Nabu Casa. Zie https://www.openhomefoundation.org/structure/
Nabu Casa zorgt wel voor grootste deel van de funding van de stichting maar is wel onderscheid..

[Pyronick]

Nabu Casa is het bedrijf dat Home Assistant ontwikkelt. Dit wordt betaald van de hardware en software die ze verkopen. Ga nou niet doen alsof dit een stel altruisten op hun zolder zijn.

Dat Nabu Casa via de verkoop van hardware en de Home Assistant Cloud-abonnementen de salarissen van de kernontwikkelaars betaalt, klopt helemaal. Open-source ontwikkeling op deze schaal is een enorme systeemtechnische uitdaging en is simpelweg niet gratis. Nabu Casa ontwikkelt vooral hardware en het cloudplatform.

Home Assistant, daarentegen, is eigendom van de Open Home Foundation. Nabu Casa heeft het project dus niet in handen, maar fungeert hooguit als de commerciële motor die de winst afdraagt aan deze stichting. Het is geen kwestie van blinde altruïsme op een zolderkamer, maar een doordacht, pragmatisch model om technologische soevereiniteit en "right to repair" te financieren, zonder de ziel van het platform te verkopen.

[R_Zwart]

Dat je spullen kunt kopen bij/van Home Assistant maakt het nog geen betaald project. De software is gewoon een open source project.

[DennusB]

Stabieler, mwaaaaaaah. Vooral een stuk beperkter.

[Sito]

Home Assistant kondigt dit soort breaking-changes altijd ruim van tevoren aan, dus ik snap de uitspraak 'recent besloten' niet zo goed. Zoals @lenwar hieronder aangeeft, begon dit deprecation proces al in oktober 2022, waarbij in december 2024 je deprecation warnings zag in Home Assistant als je de oude unit nog gebruikte.

Kan het zijn dat je deze meldingen over het hoofd hebt gezien? Of tactisch genegeerd hebt?

[Osiummaster]

Ik heb geen enkele melding of popup gekregen dat het deprecated zou zijn.

Nog kwalijker: ik kreeg geen melding na de update dat het deprecated was. Mijn automations waren gewoon plots kapot. Ik moest zelf de logfiles doorlezen om het probleem uit te vinden.

De volledige patch notes moeten lezen voor iedere update is geen excuus voor slechte development. Dit had heel makkelijk automatisch opgelost kunnen worden bij de update (dat is wat de meeste updates doen, die veranderen automatisch de nodige oude code met nieuwe code)

[dhrto]

Dit stond duidelijk in de breaking changes bij de betreffende release.
Zo veranderen er wel vaker fundamentele dingen in HA. Altijd goed om de release notes te lezen, alvorens klakkeloos op update te drukken (en een backup te hebben, om snel terug te kunnen voor het geval dat).

[Osiummaster]

Want iedereen leest altijd elke patch note door voor alles voordat ze op update drukken. Elke dag voordat ik sudo apt update && sudo apt upgrade -y druk, lees ik altijd eerst elke patch note voor elk programma. En natuurlijk gaat men ook altijd naar de Microsoft website om te lezen wat er veranderd is voordat ze op update drukken.

Als dit relevant was had het bij het update knopje moeten staan voordat de patch apply'de

[Heady]

Ik hoor hier ontzettend veel frustratie, bij een GRATIS product wat blijkbaar niet weg gelegd is voor jou omdat je verwachtingen hebt die simpel weg niet altijd haalbaar zijn.

Zoals iedereen hier tracht uit te leggen is dat Home Assistant een community driven software is, waarbij Nabu Case extra ondersteuning aan bied aan de community.

Zoals ik het bekijk heb je 2 opties.
1: Als je dit zon groot punt vind, zou ik zeggen doe mee met de community en de ontwikkeling en zorg ervoor dat dit soort scripts/functionaliteit aanwezig zijn.
Het is immers open-source en daarom dus je mee kan dragen aan dit soort dingen.
En of bij elke release de release notes door nemen zodat je zelf hier rekening mee kan houden.
Immers ben je zelf verantwoordelijk voor wat je configureert binnen home-assistant.

2:Naar een volledig payed closed off systeem gaan en alles van maar 1 vendor gebruiken voor all je apparaten en dus ook de beperkingen die er zijn voor lief nemen.

Mijn advies voor jou?
Blijf lekker in 1 eco systeem van een vendor, die hoeven maar rekening te houden maar met een handje vol devices in plaats van honderden verschillende devices die ieder ander op een ander manier gebouwed is.
En je 90% meer zekerheid geeft voor het gene wat je 5 jaar geleden gebouwed heeft blijft werken totdat de vendor besluit support te stoppen voor je devices en je dus na x jaar alles moet vervangen
Maar dan weet je wel gelijk de oorzaak en scheelt je uren troubleshooten

***
Price is what you pay
Value is what you get
***

De waarde die home-assistant mij geeft is niet te vergelijken met de tijd die ik moet spenderen om bij elke release het werkend te houden

[Osiummaster]

Ik heb financieel bijgedragen aan Home Assistant zowel met hardware als software aankopen en het is nu gewoon een bedrijf met meerdere betaalde werknemers. Het krijgt dan ook de verantwoordelijkheid van een bedrijf dat betaalde diensten levert. Dit soort harde breaking changes die makkelijk voorkomen hadden kunnen worden horen niet voor te komen.

[19JM81]

Laat ik je gelijk uit de droom helpen, nee, absoluut niet.

[JRX]

Ik heb heel lang Homey Pro gebruikt. Waar dat in het begin heel stabiel was, werd dat steeds minder het geval; meerdere vastlopers per dag, waarbij de Homeys ook lokaal niet meer bereikbaar was en apparaten niet meer reageerden. Ook na de upgrade van een 2019 Pro naar 2023 Pro bleven deze problemen terugkomen.

Nu juist overgestapt op Home Assistant (als VM op een server met Proxmox) en dat werkt gewoon heel stabiel. Het inrichten en opzetten van de automations is wel wat omslachtiger dan bij Homey en niet alles wordt zomaar ondersteund; er zijn nu een paar extra apparaten nodig voor het aansturen van bepaalde IoT-devices (denk aan IR, Somfy RTS en natuurlijk ook Zigbee), maar ook die draaien heel stabiel.

Ik kan me wel voorstellen dat het heel irritant is als bepaalde automatiseringen ineens niet meer werken, doordat implementatiedetails - zoals de Kelvin in jouw voorbeeld - zomaar aangepast worden. Je zou verwachten dat er met zo'n wijziging nagedacht wordt over een migratie van dergelijke automatiseringen, of een duale periode waarin beide standaarden ondersteund worden. Maar het is natuurlijk wel open source, dus als iemand zich geroepen voelt om dit bij te dragen...

[Mathi159]

Welke unit werd hiervoor gebruikt dan? Lichttemperatuur is toch standaard in Kelvin (althans, de wit balans dan natuurlijk)

[Osiummaster]

Mireds blijkbaar (niet dat ik dat wist, ik gebruikte gewoon de UI om mijn licht scripts te maken en die had een temperatuur slider)

[iAR]

Home Assistant heeft afgelopen jaren veel ontwikkelingen doorgemaakt. Die gaan nu eenmaal gepaard met breaking changes. De release notes zijn daar heel duidelijk over.

Homey is niet perse stabieler, sterker nog: Zigbee is in HA vele malen stabieler bij veel apparaten dan Homey. Het enige dat ik mis van Homey is Advanced Flow.

[Llopigat]

Dat is inderdaad vreselijk irritant aan home assistant. Elke release wordt er wel wat stuk gemaakt. De template sensoren een paar maanden geleden waren ook enorm irritant. Ik had er een stuk of 60, die moesten allemaal veranderd worden. Juist ook omdat Home Assistant het weigert om dingen in de presentatielaag af te handelen van dingen die daar puur thuishoren en er altijd maar weer wordt geroepen: Maak een template sensor aan. Als je bijvoorbeeld een temperatuur binnenkrijgt met 10 cijfers achter de komma maar 15,3846527 graden liever als 15,4 wil zien in je dashboard. Daar is geen vinkje voor in de UI, nee dan moet je een hele aparte template sensor maken die je apart loopt te loggen in de database enz Hetzelfde met esphome, daar moet je regelmatig ook van alles omkatten in de configuratie.

Dat vermindert voor mij het vertrouwen, en vergroot de irritatie/frictie met het systeem. Het is iets waar ik niet elke maand aan wil lopen knutselen als hobby. Het is iets wat gewoon in een hoekje moet zitten draaien en zijn werk doen. Dus wat krijg je dan, dat ik helemaal niet meer op update ga drukken omdat ik geen zin heb in alle gedoe die daar bij komt kijken, maar dan gaat na een maand of 6 natuurlijk echt alles kapot.

Ik heb ook al een paar keer serieus zitten zoeken naar wat anders. Zoals Openhab enzo, domoticz. Maar die twee vind ik ook niet interessant. Homey is voor mij niet echt een oplossing, te commercieel. Ik hoop eigenlijk dat er een fork komt van home assistant met meer focus op stabiliteit van de configuratie. En minder focus op de massagebruiker (die hier toch helemaal niet aan wil, die kijkt niet verder dan een homekit of google home).

[Reactie gewijzigd door Llopigat op 11 maart 2026 18:54]

[RobertMe]

Zou dit er toevallig mee te maken kunnen hebben met dat Home Assistant volledig in Python is geschreven? Waarbij vanuit Home Assistant integraties vaak/altijd een losse library (moeten?) gebruiken om ergens mee te koppelen. En de integratie in Home Assistant is vervolgens puur de "lijm" die de library aan Home Assistant plakt.

In principe zou het dus mogelijk moeten zijn om zo'n library te pakken en vervolgens "aan Homey te lijmen" via dan deze Python SDK. Waardoor de ontwikkelaar van de Homey app niet meer perse alle ins- en outs hoeft te weten hoe met een extern systeem te integreren, en ook niet bezig hoeft te zijn met wijzigingen van dat externe systeem, omdat de gebruikte library dat soort dingen kan abstraheren.

[lenwar]

Ik vermoed eerder omdat Python een populaire taal is, en dat er (zoals je aangeeft) gigantisch veel libraries als in Python beschikbaar zijn. Veel mensen 'spreken' Python, dus dat helpt dan.

[jrswgtr]

Een externe library neemt werk uit handen, maar lost onderhoud niet magisch op. Een libary kan zelf ook breaking changes introduceren of achterblijven met updates terwijl de achterliggende API wel verandert.

[pOZOR jED]

Dit maakt Homey eindelijk een aantrekkelijk alternatief!
De 'talen' die ze tot op heden ondersteunden, waren mijn inziens niet de meest logische, dus bleef ik altijd op het oude vertrouwde Home Assistant hangen.

[kylemichiels]

Dit vind ik een rare opmerking.
TypeScript (of JavaScript) zijn beide veel logischere talen dan Python.

[pOZOR jED]

Voor communicatie met API's, het kneden van de data? nee sorry, dan toch liever Python dan Javascript. Misschien komt het mede om hoe ik Javascript heb leren kennen in de jaren '90 dat ik het niet als serieuze taal zie, kan. Maar het is meer een frontend iets dan een serieuze taal voor mij.

[basmilius]

Dat is de afgelopen jaren echt heel erg veranderd. Kijk naar Node.js en de hele community daaromheen. JavaScript is echt wel een serieuze taal. Ik heb voor mijn Homey Apple TV & HomePod app de protocollen van Apple moeten implementeren, in TypeScript en dat werkt.

Tuurlijk zitten er rariteiten in, maar om het geen serieuze taal te noemen...

[pOZOR jED]

Daarom zei ik al, ik ken het vanuit de jaren '90 ;)

Python heb ik ook in de jaren '90 leren kennen, naast Perl toen der tijd, en dat voelde toen allemaal net iets serieuzer, daarna dus nooit meer teruggekeken naar JavaScript. Had ik wellicht eens moeten doen, maar ik juich deze stap van Homey daarom ook toe. Misschien gewoon mijn gebrek

[salipander]

Dat is een grote stap voorwaarts die alleen maar te verwelkomen is!

[AJediIAm]

Ik hoop dat er meer kruisbestuiving komt tussen Homey en Home Assistant. Het zijn verschillende platformen voor verschillende doelgroepen en het zijn voornamelijk de consumenten die profiteren van meer integraties en apps.

[basmilius]

Eindelijk officieel! Paar weken geleden al stiekem het migreren van de Apple TV & HomePod app van mijn eigen typescript library naar pyatv gestart

[nklerk]

Goed om te horen.

[telenut]

Ontwikkeling van Homey blijft toch goed doorgaan.
Ik heb deze week voor het eerst zelf een app "gemaakt". 100% vibe coded.
Heb lang zitten twijfelen om over te stappen op HA, omdat die specifieke zaken die ik wou net daar wel in zaten en in Homey nog niet. Echter is het gebruiksgemak van Homey zo veel groter...
Dus vroeg ik gewoon aan Gemini om een app van HA om te zetten naar een app voor Homey, binnen het uur had ik al een werkende versie! Door ondersteuning voor python zal dit vermoedelijk nog makkelijker worden.

[iAR]

Ik vind dat Home Assistant echt wel flinke stappen maakt. Maar goed, iets complexer blijft het. Maar goed, je kan in HA dan ook echt alles naar je hand zetten. Dat is in Homey niet. Hopelijk komt Advanced Flow ooit nog naar HA.

[telenut]

Ja, veel kleine stappen :-)
Op enkele maanden tijd stonden bijna wekelijks updates klaar... Nu, is bij Homey misschien ook, maar daar merk ik het toch niet

[JPB02]

HA heeft ipv advanced flows nodeJS, of recenter C.A.F.E. (Deze heeft nog redelijk wat bugs en mist features maar PR's zijn welkom daar) die werkt met de automatisatie engine van HA zelf. Op eerste gezicht lijkt dat redelijk hetzelfde, of bedoel je iets anders?

[Ethirty]

Hopelijk gaan een aantal leveranciers die wel voor HA ontwikkelen nu hun apps ook naar Homey brengen.

Zeker als een deel van de codebase gedeeld kan worden tussen die twee platforms lijkt me dit een goede ontwikkeling.

[The_Brug]

Mooie stap van Athom. Voor degenen die hopen dat dit de deur openzet om Home Assistant (HA) direct op een Homey Pro te draaien: dat gaat helaas niet gebeuren, en dat is ook logisch.

Python op Homey is een uitbreiding van de SDK (de sandbox), geen openstelling van het OS. HA is een compleet ecosysteem (HAOS/Container) dat directe hardware-toegang nodig heeft voor zaken als Zigbee/Z-Wave drivers. Homey laat je binnen hun afgeschermde omgeving werken, wat juist de stabiliteit waarborgt waar Homey-gebruikers voor kiezen.

Waar de winst wél zit: de drempel voor HA-ontwikkelaars om hun complexe integraties of AI-gebaseerde scripts naar Homey te poorten is nu factor 10 lager. Vooral met de 4GB RAM in het nieuwe 2026-model is er eindelijk ruimte voor zwaardere Python-libraries (denk aan lokale data-analyse of uitgebreidere device-drivers).

Kortom: Geen HA op Homey, maar wel een Homey die veel meer op HA gaat lijken qua community-power.