4 ms·

I don't understand the problem that thread solves that zigbee doesn't! The article says that thread doesn't require a hub but it require a border gateway that i

I don't understand the problem that thread solves that zigbee doesn't! The article says that thread doesn't require a hub but it require a border gateway that is almost indistinguishable from a hub. And as far as my home assistant setup is concerned, it doesn't require a hub, only a zigbee radio. The only thing that seems to advantage thread is manufacturers support, but I don't see what's stopped them to regroup around zigbee. Any one has clues on why Thread was needed when zigbee already existed?

AndrewDucker 1y ago
My understanding is that Thread is lower latency and lower power than Zigbee.
- nick__m 1y ago
  How is that possible when thread use an ipv6 stack over 802.15.4 while zigbee use a simpler stack also over 802.15.4 ? The only thing I see is that manufacturers prefer an ip stack because it's "easier" to develop for.
  - AndrewDucker 1y ago
    An excellent question - all I can do is point you at the research. See the top graph here: https://www.reddit.com/r/homeautomation/comments/nxmehn/clearing_up_confusion_thread_is_much_faster_than/ https://www.reddit.com/r/homeautomation/comments/nxmehn/clea...
    - nick__m 1y ago
      I should have been more precise, I don't doubt the claim about latency nor speed, but I really doubt that running an ipv6 stack requires less power than running the simpler zigbee stack. Also one Thread advantage from that discussion made me laugh: safe as the internet, using proven IP technologies But thanks you for answering me!
      - dgacmu 1y ago
        I haven't measured it, but: in a lot of embedded situations, the radio transmission time is the single biggest consumer of power. Thread+matter being more efficient on number of packets transmitted per command (the reason latency is lower) could actually translate to battery savings.
    - 0x000xca0xfe 1y ago
      But does it translate to real world gains? I've developed a Matter (wifi) device and the stack is ridiculously chatty.
    - AceJohnny2 1y ago
      (offtopic) from the link > as redundant and safe as the internet Ahaha! Haaahahaha! i'm choking (Joking aside, I get that their point is they leverage the decades of work into IPv6 rather than recreate their own ad hoc, informally-specified, bug-ridden, slow implementation of half of the IP stack, but man did that phrasing get me)
  - RandomThoughts3 1y ago
    > The only thing I see is that manufacturers prefer an ip stack because it's "easier" to develop for. It is easier to develop on an ip stack. You have great tooling and great libraries out of the box because pretty much everything uses ip nowadays. Plus, at least part of the controllers people use for their smart home will use ip anyway. A non ip network will need a bridge. > How is that possible when thread use an ipv6 stack over 802.15.4 while zigbee use a simpler stack also over 802.15.4? Easy, zigbee doesn't use a simpler stack. Using the same physical layer protocol doesn't tell you anything about the rest of the stack. It's actually pretty simple. 6LoWPAN which is what Thread uses is more efficient than the Zigbee network protocol. Packets are smaller and the routing is better. It's not particularly surprising to be honest because Thread was designed by people who knew Zigbee really well and were aiming for an improvement.
alsko 1y ago
Matter was created by the Connectivity Standards Alliance (CSA), formerly known as the Zigbee Alliance! Basically, Matter is the next generation Zigbee. Thread as a protocol predates Matter, and it is just one of the supported transports, together with Wifi and Ethernet (for now). Edit: One thing Matter adds that was not in Zigbee is Bluetooth provisioning, letting you use your phone to add a device to your network without QR codes or numbers to type in. Also fun fact; Homeassistant is part of the CSA and apparently, Google, Apple and others use HA for testing!
- bevr1337 1y ago
  > Edit: One thing Matter adds that was not in Zigbee is Bluetooth provisioning, letting you use your phone to add a device to your network without QR codes or numbers to type in. What follows are my two pennies as a developer working in home automation for 7 years. In this venue, readers may even have more knowledge regarding security, but I hope to speak to a common case. I develop this exact feature though not for Ikea. Having made the sausage, some of these UX-first flows are worrisome. Consider a lightbulb that factory resets given a rapid succession of power cycles. Most consumers won't have redundant power during a brownout, so there is an edge case where dirty power can mistakenly send the bulb to a reset state. (More plausibly, a child tugging at a light switch?) Now, any device in radio range has an opportunity to take over the bulb. Provisioning is rare. Unless the owner enjoys tinkering, a residential IoT device is provisioned a handful of times in its life. I personally think it's a waste of time to optimize this flow if the improvements are also vulnerabilities. Suppose I have a great new smart bulb. I'm ready for a larger market so I prepare a demonstration for Lowe's, hopeful for space in their lighting and rough electric aisles. Lowe's has seen this before. My bulb works fine but my users aren't technical. Lowe's replies, "we can't carry this. Users must deploy and control from a single app in 5 minutes." If I want my smart device to compete, my hand may even be forced to implement UX-first provisioning. Companies like Lowe's and IKEA don't want to be in the tech support business. My bulb is a liability because their customers will call with complaints or questions. I find QR codes to be a slick implementation. They don't even need electricity! Users can manage the system even when components go offline. Folks are trained on social security numbers and PINs for bank cards. It's easy to comprehend the QR code as a password.
