As it stands I dont see this being a thing that benefits me. It is more likely that this pushes smart home manufacturers away from Zwave, and makes my life worse because now I can't buy IoT devices without granting them internet access. Then I have to go through and start setting up IoT VLANs to quarantine devices, and in some really shitty cases, Ive seen WiFi devices where the app sends a message to a server, and the server sends a message to the device... so I can't quarantine the device without modifying it or losing functionality (see MyQ garage door openers). The industry looks bleak.
Agree on all points of preferring Z-wave though and it's also what I use. However, Linus (of Linus Tech Tips) recently redid all the switches in his home with Zwave switches... and they had a firmware issue... And the company refused to publish firmware updates in any way except through "official" Zwave hubs, and not Home Assistant. It eventually got sorted out, but Zwave isn't necessarily intrinsically failproof either.
Yes, I followed that drama as well and the did eventually make the newer firmware available to HA and similar though that doesn't exactly negate anything I said. For new features/fixes you are dependent on the manufacturer but that's the same everywhere. The big difference is that if Linus' switch company went out of business then his switches would continue to work the same way they always did (bugs and all). But I do agree with you Z-wave isn't perfect and does sometimes require a little more knowledge to work with.
Thankfully I'm all set currently (aside from the SmartThings rug-pull that I have to deal with and finally move everything remaining to HA instead of using my ST hub as just a controller from HA) and I'm just going to sit tight over the next few years and see how things shake out before I upgrade/replace any of my gear.
> As it stands now I don't care at all who made my Z-wave switches/bulbs/plugs, they could already be out of business for all I care
If the company was out of business and there was no way to get the newer firmware, LTT might have had issues. Also, buying a switch because it is advertised as having feature X, only to find out that feature X was added in a newer firmware than you have, and you can't get that firmware. That means it isn't just a "I dont care at all who made my product" scenario. It's much lower risk (especially if the feature you want is basic functionality rather than automation), but it's not 0 risk.
I agree with you that Z-wave is going to be 100% better than WiFi devices that call home and join a botnet, but I wanted to make sure it was clear that there is still room for issues.
It definitely confuses the user story though, idk why they included wifi at all.
> Wi-Fi enables Matter devices to interact over a high-bandwidth local network and allows smart home devices to communicate with the cloud.
If only there was a way to have it explicitly NOT communicate with the cloud. That's the last thing I want.
When operating via thread, those ipv6 packets are just using it as low powered wifi alternative for those packets. Both Wifi and Thread connections thus require two levels of joining. One for connection to the AP/thread mesh network, and one for the matter encrypted network. Ethernet based devices on the other hand, can simply join directly to the matter encrypted network.
BLE for joining can simplify this, as a controller can provide the needed info about thread or wifi, as well as the info needed to join the matter network.
----
Now I very much support local control. Most of my smart home devices right now are either Zigbee or Z-Wave. I have 9 z-wave devices (plus the home-assistant controller), and 4 Zigbee ones at the moment, although only 2 are in use. (These current ones will never upgeade to support matter over thread). I am waiting on he new inovelli switches which will initially run on zigbee, but I will probably later upgrade them to run on matter. (After I buy a new zigbee radio dongle that supports dual stack zigbee/thread operation, and home-assistant officially releases their support for doing that).
But those of us running home-assistant, or the like are not the real target market of Matter. For more typical users, they end up with a bunch of smart devices that are wither wifi based, or have their own hub. Each one has a seperate app. Some might be homekit compatible, some might be hue compatible (work via the hue hub and its app), some might be compatible with amazon Alexa via the cloud, some might work for Alexa via zigbee (but only if you have an echo model that supports zigbee). It is not easy for consumers to even be certain what works with what.
With Matter, every Matter device will be compatible with homekit, will be compatible with Alexa, will be compatible with google home, will be compatible with SmartThings. The only requirements are that your controller device have support for the general type of device in question, and if it is a Thread device you have at least one Thread "border router" (ip gateway, equivalent to wifi AP) in your matter network. Homepods for example include such a border router, and likely some future Amazon Echo models will too, and it has been suggested that some Wifi Routers will include that functionality too.
That is a huge win for the average consumer!
The one nice thing about it, above Zigbee, is that you can expect devices to work together. With Zigbee you frequently have to pair a device with a hub from the same manufacturer.
During my first attempt at home automation, I used to mess around with flashing custom firmware onto WiFi devices (Tasmota, ESPHome.) It was a huge pain whenever the hacking process stopped working (tuya-convert), and I had to open up the device, solder some wires, and flash the chip via USB serial.
Nowadays I can just buy any Zigbee product I want (usually from AliExpress), and get it set up in zigbee2mqtt without any extra steps. And it's all local within my home, and no hubs or cloud services required.
I think Zigbee is better for me because I have a lot of battery-powered devices, such as sensors for motion, door contacts, and temperature/humidity. I'm really impressed that the button batteries usually last for 1-2 years.
On the other hand, Zwave radio spectrum varies depending on region, so you need to be very careful that you don't spend hours troubleshooting something that doesn't work because it's a device intended for the EU market instead of US.
IIRC, Zigbee is better here.
I have a handful of Aqara sensors that constantly dropped away, so I just flashed an XBee with router firmware and have it on a small USB battery that stays plugged in. That way power outages won’t cause issues with the “leave and rejoin” request that routers will issue to aged-out devices, which my Aqara devices seem to balk at.
I had less luck finding Matter with DuckDuckGo. Evidently a competitive search term (which is to be expected).
As it stands now I don't care at all who made my Z-wave switches/bulbs/plugs
Even Enbrighten, a former GE brand and so ostensibly reputable (this of course depends on how familiar you are with the GE of today) is shipping some total garbage that they haven't even bothered to develop real documentation for. Curiously, I've found that some Enbrighten products and Zooz products are physically identical to the degree that I think they are both sourcing some of their hardware from the same manufacturer... but Zooz has very noticeably superior firmware.
* Signal strength. Getting more repeaters and devices fixed this * Flaky service implementation. Uprading ZWave JS on Home Assistant and adding a monitor that got ZWave JS to ping devices when they were unavailable as made the system very reliable.
I have had no need for any additional documentation for all of the GE / Enbrighten switches I have installed in my house. Other than how to wire it and how to get it in pairing mode, what else is there?
i have a bunch of zigbee devices (mostly ikea tradfri) that i'm eager to upgrade in the hopes that i get more reliability and speed out of my connected devices (mostly lighting).
explodes
The fact of the matter is that Zigbee isn't competing with Matter, it's being replaced with Matter. Rebranding may not be the best choice of words, but I think you're missing the point.
they want you to look for "Alexa" or "Google Home" or "Apple HomeKit" labels, not "Zigbee" or "thread" or "zwave"
edit: Just in case anyone is not following C# developments
Old: .NET 1.0 … -> .NET 4.7 -> .NET 4.8
New and not compatible: dotnetcore 1 … -> dotnetcore 3 -> .NET 5
And of course, there is their ORM which did not drop the "core" part, so for .NET 4.8 there is Entity Framework 6, the version for .NET 5 is called Entity Framework Core and reached 6 as well last year. For ASP.NET (that is, on .NET 4.8) MVC 5 is the current MVC solution, I think for ASP.NET Core (.NET 5) MVC 6 might be, but despite actually working with those technologies, I’m not sure.
To some extent, Thread and Matter are direct replacements for Z-wave at different levels of the stack. There are some different pros/cons between the two though. The major advantage of 6LoWPAN is that it shares a lot of the design and implementation with existing network stacks and can be carried directly over IP networks. This is expected to make more complex 6LoWPAN topologies much easier to implement (e.g. 6LoWPAN traffic can be easily forwarded over the internet by a gateway). None of this is really anything that can't be done with Z-wave, but 6LoWPAN makes it easier by having a lot of common design and implementation with ubiquitous IP stacks. Matter itself has the major advantage of being a newer and higher-level design than Z-Wave which should result in more consistent interoperability of a wider range of devices.
Z-wave will probably remain superior for battery-powered sensors into the future, because Thread doesn't allow for the extremely aggressive sleep schedules (e.g. sleep mode for 18 hours at a time between supervisions for security sensors) that Z-Wave does... although we can of course debate how wise it is to only perform supervision every 18 hours, even if UL allows it for burglar alarms.
IIRC Zigbee is: 802.15.4 -> "Zigbee"
And my (mostly incomplete) understanding of matter is it's: 802.15.4 -> 6LoWPAN -> Thread -> "The device model of Zigbee"-like Application Layer (for thread devices)
It did? I moved into a new home a year ago and have been outfitting it with smart devices. I have no real preference for Zigbee but ended up with a bunch of Zigbee devices and zero Z-Wave devices.
They will only use "thread" for low data rate communications. They will all have Wi-Fi. thus the ipv6/cloud/tcp/udp talk.
I want _just_ thread out of these things. I want my devices to talk to my zwave/zigbee/thread network and to not talk to the cloud without my permission.
AFAICT, devices that don't need high-data rate connectivity aren't required to have WiFi. IOW a thread camera will have WiFi but a thread light switch doesn't have to.
And I assume there is no way to make sure that the camera never connects to the internet without setting up firewall rules on my router. Because the announcement specifically calls out the ability for smart devices to phone home as a perk, I imagine blocking devices from phoning home isn't an option, and you have to assume that any device with WiFi will attempt to phone home even if it's not "smart".
If there was a way on hubs to have mobile phone like permissions. "This device can use local WiFi" and "This device can access the internet for Smart stuff" as separate permissions, I might be ok. But since most WiFi IoT devices are dumb and just punch a tunnel through your firewall so you can access them with a mobile app and wind up in botnets, I don't have a lot of faith in IoT companies to do it right, so until I can be assured (and verify myself) that WiFi doesn't mean "can phone home", theres no way in hell Im going to use Matter wifi devices.
Thread is a mesh protocol. They won’t wifi mesh a camera.
> Which makes the WiFi not really a mesh, but a standard WiFi connect to the hub.
Yea.
> Because the announcement specifically calls out the ability for smart devices to phone home as a perk
It is a perk to some.
> until I can be assured (and verify myself) that WiFi doesn't mean "can phone home", theres no way in hell Im going to use Matter wifi devices.
Some devices will some won’t. Surely some devices will advertise being local only. Some companies won’t won’t the expense of a server.
Some matter devices won’t need wifi at all (lights). You might be more comfortable with them instead of writing it all off.
> wind up in botnets
Ironically cheaper devices may bet better off here. They’re probably too cheap to use anything but embedded code instead of embedded Linux so there’s less attack surface (excluding vendor provided).
Matter provides a secure channel to share OTA updates (eg through a thread hub) that is signed by the vendor. So this should be a step in the right direction in terms of security.
I don't know why you think your zigbee devices will be upgradeable to thread - that strikes me as quite unlikely, although perhaps physically possible depending on how much hardware offload the devices use.
Matter actually uses an iteration of the Zigbee device model - from an application level they are actually somewhat similar
> I don't know why you think your zigbee devices will be upgradeable to thread - that strikes me as quite unlikely
Most Zigbee radios are dual Zigbee/Thread since both protocols are build on 802.15.4. I suspect that the limitation is going to be on manufacturers rather than hardware limitations
Thread is a protocol, this is only as true as the statement "WiFi gives each device access to the internet".
It _can_ give devices access to the internet, but only if you plug your (border) router into an internet connection. (Or otherwise bridge the networks. Your border router could still have internet access itself without bridging the thread network out to the internet.)
To be clear, Thread is not Wifi.
What wireless protocol has the range to cover an entire house or lot? Bluetooth is sketchy beyond the same room, and I don't want to deploy a dozen hubs just to cover all my stuff...
My, maybe not-so-naive, assumption is that manufacturers will require an internet connection for some/all functionality because they can.
There was no need for wifi or Bluetooth or rc or anything funky like that. It was about as dumb as a smart home could get.
Insteon was simple and mostly just worked. Even my wife saw the benefit of the thing.
Uh what? This is definitely not the case with my nanoleaf bulbs..
I have a huge issue with this. The fact that zwave/zigbee cannot connect to the internet is why I have so many in my home and I'm not as concerned about them.
I think I remember looking at the vendors that were involved in Thread and none were privacy conscious. Apple, Google, Amazon, major Semiconductor manufacturers, Samsung, Yale. No-one who actually promotes privacy in standards.
I'm gonna guess Thread will be a privacy nightmare with the internet access making it no better than wifi. Lame.
That said, an explicit goal of Thread is to make the implementation of the gateway device easier and thus allow devices to communicate with a backing cloud service with less active participation of the hub... the hub is still "in the loop," but it doesn't need application-specific implementation for every device, it can just forward messages.
Enthusiast solution would be to use Home Assistant as your thread gateway to actually be in control of the connections:
https://community.home-assistant.io/t/home-assistant-skyconn...
> 2.3. Network Topology
> [...]
> This protocol may operate in the absence of globally routable IPv6 infrastructure. This requirement enables operation in a network disconnected or firewalled from the global Internet.
May implies it is up to the manufacture is internet (i.e globally routable IPv6 infrastructure) if required or not.
Confusingly, in legal terms "may" can also indicate a mandatory provision, depending on the context. https://www.law.cornell.edu/wex/may
With a simple (open,pf)sense firewall, ubiquity AP you can easily configure a WiFi network that is completely internal and can talk to each other, but not to anyone else.
It's a matter of defaults - isp provided firewall/routers these days commonly come with a guest WiFi mode, and good ones even segregate that network. I can envision an iot mode that would a large minority of users could use. There's always going to be users who don't care, or don't have the technical knowledge, but recognise that stories on /r/sysadmin skew away from the "average user".
Sure I can block them from the internet but if their management requires a cloud server (which many do) then they are bricks
There's no WiFi, they use Zigbee behind the scenes, what changed is that they are addressed via IP, but it's still a strictly local network.
> Matter uses Bluetooth Low Energy for provisioning via a QR code, while it relies on Wi-Fi for high-data rate connectivity and Thread for low-data-rate communications.
So you say no WiFi but the post specific says WiFi. And if there's wifi then I have to set up my network to ensure they don't have internet access, thats not something Im going to leave up to the honor system.
Wi-Fi in the hub but not in the devices would make no sense. Why have Wi-Fi in the hub if devices aren't going to use Wi-Fi to connect to it?
Also I went back, and searched the post for Wi-Fi, and the thing I quoted is the only reference to Wi-Fi. It uses Wi-Fi for high data rate connectivity. IE, a camera transferring data to the hub. so the camera has wifi. You can't transmit data over Thread, it's not high bandwidth enough. No where in the linked post, though, or in the source press release does it mention that Wi-Fi is optional, but other more informed users here have said that it is optional, and only necessary for high bandwidth stuff like cameras, so lightswitches could be Thread only. So some devices apparently won't have it. But many will.
Reading the actual CSA press release, it says
> Wi-Fi enables Matter devices to interact over a high-bandwidth local network and allows smart home devices to communicate with the cloud.
So yes. The goal for the Wi-Fi is both to transmit high bandwidth stuff like camera feeds over local network, but also to allow "smart devices to communicate with the cloud" aka "reach the internet". So yes, the devices _will_ have WiFi.
You should read it more carefully.
Let's wait and see what this thing really looks like.
As it stands now I don't care at all who made my Z-wave switches/bulbs/plugs, they could already be out of business for all I care, that's not the case with 90% of "smart home" shit I see online. "No hub" means "absolutely not" for me because that's a wifi device with full access to your network (unless you segment) and the internet.