Kategorien
Interview

„Den Open-Source-Weg bis zum Ende gehen“

Ein Interview mit Lukas Zeller, Smarthome-Entwickler aus Zürich. Der Einzelunternehmer bietet Gateways für das digitalSTROM-System an und integriert den matter-Standard bereits in seine Produkte. Im Gespräch erklärt er, was er vom Open-Source-Ansatz hält – und wo noch Nachholbedarf besteht.

The interview was conducted in German. Please click here for the English translation.

Sie entwickeln als Einzelunternehmer Produkte für die Gebäudeautomatisierung. Welche Bedeutung hat der matter-Standard für Sie?

Lukas Zeller: Die Bindung an ein System wie digitalSTROM hat die Einsatzmöglichkeiten meines Produkts und das Verkaufspotential limitiert. matter ermöglicht es jetzt, die bereits vorhandene und ausgereifte Funktionalität der Bridge über den digitalSTROM-Kontext hinaus einem erweiterten Kreis von Kund:innen anbieten zu können.

matter ist meines Wissens auch der erste Smarthome-Standard, der Bridges zu Fremdtechnologien direkt integriert. Es gab schon immer Bridges zwischen Systemen, aber in den meisten Fällen bestand ihre Hauptaufgabe darin, zu „verheimlichen“, dass die Steuerung mit einer Fremdtechnologie „spricht“. Das führte dann oft zu subtilen Problemen. In matter hingegen ist das Konzept der Bridge bereits in Version 1.0 ein fester Bestandteil. Bedeutet, dass Bridges in den Ökosystemen auch als solche angezeigt und verwaltet werden können – ein enormer Vorteil gegenüber „unsichtbaren“ Geräten.


matter ist meines Wissens nach der erste Smarthome-Standard, der Bridges zu Fremdtechnologien direkt integriert.


Heißt der Open-Source-Ansatz von matter, dass Kleinunternehmen wie Sie in Zukunft leichter und kostengünstiger Produkte entwickeln können?

Zeller: Was die technische Entwicklung betrifft, bestimmt. Dank des offen auf Github entwickelten Software Developer Kits (SDK), das viele praktische Beispiele enthält, wird der Entwicklungsaufwand für gängige Gerätetypen wie Leuchten, Schaltsteckdosen, Taster etc. sehr überschaubar. Bei komplexeren Produkten wie einer Bridge ist er höher, aber immer noch viel geringer als mit eigenen Entwicklungen oder eingekauften Softwarekomponenten.

Außerdem zeigt der quelloffene Code transparent, wie matter sich weiterentwickelt und welche Änderungen in Arbeit sind. Kleinstunternehmen wie mir hilft das, ihr Produkt up to date zu halten. Ein geschlossener Standard, der plötzlich in einer neuen Version erscheint, kann auf einmal viel Aufwand produzieren. Das ist ein Risiko.

Auf administrativer Ebene und bei der Zertifizierung denkt die CSA leider noch proprietär. Da passt das Vorgehen nicht so recht zur Open Source.

Wie meinen Sie das?

Zeller: Trotz Open Source und SDK geht man offenbar davon aus, dass eine im Detail nicht offengelegte Prüfprozedur und kryptografische Signaturen von einer zentralen Stelle mehr Sicherheit bieten als eine komplett offengelegte Firmware.

Dabei zeigen Projekte wie das offene Router-Betriebssystem OpenWrt durchaus, dass offene Firmware auf kommerzieller Hardware in Sachen Sicherheit und langjähriger Updatefähigkeit bessere Resultate erzielen kann als proprietäre Originalfirmware.

Ich sage nicht, dass Open Source für alles passt, vor allem nicht für jedes Geschäftsmodell. Aber für solch ein fundamentales Infrastruktur-Thema wie Haustechnik müsste meiner Meinung nach auch der Open-Source-Weg zu Ende gedacht werden. Das fehlt derzeit noch im Angebot der CSA.

Versuchsaufbau in Zellers Labor: der matter-Code steuert eine DALI-Lichtleiste. Bild: Plan44

Wie läuft die Entwicklung ab? Benötigt man spezielle Hardware dafür? Manche Chip-Hersteller bieten ja komplette Chip-Plattformen, Google & Co. eigene SDKs dafür an.