amluto 1y ago
As I understand it, Thread can transparently extend its mesh over regular IPv6 (Ethernet, Wi-Fi, etc), whereas extending a Zigbee (or Z-Wave) mesh beyond useful mesh range is a mess. I have a Z-Wave network that uses two controllers, and it sucks. It’s utterly obnoxious to maintain, the whole concept of multiple controllers is barely supported by zwave-js-ui, it is far to dumb to recover quickly on its own if it transiently loses connectivity to a node, and roaming between controllers is a complete non-starter. I haven’t tried Thread yet, but I’m delighted by the concept of having a couple of easy-to-maintain base stations (routers or whatever they’re called) connected to the local network and having devices automatically roam between them. I am not delighted by the fact that an Apple Home Thread network, a Google Home thread network, and a Home Assistant native thread network appear to be different things that are not entirely compatible with each other.
- izacus 1y ago
  > I am not delighted by the fact that an Apple Home Thread network, a Google Home thread network, and a Home Assistant native thread network appear to be different things that are not entirely compatible with each other. Hmm, in what way? The Matter standard does demand that devices support at least 5 of such "fabrics" at once. Where is the issue in practice?
  - amluto 1y ago
    Maybe there isn’t one. Can I “pair” a Thread device with, say, an Apple TV and have it talk to the Apple TV via radio to an IKEA Dirigera hub and then IPv6 over Ethernet from the Dirigera to the Apple TV?
- mox1 1y ago
  Yes this is indeed a problem. You can get around this by piping the Z-Wave or Zigbee information into a MQTT server and basically run them as separate networks, with Home Assistant and MQTT tying it all together. But you will need some type of Zigbee to Ethernet adapter (Sonoff makes one, Raspberry Pi, etc.) or Z-wave to ethernet adapter (again Raspberry Pi). It's definitely clunky. But doable. I am running multiple Zigbee networks near each other (in a house and in a detached garage) with Home Assistant, MQTT server and a Sonoff Zigbee bridge, with Tasmota.
ianburrell 1y ago
Thread can talk to your phone using a gateway. Thread is IPv6 based. The gateway, called border router, is no different than access point in function. Current systems require a hub, talk protocol to hub, hub talks Zigbee to device. Home Assistant is great, but you still need device running it. Thread requires border router, but that is simpler device and only does networking. Matter is the other part of Zigbee, the home automation profile. I get the impression it is bloated with multiple companies involved, but it is standard. Matter means that your phone can talk to Wifi device with your choice of apps.

AndrewDucker 1y ago

My understanding is that Thread is lower latency and lower power than Zigbee.

nick__m 1y ago
How is that possible when thread use an ipv6 stack over 802.15.4 while zigbee use a simpler stack also over 802.15.4 ? The only thing I see is that manufacturers prefer an ip stack because it's "easier" to develop for.
- AndrewDucker 1y ago
  An excellent question - all I can do is point you at the research. See the top graph here: https://www.reddit.com/r/homeautomation/comments/nxmehn/clearing_up_confusion_thread_is_much_faster_than/ https://www.reddit.com/r/homeautomation/comments/nxmehn/clea...
  - nick__m 1y ago
    I should have been more precise, I don't doubt the claim about latency nor speed, but I really doubt that running an ipv6 stack requires less power than running the simpler zigbee stack. Also one Thread advantage from that discussion made me laugh: safe as the internet, using proven IP technologies But thanks you for answering me!
    - dgacmu 1y ago
      I haven't measured it, but: in a lot of embedded situations, the radio transmission time is the single biggest consumer of power. Thread+matter being more efficient on number of packets transmitted per command (the reason latency is lower) could actually translate to battery savings.
  - 0x000xca0xfe 1y ago
    But does it translate to real world gains? I've developed a Matter (wifi) device and the stack is ridiculously chatty.
  - AceJohnny2 1y ago
    (offtopic) from the link > as redundant and safe as the internet Ahaha! Haaahahaha! i'm choking (Joking aside, I get that their point is they leverage the decades of work into IPv6 rather than recreate their own ad hoc, informally-specified, bug-ridden, slow implementation of half of the IP stack, but man did that phrasing get me)
- RandomThoughts3 1y ago
  > The only thing I see is that manufacturers prefer an ip stack because it's "easier" to develop for. It is easier to develop on an ip stack. You have great tooling and great libraries out of the box because pretty much everything uses ip nowadays. Plus, at least part of the controllers people use for their smart home will use ip anyway. A non ip network will need a bridge. > How is that possible when thread use an ipv6 stack over 802.15.4 while zigbee use a simpler stack also over 802.15.4? Easy, zigbee doesn't use a simpler stack. Using the same physical layer protocol doesn't tell you anything about the rest of the stack. It's actually pretty simple. 6LoWPAN which is what Thread uses is more efficient than the Zigbee network protocol. Packets are smaller and the routing is better. It's not particularly surprising to be honest because Thread was designed by people who knew Zigbee really well and were aiming for an improvement.

