- cross-posted to:
- homeautomation@lemmy.world
- homeautomation@lemmy.ml
- cross-posted to:
- homeautomation@lemmy.world
- homeautomation@lemmy.ml
You must log in or register to comment.
Man there are way too many IoT standards. What’s the difference between these two? How do they each compare to Matter?
An important difference between thread and zigbee/wi-fi I’m not seeing mentioned is that all thread devices automesh in a hub/spoke model as long as they’re not battery powered. So your light bulbs, plugs, etc all become extenders and part of a self healing mesh network without a single point of failure. For me it works better than Zigbee for this reason.
I exclusively use ZigBee. It automeshes.
Thread is a wireless standard meant to sit next to Bluetooth and WiFi.
Matter is a home automation protocol can that be used over Thread or WiFi. Ideal Matter devices use Thread instead of WiFi because running a bunch of home devices like light bulbs or switches on your WiFi is a recipe for disaster.
Matter is important because it provides native compatibility among different platforms.
What kind of disaster specifically? I hear everyone discouraging from using WiFi for home devices, but never understood what the actual risks are.
I see someone replied about security. But I was just taking about stability.
Most people don’t have super beefy wifi routers. Many have whatever shit their ISP sent them. These are fine for your average number of laptops and phones, etc. but if you then throw on 10 more 2.4GHz WiFi IOT devices, you are probally going to run into devices randomly dropping off the wifi, etc.
Additionally, wifi is usually chosen over other protocols by manufacturers due to the cost of hardware and development. So they are often lower quality. (This is only one reason)
But sure, if you have a super awesome 2.4GHz wifi setup and high quality wifi devices, maybe things will work out just fine. But my personal experience with WiFi tells me I shouldn’t clutter my WiFi.
Also, if you were curious, yes: almost all WiFi IOT devices are 2.4GHz only.
This sort of makes it sound like the advantage of Thread is merely that it’s new, and therefore nobody will be affected by having a poor pre-existing Thread setup. If ISPs were sending people Zigbee hubs, it sure would be the cheapest shit available, which could very well translate to similarly terrible Zigbee performance.
I see your point, but there should be much more merit to the specialized IoT protocols than just that nobody has yet flooded the market with terrible Thread/Zigbee devices.
I’m not sure manufacturers choose WiFi because of hardware costs. There are often other reasons (some good, some terrible) for this choice, but I’m certain Zigbee support has to be cheaper; having disassembled plenty of such devices it’s almost always a dedicated IC and a tiny PCB trace for an antenna. WiFi support requires a fairly complete TCP/IP stack implementation, basic certificate management etc. which will inevitably require a small SoC; and while prebuilt solutions are plentiful, Zigbee alternatives are an order of magnitude cheaper.
I can imagine software development costs being lower, though, given how every other programmer knows a fair deal about TCP/IP networking, while good comprehension of dedicated IoT protocols is a much rarer skill, there are also much less community resources and open-source solutions available etc.
Thread is the replacement for zigbee.
It’s zigbee plus more features.
There is nothing zigbee does better than thread.
Lower power usage, ipv6, standard tls security, not proprietary, etc.
Let’s say your lightbulb(s) become comprised. A bad actor now has a toehold into your network.
Maybe they run a spam relay through the bulb. Maybe they attack your network by attacking the printer that hasn’t had a firmware update in years.
Point is, there’s someone with access to your network that isn’t you.
https://old.reddit.com/r/Ubiquiti/comments/1fjspoc/what_is_the_point_of_having_a_separate_devices/
Right, thanks. But this can be easily resolved by:
- Removing devices’ access to WAN, which also vastly reduces the external actor’s ability to compromise them in the first place.
- Isolating devices from each other with internal firewall rules, allowing them to only interact with the hub host. Is this correct, or am I missing something?
firewall rules? who cares about firewall rules if the switch still forwards packets to the printer?
firewall rules only work on end devices, and routers when the destination is in a different subnet and broadcast domain.
Good luck explaining how to do any of this to my parents, for example. For someone with a technical background that’s feasible, for someone with an it background it’s even easy. For the other 90 or 95% of people who are actually supposed to buy and use these things, it isn’t. They don’t even know something like this can be done, let alone that it should be done.
But that is not a fault of WiFi as a medium, but rather of the ecosystem of devices as we know them. Some company might launch a “Home Automation WiFi” product, which would be simply a home hub with a builtin WiFi router pre-configured with the recommended security settings. Zero config nor admin work required, just buy the right (hypothetical) hub.
Though the real problem is that every other device relies on cloud connectivity, which highly limits such hubs effectiveness. Again, that isn’t an inherent fault of how WiFi works, rather I see it as a problem with the ecosystem and how consumers want their devices to work without any hub. Hopefully with more local-only devices that trend can still be reversed.
But that is not a fault of WiFi as a medium, …
but it is a fault of WiFi as a choice for that application. Just because it does wireless communication doesn’t mean it’s suited for any application that needs a wireless protocol. Using it for very-low traffic applications is simply not what it was designed to do, and it has significant negative effects if you do. Any device you add basically slows down any other device by a bit. And wifi network you add in a physical area decreases the effectiveness of all other wifi networks in it’s vicinity. In even medium densly populated areas, wifi is already borderline unusable due to congestion. Your proposed (dedicated) hub is a good idea for network isolation, assuming it’s designed and configured correctly, but that also comes with more and frankly just as bad security implications, just different ones. To be clear, having like a light bulb or two wifi is a fine choice. For 50 or a whole smart home network, it no longer is.
Both Zigbee and Matter do not rely on cloud connectivity as a protocol, though many of the manufacturers implementations do effectly add that on top: you get the exact solution you propose here as well. At least with these standards you can control everyhing locally, if you want to, and you don’t congest the spectrum nearly as much as wifi does.
Sounds like homework
Sounds like an admin job I don’t want to do.
There are also performance implications (a Zigbee coordinator can easily handle 100 devices, while many routers would struggle with that amount of clients), power saving (especially for battery powered sensors) - some Zigbee sensors can last years on a single coin cell battery.
Thread is a network layer thing, comparable to WiFi or Bluetooth. Matter is an application later thing, comparable to HomeKit or Google home.
Zigbee is both network and application layer.
This article has a decent overview https://www.smarthomeperfected.com/zigbee-vs-thread/
Googling didn’t reveal any useful answer, did anybody know it has an article about what’s the advantage of matter vs mqtt?
Do you mean Matter vs Zigbee? Matter and MQTT are totally separate things.
So, if I’m invested in zigbee, but want to future proof, I should consider threads/matter, and a hub that talks to both?
Can home assistant do that?
Yes if you have a Zigbee and a Thread antenna module connected to your HA instance you can run it as an Zigbee and Matter hub and connect Zigbee and Matter devices. A cheap antenna module is the Sonoff ZBDongle-E. You can flash the firmware of it and turn it into a Thread antenna module. It can also run as a Zigbee and Thread antenna simultaneously, but I never got that working properly. So I just bought two dongles. One for Zigbee and the other for Matter.
Hows that working software-wise in HA? One running in Z2M, the other ZHA?
I’m not running Z2M and ZHA together though. Just ZHA and Matter. But I’ve read that running Z2M and ZHA with two dongles is no problem in HA you just have two separate networks
I only just bought a zigbee USB antenna, and 4 smart plugs. You’re saying I need a second USB antenna dongle for thread?
I am pretty happy with zigbee so far. Is that a good thing? I haven‘t done anything with matter so far.
I am just getting started on this journey but zigbee seems great and I like that it works fine even if the wifi goes down. I’m not sure what the drawbacks are or the benefits of Matter.
matter and thread are different things fyi…
thread uses the same wireless communication as zigbee (zigbee has other stuff on top of it), so is a low power wireless protocol
matter is the data format that devices use to communicate on top of an IP-based network like wifi or thread. it’s meant to standardise all these competing “works with google” “works with alexa” “homekit compatible”: if it works with matter, it should work with any coordinator that has matter compatibility (which all the big ones do these days)
thread will work great if the wifi is down - same as zigbee!
matter also (afaik) forces local devices: your coordinator (a homepod, alexa, etc) talks directly to the device without going through the internet. again, same as zigbee
Thanks for the explainer, that last point is really great actually and I’m surprised that Amazon/Google etc are pushing for Matter if the data isn’t sent to the internet.
well your coordinator gets to end whatever it likes wherever it likes but the devices themselves communicate over your internal network so everything should be much snappier
Isn’t the HA cloud dongle able to do both because they’re on the same 2.4 gigahertz or whatever?
The dual stack firmware was deprecated because of issues, I believe.
It’s still marked as experimental, not deprecated, just will likely stay that way. However, it does work with both protocols individually, and the first-use wizard asks you which dedicated firmware you would like to install:
https://support.nabucasa.com/hc/en-us/articles/26124710072861-Enabling-Thread-support
xkcd 927 in action right there.
Zigbee works just fine, but needs a hub to share out devices eg internet access or HomeKit. But it is quick. How thread compares remains to be seen.
Remains to be seen? What other information are you waiting for?
I’ve been using Thread devices for ~5 years now.
How are the battery lives of your devices? I have motion sensors throughout my house connected via zwave, and I replace their button batteries about every 18 months. Does Matter run over a low energy technology?
Thread is just as efficient based on the few battery operated motion sensors I have. That’s another reason Matter over Thread is better than Matter over WiFi.
I personally won’t buy another IoT device unless it’s Matter over Thread.
With that said, if you already use home assistant, and what you have works well enough. I wouldn’t rush to upgrade. But I would choose Matter + Thread over older technologies moving forward.
If you want to move to all HomeKit, then the upgrades are worth it.
In an ideal future world, Matter + Thread devices won’t need a vendor app to work. They just connect to your Amazon Voice assistant, or your Google Home, or your Apple HomeKit setup directly. (Or Home Assistant)
In the future we should see more vendors selling Matter compatible devices that don’t even offer an app. But this is down the road.
Crap. I use pretty much exclusively Ikea stuff with my Home Assistant
