Live data from Hacker News

Zigbee vs. Matter over Thread:Understanding IoT Protocol Performance in Practice

arxiv.org

81–90 of 104 posts

Re: Zigbee vs. Matter over Thread:Understanding IoT Protocol Performance in Practice

#81
post #58

`establishing it as a more robust foundation for larger and more heterogeneous deployments.` Based on.... 6 devices? Quite honestly I would have been interested in measurements with more than only 6 devices. Maybe upto 50 or so,even better if they'd mixed different hardware nodes for a more realistic scenario

I have 47 thread/matter devices, alongside some 10-15 matter over wifi devices, so not quite 50, but "close enough".

It's not as fast as Zigbee, not in day to day usage, and not in terms of reconnecting, which often takes 30 seconds (ie. after a power outage) where my Zigbee devices just seem to reconnect instantly. On day to day usage there's a slight delay when turning something on, but it's maybe 100ms or less.

I initially had quite a few problems, but after "standardizing" on a single thread network (I had 3 before for some reason), as well as adding some wired thread border routers, things have become much more stable.

My zigbee to thread is still a "work in progress", replacing devices as they fail (ie. lightbulbs), and I'm also still adding new Zigbee devices like the Aqara T1 Valve controller, but I prefer thread over zigbee today.

One thing I will note, people tend to underestimate the range of thread (and zigbee for that matter). Each mains powered device will function as a repeater just like zigbee, and I initially thought I might need a couple of smart plugs as repeaters, but despite having a somewhat large house (by european standards) as well as double brick walls dividing it, my thread devices have no problems "seeing" a thread border router in the opposite end of the house.

Re: Zigbee vs. Matter over Thread:Understanding IoT Protocol Performance in Practice

#82

Earlier quoted context omitted.

Sorry to pop your bubble, but the moment you add any IP connectivity it will be eventually used to mandate internet access. The devices you have now might not yet demand it, but you will have to replace them at some point or extend your setup in the future. We've seen this play out so many times now, it's baffling people still think this time will be different. There's a saying: If you set up a trough, the pigs will…

I run 100-device zigbee network with zigbee2mqtt. Philips, Bosch, Sonoff and some others. No internet access. Zigbee devices are slow and low power, they cannot access internet directly.

Not directly, no; they do it via the hub

Re: Zigbee vs. Matter over Thread:Understanding IoT Protocol Performance in Practice

#83
post #82

Earlier quoted context omitted.

I run 100-device zigbee network with zigbee2mqtt. Philips, Bosch, Sonoff and some others. No internet access. Zigbee devices are slow and low power, they cannot access internet directly.

Not directly, no; they do it via the hub

Zigbee: You can buy vendor independant bridge / antenna and vendor independant automation server (Home Assistant being the most popular).