alsko 1y ago

Matter was created by the Connectivity Standards Alliance (CSA), formerly known as the Zigbee Alliance! Basically, Matter is the next generation Zigbee. Thread as a protocol predates Matter, and it is just one of the supported transports, together with Wifi and Ethernet (for now). Edit: One thing Matter adds that was not in Zigbee is Bluetooth provisioning, letting you use your phone to add a device to your network without QR codes or numbers to type in. Also fun fact; Homeassistant is part of the CSA and apparently, Google, Apple and others use HA for testing!

bevr1337 1y ago
> Edit: One thing Matter adds that was not in Zigbee is Bluetooth provisioning, letting you use your phone to add a device to your network without QR codes or numbers to type in. What follows are my two pennies as a developer working in home automation for 7 years. In this venue, readers may even have more knowledge regarding security, but I hope to speak to a common case. I develop this exact feature though not for Ikea. Having made the sausage, some of these UX-first flows are worrisome. Consider a lightbulb that factory resets given a rapid succession of power cycles. Most consumers won't have redundant power during a brownout, so there is an edge case where dirty power can mistakenly send the bulb to a reset state. (More plausibly, a child tugging at a light switch?) Now, any device in radio range has an opportunity to take over the bulb. Provisioning is rare. Unless the owner enjoys tinkering, a residential IoT device is provisioned a handful of times in its life. I personally think it's a waste of time to optimize this flow if the improvements are also vulnerabilities. Suppose I have a great new smart bulb. I'm ready for a larger market so I prepare a demonstration for Lowe's, hopeful for space in their lighting and rough electric aisles. Lowe's has seen this before. My bulb works fine but my users aren't technical. Lowe's replies, "we can't carry this. Users must deploy and control from a single app in 5 minutes." If I want my smart device to compete, my hand may even be forced to implement UX-first provisioning. Companies like Lowe's and IKEA don't want to be in the tech support business. My bulb is a liability because their customers will call with complaints or questions. I find QR codes to be a slick implementation. They don't even need electricity! Users can manage the system even when components go offline. Folks are trained on social security numbers and PINs for bank cards. It's easy to comprehend the QR code as a password.

amluto 1y ago

As I understand it, Thread can transparently extend its mesh over regular IPv6 (Ethernet, Wi-Fi, etc), whereas extending a Zigbee (or Z-Wave) mesh beyond useful mesh range is a mess. I have a Z-Wave network that uses two controllers, and it sucks. It’s utterly obnoxious to maintain, the whole concept of multiple controllers is barely supported by zwave-js-ui, it is far to dumb to recover quickly on its own if it transiently loses connectivity to a node, and roaming between controllers is a complete non-starter. I haven’t tried Thread yet, but I’m delighted by the concept of having a couple of easy-to-maintain base stations (routers or whatever they’re called) connected to the local network and having devices automatically roam between them. I am not delighted by the fact that an Apple Home Thread network, a Google Home thread network, and a Home Assistant native thread network appear to be different things that are not entirely compatible with each other.

izacus 1y ago
> I am not delighted by the fact that an Apple Home Thread network, a Google Home thread network, and a Home Assistant native thread network appear to be different things that are not entirely compatible with each other. Hmm, in what way? The Matter standard does demand that devices support at least 5 of such "fabrics" at once. Where is the issue in practice?
- amluto 1y ago
  Maybe there isn’t one. Can I “pair” a Thread device with, say, an Apple TV and have it talk to the Apple TV via radio to an IKEA Dirigera hub and then IPv6 over Ethernet from the Dirigera to the Apple TV?
mox1 1y ago
Yes this is indeed a problem. You can get around this by piping the Z-Wave or Zigbee information into a MQTT server and basically run them as separate networks, with Home Assistant and MQTT tying it all together. But you will need some type of Zigbee to Ethernet adapter (Sonoff makes one, Raspberry Pi, etc.) or Z-wave to ethernet adapter (again Raspberry Pi). It's definitely clunky. But doable. I am running multiple Zigbee networks near each other (in a house and in a detached garage) with Home Assistant, MQTT server and a Sonoff Zigbee bridge, with Tasmota.

ianburrell 1y ago

Thread can talk to your phone using a gateway. Thread is IPv6 based. The gateway, called border router, is no different than access point in function. Current systems require a hub, talk protocol to hub, hub talks Zigbee to device. Home Assistant is great, but you still need device running it. Thread requires border router, but that is simpler device and only does networking. Matter is the other part of Zigbee, the home automation profile. I get the impression it is bloated with multiple companies involved, but it is standard. Matter means that your phone can talk to Wifi device with your choice of apps.