4 ms·
A co-worker and I were just talking about Matter yesterday. Underneath the hood this runs on a networking protocol called "Thread"[1], which itself uses IEEE 80
by mox1 4y ago
A co-worker and I were just talking about Matter yesterday. Underneath the hood this runs on a networking protocol called "Thread"[1], which itself uses IEEE 802.15.4. This is pretty similar to ZigBee. Thread runs on 2.4ghz.
Thread uses ipv6 and UDP (TCP optional), so it should integrate well with existing network infrastructure.
1. https://en.wikipedia.org/wiki/Thread_(network_protocol) https://en.wikipedia.org/wiki/Thread_(network_protocol)
- deleted 4y ago[deleted]
- quadrifoliate 4y ago> Underneath the hood this runs on a networking protocol called "Thread" This is correct, but potentially leaves out a level of abstraction [1]. Matter is designed to abstract away multiple networking protocols, including Thread and Wi-Fi. Philips Hue, for example, plans to support Matter but not Thread [2]. ---------------------------------------- [1] A bit like saying "HTTP runs on TCP". It usually does, but it's not necessary to the standard. [2] https://matter-smarthome.de/en/interview-en/we-dont-have-plans-to-build-thread-light-bulbs/ https://matter-smarthome.de/en/interview-en/we-dont-have-pla...
- RetpolineDrama 4y agoWhat's hue's deal with not supporting thread? Seems far superior to their current setup.
- ktta 4y agoYou can always read what the GP linked. It details why
- vineyardmike 4y ago> The Hue Bridge is not just a Wi-Fi to Zigbee translator. It has never been. It’s also the local intelligence of the system. It coordinates that your switches work well with the lights, it is what makes sure that the network is well managed. Entertainment streams, cloud services, automations, schedules … all that and more is managed by the bridge. Such a small, reliable “edge computer“ in the home is essential. matter does not offer a solution for it. Building all the functionalities directly into lamps would make things much more complicated, and we don’t want to move them to the cloud. That is, even if we used Thread, we would still need a bridge. Second: Mesh networking with Zigbee in an efficient and reliable way is really hard. We have been working on getting that to work well for a decade. And Thread at scale in the complexity of users homes is not yet proven. I’m a bit afraid of how open Thread will be. There will be many, many companies with many different implementations in the same network. So, I see a lot of risk, and we don’t have plans to build Thread light bulbs. I don’t say never, but we have very much a “wait and see“ approach towards it. Last not least: We have a very happy and large installed base. A key benefit of Philips Hue is future-proof and always up to date. Many people have made large investments in a Hue system as part of their home infrastructure, not as a gadget. And they expect that these products remain relevant for at least ten years. So far, we have never asked consumers to buy new lights.
- chrismorgan 4y agoAnd HTTP/3 doesn’t run on TCP.
- tveita 4y agoI was curious how Thread compares with ZigBee in power usage. One white paper I found suggests that Thread uses slightly less power. E.g., for a device on a CR2032 battery sending a packet every minute, with ZigBee they estimate the battery lasting 1.38 years vs 1.49 years with Thread. https://infocenter.nordicsemi.com/pdf/nwp_039.pdf https://infocenter.nordicsemi.com/pdf/nwp_039.pdf But another white paper at https://www.ti.com/lit/an/swra595/swra595.pdf https://www.ti.com/lit/an/swra595/swra595.pdf has them the other way around, by about the same amount. Either way I guess it's close.
- pantalaimon 4y agoI’m always a bit confused what does thread add on top of 6LoWPAN?
- oflannabhra 4y agoA lot. Mesh routing, security, onboarding, and more. 6LoWPAN pretty much only describes how to compress IPv6 headers into 802.15.5 packet sizes
- pantalaimon 4y agoIs Mesh routing RPL or something else?
- oflannabhra 4y agoIt is not RPL. Thread defines it’s own routing algorithm, specifically to solve two key problems: a single point-of-failure from a single border router, and to allow for ephemeral, sleepy devices. It is similar to RIPng.