Google voegt lokale aansturing van Matter-apparaten toe aan Google Home

Matter-apparaten kunnen voortaan ook lokaal aangestuurd worden via Google Home. Google heeft dat mogelijk gemaakt door de integratie van Google Home Runtime in ruim veertig miljoen apparaten, waaronder Nest-apparaten, Chromecasts en Google TV op Android 14.

De lokale ondersteuning is alleen beschikbaar voor apparaten met Matter-ondersteuning. Matter komt namelijk met een gestandaardiseerde aanpak voor lokale aansturing. Daardoor hoeven bijvoorbeeld slimme lampen niet meer met de cloud te communiceren als ze de opdracht krijgen om aan te gaan. De gestandaardiseerde aanpak maakt het eenvoudiger om deze lokale aansturing toe te voegen aan smarthomeplatformen.

Google heeft die stap nu genomen, wat betekent dat de Google Home-hubs ook niet meer met de cloud hoeven te communiceren om een Matter-apparaat aan te sturen. Slimme apparaten met Matter-ondersteuning zijn dus ook via Google Home aan te sturen als er geen internetverbinding beschikbaar is, bijvoorbeeld tijdens een internetstoring. Voorwaarde is wel dat de slimme apparaten en de Google Home-hub in kwestie in hetzelfde huis staan en dat de gebruiker deze thuis aanstuurt, verklaart Google Home-productmanager Jeannie Zhang tegenover The Verge. Het is dus niet mogelijk om buitenshuis gebruik te maken van de lokale aansturing.

Google maakt verder bekend dat het zijn Home-api's openstelt voor alle ontwikkelaars. Daarmee kunnen ontwikkelaars ondersteuning voor Google Home- en Matter-apparatuur toevoegen aan hun applicaties en hier zelf automatiseringen mee maken. De Home-api's werden afgelopen mei al aangekondigd, maar waren destijds nog niet voor alle ontwikkelaars beschikbaar.

Door Eveline Meijer

Nieuwsredacteur

09-01-2025 • 08:52

47

Reacties (47)

47
47
8
0
0
38
Wijzig sortering
Je kan lokaal helemaal geen matter apparaten bedienen met Google home als internet eruit ligt.
De google apparaten werken dan niet.
Als je goed leest gaat dat dus veranderen.

Een klein maar voor tweakers misschien significant detail is dat Matter gebruik maakt van IPv6 adressering. Dus iedereen die dat geforceerd uit heeft staan bijt zichzelf hier in de vingers.
Nee @joosd heeft gelijk.
Wanneer je internetverbinding eruit ligt houden de Nest Hubs volledig op met werken, je krijgt dan ook een foutmelding op het scherm en vervolgens begint het je DNS server te spammen.
Mijn ervaring is dat zodra mijn internet wegvalt ik de Nest helemaal niet meer kan gebruiken, alles valt uit, ik kan zelf de foto , het uur of het weer niet meer zien, er komt dan een erg lelijke fout op dat er geen internet is. Dus zelf moest het matter kunnen ondersteunen lokaal, dan kan je nog steeds niet aan de GUI.

Dat heb ik trouwens altijd vreselijk gevonden, waarom alle functies uitschakelen zodra er even onderbreking is zoals een router herstarten.
Kun je IPv6 überhaupt uitzetten op smart devices? Op mijn lampen of stekkers zit geen netwerkconfiguratiescherm.
Met smart-devices is het apparaat afhankelijk. Gezien Matter de IPv6 adressen gebruikt, zal je bij het blokkeren/uitzetten van IPv6 ook het Matter protocol uit zetten. Daarmee lijkt het mij niet praktisch om IPv6 uit te zetten.

Andersom: Als je matter wilt gebruiken en je wilt matter over IP laten lopen, dan moet je dus IPv6 ondersteunen op je interne netwerk. Gezien de aard van Matter zullen zaken als 'auto discovery' en dergelijke wel aan moeten staan. Het is zeer waarschijnlijk dat Matter apparatuur geen IPv4 ondersteunt. IPv4 is namelijk geen onderdeel van de Matter standaard.
Zou Matter over Thread daar last van moeten hebben dan?

