I’ll take good news wherever I can get it. If IKEA can stick the landing it’ll mean a lot for Matter adoption.
post
Hmmm how's the matter integration with HA tho....
Edit: it is goooood!
What does it say?
Man there are way too many IoT standards. What's the difference between these two? How do they each compare to Matter?
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.
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?
With a good router, it's not that hard to do. But even then it took me a long time to get around to setting up the separate network, and I don't think I've migrated all of my devices over to it still (some got moved, new ones go there, but there are some older devices still sitting on the original network). So, yeah, there's definitely extra effort, and it's not really fun like getting that new smart device integrated. I will say the stuff on that network works perfectly - I haven't noticed any side effects.
Oh I did allow them access to the pool ntp server so they can pick up the correct time, and some require temporary access to the internet while setting up (the linknlink RF device needed it to download the Home assistant version of their firmware, for example).
ZigBee/Thread are just better for this, you're protected without doing anything.
Requirements like the ones you listed above make widespread adoption impossible, short of forcing routers to have a separate IoT network and forcing devices to use only that, with all the issues that may prop up along the way.
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.
Using it for very-low traffic applications is simply not what it was designed to do
Was it not? Sure, it wasn't specifically designed for low traffic, but it was designed with a wide range of traffic levels in mind; after all, virtually every WiFi capable device, home automation or not, uses very little traffic most of the time as it idles. Now, I absolutely appreciate Zigbee or ZWave being optimized for minimal energy consumption, which is useful for some device types; but I feel it isn't right to call WiFi a poor choice for low traffic just because it also handles very high traffic well.
You raise an interesting point about congestion, though, and that is very much was I hoped to learn about. I am sometimes under impression that device designers assume everyone lives in a detached house so interference can be ignored. Do you know how specifically is Zigbee better in this regard? Living in a condominium I always had very poor experience with Zigbee reliability, which might or might not have been due to local radio noise at various ares of the spectrum, so I'm curious to learn about details how exactly these purpose-specific transfer layers deal with noisy neighborhoods.
In the context of communication networks, WiFi is a high speed netowrk. It was designed to be basically a "normal" (ethernet-like) network, but wireless. It acts for all intents and purposes like an ethernet network. There are significant requirements that devices need to follow, many include frequently saying "hello" (simplified). The complexity of the protocol to be able to send at gigabit and faster speeds over dozens of meters is significant. Having relatively low latency adds to this as well. If all you need is a few bytes every now and then, that isn't ideal. Having devices in your network that follow older/slower standards is essentially like pulling the handbrake for your network (again, very simplified). But explaining this in detail is also very much beyond the scope of a comment here.
ZigBee devices form a mesh network, which WiFi devices don't do. This means I can have my hub on one side of my house and a bunch of bulbs and smart outlets maintain a backbone through the house for a bunch of low power devices (like thermostats and door sensors) to connect to it.
If you're having a bad ZigBee experience, I recommend making sure your bulbs can serve as a general ZigBee bridge, and not just a bridge for other bulbs of that brand. Otherwise, a well placed smart outlet can serve the same purpose.
Both Zigbee and Matter do not rely on cloud connectivity as a protocol
In my ideal world, no devices would not rely on cloud connectivity ever, regardless of their choice wireless transport layer. The fact that the nature of Zigbee or Thread stop device manufacturers from stupid practices (such as relying on direct WAN access) is nice, sure, but does being less capable really make them better suited for the job? I would prefer to appreciate Zigbee or Thread for what they are and have, rather than by the fortunate side effects of what they can't do.
I also don't want devices I'm actively using to needlessly compete with random logistical packets from a dozens of devices around my house. I also don't want the devices themselves to need all the power of a WiFi connection when another protocol suited to low power home automation devices is sufficient.
ZigBee/zwave were fine for me, though. I personally haven't seen a clear benefit to matter+thread yet.
My favourite thing about these non-wifi wireless protocols is that devices using them seem to want cloud connectivity a lot less than those that come with wifi.
Zigbee or Thread doesn't actually stop them from adding cloud connectivity, they all still do. But you yourself can stop it. Similar to the "gateway" you suggested with dedicated WiFi, they sell you a gateway for Zigbee or Thread, which then connects to the cloud/internet to allow you to control your stuff. As they would with a WiFi gateway. The protocol isn't "less capable", it's intended use is around (home-)automation. It is low power, low bandwidth and most importantly both are a mesh network. That means that while you have a central point to access them (at least Zigbee has exactly 1), they all talk to each other and for a fully connected mesh. A device doesn't need to be able to see/hear that central point. It can send it through a multi-hop route, and that route is dynamic so when a device leaves (out of power, turned off, ..) the packets basically just find their way. Generally anything that has a stable power sounce will act as a router and forward packets. The low power part means that if you have a battery powered thing (remote switch, thermometer, ...) it can run off a single button cell for like a year or so. With wifi it would last a week, maybe two. The bandwidth thing is related to that as well, as a thermoeter needs to send the temperature and/or humidity maybe every few minutes, or even just when it changes and there is no need for that. That comes with power usage, complexity and many other downsides, but of course a zigbee device can't stream video or something (like a security camera would need to).
When using wifi, any device needs to be in range of the access point. You can have multiple access point but those aren't that cheap, and should be wired in. Devices only ever talk to the access point. When multiple devices talk to each other, it goes to the access point who then sends it out again to the other device.
There are great writeups on the internet, just google "zigbee vs wifi" or something. I'm not gonna repeat what
Side note: you can reply to more than 1 paragraph in a reply. No need to reply three times, but I guess I'll stick with it now.
but that also comes with more and frankly just as bad security implications, just different ones
What do you have in mind? Surely, no solution is perfect, but at least on the surface it sounds much better than the alternative of no isolation at all, so I'd love to learn what worries you.
If I'm gonna install a device by some random manufacturer that acts as a wifi access point inside my network, I also give them full access to my network. That access point can do all sorts of things, and I would describe this as a security nightmare. It also doesn't even have to be malicious: the manufacturer could get hacked, and now the hacker has access to all these wifi access points all over the world, and all their home networks. Fun.
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.
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.
I never meant to imply that Thread was the only solution to WiFi based IOT being bad. Just that it is a forward looking choice that has interoperable support from the dominant computing platforms. This is why IKEA is moving to it.
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.
Thread is a bit more power efficient, which matters for battery powered devices that aren't connected to permanent power and don't need to transmit significant data, like door locks, temperature/humidity sensors, things like that. A full wifi networking chip would consume a lot more power for an always-on device.
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.
Dishonest question, your following comments show you clearly know the common points of these discussions.
There's no arguing that using WiFi for this purpose is an obstacle to widespread adoption and a security risk, no matter how well you yourself are handling it.
There's also the technical advantage of those IoT networks being meshed by design, whereas expanding a WiFi network with mesh functionality often carries challenges.
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/
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.
Yes, Thread serves similar functionality to Zigbee, to the extent that some people describe it as Zigbee 2.0.
However it’s a new protocol for a new standard, that has backing from all the big names in home automation, including Apple, Amazon, Google.
Zigbee is a great protocol. Thread will bring better connectivity for the future (we hope)
Pretty sure than an underlying feature of both zigbee and zwave.
They're different in their implementation. Zigbee automesh is more of a centralized router-hub model with self healing relying on routing tables. This caused significant issues for me. Thread is true automesh with all devices acting as a hub in a hub/spoke model, so there's no centralized routing table to act as a single point of failure.
Thread also works on the 2.4 GHz range but can utilize sub ranges of 868 in Europe and 915 in north America. The 868 and 915 GHz ranges are what LoRa operates on and provides a much greater range for low data rate transmissions.
In fact Meshtastic operates on LoRa on 915 here in the U.S. and I have a node in my second floor window with a 3db antenna and I have been able to message both ways up to 3 blocks away.
Long story short, utilizing 868 and 915 in these devices will make dead spots a thing of the past within a home, even with their lower gain internal antennas.
Thread works with matter, these devices will use Matter over Thread.
It makes sense. Hopefully it's more reliable than my Zigbee devices. I constantly have to power cycle devices made by a variety of manufacturers to get them to register again. And I've tried more than a few zigbee hubs. Can't say I'm a fan.
Check interference with wifi signals wifi on channel 1 and zigbee on channel 25 gives you the most separation. As long as a neighbor doesn't blast on wifi channel 11.
There is also software compatibility, I found hue to be the most stable for routers. Osram was terrible, recent firmware made it okay.
I'm in literally the middle of nowhere, the next nearest house is 4 miles away and I'm not even connected to the grid. If there's a wifi signal detectable, it'll be mine. So I've shifted frequencies around trying to get it to stabilize, with little luck. I've primarily been using Sonoff, Aqara, Ikea and SMLight, and hubs from each of them.
Honestly, I've been migrating to zwave since I don't seem to have issue with anything I use on that protocol.
Aqara (specially older devices) are known for being temperamental and not playing well with other hubs/devices. If you have each manufacturer on its own hub, make sure they are using separate channels. If everything else fails, 2.4GHz is also used for Bluetooth, microwaves and other, maybe your location has noise on that band,
Z-Wave is using lower bands (800-900mhz depending on location) and certifying the devices better for software compatibility. It's a fine solution as if it works for you, any limitations are basically theoretical (like the 200 devices).
I'm using zigbee2mqtt, I've noticed that leaving things alone for a while helps with network stability.
I don't use third party hubs, everything is connected to the z2m coordinator.
I've ditched pretty much all Aqara devices as they have problems getting their messages relayed, the best alternative was creating a separate network just for them, I did that for a while but then I decided to just replace them.
Never had this with ZigBee, one hub lots of different devices. Had to switch hub to USB2 at beginning to reduce interference but after that smooth sailing.
Crap. I use pretty much exclusively Ikea stuff with my Home Assistant
It's not like it'll stop working once this is introduced
I just bought the last thing I wanted from them and finally moved to their infrastructure. Like, yesterday. Welp, I hope I don't have to change anything ever again.
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
My understanding is that you can replace the ZigBee firmware with Threads firmware if you want.
Yeah, that's what it looks like to me as well, but since I'm currently using Zigbee devices, I would need to either move them to a new hub, or get a second cloud connect, ZBT1, so that one could be dedicated for threads and the other could be dedicated to Zigbee.
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.
You can flash the SLZB-06 to use Matter over Thread too. I like those because they use Ethernet and can be powered via PoE, so you can put them practically anywhere you can reach using an Ethernet cable.
I only just bought a zigbee USB antenna, and 4 smart plugs. You're saying I need a second USB antenna dongle for thread?
Yeah you need a separate dongle. The ZBDongle-E from Sonoff is pretty cheap on AliExpress. Cheaper than the official Home Assistant ZBT-1 dongle Nabu Casa sells. Unfortunately running both Zigbee and Thread on one antenna doesn’t work very well even with the dongle from Nabu Casa.
Only thing with the ZBDongle-E is that you need to flash it yourself to run OpenThread via this website https://darkxst.github.io/silabs-firmware-builder/ it’s not hard though.
Thanks. I'll look into it. Right now I have mainly lights and sockets, through a Lidl zigbee hub, a rebranded Tuya, I believe, but I'm looking into going a bit deeper.
I’ve been using the OG tradfri devices since 2017/18 and have been very happy. Reliable, cheap to add a lightbulb or switch. Just works. Even integrated with home assistant v easily
Googling didn't reveal any useful answer, did anybody know it has an article about what's the advantage of matter vs mqtt?
Initially, Dirigera will only support Matter device types that Ikea currently offers — so, no robot vacuums, door locks, or fridges. However, Granath says that as they launch more smart home products, the hub will be updated to support more device types.
Am I reading this right? Is there a filter possible where Ikea can decide to only accept Ikea ~mac addresses? If so, can they continue to ignore the wider product space?
... or will an Ikea thread hub automatically accept rando thread units as per standard and they're just using really bad sentence structure?
It has to do with the device types not the devices themselves. Matter itself didn't support every type of device at launch. It's a software support thing.
The second. It works with non-Ikea devices, but only works with device types that have an Ikea version like bulbs.
Kind of a lazy question, but are any of these protocols substantial over 802.11, especially if you just use p2p/adhoc/mesh modes?
I haven't touched mobile networks in a while so I've forgotten a lot, but iirc the main concern of mesh networks was efficient routing (which has been solved with some cool algorithms) and power efficiency for devices transmitting (again could have sworn 802.11 and even bluetooth can already achieve this).
Zigby particularly stood out as annoying to me as it includes its own 2.4ghz physical layer stack which uses the same range as WiFI, which is already overcrowded as hell and relies on some CSMA/CA magic to make even the most apartment crowded area of APs function decently.
Zigby particularly stood out as annoying to me as it includes its own 2.4ghz physical layer stack which uses the same range as WiFI, which is already overcrowded as hell and relies on some CSMA/CA magic to make even the most apartment crowded area of APs function decently.
I mean, there isn't really any other choices for unlicensed consumer use? 5GHz is dedicated to WiFi. The sub-GHz bands would be great, as there isn't a need for much bandwidth, but it's a huge mishmash of frequencies that would require many different SKUs per device:

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.
I haven't started with home automation yet.
How's product availability for thread bulbs and motion sensors? Expensive? Works with HA?
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.
So Thread is a low-power radio, and Matter is the protocol? Does it is the same frequency ranges - 2.4 and 5 GHz? Or does it have a different spectrum? One of the reasons I chose zwave initially was because the standard allows far more devices in the spectrum than ZigBee, and WiFi crowding is already an issue with only all of the phones, tablets, computers, and devices that I couldn't get in zwave.
It’s still 2.4, but it meshes and extends itself with more devices.
If you have an exceptionally bad RF environment, maybe you will have issues.
But keep in mind that IOT devices are not usually broadcasting in the way WiFi is. The impact of 10 Thread devices is not the same as 10 old school 802.11 devices.
Thread is still better than 2.4ghz WiFi for IOT, and I would say this is true for the vast majority of people. But maybe there is a small percentage who have such an intense RF situation that they will need a different spectrum. But really, it sounds like you are possibly either an outlier, or are misunderstanding the shape of the situation. Lamenting that a phone or tablet can’t use zwave for networking is really strange.
Lamenting that a phone or tablet can’t use zwave for networking is really strange.
It would be, if anyone were doing that.
Thread is basically the same thing, but with a different upper level layer (IP), lower lever is still 802.15.4
Very lame :( Proprietery license hell awaits. Matter is such a misguided solution to the smarthome space.
How so? what's the matter with matter?
It's open-source but you do require a certification if you want to release a matter device. But there is no real way around this, else anyone can just release a "matter" device that doesn't properly follow the standard and then everyone is worse off.
How about they start by paying taxes?! They haven't paid any income tax in Australia the whole time they've been in the country due to "creative accounting"
They're culling staff, in favour of machines.
They're a corporate leech.
all 4 comments