Zeller: Grundsätzlich benötigt matter keine besondere Hardware – und auch keinen Funk. Darüber wird wenig berichtet, aber ein wesentliches Merkmal des Standards ist, dass er sich auch gut für eine verdrahtete Infrastruktur eignet. Einzige Voraussetzung: eine Netzwerkverbindung auf Basis von TCP/IP, etwa ein gewöhnlicher Ethernet-LAN-Anschluss.

Die Entwicklung der matter-Komponente für meine plan44-Produkte (link) bestand vor allem darin, sich mit dem großen, komplexen SDK vertraut zu machen, und dann auf dem passenden Beispiel aufbauend die existierenden Funktionen (DALI, EnOcean, SmartLEDs etc.) in matter abzubilden. Dabei sind bereits einige kleine Contributions am matter-SDK entstanden, also Code, den andere Hersteller jetzt mitnutzen können. Meine Hardware musste nur über genügend Speicherplatz verfügen, um den nicht eben kleinen matter-Stack zu verkraften.

Wie viel Speicher verlangt matter?

Zeller: Im Fall der P44-Bridge kann ich das beziffern: Das „Hauptprogramm“ mit allen Funktionalitäten (DALI, EnOcean, Philips Hue, SmartLED etc.) sowie dem digitalSTROM-Interface hat etwa 3 Megabyte. Die matter-Bridge, die neu dazu kommt, ist rund 2,5 MB groß. Das lässt sich auf andere Produkte natürlich nicht 1:1 übertragen. Aber es gibt einen Eindruck davon, was matter platzmäßig bedeuten kann.

Die Plan44-Gateways verbinden digitalSTROM mit anderen Systemen – und neuerdings auch mit dem matter-Standard. Bild: Hersteller

Und was spricht für vorbereitete Chip- oder Software-Lösungen?

Zeller: Komplette Chip-Plattformen sind für Hersteller interessant, deren Kernkompetenz an anderer Stelle liegt als in der Elektronikentwicklung. Da macht der Einkauf von Modulen dann Sinn. Sie integrieren zum Beispiel alles, was ein batteriebetriebenes, mit Thread-Funk ausgestattetes Gerät so benötigt – inklusive der für matter passenden Speicher-Ausstattung.

Obendrein stellen die Module sicher, dass Funktechnologien vorschriftsmäßig umgesetzt sind. Sie werden die notwendigen Prüfungen im Bereich Abstrahlung, Störfestigkeit etc., die es etwa für CE-Konformität braucht, ohne Überraschungen bestehen.

Was die SDKs der großen Ökosystem-Anbieter wie Google & Co betrifft: Denen geht es darum, ihre Kunden zu binden. Deshalb bieten sie SDKs an, die über den matter-Standard hinaus Funktionalität enthalten – bei Google etwa KI-gestützte Personalisierung. App-Entwickler können das nutzen, sind dann aber ihrerseits an das jeweilige Ökosystem gebunden. Für Anbieter von matter-Gerätschaften wie mich spielt das jedoch keine Rolle – im Gegenteil, dank matter müssen sie sich eben nicht mehr um die Eigenheiten der Ökosysteme kümmern. Jedenfalls nicht primär – um Praxis-Tests mit allen großen Plattformen und Detailpflege kommt natürlich niemand herum …


„Den großen Ökosystem-Anbietern geht es darum, ihre Kunden zu binden.“


Ihre Bridge richtet sich nach den Spezifikationen des Standards, ist aber noch nicht von der CSA zertifiziert. Funktioniert sie trotzdem?

Zeller: Ja, sehr gut sogar. Das Experimentierfeld ist aber noch eingeschränkt, denn außer Apple mit iOS 16.1 und SmartThings – offenbar mit Einschränkungen für Bridges – gibt es aktuell noch keine Ökosysteme, die matter produktiv freigeschaltet haben.

Apple handhabt unzertifizierte matter-Produkte gleich wie bisher schon nicht-zertifizierte HomeKit-Geräte: Bei der Inbetriebnahme erscheint ein Dialog, der auf die fehlende Zertifizierung hinweist, hier muss man explizit bejahen. Ansonsten scheint es keinerlei Einschränkungen zu geben.

Die Entscheidung, das so zu handhaben, liegt allerdings bei der jeweiligen Firma. SmartThings scheint es gleich zu machen wie Apple, prinzipiell könnten Google und Amazon sich anders entscheiden – aber das halte ich für eher unwahrscheinlich.

Bestimmte Leistungen der CSA stehen einem unzertifizierten Produkt nicht zu Verfügung. Welche sind das? Und was würde das für eventuelle Käufer bedeuten?