Oprechte vraag, maar mij lijkt het dat dat niet over je reguliere wifi netwerk gaat en dus ook geen last heeft van routerconfiguratie. De Thread Border Router handelt dan het verkeer af.
Volgens mij gebruikt matter over thread ook de IPv6 adressen. De kans is groot dat de routering en dergelijke via thread het zelfde gebeurt als via ethernet of wifi.

In het iso-osi model zitten ethernet, wifi en thread in de onderste lagen (laag 1 voor de 'hardware', laag 2 voor verkeer dat door je switch (op basis van mac address) of door de ether (bijvoorbeeld op basis van je wifi-naam) gaat. Gerouteerd verkeer zoals IPv4 en IPv6 in de laag daar boven (volgens mij laag 3).

Daarmee zie ik thread (en zigbee, z-wave, 443MHz en dergelijke) ook in iso-osi laag 2 zitten.

Uiteindelijk zie ik het Matter protocol in iso-osi in de data lagen (5, 6 en 7) zitten. Zie voor het plaatje.
Tuurlijk gebruikt Matter als protocol IPv6.

De stelling was dat als je IPv6 zou uitschakelen binnen je draadloos/bekabeld netwerk, dat ook impact zou hebben op Matter accessoires.

Dat is natuurlijk enkel zo als ze effectief op je netwerk zitten en geen eigen netwerk hebben, wat Thread net zoals Zigbee is.

Je kan IPv6 uitzetten zoveel je wil op je eigen netwerk, als het Thread netwerk daar niks van aantrekt heeft het ook geen impact op je Matter devices die via Thread onderling communiceren.
Op zich heb je helemaal gelijk. Maar bedenk dat er altijd wel een Matter apparaat is dat via het thuis-netwerk gat werken. Zoals bijvoorbeeld de google apparatuur waar dit bericht mee begon. En denk ook aan de centrale waar vandaan je de apparatuur allemaal bedient.
Als je eindapparaten via Matter over Thread gaan, dan kan je Google apparaat prima tot aan de Thread Border Router over IPv4 communiceren.
De google apparatuur heeft allemaal hun eigen api. En zoals in het bericht aangekondigd wordt er voor sommige apparaten een nieuwe api geregeld. Die is dan als api beschikbaar op de netwerk aansluitingen.

Maar het matter protocol ondersteunt geen IPv4. Daarmee zal het geen matter verkeer worden. De functionaliteit die via het matter protocol wordt geleverd maar op de api niet beschikbaar is, zal dan niet werken.

Uiteindelijk is het IPv6 protocol zodanig dat het vanzelf gaat werken. Zet je het op bepaalde apparatuur bewust uit, dan doet die apparatuur dus niet mee in het IPv6 netwerk. De rest gaat gewoon via IPv6 werken. Pas als je actief het IPv6 verkeer gaat blokkeren, zal matter daar niet langs/doorheen kunnen. IPv6 zou er dan zomaar langs kunnen gaan en haar eigen paden op je netwerk vinden.
Ik denk dat je zaken door elkaar haalt.

Het maakt niet uit welke API Google aanspreekt, maar als ze Matter gaan aansturen lokaal, en het Matter over Thread is, dan moet dat verkeer tot aan de thread border router geraken.

Dat kan prima via ipv4.

De thread border router kan dan onafhankelijk van de rest van je netwerk communiceren met Matter apparaten via het Thread netwerk.

En als andere apparaten met Google willen communiceren, dan gaan de Matter over Thread apparaten van Google communiceren met de border router, niet via je reguliere netwerk.
Waarschijnlijk hebben jij en ik de protocollen en de iso-osi stack niet helemaal het zelfde ingevuld. Matter is niet een protocol dat over een ip-netwerk gaat. matter is een eigen protocol dat over ethernet of over thread gaat. Matter is in plaats van tcp/ip. Daarbij gebruikt matter de IPv6 addressering en eventueel ook de IPv6 routering.

Als je denkt dat Matter in je privé netwerk over IPv4 draait en je start de monitoring op, dan zal je zien dat het IPv6 pakketten zijn. Binnen een geswitcht netwerk zal dat netjes werken, zelfs tussen wifi en ethernet. Maar als jou router geen IPv6 ondersteunt, dan zal het verkeer daar niet door heen gaan.

De thread border router is effectief ook een IPv6 router. Die routeert het IPv6 verkeer. Het zou zelfs kunnen dat je met 2 thread border routers via een thread netwerk 2 'normale' netwerken met elkaar verbind. Dat mits de thread router dat verkeer wil en mag routeren.
Volgens mij hoef je geen publieke IPv6 range of zo te hebben. Ik vermoed dat Matter ULA (Unique local addresses) adressering gebruikt tussen devices. Dat werkt ook zonder dat de eindgebruiker enige kennis van netwerken heeft.
Is er een reden om IPv6 uit te zetten dan?
Naar mijn mening niet. Maar er zijn mensen die niet begrijpen hoe het werkt en het dan liever uitschakelen.
Schuldig. Ik heb al jaren AGH dns en nooit de moeite genomen om ipv6 dns adblocking te doen. (inclusief block van ip ranges oa google dns).

Maar, als ik matter wil hoef ik dus niet perse over ook begrijp ik
Wat mij betreft is dat er nooit geweest.

Er zijn altijd 'techneuten' en 'goeroes' die beweren dat IPv6 niet goed zou zijn of zelfs dat het onveilig is en dat die het daarom uit willen hebben.
En er zijn nog steeds veel te veel organisaties die niet de moeite nemen om een vertaling van de gevestigde IPv4 configuratie te maken naar een nette IPv6 configuratie.
Ik zou het zelf anders bekijken, is er een reden om IPv6 uberhaupt te gebruiken? Ik ben zelf 1 van de ipv6 uitschakelaars (op het thuisnetwerk) puur omdat de adressering een pita is (even je lokale ipv6 intikken in de browser is voor mij in elk geval niet zo makkelijk als ipv4).

Als er een goede reden zou zijn zou ik deze heel graag horen aangezien mijn netwerk binnenkort op de schop gaat en ik daar wat keuzes in moet/wil maken.
Ik typ ook nog steeds v4 adressen in als ik per sé een adres moet typen. Maar voor de meeste interne hosts heb ik gewoon DNS records gemaakt. Toch heb ik alles dual-stack draaien, dus zowel v4 als v6. Het is immers op termijn niet meer weg te denken dus ik wen er liever geleidelijk aan en leer zo hoe het werkt dan straks ineens om moeten.

Soms komt het ook echt wel van pas. Nu we op mijn werk ook v6 hebben kan ik de webapps op mijn interne hosts rechtstreeks bereiken zonder port-forwarding met unieke poortnummers. Dus gewoon https://sonarr..../ i.p.v. https://sonarr...:8443/ of iets dergelijks.

Het was verrassend makkelijk in te stellen op mijn Unifi netwerk met KPN glas.
Ik gebruik zelf inderdaad een wildcard dns record voor mijn services, maar aangezien dit niet mijn expertise is heb ik soms lokale ips wel nodig voor troubleshooten (heeft het echt nut om bijvoorbeeld elke smartplug op je domain te hebben? Ik heb besloten van niet, maar dit is natuurlijk persoonlijk). Ik moet zeggen dat ik ook nog geen services gebruik die ipv6 vereisen dus als dit veranderd zal ik inderdaad wel mee moeten, denk ik. Ik gebruik zelf altijd een VPN om bij mijn services te komen dus ik expose alleen wireguard extern (alleen intern https 443 via reverse proxy nodig).

Misschien nadat ik mijn netwerk opnieuw ingericht heb toch eens een testje runnen met ipv6!
Met stembesturing misschien niet, maar ik kan via het scherm van de Nest Hub via het touchscreen diverse apparaten aansturen. Fijn dat dat nu ook kan als het internet eruit ligt.

[Reactie gewijzigd door Sandburger op 9 januari 2025 09:04]

Leuk dat bijvoorbeeld de nest hub matter ondersteund maar zodra ik deze koppel met homekit kan ik er vrijwel niks mee en is het koppelen ook niet zo makkelijk.

Matter is nu een standaard waar vooral apple en google dingen mee doen voor eigen bestwil en het idee van matter dat je het met alles kan gebruiken word nog niet gerealiseerd.

[Reactie gewijzigd door valhellis op 9 januari 2025 13:40]

Leuk dat bijvoorbeeld de nest hub matter ondersteund maar zodra ik deze koppel met homekit kan ik ee vrijwel niks mee en is het koppelen ook niet zo makkelijk.
Het titel van het artikel is toch:
Google voegt lokale aansturing van Matter-apparaten toe aan Google Home
En niet:
Google voegt lokale aansturing van Homekit-apparaten toe aan Google Home

[Reactie gewijzigd door watercoolertje op 9 januari 2025 09:30]

Ik maak de vergelijking omdat homekit al lokale ondersteuning heeft en google voor zichzelf kiest ipv matter gebruikt waar het voor bedoeld is, een makkelijke standaard voor apparaten die met elkaar kunnen communiceren maar google kiest vooral voor communiceren met hun eigen ecosysteem
Homekit heeft lokale ondersteuning met Matter en Google nu dus ook. Waar haal jij dat eigen ecosysteem vandaan?
En welk ecosysteem bedoel je eigenlijk ik ken geen lampen of sensoren van Google?
Google heeft die stap nu genomen, wat betekent dat de Google Home-hubs ook niet meer met de cloud hoeven te communiceren om een Matter-apparaat aan te sturen.

[Reactie gewijzigd door gaskabouter op 9 januari 2025 12:30]

Met ecosysteem bedoel ik homekit of google home.

Een google nest hub met matter ondersteuning kan alleen lampen schakelen in een google home omgeving en is vrijwel nutteloos in een homekit omgeving
Dat laatste valt wel mee, de Philips / signify Hue producten en Ikea producten ondersteunen het ook netjes. Zeker als je dan ook nog Home Assistant erbij draait.
Ik zie de apple producten zoals speakers matter ondersteunen maar ze hebben geen matter cast zodat iedereen met elke merk telefoon er muziek heen kan sturen. Dit geld trouwens ook voor google speakers en nest hubs, alhoewel je hier dan wel naar toen kan casten

Google en apple hebben matter op hun eigen producten voor hun eigen bestwil en hun eigen ecosysteem.

[Reactie gewijzigd door valhellis op 9 januari 2025 09:50]

ik begrijp je punt helemaal niet blijkbaar. Maar Matter cast is een vrij nieuw (net 1 jaar oud) onderdeel van Matter en een informele feature.
Lijkt mij toch logisch dan dat nog niet iedereen het geimplementeerd heeft. Apple en Google nog niet, misschien in de toekomst mogelijk wel.
Amazon wel.

Als het van informele feature naar formele feature gaat zal Apple en Google zeker gewoon meegaan. Overigens kunnen ze zelf nog altijd besluiten om het toe te voegen ook al is het niet formeel.

Wat is nu je punt
Mijn punt is nu dat matter een goede standaard is maar apple en google het nog niet correct ondersteunen en het nu zo lijkt alsof ze alleen de features gekozen hebben die het beste voor hun eigen ecosysteem zijn.

Daarnaast zijn apple en google vrij stil over de nieuwe matter functies zoals matter cast.

Ik zou graag willen zien dat apparaten met matter out of the box werken op elk ecosysteem
het duurt altijd een tijd tot spelers iets nieuws gaan ondersteunen.

daarnaast is matter in de basis helemaal niet bedoeld voor iets als muziek. Die toevoeging zal gerust mooi en nuttig zijn, maar het is niet gezegd dat die in reeds bestaande devices te implementeren is.
Is er ergens een handleiding hoe dit werkt? Ik heb Hue, Ha op Synology en diverse Google devies zoals Nest, Chime, Nest Learning Thermostat etc maar nog nooit naar Matter gekeken.Hoe gaat dat in zijn werk?

[Reactie gewijzigd door wvkreg op 9 januari 2025 10:56]

je zoekt dit?
https://www.home-assistant.io/integrations/matter/

Volgens mij kun je het beste de homeassistant skyconnect dongel aanschaffen en deze aansluiten.
Al betwijfel ik of het handig is om dit op de synology te draaien. Ik heb zelf een losse x86 mini pc met alle antennes draaien.
Als je het artikel goed leest, dan heeft google haar firmware/software aangepast zodat het nu lokaal aangestuurd kan gaan worden en dat zelf zo veel mogelijk ook gaat doen.

In dat proces is de api aangepast en kunnen andere systemen daar nu mee aan de slag. Dus de homekit en andere systemen van buiten het google platform kunnen nu hun software/interface aanpassen zodat ook zij lokaal kunnen werken. Detail hier is dat dit dus buiten de matter standaard om is. Misschien wel omdat hier zaken worden verwerkt die nog niet in de matter standaard zijn gedefinieerd.

De matter standaard is iets wat nog best erg in de kinderschoenen staat. Veel systemen bieden wel al een basis matter ondersteuning maar de details gaan nu pas worden aangemaakt en ingevoerd.
Als fabrikanten nu ook alle features vrijgeven dan, ik heb laatst slimme stekkers gekocht met Matter. Toegevoegd aan Google Home, kan ik ze alleen aan / uit zetten. Voor het stroomverbruik ben ik verplicht hun eigen app te gebruiken |:(
Welke stekkers heb je gekocht? EVE bijv. ondersteunt momenteel enkel Matter 1.2 + hun eigen Custom Custers die wel energiemeting omvatten. Daardoor kan je de energiemeting enkel gebruiken in hun applicatie, maar ook via Home Assistant waar ze die Custom Clusters hebben meegenomen in de integratie. EVE gaat kortelings Matter 1.3 via FW updates implementeren. Volgens mij is EVE niet de enige die Matter 1.2 + Custom Clusters gebruikt. Vandaar dat je de energiefuncties enkel via de "propriety" software kunt gebruiken.

Edit: Het lijkt dus dat het Matter 1.3 is maar het is het niet echt.

[Reactie gewijzigd door Gely op 9 januari 2025 09:50]

Zijn stekkers van Meross, de MSS315
Naar wat ik weet staan enkel de UK versies van de MSS315 momenteel via FW op Matter 1.3. De roll-out voor EU is bezig, het zal wellicht een kwestie van dagen zijn.

Edit: Heb nog even voor jou rondgekeken en vond deze thread op het HA forum m.b.t. Meross MSS315: https://community.home-as...atter-server-v6/738089/61

[Reactie gewijzigd door Gely op 9 januari 2025 10:04]

Dat is in Matter nog vrij nieuw.

Voor de Homey Pro 2023 is bijv. pas in de recente experimentele firmware v12.3.0-rc.7 vermeld: "Matter: Adds support for power measurement."

https://homey.app/en-us/w...-2023-firmware-changelog/

Ik verwacht dat meting van stroomverbruik dus in de komende maanden naar meerdere platforms gaat komen.
dat komt omdat stroomverbruik dacht ik niet in matter zit of lange tijd zat. Het was primair bedoeld als control protocol. (on/off, up/down, etc).

komt ook omdat het protocol bij design en door de gebruikt frequentie heel weinig bandbreedte heeft. Gaat wel dwars door muren enzo heen. (wat precies is wat je wil).
Leuk die nieuwe api's! Betekend dat ook dat mijn Nest Learning Thermostat nu eindelijk weer in Domoticz aangestuurd kan worden?
Wel handig dat het zonder internet kan, maar wanneer word er dan NAT64 ondersteuning toegevoegd aan de Hub? Sommige Matter apparaten zijn enkel lokaal te bedienen met de hub omdat ze via IPv4 communiceren naar het internet. Zoals m’n Nuki 4.
NAT64 helpt daarvoor niet (dat doet het omgekeerde, lokaal IPv4, internet IPv6). Nuki moet hun servers over IPv6 bereikbaar maken.
Kon allang met Zigbee en Zwave (Matter 0.1) lokaal alles via Home Assistant aansturen. Tuya wifi via de LocalTyua integratie.
Matter kan ook al lang lokaal aangestuurd worden via Home Assistant. Dat doet er hier ook niet toe.

Het is Google Home en derivaten van Google die nu ook Matter apparaten lokaal kunnen aansturen zonder via een Google server te passeren. Apple Home(kit) en HomeAssistant deden dat altijd al.

Op dit item kan niet meer gereageerd worden.