Bij Zigbee doet de Hub meer dan alleen routeren. Dat zorgt er voor dat bij Zigbee de hub ook moet weten met wat voor apparaat het praat en hoe je daar mee moet praten, met Thread hoeft de router die niets van te snappen als ik mij niet vergis.
Dit is precies het belangrijke verschil. Zigbee heeft een vertaalslag nodig om van internetverkeer (het pakketje dat jij naar de Zigbee-hub stuurt om jouw lamp aan te zetten) een bericht te maken dat de apparaten binnen het Zigbee-netwerk begrijpen. Alles wat je binnen je netwerk wilt doen, voert de hub voor jou uit. De hub ontvangt het (internet)bericht dat je de lamp wilt inschakelen, die interpreteert het bericht, en stelt een Zigbee-bericht op met de instructie aan de lamp om in te schakelen, waarna dat bericht via het Mesh-netwerk van Zigbee naar het apparaat wordt verstuurd.
Wat dus fijn zou zijn is om een manier te vinden waarmee die hele vertaalslag er tussenuit gehaald kan worden. Die maakt namelijk dat je afhankelijk bent van een stukje hardware die wel moet kunnen communiceren met de apparaten die je thuis hebt. Als het Zigbee-thuisstation dat jij hebt van fabrikant A toevallig geen ondersteuning heeft voor het apparaatje van fabrikant B, tough luck; je zult dan ook een thuisstation van fabrikant B moeten aanschaffen om het apparaat te kunnen gebruiken. Oplossingen als de Homey hebben een brede ondersteuning voor allerhande apparaten en het is daardoor geen probleem waar je vaak tegenaan loopt, maar het is wel mogelijk.
Dan nu, welkom: Thread.
Thread werkt inderdaad op het IP-protocol, maar dat spreekt bij de meesten wat weinig tot de verbeelding wat dat eigenlijk uitmaakt. Wat ik een betere omschrijving vind is dat ieder apparaat dat op Thread werkt, net als een computer in je netwerk, een IP-adres heeft die je direct kunt aanspreken via je (lokale) netwerk. Nou is het wel zo dat er nog steeds een apparaatje nodig is (de zogeheten Edge router) om communicatie tussen je draadloze/bekabelde netwerk thuis en het Thread-netwerk mogelijk te maken, maar die apparaatjes doen niets met de inhoud van het bericht zelf. Anders dan Zigbee interpreteren ze het bericht niet en vertalen ze het niet naar een bericht dat specifiek is voor het type apparaat van Fabrikant A, maar het bericht wordt slechts een beetje anders verpakt en doorgestuurd op het Thread-netwerk
*1.
Dit lijkt een klein verschil, maar het verschil is wezenlijk. Zolang je een edge-router hebt, ongeacht fabrikant, is er communicatie mogelijk tussen een apparaat in je LAN en in je Thread-netwerk. Het maakt het enorm veel eenvoudiger voor ontwikkeling, want je kan nu gewoon met je lichtschakelaar communiceren alsof het een printer of een andere computer binnen je netwerk is. Je kunt je lampen en lichtschakelaars
*2 gewoon pingen via cmd/terminal! Ze hebben immers een eigen IP-adres! Bovendien hoeft de Edge-router dus niets te begrijpen over de berichten die je naar de apparaten op het netwerk stuurt. Het begrijpen van het apparaat en het weten welk soort bericht er moet worden gestuurd om een Thread-lamp aan of uit te schakelen, zit nu puur in de software van de app/applicatie die je gebruikt om die lamp mee aan te sturen.
Het maakt van wat een firmware-probleem is bij Zigbee, namelijk het correct interpreteren en vertalen van een bepaald commando voor een Zigbee-apparaat, een software-probleem, waarin de app/applicatie zelf ervoor moet zorgen dat een correct bericht via het lokale netwerk wordt gestuurd naar het IP-adres van de lamp om deze aan te sturen. Je bent dus als ontwikkelaar/fabrikant van een slim apparaat niet langer overgeleverd aan de ondersteuning van jouw apparaat in de firmware van bijvoorbeeld een Homey waarbij je afhankelijk bent van een derde partij, of zelf een eigen hub moet aanbieden; die tussenlaag is compleet weg. Je hebt alleen nog maar de hardware die je als fabrikant maakt, en de software in de vorm van een app of een API.
Daarom ben ik enorm blij met de komst van Thread en dat het steeds meer tractie begint te krijgen. Hoe succesvol Zigbee ook is, hoe goed het eigenlijk werkt en hoe weinig problemen er zijn met Vendor Lock-ins met Zigbee-apparaten, het probleem is dat het KAN. Thread maakt Vendor Lock-ins in die zin vrijwel onmogelijk, en maakt de ontwikkeling van nieuwe apparaten een enorm stuk eenvoudiger voor mij als ontwikkelaar.
1. De reden dat het pakketje moet worden aangepast is omdat internetberichten op een 802.11 netwerk minstens 1280 bytes lang moeten kunnen zijn, terwijl de berichten die over een Thread-netwerk lopen (802.15.4, andere standaard) maximaal 127 bytes lang mogen zijn. Bovendien werkt het op een variant van IPv6, maar complete headers van IPv6 nemen al een behoorlijke slok (40 bytes) van die maximaal 127 bytes op. De Edge-router comprimeert de IPv6-header naar een 6LoWPaN-header om de overhead die IPv6 anders zou verzorgen te reduceren, en verstuurd het bericht gefragmenteerd (in stukjes) als het te lang is om in één Thread-bericht te kunnen versturen.
2. Lichtschakelaars zijn eigenlijk wel weer een uitzondering, want vaak zijn dat apparaatjes op een batterij en om energie te besparen, staan deze eigenlijk altijd uit, tenzij deze wordt bediend. In zo'n geval houdt de eerste permanent ingeschakelde node waarmee de lichtschakelaar is verbonden het bericht vast totdat de lichtschakelaar van zich laat horen, waarna het kortstondig de tijd heeft om het opgeslagen bericht door te sturen aan de lichtschakelaar. Maar pingen van de lichtschakelaar zal waarschijnlijk voor een time-out zorgen, al zou ik dat eens moeten testen.
[Reactie gewijzigd door naarden 4ever op 10 juli 2025 15:45]