Zeller: Ein nicht zertifiziertes Produkt darf sich nicht „matter compliant“ nennen oder das matter-Logo in irgendeiner Form im Marketing, auf dem Gerät selbst oder auf der Packung verwenden.

Es fehlt außerdem im DCL, dem „Distributed Compliance Ledger“. In dieser verschlüsselten Datenbank sind zertifizierte Geräte mittels digitaler Signaturen identifizierbar und auch Metadaten wie Produktbeschreibungen oder sichere Links für Firmwareupdates enthalten.

Bedeutet das, ein unseriöses Produkt mit Sicherheitslücken kann die ganze matter-Installation kompromittieren?

Zeller: Ja. Auch die Zertifizierung mit allen Tests kann nicht ausschließen, dass in einer signierten Firmware – absichtlich oder unabsichtlich – sicherheitsrelevante Fehler stecken, die sich ausnutzen lassen.


„Auch die Zertifizierung kann nicht ausschließen, dass sicherheitsrelevante Fehler in der Firmware stecken.“


Der DCL-Mechanismus senkt aber die Wahrscheinlichkeit, dass bösartige Akteure von außen eine modifizierte Firmware in ein weit verbreitetes Produkt einschleusen, ohne dass es auffällt. Das ist ein realer Schutz für Massenprodukte, die ein viel lohnenderes Ziel für Angreifer darstellen als Nischenprodukte. Und es hilft bei online gekaufter Ware, deren Hersteller vielleicht schwer zu kontaktieren ist. Wer ein Nischenprodukt kauft, informiert aber meist ohnehin, macht Recherchen und zieht Empfehlungen anderer User zurate.

In einem Punkt hoffe ich allerdings, dass die CSA noch nachlegt: Im Moment gibt es – anders als bei anderen Standards wie Bluetooth – keinen kostenlosen oder günstigen Mitgliedschafts-Level, um die technisch erforderliche Vendor-ID zugeteilt zu bekommen. Das heißt, unzertifizierte Produkte müssen bislang eine der vorhandenen „Test“-IDs verwenden und können sich nicht eindeutig identifizieren. Das ist auch aus Sicht der CSA eher kontraproduktiv, denke ich.

Was bedeutet das genau? Welchen Vorteil hätte diese Hersteller-Kennung?

Zeller: Sie würde den reibungslosen Übergang bei einer nachträglichen Zertifizierung erleichtern. Wenn die Vendor-ID erst mit der offiziellen Zertifizierung kommt, dann zerbrechen ziemlich sicher alle Verbindungen, die vorher mit einer Test-ID angelegt wurden. Für Nutzerinnen und Nutzer, die dem Hersteller schon vorher vertraut haben, ein Nachteil.

Es wäre ein Zeichen der CSA, dass man den langsamen Weg hin zu einer Zertifizierung, den kleine Firmen und Open-Source-Projekte beschreiten müssen, ernst nimmt, wenn sie die Vendor-ID niederschwelliger vergeben würde.

Lohnt sich eine Zertifizierung für Einzelunternehmer wie Sie überhaupt, etwa von den Kosten her?

Zeller: Das würde ich auch gerne genauer wissen. Als Nichtmitglied habe ich nur die öffentlich zugänglichen Informationen. Demnach kommen zum jährlichen Mitgliedsbeitrag von 7000 US-Dollar noch Einmalkosten in Höhe von 3000 Dollar für jedes zertifizierte Produkt.

Wie eine Bridge, die verschiedene Hardware-Produkte und Funktionalitäten einbindet, hier gezählt wird, weiß ich nicht. Ebenso wenig, wie Software-Updates gehandhabt werden, die ja jedes Mal signiert werden müssen, um als zertifiziert zu gelten.

Eine seriöse Abklärung und Abschätzung der Kosten ist leider erst nach Vorab-Investition von 7000 Doller in eine CSA-Mitgliedschaft möglich. Als Einzelunternehmer würde ich mir hier mehr Transparenz wünschen.


Als Einzelunternehmer würde ich mir mehr Transparenz wünschen.“


Ganz klar ist für mich jedoch, was matter so einzigartig und fortschrittlich macht: ein durch und durch als Open Source ausgeführtes SDK, mit dem ich selbst aus einer ganz kleinen Nische heraus sinnvolle Beiträge zur Weiterentwicklung des Standards leisten kann.

Herr Zeller, vielen Dank für dieses Interview.


Diesen Beitrag teilen: