Thread: Eine Technologie, die man weder nutzen noch lehren kann?
(overengineer.dev)Eine ausführliche Erklärung zu Thread und seinen Problemen
- Ein Beitrag von Dennis Schubert aus dem Jahr 2022 über die Verwaltung einer übermäßig aufwendig konstruierten Lösung zur Lagerung und Bestandsverwaltung von Kaffeebohnen inspirierte viele Menschen
- Kürzlich baute Dennis Version 2 seines früheren Projekts, um die Batterielaufzeit zu verlängern, und begann dabei, sich mit stromsparender Elektronik zu beschäftigen
- Profiling zeigte, dass WiFi der Hauptgrund für den Batterieverbrauch war, weshalb er nach Alternativen wie LoRa oder Zigbee suchte
- Ein Netzwerk-Stack namens Thread wirkte wie eine attraktive Option, da er dieselbe physische Schicht wie Zigbee nutzt, aber auf IPv6 basiert und sich über eine Bridge mit bestehenden Heimnetzwerken verbinden lässt
- Viele Geräte wie Apple HomePod und Nest Hub fungieren bereits als Thread Border Router, sodass sich Thread leicht einsetzen lässt
- Er plante, selbst ein Thread-basiertes Projekt umzusetzen und darüber einen Blogpost zu schreiben
Das Problem der Geschlossenheit der Thread Group
- Thread verwendet offene Standardtechnologien wie IEEE 802.15.4, IPv6 und CoAP, doch die Spezifikation selbst bleibt nicht öffentlich zugänglich
- Die Spezifikationsdokumente sind mit DRM versehen und mit Wasserzeichen markiert
- Wer die Thread-Technologie implementieren und in Produkten einsetzen will, muss der Thread Group beitreten
- Die günstigste Mitgliedschaft der Stufe Implementer kostet 7.500 US-Dollar pro Jahr
- Es gibt mit OpenThread zwar eine Open-Source-Implementierung, doch selbst für die Markteinführung von Produkten auf dieser Basis ist eine Mitgliedschaft erforderlich
- Dass für kommerzielle Produkte eine Zertifizierung verlangt wird, ist nachvollziehbar, doch auch nichtkommerzielle Nutzung zu verhindern, ist schwer verständlich
- Besonders problematisch ist, dass Elektronikstudierende und angehende Entwickler dadurch kaum die Möglichkeit bekommen, mit der Technik in Berührung zu kommen, bevor sie in die Branche einsteigen
- Die von Großunternehmen wie Apple und Google dominierte Thread Group scheint vor allem auf Marktbeherrschung fokussiert zu sein
Meinung von GN⁺
-
Netzwerktechnologien wie Thread, die faktisch als proprietäre Monopoltechnologien betrieben werden, dürften ein Hindernis für ein lebendiges Entwicklerökosystem sein. Gerade freie Experimente und frühe Versuche von Entwicklern zu blockieren, kann die technologische Weiterentwicklung langfristig bremsen.
-
Für einen lebendigen IoT-Markt gewinnt die Bedeutung offener Netzwerkprotokolle weiter an Gewicht. Statt von Großunternehmen dominierter Konsortien könnten community-getriebene Open-Source-Projekte eine Alternative sein.
-
Open-Source-Projekte mit ähnlichem Technologie-Stack sind etwa Zigbee2mqtt oder Z-Stack. Zwar haben sie im Home-IoT-Markt bislang nicht die gleiche Verbreitung wie Thread, könnten aus Entwicklerperspektive aber die bessere Wahl sein.
-
Angesichts des enormen Einflusses der Großunternehmen, die Thread vorantreiben, ist kurzfristig wohl kaum mit Verbesserungen zu rechnen. Dennoch braucht es eine Entwickler-Community, die ihre Stimme erhebt und nach Alternativen sucht. Jetzt ist die Zeit für kluge Wege, Unternehmensinteressen und die Freiheit von Entwicklern in Einklang zu bringen.
1 Kommentare
Hacker-News-Kommentar
Ist das wirklich so? Die juristische Formulierung der Lizenz scheint sich auf Patente zu beziehen, und wenn keine kommerzielle Beteiligung vorliegt, gelten Patente nicht für private Arbeiten.
Wenn man über den Hobbybereich hinaus allgemeiner darauf blickt, wird in dieser Struktur die Absurdität des Monopols deutlich, das das heutige Patentsystem gewährt. Große Unternehmen mit Patentportfolios können OpenThread frei nutzen, kleine und mittlere Unternehmen sowie Startups hingegen nicht.
Ich höre zum ersten Mal von Thread und wünschte, ich hätte nie davon erfahren. Es macht mich traurig, weil ich jetzt noch einen Grund mehr habe, wütend zu sein.
Solche Dinge sollte man möglichst meiden und darauf hoffen, dass sie verschwinden. Ich würde niemandem raten, das zu akzeptieren oder einzuführen.
Besser Zigbee verwenden. 3.x ist offen und gut definiert. Auch Dongle-Bridges für HomeAssistant sind günstig.
Die Matter-Spezifikation hat ein ähnliches Problem. Der Teufel steckt im Detail, und wegen cleverem Marketing verstehen die Leute nicht, was genau sie da loben.
Das eigentliche Problem sind die Leute, die in so etwas Geld investieren.
Ich möchte nicht einmal schon den Namen Thread verwenden. Es klingt nach Meetings über Monate oder Jahre hinweg, in denen unklar bleibt, ob von OS-Scheduler-Threads oder vom Framework-Namen die Rede ist. (Stell dir vor, Menschen, deren Muttersprache nicht Englisch ist, reden aneinander vorbei, weil sie thread und threads nicht unterscheiden können.) Erlöst mich einfach.
Wenn man der Lizenz für die Thread-Spezifikation nicht zustimmt und OpenThread direkt verwendet, gelten diese Lizenzbedingungen dann trotzdem? Wenn man nur der BSD-Lizenz zugestimmt hat, dürfte man doch wohl kaum verklagt werden, lol
„Wenn jemand als Hobbyentwickler nicht das Geld hat, der Thread Group beizutreten, gibt es keine legale Möglichkeit, Thread zu nutzen“
Das lässt sich nicht wissen, bis jemand herausfindet, ob es relevante Patente gibt.
Wahrscheinlich müsste Compaq das im Clean Room nachbauen und dann abwarten, ob man getroffen wird, falls es gültige Patente gibt ...
Müssen wir also warten, bis Regulierungsbehörden eingreifen und es zwangsweise öffnen, sobald es de facto zum Standard für Heimkommunikation geworden ist?
Ich möchte nicht darauf wetten, welche Behörde es sein wird, aber wir wissen alle, welche das sein dürfte.
Ich kenne mich mit Lizenzen auf diesem Niveau nicht gut aus. Wie verhält sich die Lizenzierung von Thread im Vergleich zu etwas wie Bluetooth, wo man zahlen muss, um es in ein Produkt zu integrieren?
Ich habe diese Woche zufällig mit Thread herumgespielt, und es war leichter als erwartet, ein Beispielprojekt auf ein ESP32 zu flashen und dann vom Laptop aus Pings zu schicken.