Live data from Hacker News

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

arxiv.org

71–80 of 103 posts

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

#71

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…

What's to stop Ikea from pushing an OTA and crippling your whole setup 2 years from now?

That they would never see me buying again from them. That I can stop OTA. That matter is interoperable and I can run multiple gateways before cutting them out.

Most IoT stuff I own had a good track record. The only stuff that screwed me over was the logitech harmony smart remote.

But I usually pick the more open ecosystems and vendors. E.g.heating is on shelly.

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

#72
I'm running both now, and while my Matter network seems to be solid, I can't get over the fact that it's so much harder to set up devices than on Zigbee. Why does Google need to get involved for me to set up a local IKEA device with my local border router?

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

#73
post #71

Earlier quoted context omitted.

What's to stop Ikea from pushing an OTA and crippling your whole setup 2 years from now?

That they would never see me buying again from them. That I can stop OTA. That matter is interoperable and I can run multiple gateways before cutting them out. Most IoT stuff I own had a good track record. The only stuff that screwed me over was the logitech harmony smart remote. But I usually pick the more open ecosystems and vendors. E.g.heating is on shelly.

If we start from GP premises where they were multi-vendor on ZigBee and now (allegedly) are living a much better mono-vendor life with Matter, you cannot play the multi-vendors card. I'm on ZigBee multi-vendor orchestrated by Zigbee2MQTT and while some devices are quirky sometimes (worse offender... IKEA) I'm not planning to move over to Matter any time soon at all.

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

#74
post #39

Earlier quoted context omitted.

Because zwave is proprietary. There's money to be made here! Can you imagine the lost profit potential if people standardize on an open protocol like ZigBee?

It is so proprietary in fact all of the spec is on github: https://github.com/zwave-js/specs

Try to build a device and not pay the tax stamp.

You can see it in products like inovelli where zwave is always more than zigbee.

https://inovelli.com/collections/z-wave-light-switches-red-s...

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

#75
post #59

Earlier quoted context omitted.

You don't need to update your devices, and they don't need to be connected to any cloud. That's the whole point of these local communication protocols, after all.

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.

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

#76
post #68

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…

For IPv6 networks you're in luck. The hubs are not proxies so the IPv6 enabled IoT device in an IPv6 network can still be blocked at firewall level from accessing the internet. Less that the separation Zigbee provides but better than nothing. For IPv4 networks you're out of luck. The internal mesh traffic is still IPv6 to the hub and anything crossing into the IPv4 network is done through the hub's IP. No more blocki…

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.

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

#77

Earlier quoted context omitted.

I took their point to be about wifi being jammable

Yeah first thing burglars are gonna do is jam your wifi camera so you don't have any video of them. Run cat-5 and get a PoE camera.

Yeah, not sure why people are downvoting you. I suspect because most people run wifi cameras and don't see the reason to run a ethernet cable.

If you are halfway serious about your home security, you should use ethernet. It's trivial for thieves to jam wifi now.

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

#78

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 downgrade in quality of life to me.

Now: May this be due to that specific setup or is the delay somehow inherent to the technology?

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

#79

A lot of graphs where OpenThread & zigbee dance around each other, are within 2x of each other. Two huge notables to me: message throughput for openthreads scales up, zigbee seems to hit a wall early. Not sure when that matters but very clear. The last table was a fright through: it takes half a minute for OpenThreads to recover after a node drops where-as Zigbee a quarter second! Wow.

Is there a situation in which your smarthome taking 30s to recover from a node failure is impacting your life? Seems like a distinction without a difference

Oh, absolutely. That is the hot path.

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

#80
post #68

Earlier quoted context omitted.

For IPv6 networks you're in luck. The hubs are not proxies so the IPv6 enabled IoT device in an IPv6 network can still be blocked at firewall level from accessing the internet. Less that the separation Zigbee provides but better than nothing. For IPv4 networks you're out of luck. The internal mesh traffic is still IPv6 to the hub and anything crossing into the IPv4 network is done through the hub's IP. No more blocki…

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.

Post reply on HN