Matter 1.6 für Gerätehersteller: Was es bringt und wo Apple, Google & Amazon bremsen
Am 17. Juni 2026 hat die Connectivity Standards Alliance Matter 1.6 veröffentlicht. Stell dir vor, eines eurer Geräte ist seit Monaten Matter-zertifiziert und landet in der Home-App eurer Kund:innen trotzdem als leere Fläche ohne Bedienelemente. Dieser Artikel zeigt euch, was Matter 1.6 wirklich bringt, wo die großen Ökosysteme noch bremsen, und was das für eure Produkt-Roadmap heißt.
Das Wichtigste in Kürze
Die Connectivity Standards Alliance hat den Smart-Home-Standard Matter am 17. Juni 2026 in Version 1.6 veröffentlicht – der Fokus liegt auf einfacherer Geräte-Einrichtung und geräteübergreifender Verwaltung, nicht auf neuen Gerätekategorien.
Was der Matter-Standard beschreibt und was die großen Ökosysteme (Apple Home, Google Home, Amazon Alexa, Samsung SmartThings, Home Assistant) tatsächlich umsetzen, klafft je nach Ökosystem zwischen wenigen Wochen und über zwei Jahren auseinander.
Für Hersteller heißt das konkret: Ein für Matter zertifiziertes Gerät kann trotzdem in der Home-App der Kund:innen nicht bedienbar sein, weil das jeweilige Ökosystem den Gerätetyp noch nicht unterstützt – mit direktem Risiko für Support-Anfragen.
Der Artikel zeigt anhand eigener Messungen mit einem selbst gebauten Matter-Simulationstool, einer Test-App und einem Prototyp-Board, was bei zwei nicht unterstützten Gerätetypen (Geschirrspüler, Fenster-„Closure") in Apple Home und Google Home tatsächlich passiert.
Für die eigene Matter-Roadmap gibt es zwei Werkzeuge: Geräte-Funktionen in der Firmware aus mehreren bereits unterstützten Matter-Bausteinen zusammensetzen (schnell nutzbar, aber mit Rückbau-Aufwand, sobald der passende Gerätetyp unterstützt wird) – oder eine eigene App bauen (mehr Aufwand jetzt, dafür dauerhaft ohne Rückbau).
Am Ende des Artikels: vier konkrete Fragen für das nächste Matter-Roadmap-Meeting im Produktteam.
Dieser Artikel ist für dich, wenn...
Dieser Artikel richtet sich an Produktteams, die entscheiden müssen, wie viel Matter in ihr nächstes Gerät gehört. Die Pain dabei: Matter-Support in der Spezifikation zu haben, garantiert nicht, dass Apple Home, Google Home oder Alexa die Funktion auch tatsächlich anzeigen — mit dem Risiko, dass eure Kund:innen ein Gerät kaufen, das in ihrer Home-App nicht bedienbar ist, und ihr die Support-Tickets dafür bekommt.
Vor einer Weile haben wir in einem separaten Artikel erklärt, was Matter verspricht. Heute schauen wir uns an, was davon in den Ökosystemen angekommen ist und warum die Antwort darauf jede Produkt-Roadmap betrifft, in der das Wort „Matter" vorkommt. Vorweg, damit du weißt, worauf das hinausläuft: Die Lücke zwischen dem, was Matter kann, und dem, was Apple Home, Google Home & Co. davon zeigen, ist kein technisches Problem. Sie ist eine Entscheidung von Apple, Google und Amazon. Und du kannst damit arbeiten, sobald du sie als solche erkennst.
Kontaktiere uns gerne mit deinen Fragen und Anliegen rund um Matter.
Matter 1.6: Die wichtigsten Neuerungen im Überblick
Matter wächst schnell. Seit dem ersten Release 2022 kamen neun Versionen dazu, und der Funktionsumfang hat sich vervielfacht. Mehrere davon beschreiben neue Gerätearten — im Standard heißen sie Device Types, eine Art Bauplan pro Gerätekategorie. Drei Meilensteine des Standards reichen, um die Bewegung zu zeigen.
Oktober 2023, Matter 1.2: Der Standard bekommt Großgeräte. Geschirrspüler, Waschmaschinen, Kühlschränke, Robotersauger, Luftreiniger. Ab hier ist Matter mehr als Licht und Steckdose.
November 2025, Matter 1.5: Für uns das inhaltlich größte Release bisher. Kameras und Türklingeln kommen dazu, Bodensensoren, Bewässerung, Strompreise und CO₂-Signale aus dem Netz. Und, für alle in der Gebäudetechnik das eigentliche Highlight: Closures.
Der Name klingt unspektakulär, die Sache dahinter ist es nicht. Vor 1.5 kannte der Standard für alles, was sich öffnet und schließt, genau zwei Modelle: Türschloss und Rollladen. Wer etwas anderes baute, musste sich für eines davon verkleiden. Ein Markisenantrieb wurde zum Rollladen; ein smarter Fenstergriff meldet sich bis heute als Türschloss an. Closures ändern das grundlegend: Ein Gerät setzt sich jetzt aus Bausteinen zusammen, kennt schiebende, drehende und öffnende Bewegungen, unterstützt Ein- und Zweiflügel-Konfigurationen und meldet seine Position sauber zurück. Rollläden, Markisen, Vorhänge, Tore und Garagentore — alles im Standard beschrieben.
Juni 2026, Matter 1.6: Diesmal keine neuen Gerätekategorien, sondern Tiefe. NFC-Commissioning richtet ein Leuchtmittel ein, bevor du es in die Fassung drehst. Joint Fabric lässt mehrere Ökosysteme ein gemeinsames Netz verwalten, statt dass jedes sein eigenes aufbaut. Ein Fabric ist in Matter der Vertrauensraum eines Ökosystems: eigene Zertifikate, eigene Geräteliste. Bisher baut jedes Ökosystem seinen eigenen auf, und du koppelst jedes Gerät für jedes Ökosystem einzeln nach. Und die Suggestions drehen bei Thermostaten die Richtung um: Das Ökosystem schickt keinen Befehl mehr, sondern einen zeitlich begrenzten Vorschlag. Das Thermostat entscheidet selbst, ob es mitmacht.
Auf dem Papier ist Matter damit erwachsen geworden.
Matter-Ökosysteme im Vergleich: Was Apple Home, Google Home & Co. unterstützen
Ein Ökosystem kann nur das anzeigen, was es implementiert hat. Und die fünf großen sind unterschiedlich weit. Der Stand im August 2026:
Home Assistant liegt stabil auf 1.5.1, 1.6 läuft in der Backend-Beta. Abstand zur aktuellen Spezifikation: Wochen.
Samsung SmartThings setzt 1.5 mit 58 Gerätetypen um. Abstand: rund eine Version.
Amazon Alexa baut auf dem 1.5-SDK auf, unterstützt davon aber nur eine Teilmenge der Gerätetypen. Nah an der Spezifikation, arm an Typen.
Google Home hat das SDK auf 1.4.1, die Gerätetyp-Dokumentation reicht bis 1.3. Abstand: anderthalb bis zwei Jahre.
Apple Home pickt selektiv aus 1.4 und unterstützt keinen einzigen Gerätetyp aus 1.5. Hier ist der Abstand am größten.
Stand: August 2026. Prüfe die Ökosysteme, die für dich relevant sind, vor jeder Roadmap-Entscheidung neu.
Übersetzt in die beiden Beispiele von oben:
Der Geschirrspüler steht seit Oktober 2023 in der Spezifikation. Bis Google Home ihn für Hersteller freischaltete, vergingen 23 Monate. In Apple Home darfst du ihn hinzufügen. Steuern kannst du ihn nicht. Nach knapp drei Jahren ist das kein Rückstand mehr, das ist ein Zustand.
Closures gibt es seit November 2025. Unterstützt werden sie von SmartThings und Home Assistant. Bei Apple, Google und Alexa: nicht in der Liste. Amazons Dokumentation stellt dabei eine Falle — dort steht zwar „closure devices“, gemeint sind aber die alten Typen Türschloss und Rollladen, nicht der Device Type aus 1.5. Was in diesen drei Ökosystemen stattdessen passiert, dazu komme ich gleich. Dein zertifiziertes Matter-Fenster kann seine Position melden, seine Flügel einzeln ansteuern und sauber kalibrieren — und landet in der Home-App deiner Kund:innen trotzdem als Rollladen mit halbem Funktionsumfang. Oder gar nicht.
Matter-Praxistest: Ein Closure-Gerät in Apple Home und Google Home
Das wollte ich nicht aus Dokumentationen ableiten, also habe ich es gemessen. Für unsere eigene Arbeit haben wir ein Matter-Simulationstool gebaut, mit dem wir beliebige Geräte emulieren können. Dazu kommen eine Test-App und ein Prototyp auf einem Nordic-Entwicklungsboard. Damit habe ich zwei virtuelle Geräte erzeugt — einen Geschirrspüler und ein Closure Panel — und sie an Google Home und Apple Home gekoppelt.
Geschirrspüler in Google Home vs. Apple Home
Der Geschirrspüler in Google Home funktioniert. Erwartungsgemäß, seit dem Rollout im September 2025.
Der Geschirrspüler in Apple Home lässt sich hinzufügen. Danach steht er da. Controls gibt es keine — die Detailansicht ist eine leere Fläche mit einem Namen darüber. Ein Gerät, das erfolgreich gekoppelt ist und nichts kann.
Closure Panel in Google Home vs. Apple Home
Das Closure Panel in Google Home wird als Rollladen einsortiert — das passende Icon setzt Google automatisch. Gesteuert habe ich damit trotzdem nichts, und Googles eigene Dokumentation erklärt, warum: Im Datenmodell der Home APIs gibt es den Cluster WindowCovering, aber weder ClosureControl noch ClosureDimension — genau die beiden, über die ein Closure bewegt wird. Es existiert kein Befehl, den Google an so ein Gerät schicken könnte.
Das Closure Panel in Apple Home erscheint mit dem Hinweis „Not Supported". Daneben steht ein orangenes Haus . Ein ähnliches Icon hat der Geschirrspüler. Mit dem tatsächlichen Gerät hat das bei beiden nichts zu tun. (siehe Screenshot weiter unten)
Die letzte Zeile im Screenshot ist die klarste von allen vier, und das ist der Punkt, der mich am meisten beschäftigt hat. „Nicht unterstützt“ ist unangenehm, aber eindeutig: Du weißt sofort, woran du bist. Ein Gerät, das aussieht, als würde es funktionieren, und dann auf keinen Tastendruck reagiert, erzeugt Support-Tickets. Und die landen nicht bei Apple oder Google, sondern bei dir.
Warum hinken Apple Home und Google Home bei Matter hinterher?
Die naheliegende Erklärung: Matter-Support ist aufwendig, und die großen Plattformen brauchen eben ihre Zeit.
Home Assistant widerlegt das gründlich. Das Projekt ist seit dem Umstieg auf matter.js so nah an der Spezifikation, dass 1.6 keine vier Wochen nach der Veröffentlichung in der Backend-Beta lief. Ein Open-Source-Projekt zieht den Spec-Support in Wochen nach, während zwei der größten Technologiekonzerne der Welt seit anderthalb Jahren auf demselben Stand stehen. Am Aufwand für das Protokoll liegt es also nicht.
Der Flaschenhals sitzt woanders: bei der Oberfläche. Das Protokoll selbst zu unterstützen ist der einfache Teil. Aber jede Gerätekategorie braucht eine eigene UI — Bedienelemente, Symbole, Sprachbefehle, Automatisierungslogik, Übersetzungen in dreißig Sprachen. Diese Arbeit leisten Apple und Google dann, wenn eine Kategorie zu ihrer Produktstrategie passt. Bei Kameras zum Beispiel steht dem eigene Hardware im Weg: HomeKit Secure Video hier, Nest dort. Mit der Implementierung des Standards würden sie sich unweigerlich Konkurrenz in eigene Ökosystem holen.
Wie weit das geht, zeigt Googles eigene Gerätetyp-Liste. Neben dem standardisierten Window Covering, das unter der Kennung 0000 für den Namensraum der Allianz läuft, stehen dort zwei weitere Einträge: GoogleGarageDevice und GoogleGateDevice. Ihre Kennung lautet 6006 — das ist Googles eigene Matter Vendor ID. Garagentore und Tore hat Google also als herstellerspezifische Typen nachgebaut, statt auf den standardisierten Closure-Typ zu warten. Nicht nur Gerätehersteller weichen auf Eigenes aus, wenn der Standard ihnen nicht schnell genug folgt. Die Ökosysteme tun es selbst.
Dazu kommt ein zweiter Effekt, der auch dann bleibt, wenn dein Gerätetyp irgendwann unterstützt wird: Matter beschreibt Standard-Cluster. Alles, was dein Produkt besonders macht, liegt außerhalb davon. Die Spezifikation erlaubt zwar herstellerspezifische Cluster, aber kein großes Ökosystem stellt sie generisch in der Oberfläche dar. Sie kommen an und werden ignoriert.
Den deutlichsten Beleg dafür liefert wieder Home Assistant: Wo es eine native Integration mit lokaler API gibt, weist das Projekt selbst darauf hin, dass Matter nicht die beste Wahl sein muss. Der Grund: Matter beschneidet den Funktionsumfang.
Video-Podcast
Licht: Mehr als nur Beleuchtung?
Software entscheidet heute darüber, was eine Leuchte kann, nicht mehr nur die Hardware. Trilux hat das früh erkannt und entwickelt seit über 10 Jahren eigene Steuerungssysteme, Sensorik und Funkstandards. Die größte Herausforderung dabei war nicht die Technik, sondern die Organisation: Wie bringt man Leuchtenbauer und Softwareentwickler wirklich zusammen?
Matter für Hersteller: Was die Ökosystem-Lücke für dein Produkt bedeutet
Zwei Reflexe liegen nah. Beide führen in die Sackgasse.
Reflex #1: auf die Ökosysteme warten.
Der Geschirrspüler zeigt, wie lange das dauern kann, und deine Produkteinführung richtet sich nach deinem Markt, nicht nach Apples Release-Zyklus.
Reflex #2: Matter deshalb weglassen.
Der Standard löst das Onboarding, die lokale Steuerung und die Basisbedienung in jeder Home-App. Das ist echter Wert, und deine Kund:innen erwarten ihn inzwischen. Die Antwort besteht aus einer Grundlage und zwei Werkzeugen, zwischen denen du bewusst wählen musst. Die Grundlage: Matter für alles, was heute schon geht. Fenster auf, Fenster zu, in jedem Ökosystem, ohne Cloud, ohne Konto. Das funktioniert ab Tag eins, auf jeder Plattform.
Werkzeug #1: funktionale Komposition in der Firmware.
Statt auf einen Device Type zu warten, den noch niemand implementiert hat, setzt du dein Gerät aus mehreren Geräte-Repräsentationen in Matter zusammen, die heute schon überall unterstützt werden. Ein zweiflügeliges Fenster wird zu zwei Window Coverings mit eigener Positionssteuerung. Eine Lüftungsfunktion wird zum eigenen Gerät. Das passiert vollständig in der Embedded-Software auf dem Gerät. Kein zusätzliches App-Projekt, kein neues Backend.
Der Gewinn ist groß: Deine Funktion bleibt dort bedienbar, wo deine Kund:innen sowieso sind, und sie taucht in ihren Automatisierungen auf, allerdings als drei einzelne Geräte.
Der Preis steckt im Lebenszyklus, und er wird gern übersehen. Denk den Tag mit, an dem das Ökosystem den richtigen Device Type endlich unterstützt. Dann hast du zwei Wege, und beide kosten etwas. Entweder du lässt die komponierten Accessories dauerhaft neben dem standardkonformen Gerät stehen — dann leben deine Kund:innen für immer mit Dubletten in der Geräteliste. Oder du entfernst sie per Firmware-Update und ersetzt sie durch die standardkonforme Lösung — dann verschwinden über Nacht Geräte aus den Home-Apps deiner Kund:innen, und ihre Automatisierungen laufen ins Leere.
Das ist ab diesem Punkt keine Firmware-Aufgabe mehr, sondern eine Support- und Kommunikationsaufgabe. Ein Release Note reicht dafür nicht.
Komposition lohnt sich deshalb vor allem dann, wenn die Funktion zum Kern deines Produkts gehört und du realistisch nicht absehen kannst, wann ein Ökosystem nachzieht. Ist die Funktion dagegen ein Nebenschauplatz, oder steht die Unterstützung erkennbar bevor, zahlst du für den Umbau mehr, als der Zwischenschritt dir bringt.
Werkzeug #2: deine eigene App.
Was sich nicht sinnvoll komponieren lässt, gehört dorthin: Kalibrierung, Wartungsintervalle, Firmware-Updates, Diagnose, die Auswertung, für die deine Kund:innen dich eigentlich bezahlen. Der Vorteil gegenüber der Komposition ist, dass du nichts zurückbauen musst. Die App bleibt richtig, egal was die Ökosysteme in zwei Jahren tun.
Der wichtige Teil daran ist die Haltung: Diese App ist keine Notlösung, bis Apple nachzieht. Sie ist eine Architekturentscheidung. Sie gehört von Anfang an in die Planung, mit eigenem Budget und eigenem Designprozess. Wer sie als Übergangslösung baut, baut sie zweimal.
Vier Fragen für deine Matter-Roadmap im Produktmanagement
Spezifikation und Home-App geben zwei verschiedene Antworten. Prüf beide, Ökosystem für Ökosystem.
Du zertifizierst einmal bei der CSA. Ob deine Funktion in Apple Home, Google Home oder Alexa dann bedienbar ist, entscheidet jedes Ökosystem selbst. Daran hängt, wo du testest und was du auf die Verpackung schreibst.
Alles, was dein Produkt besonders macht, liegt außerhalb der Standard-Cluster. Diese Grenze zieht dein Produktteam, nicht deine Firmware.
Jeder Zwischenschritt, den du heute baust, hat ein Ablaufdatum. Plan den Weg zurück auf den Standard mit ein, solange er noch billig ist — sonst zahlt ihn später dein Support.
Wie slashwhy Hersteller bei der Matter-Integration unterstützt
Genau an dieser Schnittstelle arbeiten wir jeden Tag. Unsere Crews für Gebäudetechnik und Consumer Electronics bringen Embedded-Entwicklung, App-Entwicklung und UX in einem Team zusammen. Das ist auch nötig. Denn „Was gehört in Matter, was in die eigene App?“ ist zu gleichen Teilen eine Protokoll-, eine Produkt- und eine Designfrage — und wer nur eine der drei beantwortet, baut am Ende zweimal.
Wir bauen die Firmware auf dem Gerät, die App daneben und die Cloud dahinter. Bei der Entwicklung der Firmware gehören die Chips von Espressif, Nordic und Silicon Labs zu unserem Tagesgeschäft. Apps entwickeln wir nativ und cross-platform. Matter und Thread verfolgen wir aktiv seit der ersten Version. Und statt zu schätzen, was die Ökosysteme daraus machen, haben wir uns ein Simulationstool gebaut und nachgemessen.
Wenn du gerade überlegst, wie viel Matter in dein nächstes Gerät gehört: Komm auf uns zu. In einem Workshop schauen wir gemeinsam auf deinen Gerätetyp, deine Zielökosysteme und deinen Zeitplan. Dann sortieren wir, was der Standard für dich übernimmt und wo du selbst baust.
Und wenn du diesen Text in einem Jahr liest, hat sich ein Teil der Übersicht oben erledigt. Die Frage war nie, ob die Ökosysteme nachziehen. Die Frage ist, ob dein Produktzyklus so lange warten kann.
Klingt spannend?
Ihr wollt wissen, ob euer nächstes Gerät in den Home-Apps eurer Kund:innen wirklich bedienbar ist und was das für eure Matter-Roadmap heißt?
Sprecht uns gern an – wir freuen uns darauf, gemeinsam mit euch Klarheit für euer nächstes Produkt zu schaffen!
