Ein Interview mit Stefan Bauer-Schwan, Vizepräsident Forschung und Entwicklung beim Smarthome-Hersteller Eve Systems (link). Es geht um das Funkprotokoll Thread. Warum der hersteller-übergreifende Einsatz im Matter-Standard noch nicht perfekt ist – und was die Ökosysteme von Amazon, Apple, Google & Co. damit zu tun haben.
The interview was conducted in German.
Please click here for the English translation.
Die Erwartungen an den Thread-Standard sind klar. Er soll ein gemeinsames, herstellerübergreifendes Funknetz schaffen, in das sich Geräte zu Hause einklinken können, ähnlich wie ins WLAN. Aktuell spannen Border Router von Amazon, Apple, Google & Co aber häufig eigene Thread-Netzwerke auf, die im schlimmsten Fall miteinander konkurrieren. Warum?
Stefan Bauer-Schwan: Das ist nicht der gewünschte Zustand. Im Gegenteil: Die Problematik ist lange bekannt und wurde im Thread-Standard bereits gelöst, ehe der Matter-Standard herauskam. Die Ursache liegt nicht im Thread-Protokoll, sondern in den Plattformen, die damit arbeiten. Amazon, Apple, Google & Co. müssen sich einigen, wie sie untereinander Thread-Credentials austauschen, also die Zugangsdaten zum Netzwerk. Damit neue Geräte einer existierenden Thread-Installation beitreten können.
Technisch erlaubt der Standard sehr wohl, ein großes gemeinsames Netz zu formen, in dem sich Border Router herstellerübergreifend ergänzen und einander aushelfen, etwa wenn einer davon vom Netz geht. Es ist sogar physikalisch möglich, mehrere Thread-Netzwerke im Haus zu haben, die dann logisch zu einem Netzwerk zusammengefasst werden. Das kann hilfreich sein, wenn es viele Stockwerke gibt. Auf denen stehen dann eigene Border Router, die aber gemeinsam ein logisches Netzwerk bilden.
Warum nutzen die Hersteller nicht alle diese Möglichkeiten?
Bauer-Schwan: Weil wir es mit zwei verschiedenen Sicherheitsmechanismen zu tun haben. Da sind zum einen die Netzwerk-Eigenschaften von Thread. Ähnlich wie im WLAN gibt es einen Netzwerknamen und ein Passwort, damit die Kommunikation sicher ist. Dazu kommen noch weitere Informationen wie PAN ID und XPAN ID, die das Thread-Netzwerk beschreiben. In Matter geht es darum, diese Credentials sicher zwischen den Plattformen auszutauschen. Dafür gibt es bislang aber keinen standardisierten Weg.
„Für den Austausch der Credentials zwischen den Plattformen gibt es bislang keinen standardisierten Weg.“
Manchmal scheint es aber trotzdem zu funktionieren. Dann landen neu hinzugefügte Geräte in einem gemeinsamen Netzwerk …
Bauer-Schwan: Das stimmt. Nutzt eine Installation Border Router von Apple, Google und SmartThings, die mit einem Betriebssystem eingerichtet werden, auf dem alle drei Plattformen sichtbar sind – sprich iOS – dann nehmen alle dieselben Thread-Credentials. Ganz einfach, weil Apple diese Daten in seinem Schlüsselbund speichert und sie den anderen Systemen zugänglich macht.
Bei Android fehlt diese übergreifende Lösung?
Bauer-Schwan: Auch bei Android gibt es eine entsprechende Lösung, diese kann jedoch natürlich nicht auf Zugangsparameter zugreifen, die exklusiv auf einem Apple-Gerät verfügbar sind. Bekanntlich kann man einen HomePod nur über iOS administrieren, weshalb sich der beschriebene Fall nicht auf Android übertragen lässt.
Es sind aber Bestrebungen im Gange, diese Situation zu verbessern. Die Betreiber der Plattformen halten sich diesbezüglich zwar bedeckt. Aber aus vielen persönlichen Gesprächen weiß ich, dass keiner von ihnen ein Interesse daran hat, die aktuelle Situation noch lange so bestehen zu lassen.
Und was machen Nutzer, die ihre Geräte bereits unter Android in Betrieb genommen haben? Zurücksetzen und neu einrichten?
Bauer-Schwan: Es gibt theoretisch die Möglichkeit, die Zuweisung zu einem Thread-Netzwerk nachträglich zu ändern. Im Matter-Standard ist das sogar vorgeschrieben und Teil der Zertifizierung. Ich kann einem Produkt wie Eve Energy – und allen anderen Matter-Geräten – jederzeit sagen: Hier ist ein anderes Netzwerk, nimm ab sofort dieses.
Aktuelle Apps machen keinen Gebrauch davon, weshalb wir überlegen, diese Funktionalität in unsere Eve-App einzubauen. Allerdings müsste das so gelöst sein, dass technische Details wie PAN ID & Co. gar nicht in Erscheinung treten. Die Herausforderung besteht weniger in der technischen Umsetzung als in der selbsterklärenden Benutzerführung. Im Idealfall würde die App alle Endgeräte in ihren Netzwerken automatisch erkennen und auf Wunsch zum Transfer anbieten. Nur Border Router wie den Nest Hub müsste ich dann noch auf Werkseinstellungen zurücksetzen und neu einrichten.
„Die Zuweisung zu einem Thread-Netzwerk lässt sich nachträglich ändern. Aktuelle Apps machen keinen Gebrauch davon.“
Das klingt nach Entwicklungsaufwand. Aktuell werden die Informationen in der Eve-App ja eher weniger. So zeigt die Übersicht des Thread-Netzwerks fremde Matter-Geräte nicht mit ihrem Namen an.
Bauer-Schwan: Das ist den Privacy-Richtlinien des Matter-Standards geschuldet. In HomeKit hat man die Möglichkeit, über das unverschlüsselte Bonjour-Protokoll von Apple herauszubekommen, wie der Name lautet. Mit Matter geht das nicht mehr, weil Matter-Geräte im Netzwerk keine Klarnamen haben. Aus gutem Grund, denn so kann niemand herausfinden, um welche Art von Produkt es sich handelt. Türschloss, Steckdose, Smarthome-Hub oder Fensterkontakt, für potenzielle Angreifer ist das nicht erkennbar – eine zusätzliche Sicherheitsbarriere, die mögliche Angriffsziele verschleiert
Heißt das, die bewährte Netzwerk-Übersicht aus HomeKit-Zeiten wird es mit Matter in der Eve-App nicht mehr geben?
Bauer-Schwan: Wir haben andere Möglichkeiten, ein Matter-Gerät zu identifizieren, denn die eindeutige Node ID eines Geräts wird vom Netzwerk ja übertragen. Dass es bislang nicht passiert, liegt vor allem daran, dass wir nicht alles auf einmal machen können. Im letzten halben Jahr war so viel zu tun, dass es vom Arbeitsaufwand her nicht zu schaffen war. Aber wir gehen das Schritt für Schritt an, um eine bestmögliche User Experience zu bekommen.
Macht es einen Unterschied, an welchem Border Router ich mein Thread-Produkt betreibe? Manche Hersteller sagen, dass die Batterielaufzeit von Sensoren je nach Router-Modell variieren kann.
Bauer-Schwan: Wenn das so ist, hat der Hersteller einen schlechten Job gemacht. Es stimmt, dass die Plattformen in unterschiedlichen Zeitabständen einen Statusbericht von Sensoren anfordern. Ein Controller von Apple etwa fragt alle sieben Sekunden nach, ob das Endgerät noch da ist, Google alle zwei Minuten, bei SmartThings beträgt das Intervall drei Minuten. Es bleibt aber dem Sensor überlassen, ob er dieser Aufforderung nachkommt. Er kann sich im Ruhezustand auch nur alle fünf Minuten melden. Das spart Energie.
Anders verhält es sich, wenn ich mehrere Plattformen habe, die abwechselnd Bescheid wissen wollen, noch dazu mit mehreren Apps. Wenn fünf Programme den Status so eines Sensors abonniert haben, kostet ihn das mehr Energie als bei einer App. In diesem Zusammenhang möchte ich mal eine Lanze für Apple brechen. Die haben mit ihrer neuen HomeKit-Architektur in iOS 16.3 genau das Richtige getan. Seither ist der Sensor nur noch mit einer Instanz im Apple-Ökosystem verbunden – dem aktiven Hub. Alle Apps erhalten ihre Statusinformationen von diesem einen HomePod oder Apple TV. Und weil der Hub am Strom hängt, ist es völlig egal, wie viele Programme im Laufe eines Tages mit ihm kommunizieren wollen.
„Wenn die Batterielaufzeit von der Plattform abhängt, hat der Hersteller einen schlechten Job gemacht.“
Hätte man diesen Punkt nicht auch standardisieren können?
Bauer-Schwan: Der Einsatz solcher Sleepy End Devices, also von Geräten, die bei Bedarf kurz aufwachen und ansonsten schlafen, ist in den aktuellen Spezifikationen von Matter 1.0 und 1.1 tatsächlich noch nicht optimal umgesetzt. Das muss und wird mit kommenden Versionen deutlich besser werden, man denke an Geräte wie Rauchmelder oder Funktaster mit einer Knopfzelle.
Lässt sich da eine zeitliche Prognose geben?
Meine persönliche Meinung ist, dass wir sowohl bei Batteriegeräten mit sehr langer Laufzeit als auch dem Austausch von Thread-Credentials zwischen Matter-Plattformen bereits im Laufe des kommenden Jahres Fortschritte sehen werden.
Was dann noch bleibt, ist das Thema Betrieb mit mehreren Plattformen. Weil diese ebenfalls zulasten der Batterielaufzeit gehen und Ressourcen im Gerät beanspruchen. Aber auch hier sind seit längerer Zeit Bestrebungen im Gang, die Situation zu verbessern. In jedem Fall sind die Kritikpunkte, über die wir heute gesprochen haben, sind zeitlich begrenzt. Sie werden gelöst, und zwar im Interesse der Kunden.
Herr Bauer-Schwan, vielen Dank für dieses Gespräch.
„Die Kritikpunkte, über die wir heute gesprochen haben, sind zeitlich begrenzt. Sie werden gelöst, und zwar im Interesse der Kunden.“
Diesen Beitrag teilen:
