Von IoT-Technologien und Smart Spaces wird nicht weniger als die nächste technologische Revolution erwartet. Doch obwohl bereits Milliarden IoT-Geräte existieren, erweist sich die unzureichende Vereinheitlichung dieser Geräte als Hemmschuh für die gesamte Branche. Welchen Herausforderungen müssen IoT-Geräte gerecht werden, welche Lösungen sind sinnvoll und wie können Techniker eingreifen?
Der ärgste Feind des IoT: Fragmentierung
Es ist wirklich erstaunlich, wie viele IoT-Geräte weltweit bereits existieren – nach aktuellen Schätzungen mehr als 14 Milliarden. Bis zum Jahr 2024 werden es vermutlich 20 Milliarden sein. Und dabei ist nicht nur die schiere Anzahl an Geräten weltweit kaum begreiflich. Dies gilt noch viel mehr für die immense Datenmenge, die von diesen Geräten produziert wird. Bereiche wie KI und Maschinelles Lernen haben von den Weiterentwicklungen der IoT-Technologien und den von IoT-Geräten generierten Datenmengen stark profitiert. Sie konnten den Fortschritt beschleunigen und massiv erweitern, sodass die KI heute bereits im Alltagsleben gebräuchlich ist.
Aber trotzdem sind, ungeachtet der Vielzahl an IoT-Geräten am Markt und der vielfältigen Angebote im Segment Smart Home, die meisten in Privathäusern eingesetzten IoT-Geräte weit davon entfernt, intelligent zu sein. Tatsächlich werden die meisten IoT-Geräte im privaten Umfeld nur deshalb dem IoT zugerechnet, weil sie Internetverbindungen herstellen können. Sie sind aber alles andere als intelligent, weil sie ihre Daten nicht mit anderen Systemen teilen und nicht sinnvoll in Echtzeit auf Ereignisse reagieren können. Zudem integrieren die allermeisten Wohnhäuser intelligente Technologien nicht bereits standardmäßig, sind also dumm.
Obwohl es viele Faktoren gibt, die eine Integration von IoT-Geräten im privaten Umfeld erschweren, stellt die Fragmentierung mit Abstand das größte Hindernis dar.
Was bedeutet IoT-Fragmentierung?
In der IoT-Branche geht ein Scherz um, der die durch Fragmentierung verursachten Probleme perfekt beschreibt. Er läuft darauf hinaus, dass ein Techniker die Existenz von 14 IoT-Standards feststellt und daraufhin entscheidet, einen von allen zu benutzenden Standard zu entwickeln, sodass es nun 15 Standards gibt.
Unglücklicherweise kommt dieser Scherz der Realität sehr nah. Hunderte (wenn nicht Tausende) IoT-Unternehmen und -Techniker, die mit der Entwicklung und Fertigung von IoT-Geräten befasst sind, tun genau dies. Viele dieser Unternehmen schaffen nicht nur eigene Standards (getrieben von der Vorstellung, dass sie die Besten seien), sondern entwickeln zudem ganze Ökosysteme mit Lösungen, die in ihrem spezifischen Umfeld funktionieren. Dies kann gut für alle Kunden funktionieren, die ausschließlich auf die IoT-Lösungen eines Herstellers setzen. Zugleich schafft dieses Vorgehen aber vielfältige Herausforderungen, die eine Integration von Smart Spaces behindern.
Die erste daraus resultierende Herausforderung besteht in der Problematik, komplexe IoT-Lösungen zu schaffen, in denen Geräte verschiedener Hersteller kombiniert werden. Für ein Smart Home sind beispielsweise viele intelligente Geräte erforderlich, beginnend mit einer intelligenten Türglocke über intelligente Steckdosen bis hin zu intelligenten Leuchten und Heizthermostaten. Obwohl all diese Geräte am Markt angeboten werden, ist es durchaus problematisch, einen einzelnen Hersteller ausfindig zu machen, der Geräte aller benötigten Kategorien anbietet. Und verschiedene Hersteller zu finden, die ein gemeinsames Protokoll unterstützen, ist nahezu unmöglich.
Die zweite aus der IoT-Fragmentierung resultierende Herausforderung ist die unzureichende Software-Unterstützung für Smart Homes. Denn die verschiedenen Hersteller schaffen nicht nur eigene Standards, sondern entwickeln oft auch eigene Softwareplattformen zum Steuern der Geräte und Auslesen der Daten, veröffentlichen aber nur in Ausnahmefällen eine API, die von anderen Herstellern genutzt werden kann. Deshalb sind IoT-Geräte auch auf der Softwareseite oftmals fragmentiert und gegenüber anderen Entwicklern abgeschottet.
Das zwingt Kunden, IoT-Lösungen mit den Komponenten eines einzelnen Herstellers umzusetzen. In der Folge sind sie an diesen Hersteller gebunden und müssen im schlimmsten Fall alle für die betreffende Marke getroffenen Entscheidungen mitmachen. Hive hat beispielsweise kürzlich angekündigt, die Palette der HomeShield-Produkte mit Sicherheitskameras und Leckfühlern nicht fortzusetzen. Sobald die Updates und Services für diese Geräte gestoppt werden, müssen die Kunden eigentlich einsatzfähige IoT-Geräte ausbauen und entsorgen.
Was ist Matter?
Im Bewusstsein der vielfältigen Herausforderungen im Bereich der IoT-Geräte ist eine Gruppe großer Technologieunternehmen zu dem Schluss gekommen, dass es so nicht weitergehen kann. Das Ergebnis war die Entwicklung eines neuen IoT-Protokolls namens Matter. Natürlich folgt auch die Veröffentlichung von Matter dem oben zitierten Scherz, nach dem immer neue Standards entwickelt werden. Weil aber viele führende Technologieunternehmen (Google, Meta usw.) die Plattform unterstützen, werden viele Hersteller aufgrund der schieren Größe der beteiligten Technologieunternehmen gezwungen sein, diesen Standard zu berücksichtigen.
Im Kern ist Matter ein proprietärer Standard für die Home-Automatisierung, der von Herstellern genutzt werden kann, ohne dass Lizenzkosten anfallen. Nur die Zertifizierung muss bezahlt werden. Abgesehen von den Kosten für die Zertifizierung ist Matter eine Open-Source-Lösung. Benutzer können also die Arbeitsweise des Codes nachvollziehen und Bearbeitungsvorschläge machen sowie Bugs korrigieren. Noch ist nicht geklärt, welche „Strafen“ für die Verwendung von Matter ohne Zertifizierung verhängt werden. Wahrscheinlich dürfen die betreffenden Produkte einfach den Namen Matter und das zugehörige Logo nicht tragen (die Produkte dürfen also nicht mit der Kompatibilität mit Matter beworben werden).
Die ersten Matter-Projekte wurden 2019 aufgelegt. Seitdem haben zahlreiche Hersteller und Unternehmen wie IKEA, Amazon, Google, Apple und Zigbee Alliance ihre Unterstützung des Protokolls angekündigt. Da das Protokoll aber erst im Oktober 2022 offiziell veröffentlicht wurde, muss es sich noch zum neuen Mainstream entwickeln und von weiteren Anbietern übernommen werden. Die aktuelle Version von Matter unterstützt typische Haushaltsgeräte wie Beleuchtungsprodukte, Hauptschalter, Thermostate, Türschlösser, Heizungssysteme, Belüftung, Sicherheitssensoren, Fernsehgeräte und Jalousien. Mit der nächsten Version, die für März 2024 angekündigt ist, werden weitere Gerätekategorien unterstützt: Saugroboter, Kohlenmonoxidsensoren, Rauchmelder, Energiemanagement, WLAN, Kameras sowie weitere wichtige Gerätekategorien.
Gibt es Alternativen zu Matter?
Derzeit gibt es keine anderen IoT-Standards, die eine mit Matter vergleichbare Unterstützung aufweisen. Das bedeutet aber nicht, das es nicht andere Standards gäbe, die Techniker nutzen können, um eine gute Gerätevernetzung herzustellen.
Die mit großem Vorsprung populärsten Methoden für die IoT-Kommunikation sind REST und HTTP. Der Grund besteht darin, dass die meisten Webserver diese Standards von Haus aus unterstützen. IoT-Geräte können also Datenpakete an Standardwebserver senden, die in PHP oder Node.js codiert sind. Ein weiterer Vorteil dieser Protokolle besteht darin, dass die Anzeige der IoT-Daten sehr einfach ist, weil sie in den Datenbanken gespeichert werden, die den Websites zugrunde liegen. Theoretisch kann also eine vollständige IoT-Lösung in einem einzelnen Webserver umgesetzt werden.
Eine Alternative zu HTTP und REST ist die Verwendung von Websockets. PHP, HTML und JavaScript unterstützen Websockets und sind deshalb für IoT-Geräte hervorragend geeignet. Während aber HTTP und REST aus Einzelpaketen bestehende Meldungen verwenden und die Verbindung nach Übertragung eines Pakets schließen, können die Websockets geöffnet bleiben und deshalb sehr gut für das Streamen großer Datenmengen genutzt werden.
Schließlich gibt es noch MQTT, ein weiteres populäres Protokoll, das weltweit in Millionen Geräten zum Einsatz kommt. MQTT wurde ursprünglich für die Öl- und Gasindustrie entwickelt und ermöglicht ganzen Gerätenetzwerken, in bestimmte Variablen zu veröffentlichen bzw. diese zu abonnieren. Aufgrund der schlanken Struktur ist MQTT ideal für einfache Mikrocontroller mit geringem Energiebedarf geeignet. Zudem erleichtert der einfache Aufbau des Protokolls die Entwicklung spezifischer Implementierungen von MQTT. Online sind zahlreiche Beispiele verfügbar, die übernommen und angepasst werden können.
Wie sollten Techniker vorgehen?
Sowohl für HTTP als auch für MQTT können Entwickler eine API veröffentlichen, um anderen Herstellern die Möglichkeit zu eröffnen, mit den Geräten zu interagieren. Denkbar ist auch das Schreiben einer Bridging-Software, die zwei unterschiedliche Standards verbinden kann und so die Zusammenarbeit von Produkten mit den Produkten anderer Hersteller ermöglicht.
Weitere Empfehlungen für Techniker sind schwerlich möglich, weil Matter noch sehr jung, die zugehörige Dokumentation sehr detailliert und komplex und das Protokoll möglicherweise nicht für alle IoT-Produkte die beste Lösung ist. Offensichtlich ist aber das Schaffen neuer Standards nicht hilfreich. Deshalb sollten Techniker soweit wie möglich davon absehen.
Eine mögliche Lösung für Techniker besteht darin, sich auf Open-Source-Designs zu konzentrieren, die im Einsatz problemlos geändert werden können. Mit Linux-Systemen entwickelte IoT-Geräte, die Updates per Funk unterstützen, können beispielsweise theoretisch in der Zukunft mit der Unterstützung für Matter nachgerüstet werden, sobald das Protokoll sich weiter durchgesetzt hat.
Eine andere Lösung besteht für Techniker darin, weiter mit durchgesetzten Lösungen wie HTTP und REST zu arbeiten und darauf zu setzen, dass die Veröffentlichung ihrer APIs in gewissem Umfang für die Unterstützung ihrer Produkte durch Matter sorgen wird. So kann möglicherweise eine Webschnittstelle entwickelt werden, die zwischen dem IoT-Gerät und einem Matter-Server platziert wird und die ausgetauschten Meldungen übersetzt.
Aber die bloße Existenz von Matter bedeutet nicht, dass es auch genutzt werden sollte. Sofern Matter nicht wirklich für eine Entwicklung benötigt wird, kann dessen Integration zum alleinigen Zweck, Matter-Unterstützung anzubieten, mehr Schaden verursachen als Nutzen bringen. Dies gilt umso mehr, wenn sich unbekannte Bugs in Matter verbergen.