I guess a bridge vendor could pull the rug on the antenna ("your Sonoff zigbee antenna is now only compatible with Sonoff zigbee product")(to be clear: they've never done that), but the format is open enough that there's ton of alternative suppliers and open source bridge (the aforementioned zigbee2mqtt).

In any case, I've got a good amount of both Ikea tradfri and Philips Hur bulb and they have never contacted an Ikea or Philips hardware or software of their life.

Re: Zigbee vs. Matter over Thread:Understanding IoT Protocol Performance in Practice

#84

Earlier quoted context omitted.

Firewall blocking is not the point. The point is, that over time through enshitiffication the new device will require call home to unlock. Even when it does not need internet to work at all. But through this the vendor will get a foothold. Sure you can block it, but then you have a pricey paperweight. This is not unique to Thread/Matter, they can pull the rug on ZigBee as well, ofc.

The assumption of enshitification it that is receives updates. What you and a few others aren't understanding is that these don't need updates. These aren't Alexa or Google devices. They just get setup and passively work Now, will they eventually build devices that don't work like that? Maybe.

The enshitification I mean, applies to the new models. Once the current device dies, you need to replace it.

And in the future, the offline devices might be no longer available, because they stopped being produced. And only new shittier ones are for sale.

Re: Zigbee vs. Matter over Thread:Understanding IoT Protocol Performance in Practice

#85

Earlier quoted context omitted.

The assumption of enshitification it that is receives updates. What you and a few others aren't understanding is that these don't need updates. These aren't Alexa or Google devices. They just get setup and passively work Now, will they eventually build devices that don't work like that? Maybe.

The enshitification I mean, applies to the new models. Once the current device dies, you need to replace it. And in the future, the offline devices might be no longer available, because they stopped being produced. And only new shittier ones are for sale.

A lot of companies have invested a lot into matter and thread. I’d be surprised if companies started requiring a call home to work. It doesn’t make sense to need that, since a thread network is, in a sense, offline by nature. Only the hub has access to the internet and it doesn’t require access to work, so having a device require a call home wouldn’t really make sense.

I get that enshittification is a real thing but I’d be surprised if it affected smart home devices in the way you are describing.

Re: Zigbee vs. Matter over Thread:Understanding IoT Protocol Performance in Practice

#86

Earlier quoted context omitted.

The assumption of enshitification it that is receives updates. What you and a few others aren't understanding is that these don't need updates. These aren't Alexa or Google devices. They just get setup and passively work Now, will they eventually build devices that don't work like that? Maybe.

The enshitification I mean, applies to the new models. Once the current device dies, you need to replace it. And in the future, the offline devices might be no longer available, because they stopped being produced. And only new shittier ones are for sale.

Oh you're talking about a pretend device that this person with replace due to the pretend problem with their current device.

So what's your solution to this problem?

Re: Zigbee vs. Matter over Thread:Understanding IoT Protocol Performance in Practice

#87

I’m in the process of migrating from Zigbee (Z2M) to Matter over Thread (Apple HomePods + Matter Server). My Zigbee network was a mishmash of different vendors all of which had their own failure rates and quirks, Aqara having by far the highest failure rate and complexity. My new Ikea (Thread) based setup has had absolutely zero issues so far and fingers crossed it doesn’t start suffering as I scale it out. That said…

> That said, it is noticeably slower than Zigbee, but we’re talking 50ms > 250ms. Which is more than acceptable. I’m taking your “but” to mean “it is acceptable. I would at least deem it noticeable to wait a quarter second for my light to turn on . May just be my own impatience, but I get an insta-headache whenever I have to wait to find out whether something worked or I have to try again. Every bit of jank is a down…

In many situations you're already "latent" due to interacting via voice: "Hey Siri, turn on the lights" is ~3-4 seconds to say casually, allow another 0.5-1.0 seconds due to voice processing, network, etc, and the missing 200ms is basically par for the course.

Where it starts to get annoying is "door open" and "motion detected" triggers. Motion detected can be played off as a sloppiness in the sensor cone, but going from "instant" to "laggy video game" when you have a physical trigger can be relatively annoying.

Re: Zigbee vs. Matter over Thread:Understanding IoT Protocol Performance in Practice

#88

Earlier quoted context omitted.

The assumption of enshitification it that is receives updates. What you and a few others aren't understanding is that these don't need updates. These aren't Alexa or Google devices. They just get setup and passively work Now, will they eventually build devices that don't work like that? Maybe.

The enshitification I mean, applies to the new models. Once the current device dies, you need to replace it. And in the future, the offline devices might be no longer available, because they stopped being produced. And only new shittier ones are for sale.

i dont really understand the point. am i never going to buy any tech ever again, because most things tend toward enshitification?

Re: Zigbee vs. Matter over Thread:Understanding IoT Protocol Performance in Practice

#89
As someone with hundreds of Zigbee devices w/ zigbee2mqtt in a network (actually 2; one in my standalone garage, and one in the house), I'm hoping Thread/Matter will not take over because _for me_ it does not have a single improvement over Zigbee 3.0 and I have had 0 inclination to adopt any Matter devices so far. Probably why Zigbee 4.0 is a thing.

Re: Zigbee vs. Matter over Thread:Understanding IoT Protocol Performance in Practice

#90
post #2

These protocols add so much complications it makes wifi/tcp/ip a blaze They fix some problems but add more, you endup just like that xckd about protocols

A bit of clarification: Thread is a layer 2 protocol, for the user, it looks like standard IPv6. Matter is application level, and just expect standard TCP/IP underneath. There's nothing binding Matter to Thread, and in fact a lot of Matter devices use Wifi

I wish we had multimodal Matter devices that could go over Thread or Wi-Fi (or even wired networking) depending on conditions.
Post reply on HN