My biggest issue with Thread is (AFAICT) it gives each device access to the internet. That's the absolute last thing I want and the reason I went 100% Z-wave (with a handful of legacy zigbee devices). I want a single point of local hardware that my devices talk to and that hub can talk to the internet as needed but I don't want to have to vet every device or deal with companies going out of business.
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.
Yeah. I was very excited about this until i got to "Bluetooth Low Energy for provisioning" and I was like "oh.." and then "Wi-Fi for high-data rate connectivity" was a "oh. no thanks." That's a clear path to the internet and also using multiple radios so that if I lock down one thing I have to constantly worry about others.
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.
> 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.
Even if new firmware is out, you're not guaranteed to get it. Linus got it because he has millions of subscribers and if he makes a stink, companies have to listen. If you're a boring customer with just one twitter account at your disposal, you may never be able to update.
My AmpliFi router did this the other day. It added itself to HomeKit to create device specific firewall rules for iot devices on my network. The options were like “access everything, access whitelist of services, no access”. I turned on the whitelist but it broke everything :D
Not necessarily, because Wi-Fi is energy hungry and it will empty the battery in a short time. The Wi-Fi enabled CR123A battery powered Shelly devices I have exhibit shorter battery life than Zigbee devices operating on a CR2032 or CR2450 and the battery holds many more mAh. If yuo have an outlet or cable powered device then yes, they usually phone home.
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.
I have a lot of Zigbee devices, and I've never experienced a pairing issue like this. I use Zigbee2MQTT with Home Assistant, with a electrolama ZZH USB stick - https://electrolama.com/projects/zig-a-zig-ah/
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.
You haven't had an issue because you are using z2m which tries to support everything. Try using a Philips Hue hub or Aqara or whatever and most devices will not work properly.
Sure, but it's long enough that I don't get annoyed when I need to change a battery. If I ever build or renovate a house then everything will be wired, but these are working really well for now.
Although you can easily circumvent this with a cheap Zigbee USB controller, Raspberry Pi (or other computer) and something like Zigbee2MQTT. My IKEA bulbs, Xiaomi sensors and Philips remotes all work great as a mesh.
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.
Yep... cannot use US or EU market (at least I believe that's the case, based on [1] which mentions UK) z-wave gear here in Australia due to incompatible spectrum usage. And the AU market z-wave gear is about twice the price of the US equivalent, since it's low production volume.
Aqara Zigbee devices are renowned for having a longer keepalive check-in period than many routers expect. So when they don’t check in on time, the router marks it as dead. Often, a quick tap of the setup button to re-announce it to its router will cause those routers to “unmark” it as dead—you don’t need to re-pair it. But it’s frustrating enough when it happens.
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 have 8 Aqara sensors (4 temp/pressure, 4 door/window contacts), one temperature sensor consistently has this issues, no others do. Used to be Deconz, now on Zigbee2MQTT with the Conbee 2.
The whole idea of Matter is local control over IPv6. From what I understand, it is basically Zigbee's cluster library re-platformed on top of new encrypted mesh layer that runs on IPV6. This does technically mean that all such devices can send out arbitrary IPv6 packets, and for Ethernet and Wifi can even send out ipv4.
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.
Where is the developer docs? The site leads to some document under solutions that needs to be downloaded to read. It is also not clear why a protocol specs or implementation should be categorized by solutions. Overall the site documentation lacks transparency.
As it stands now I don't care at all who made my Z-wave switches/bulbs/plugs
This is maybe an optimistic view of Z-wave in my mind... early on quality and reliability problems were nearly universal with Z-wave devices, and today I have a fairly short list of brands I trust (e.g. Zooz) after having been burned by a series of devices with various firmware bugs or just very poor lifespans. The best story I have is the lightbulb that would turn on every time it received an explorer packet, and thus every time my hub at the time ran a heal, which was of course scheduled at 2AM every day and not easy to disable due to the hub's poor firmware. This was years ago, but then there's still a surprising number of Z-wave devices on the market that are just Z-wave, not the poorly named Z-Wave Plus or Z-Wave Plus V2, and thus have significantly inferior network reliability if there are any changes in the environment. In any modestly challenging environment (e.g. battery powered device a few walls away from the nearest powered device) I have gotten used to having to try out multiple products before finding one that was reliable, and that was even after learning not to buy anything that wasn't at least "500 series" (Silicon Labs part number for Z-Wave Plus).
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.
I've got about 20 zwave devices by all of the manufacturers you mention on my network and they have all been very reliable after a year of use. I had a lot of reliability issues at the start, but they all ended up being due to two issues:
* 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.
Thanks for the tip about Zooz, they do look nearly identical may have to pick up a few for additional switches.
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?
no, thread is a rebranding (and evolution) of the zigbee protocol, which is a low-power, local mesh network with no inherent internet connectivity. zigbee/thread devices work offline first, with switches that are an integral part of the local mesh network. these devices can also be connected to the internet through a hub/border router, if you so choose. matter is the umbrella brand name for the combo of BLE, wifi, and thread that provides a complete IoT ecosystem.
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).
Zigbee Alliance renamed themselves to the CSA. Can companies still keep making Zigbee devices after Matter? Sure, it's not impossible, but it's not really going to happen much more than somebody producing anything else obsolete.
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.
I suspect it is desirable as one is supposed to search for the marketed products. The magic smoke that binds the device to the app or blinky lights is of little importance.
If it was MS, it would start as ZigbeeSpecial 1, followed by ZigBee 5 and be incompatible with ZigBee 3.0
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.
Stating that Thread is a rebranding of Zigbee is incorrect. Both are based on 802.15.4 for their physical layer but the two are entirely separate and managed by different standards bodies (Zigbee under the Zigbee Alliance, now CSA - Thread under the Thread Group). Where some confusion may come is that Matter is now also under the CSA (just like Zigbee).
while you're technically correct, it's a rebranding from the (zigbee) consumer's perspective, via the CSA being a rebranding of the zigbee alliance. within that context, thread is the most direct analog of the zigbee protocol, as they're both implementations of 802.15.4 for low-power local mesh. consumers won't need to (and most won't want to) understand it deeper than that.
Matter/thread is nothing like zigbee, except the MAC layer is the same. For one, Thread uses IP(v6), and Zigbee does not use IP at all. This will make managing thread networks much more like managing normal networks (hopefully).
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/thread is nothing like zigbee, except the MAC layer is the same.
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
If all they do is connect to the hub and then the hub controls all external access then that's fine. I'm just unclear as to why there is so much talk about IPv6/cloud/TCP/UDP for something that is only talking to a local hub. I mean I totally get you can use all of that (save for "cloud") 100% locally but if that were the case I'd expect more mention of that. I'm ok with using wifi-adjacent for communication, internally but I do not all my "thread" devices to have internet access (local or external).
The idea of thread is that it is basically IPv6 over Zigbee, in the form of 6LoWPAN which is an IPv6 stack optimized for low-power devices with an addressing, discovery, and routing mechanism designed to work well on mesh networks like Zigbee.
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.
I believe would be more accurate to say it's Zigbee over IPv6.
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)
I'm using the terminology in a confusing way. Thread and Zigbee are both protocols on top of 802.15.4, but to be fair to myself there is a really common tendency to refer to "bare" 802.15.4 as Zigbee mostly because of the history. Zigbee is a very "thin" protocol though compared to Thread which is a lot more ambitious, but at the same time Zigbee goes more into application space... which kind of makes the point that Thread and Matter are a lot more "detailed" than Zigbee, which is minimalistic to the degree that interoperability of Zigbee products has always been very poor. This is one of the major reasons that Z-Wave mostly replaced Zigbee in the "smart home" space. It standardizes more functionality that Zigbee does. Thread and particularly Matter, in turn, standardize even more than Z-Wave (e.g. many of the things that are Z-wave config "mystery registers" that vary between manufacturers are included in Matter specs).
> This is one of the major reasons that Z-Wave mostly replaced Zigbee in the "smart home" space.
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.
Me too, after getting two battery powered Wi-Fi enabled devices which are rather inconvenient. Z-Wave is somewhat better if you have a big house or many neighbours with 2.4 GHz Wi-Fi APs using the spectrum because it operates on the 868/908 MHz ISM band instead of the 2.4 GHz ISM band used by Zigbee and shared with Wi-Fi and BT devices. Lower frequency waves travel more easily through thick walls and further and the 868/908 band is also subject to airtime restrictions in order to prevent interference. ZigBee uses repeaters and more frequent updates to accomplish the same thing. Most wall plug powered ZigBee devices are also repeaters. You'll probably get more samples from battery powered ZigBee sensors than from devices either using Z-Wave (which has airtime limitations) or Wi-Fi (which is power hungry and the devices are in deep sleep most of the time).
> 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.
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.
If some devices aren't required to have WiFi, then how do they effectively mesh with other devices? If I have a camera on the far side of my house, and then have a daisy chain of light switches back to my hub... the camera can communicate over zigbee/thread back to the hub to get low data instructions. and all the switches can get on/off commands.... but the camera has to communicate all the way back to the hub via WiFi. Which makes the WiFi not really a mesh, but a standard WiFi connect to the hub.
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.
> If some devices aren't required to have WiFi, then how do they effectively mesh with other 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.
yup, i should have noted that wrinkle in my original comment. some devices will have wifi connectivity built in because they need the bandwidth (and maybe the wider access too), but many won't, because they don't need the bandwidth nor the higher power consumption that comes with it. zigbee/thread-only devices can't route to the wider internet directly because of protocol differences, which is why it needs the border router, but obviously wifi connected devices can. what matter does is standardizes this combo behavior across devices for interoperability.
> My biggest issue with Thread is (AFAICT) it gives each device access to the internet.
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.)
Given that most people will use their one and only router for this, it means most of these devices will have access to the internet. Sure, you _might_ be able to prevent it if you jump through hoops (because it really is annoying to setup a second wifi network, at least in my experience) and assuming the devices don't fail if they can't phone home (and we can be sure some will). But everyone is much safer overall if the "common standard used by most people" did not use wifi.
> But everyone is much safer overall if the "common standard used by most people" did not use 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...
Given that many if not most wired devices in a zigbee or zwave mesh can already perform this task (including lowly switches and light bulbs), I'm not sure how much of a problem that is. You only need one hub.
In the 80s my dad controlled the lights in our home using the Radio Shack plug 'n power system. Plug-in switches and the control box would talk to each other by sending signals through the home electrical wiring.
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.
Good ole' X10 that later became Insteon. I actually have Insteon for all the lights and fans in my house and am quite happy with it's performance. I've been considering a migration, but I'm holding out until I see how Matter/Thread do as an ecosystem first.
Thread is an IPv6 bearing mesh network; and if you have a border router that has the appropriate IP routing rules, and your firewall allows it, your Nanoleaf bulbs can most certainly reach out to the internet (granted, they only have the concept of IPv6, so a majority of the internet is inaccessible if only because it is IPv4)
Any ideas if the HomePod Mini (probably the most popular Thread border router) grant broader internet access to Thread devices on the mesh network? I can't find any clear info about how this might work or how to test.
My understanding is it gives them an IPv6 address, but that does not mean they have internet access unless there is a hub that connects between the two.
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.
Thread and Zigbee are entirely distinct protocols; Matter does not use Zigbee in any way, at any layer of the stack, with the exception of some influence on the high-layer device/data modeling
> 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.
Yes. it says "Wi-Fi for high-data rate connectivity and Thread for low-data-rate communications"
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.
Yes, Z-Wave as as protocol is basically synonymous with a Silicon Labs product line, to the degree that the different versions of the Z-wave standard are more often referred to by their Silicon Labs part numbers (500 series, 700 series). This does seem to hold up the price of Z-wave products but, to be fair, they end up still being pretty competitive with a lot of other options, although usually more expensive than the most cost-optimized WiFi products like Tuya devices.
And at least for a long time held back the quality of open source solutions. There was (is?) frustration in the developer community in not having access to the Zwave spec and documentation.
Agreed, as far as I could tell the thread border router is designed to be opaque to traffic traversing it.
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.
I am so afraid of the potential of a cyber attack via IoT... with people taking image files from random spots on the dark web and writing them to their rasp pi's without looking at what's on the image, and putting random devices on their network without having any way to explore the code embedded -- it would be very easy for a widescale cyber attack to suddenly be unleashed and very suddenly we wouldn't even know what hit us.
Thread devices cannot access the internet without the cooperation of a gateway device. The topology is ultimately the same as Z-Wave with the devices communicating with a hub and the hub communicating with the internet. Thread is based on IEEE 802.15.4 just like Zigbee, but it uses IPv6 with extensions as the network protocol, for both a more powerful and flexible network protocol and more implementation commonality with existing network stacks.
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.
I haven't tested, but I'd hope HomePods acting as gateways would be able to toggle internet access. Apple made a whole thing about HomeKit wifi routers (there's like 1 on the market) where you can easily firewall any wifi homekit devices to within your network.
Enthusiast solution would be to use Home Assistant as your thread gateway to actually be in control of the connections:
> 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.
Note, you can always set up a Demilitarized Zone (DMZ) as a VLAN for your IOT stuff, and then use a proxy in case you need those to reach some servers outside. It is not a solution for always-on-internet devices, but for stuff like Shellies it works fine.
It's a real shame that home networking equipment don't have better firewalls or VLAN capabilities.
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.
In Germany, Fritz!Box actually managed to have advanced capabilities like that and still become mainstream. Many people use Fritz!Box routers here, and ISPs often offer them for free with higher contracts. I don’t have one, but my parents do and while I can probably do a bit more with my Ubiquity devices, it’s not that much more and the Fritxbox has a far superior user interface in exchange.
After reading /r/sysadmin for years I have zero faith in the average user's ability to use such a device. The closest thing I have ever seen was some D-Link router that had the option for a DMZ
Of course, but I'd also argue that smart home appliances are mainly for those with some technical knowledge, especially configuring them to work together. It's actually no linger uncommon to find networking gear with these features, only that most people just use what their ISP gives them.
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".
Isn't Thread 6LoWPAN? This should normally require a Thread to WiFi hardware gateway with a IPv4 to IPv4 gateway. I'm sure it also uses private address space.
"it gives each device access to the internet". I'm sure it's for your own good! I imagine the Matter SIG/Alliance is a who's who of data muncher and fetishists.
Let's wait and see what this thing really looks like.
For reference, the IEEE 802.15.4 spec is ~800 pages long. 900 pages does sound like a lot considering that Matter (AFAIK?) doesn't directly spec any hardware or transport details - those being covered in 802.15.4 and Thread.
Granted, we should remember that those 900 pages include base details that, probably, CSA are not planning to change in the foreseeable future. They need to be very thorough.
To answer your real question: device manufacturers will likely use the Matter SDK. It would be a huge undertaking for a smart-light manufacturer to re-write all of that code from scratch!
I haven’t read the spec, but I believe that some backwards compatibility is built in, and there’s a degree of complexity involved in making a robust framework that isn’t general purpose (like Wifi), but instead offers compartmentalisation of different device types and use cases.
I agree with the manufacturer concerns, but many were in a bit of limbo while Matter and Thread languished in draft RFC hell. The spec was always ‘coming by the end of the year’, and obviously impacted by the pandemic.
At least now, there is some certainty and a path forward.
> Matter lets devices communicate with bridges and controllers locally, which means that your smart home will still work when the internet goes down, and some devices may still have basic functionality even if they lose their cloud connection because the device maker goes out of business.
While I'm glad perfect did not become the enemy of the good and we actually have a standard now, I hope the consortium doesn't stop here, and keeps moving toward more vendor-agnostic, consumer-friendly standards.
> Originally, Matter was supposed to handle enough elements of provisioning and functionality so users wouldn’t have to download an app. In most cases, users will still need to do so.
While I also hope Matter doesn't turn into USB-IF ("Matter 3.1 Gen 2 SuperSpeed"), some clear evolutions or optional certifications (especially something for long-term, in-case-they-fold functionality) would be good to see them working toward.
A co-worker and I were just talking about Matter yesterday. Underneath the hood this runs on a networking protocol called "Thread"[1], which itself uses IEEE 802.15.4. This is pretty similar to ZigBee. Thread runs on 2.4ghz.
Thread uses ipv6 and UDP (TCP optional), so it should integrate well with existing network infrastructure.
> Underneath the hood this runs on a networking protocol called "Thread"
This is correct, but potentially leaves out a level of abstraction [1]. Matter is designed to abstract away multiple networking protocols, including Thread and Wi-Fi.
Philips Hue, for example, plans to support Matter but not Thread [2].
----------------------------------------
[1] A bit like saying "HTTP runs on TCP". It usually does, but it's not necessary to the standard.
> The Hue Bridge is not just a Wi-Fi to Zigbee translator. It has never been. It’s also the local intelligence of the system. It coordinates that your switches work well with the lights, it is what makes sure that the network is well managed. Entertainment streams, cloud services, automations, schedules … all that and more is managed by the bridge. Such a small, reliable “edge computer“ in the home is essential. matter does not offer a solution for it. Building all the functionalities directly into lamps would make things much more complicated, and we don’t want to move them to the cloud. That is, even if we used Thread, we would still need a bridge.
Second: Mesh networking with Zigbee in an efficient and reliable way is really hard. We have been working on getting that to work well for a decade. And Thread at scale in the complexity of users homes is not yet proven. I’m a bit afraid of how open Thread will be. There will be many, many companies with many different implementations in the same network. So, I see a lot of risk, and we don’t have plans to build Thread light bulbs. I don’t say never, but we have very much a “wait and see“ approach towards it.
Last not least: We have a very happy and large installed base. A key benefit of Philips Hue is future-proof and always up to date. Many people have made large investments in a Hue system as part of their home infrastructure, not as a gadget. And they expect that these products remain relevant for at least ten years. So far, we have never asked consumers to buy new lights.
I was curious how Thread compares with ZigBee in power usage.
One white paper I found suggests that Thread uses slightly less power.
E.g., for a device on a CR2032 battery sending a packet every minute, with ZigBee they estimate the battery lasting 1.38 years vs 1.49 years with Thread.
It is not RPL. Thread defines it’s own routing algorithm, specifically to solve two key problems: a single point-of-failure from a single border router, and to allow for ephemeral, sleepy devices. It is similar to RIPng.
I'll be closely following the development of matter, especially when it comes to compatible devices. Cloud dependency of many devices for the most basic functionality offered is an absolute dealbreaker for me. While I doubt that there will be meaningful change when it comes to the app mess retrofit smart home systems tend to create, I really do think matter will offer significant improvements. Knowing that I will still be able to dim my smart lights even if company X goes bankrupt makes is slightly easier to justify spending the premium on smart bulbs.
Also, I really hope that having one universal application level protocol for a variety of devices will further improve the home assistant experience. While the device support is great for many big brands, smaller brands (especially those outside the US) are sometimes lacking integrations.
What I don't like about Matter is that the participants in the standard itself don't seem to be proceeding with the ideal of having an abstract, unified control device. From a further link [1] from the posted article:
> Consumers will still need a lot of apps: One of the initial promises of Matter was that consumers would be able to add a device — like Amazon’s Echo — to their smart home controller but wouldn’t have to download a special app for every outlet or light switch they bring into the home. But at launch, and likely for a couple of years as the standard gets more robust, consumers will still need apps for anything beyond the basics, including installation. Even my panelists realized that this was the case.
I hope these companies realize that they are basically excluding themselves from a lot of potential customers by pulling this crap. I would have put smart bulbs as upscale stocking stuffers every holiday season if it wasn't for the fact that I have no idea what product / version / "ecosystem" the potential recipients use. "Just install a new app" is not a reasonable solution.
Give it some time. Since the software for devices is all available as open source, I expect a lot of commodity products (lights, switches) to be made available as pure Matter, without any apps, because it reduces the software development costs. The Matter early adopter companies are all companies with more expensive product lines.
Right - there was no way that the giants would partner together unless they could create their own wedges. It seems that there will be a baseline standard that allows end users to use their hardware on any one of the platforms, but each platform will have their own requirements for developers, starting with proprietary integration for the "best customer experience".
The fact I can (soon) stop having to check every device I’m interested in to see if it works with my ecosystem is great. I won’t have to settle for a worse device because the good one is Alexa (or whatever) only.
Also? Thread rules. WiFi has been (mostly) reliable but needs constant power. Every Bluetooth home automation device I’ve tried was a total mess of pairing/connection issues. Thread devices have worked great so far so I’m happy to see it continue to get popular.
HomeKit doesn't require an app for each device - sounds like Matter doesn't need one either, it's just that many devices expose controls Matter doesn't support.
My HomeKit light switch doesn't have an app on my phone at all, never installed one - just scanned the HomeKit code and set it up.
It depends. A lot of HomeKit devices have basic functionality through just the Home app, but if you want anything advanced, you need the device app. My Philips Hue bulbs only do "gradually brighten at sunrise" through the Philips app, and Nanoleaf panels need their app to do anything more complex than on/off.
>Cloud dependency of many devices for the most basic functionality offered is an absolute dealbreaker for me.
Story time: My internet got taken out by a dude with a backhoe, took a week to get repaired. I then discovered that my $4k 8Sleep mattress is entirely incapable of _any_ form of local control.
I have to bounce a packet off AWS to change the temperate of my bed, on a $4k piece of hardware. (I'm not mentioning the price to brag, but to point out the absurdity).
That and they couldn't even be bothered to put an RJ-45 on the back, so it completely failed when I migrated my main wifi to WPA3.
There's a lot of VC blood on the floor that bought us this common standard. Standardization is tough or impossible in a market that is minting unicorns -- we just had to wait for things to cool off before we could agree.
This is one of the gotchas of our current tech world: money drives progress, but that progress is almost always at the expense of cooperation.
This is great news, the Matter protocol sounds like it will make things a lot easier in the future.
If you're looking to get started with home automation, I would recommend using Home Assistant as the central software to control everything. Matter seems to solve some issues that I don't really experience as a Home Assistant user. You can use Home Assistant as the gateway that connects all your hubs and devices together.
I would also highly recommend buying Zigbee products from AliExpress. These are far more affordable than anything that you find in a retail store or from big brands. If you're very wealthy then you could afford to go with Philips Hue products for everything, but I've had a lot of success with some very affordable Zigbee and Bluetooth devices.
Here's the products I would recommend (all prices in USD):
I've been really impressed with these battery-powered devices. I was worried that I'd be constantly changing batteries, but some of my motion and door sensors have lasted for over 2 years on a single CR2032 battery.
I'm using a zzh (CC2652R Stick) from electrolama [1]. For the software, I use Zigbee2MQTT (z2m) [2] running as a Home Assistant [3] add-on. Here's a full list of supported USB Zigbee adapters for z2m [4].
What is the coolest thing you can do with a smarthome? The single biggest selling point?
Seems like you can basically just control appliances from your smartphone. Seems like such a small benefit (frankly I wouldn't even use it) for such a large effort, not to mention the security and data integrity problems.
One thing I've learned over the years is that this 100% depends on you and nobody's answer will really satisfy you, because the needs and routines of every individual can be radically different.
Do you care about energy consumption? If you do, you can pull in all that information into a dashboard, evaluate your usage patterns, and craft automations that ensure you're being as efficient as you want. Turn your lights/AC/music on and off when you go from room to room, etc.
Do you care about micro-optimizing your time usage? Create automations that support your daily routine. Tie your coffee maker's smart plug to the next upcoming alarm on your smartphone so you have breakfast ready by the time you get up. Have your garage door open automatically when it's time to go to work, and it's not a holiday, and your phone is at home, and your car is in the garage.
Do you care about eye strain? Have your smart lights change colour to match the light temperature of sunlight throughout the day.
Do you care about silly things that make you feel all powerful? Have your lights turn off, some white noise start, and all the smartphones in the house switch to Do Not Disturb when you plug in your phone to charge next to your bed after 10PM.
The sky is the limit. Over the years I've ping-ponged between "eh, this is not really worth it" and "this is actually incredibly convenient" depending on how my routine has changed.
My kids were scared of the dark, and letting them control the bathroom and hallway lights by voice (from their cozy beds) saved me from many late-night wakeup calls.
A smart home is just a problem solver, and everyone has different problems.
There are cool things you can do with a smarthome, like let a friend into your house remotely, but those aren't the selling features.
The selling features are the boring things. Like connecting a light switch to a lightbulb without having to pull wires through external walls. Or instead of waking up to an annoying alarm clock wake up to your blinds opening.
Agree, there's no one life-changing killer feature, but there's lots of small ones.
For example my thermostat goes up to 85 when I'm not at home, and I set it to a more comfortable temperature before I head home (it'll automatically get more comfortable when I arrive, but on hot days it's nice to pre-cool). You could accomplish something that works maybe 90% as well with lots of effort and a programmable thermostat, but this is more or less automatic.
My entryway light turns on automatically when I get home
I can turn off the lamp upstairs while I'm laying in bed, without having to get up.
I'd like to chime in and agree. It's the little things.
Through HomeAssistant (HA) I have a spoken notification to remind me to run the dishwasher right when the electricity time-of-use peak pricing ends each day. It also flashes a light a specific color when it says it so even if the tv is on loud, it'll get my attention.
HA automatically turns on my desk light when my webcam turns on.
HA allows me to remote-start my car with a Siri shortcut, instead of having to dig through the terrible manufactures app.
HA lets me know if I forgot to lock the door to my house.
The most recent thing I setup in HomeAssistant + NodeRed was an automation for my front porch lights, which are connected to a Lutron Caseta switch. When my Ring doorbell detects motion at night, the lights will turn on at 31%, and stay lit for 20 minutes. However this automation won't run if the lights are already turned on at some level other than 31%. Any subsequent detected motion increases the duration so that they stay on for 20 minutes after the last detected motion.
I also use Alexa to fake lights being turned on throughout the house when I'm away for an extended period of time, so the house doesn't seem as empty. There's a HomeAssistant extension that will record normal behavior in your house, and replay it on demand, which I'm thinking about using to randomize the lights even better.
Agreed about the little things. The best thing I've done is put a floor lamp on a timer... which sounds really lame but was so nice since there wasn't a light switch or outlet switch in that room.
I had it come on in the morning before I get up, then turn off after I leave for the day. Turn on in the evening, and off at bedtime. You can get mechanical timers for that, but they don't adjust themselves for daylight savings or changing sunrise/sunset times. I was going to set it up to stay on longer when it is dark and overcast out, but I moved to a place with better switch placement, so never did.
I plugged my dumb washing machine, dishwasher and tumble dryer into some zwave plugs which can report on energy draw. Hooked it up to Home Assistant, which is hooked up to Alexa. Now whenever any of my dumb washing machine, dishwasher or tumble dryer finish a run, it announces through my echo dot that it has finished. This is pretty useful to us as the washing machine and tumble dryer are in the garage, and the dishwasher finished beep is pretty quiet.
Honestly, there are no good applications beyond the most boring ones like turning your lights on automatically when the sun goes down.
Some people can figure out how to setup more complex things like "star my coffee when I wake up while gradually bringing the lights up" etc., but the whole experience is abysmal, and worse than Linux in the 90s: you need separate apps (or code stuff with Homebridge), all the devices have extremely limited capabilities (esp. when trying to control them centrally through e.g. Homekit), tgey are extremely brittle and disappear from your network if you look at them funny etc.
It's like Apple's Siri: good in commercials, but only good enough to set a timer. Same here: good in commercials, only good enough to turn on and off based on a simple timer.
Edit: I have a lighting setup with IKEA smart bulbs, Philips Hue lights, a smart plug on the balcony. I doubt I will ever touch another smart device beyond these.
I got a Google Home as a raffle prize and didn’t see the point.
But my house was built in the 70s and has almost 0 ceiling lights in the room. So I started buying smart outlets for the lamps so I could just turn the room off by yelling at it.
My wife switched us to Alexa because she had an app that would let her do her billing through voice (start working on John Doe’s case, stop).
I’ve expanded the lights through the house, I use routines to do stuff like turn off my bedroom light, turn on the fan, and turn on a “rain on a tent” sleep noise thing.
We use it as an intercom for the kids and to make announcements like “dinner time.”
I got an Amazon TV on prime day because it was cheap. It’s kinda handy to be able to yell at the TV when the kids lose the remote. Not super useful.
We all use the things to listen to music. I have mine paired with nice speakers in my office.
I gave up on being spied on. Everything I own is feeding back to Google, Amazon, and Apple. Probably China too with my cheap outlets.
I stick smart devices on a separate 2.4GHz Wi-Fi network that also can’t route to my main one, but that’s just to keep inevitable compromises contained and not fill my network with a bunch of chattering nonsense.
I wish Alexa would let me name it whatever I want vs the choose 1 of 3 names. There are more satisfying names to yell.
I have finally automated (a) determining that the washer has finished washing clothes (smart plug monitoring amperage highs and lows) and then (b) reminding the teenagers in my house that the washer is done and they should put their dang stuff in the dryer.
(They have not yet attained the self-awareness to set a timer on their phone, and I tire of tracking down the culprit every time I find wet clothes in the washer.)
Setup is Home Assistant Docker image on a Raspberry Pi, MQTT broker, and Tasmota firmware on the smart devices. 95% cloud free except for the push notifications.
Still determining how to solder together a safe dryer temperature sensor module to detect when the dryer is done...
> What is the coolest thing you can do with a smarthome? The single biggest selling point?
There's no single selling point.
> Seems like you can basically just control appliances from your smartphone.
That might be the case for most consumers, but it's nowhere near the end of what you can do.
One day my 3d printer was working and my robo vacuum bumped into it. I realized that it wasn't a good idea to start a vacuum run if the printer was busy. Both vacuum and printer were already connected to Home Assistant, so the fix was trivial and took a couple of minutes.
I've setup my air filter to turn on whenever the air quality drops - currently watching outside particulate levels, but I'm assembling a device that will allow me to measure inside levels.
We have two portable air conditioners in the same circuit. They can often run together - but not always. They are wired to smart outlets that measure power draw. Automation will turn one of them off if they exceed the recommended power draw - before the breaker gets unhappy. They will also be turned on automatically based on internal temp sensors. So I don't have to worry about my dog.
The important thing is to connect everything that can be connected and start streaming the data. You'll start to find plenty of situations where doing <x> when <y> will be useful. Want to dim the lights when the TV comes on? Easy. Want to turn the coffee maker on and open the blinds when you wake up? Simple. Want to postpone your dryer or washing machine when there's people around? Not a problem. Want a reminder that you forgot the garage door open, or a door open? You can do it.
But what's important to you will depend on your use-case.
I set up water sensors under the kitchen sink and in bathroom vanities. Each of them cost about $20 and integrated into my Home Assistant setup without any issues. Three months later, I was on vacation away from home and my water leak alert triggered. I was able to alert my parents, and they came back to shut the water and fix the problem before it translated into thousands of damages.
I've messed around with it a lot, and none of it is particularly life changing. You're not missing out on much by just ignoring it and living your life. With that said, I have three use cases that I enjoy a lot.
We sleep with a sound machine on. I have it set up so when the sound machine goes on, the lights in the bedroom go off and the subwoofer in the living room (adjacent to the bedroom) turns off. We tend to sleep at different times so this allows whoever is still awake to continue watching things without disturbing whoever is sleeping. I also have the outside lights set to turn on at sunset and turn off when the sound machine goes on.
For some reason the lights in my kitchen are controlled by two sets of switches on the opposite side of the room. I added a button to the kitchen island that turns every kitchen light on and off.
Finally, I have the under cabinet lights set to go on at 50% brightness when motion is detected in the kitchen after dark. That way we can grab a drink or a snack without blinding ourselves.
It's all pretty simple stuff but it's nice to have.
I've set up QoL notifications. One of my proudest compares the internal temperature of my home and the external temperature. If it's colder outside by a significant margin, I get a notification on my phone and TV letting me know so I can open my windows and get fresh air.
Other things include scheduling my lights (internal and external), unlocking my front door and garage with NFC stickers (sticker on my car dashboard or front door).
I think the problem is that it isn’t revolutionary today as the revolution the marketing is selling already happen or hasn’t yet. Mechanically and computerized monitoring and management was already available where it was most impactful. Its selling point is wireless and centralized switching but most features of the home need someone to physically be there to experience or to supply it to be useful so the advantage of signalling from a distance is mostly a plain micro luxury or moot. The robotized home to handle the inner home supply chains is the revolutionary application. It isn’t here yet but it will be advantaged by having a digitally communicable home between devices.
>What is the coolest thing you can do with a smarthome? The single biggest selling point?
I like having WRGB light bulbs everywhere that have full control via app/automation. I can wake up with "good morning" mode, have a day mode that's bright white and shifts to amber at sunset. I can go all hunt-for-red-october (pure red) late night. I can hit (or say) "goodnight" and transition the whole house to night mode, etc. Party mode is also rather fun :{
Best of all it works without having to do an expensive PoE retrofit to every switch and bulb in the entire house.
Control energy intensive activity like heat pumps to hours where electricity is plentiful (aka cheap). It's also literally cool when you run it in cooling mdoe.
I got into home automation because I wanted to control the temperature in my office using a plug-in electric heater and a temperature sensor. I set up a thermostat in Home Assistant that would turn on the heater when the room was cold, and turned it off once it reached the desired temperature. Then I put it on a schedule and set up some automations, so that my office would be warm by the time I got up, and the heater would turn off if I was away from home.
After that, it turned into a fun hobby. There's some cool things you can do with it, but it's just a lot of fun to write programs for my house and figure out routines and automations.
All our lights turn on automatically via motion sensors, and stay on based on bluetooth presence detection using our phones and watches. I also have a "night mode" that uses a lower brightness, and switches to using night lights in our hallway and bathrooms.
When we get up in the morning, the coffee machine turns on, the kettle starts boiling, the blinds are opened, and the TV turns on and plays a breakfast news program. (If we get up later then it chooses the TV channel on a 1 hour delay.) I set up a "movie mode" for our living room that turns off all the lights when a movie starts playing on our Roku, and turns on some dim lights when the movie is paused or stopped. We also never need to manually turn off the TV or stereo. When my wife and I both leave the living room and go downstairs, then everything turns off automatically after a few minutes (TV, stereo, any podcasts playing on an Echo, etc.)
When I walk into my office, the lights turn on, my computer wakes up, and it automatically unlocks when I'm wearing my Apple Watch. If I'm away from my office for a few minutes then the screen is locked, the lights turn off, and Spotify is paused. (Then Spotify resumes playing when I come back in, if it was previously paused by an automation.) Whenever my webcam turns on for a Zoom call, my air purifier is switched to quiet mode, and it turns off the fan in the bathroom near my office. It also turns on a ring light for better lighting, and turns it off when the call is finished.
The automations for our alarm system are really useful. Our alarm is automatically armed in "home mode" at night, and "away mode" whenever we are both away from home. It's automatically disarmed in the morning, and when we arrive home.
Our kitchen rangehood extractor fan turns on automatically when we're cooking, or if the pm25 in the kitchen goes above a certain level. Home Assistant also controls all of the heat pumps in our house, and all of our plug-in electric heaters are controlled with a thermostat that uses temp/humidity sensors.
I'm not quite finished yet - I don't have any cameras, and I want to put Amazon Kindle Fire tablets around the house to use as dashboards / controllers. It's also been surprisingly difficult to automatically open the garage door when we arrive home in the car, so I'm planning to use some ESP32s and design a secure protocol using 433 MHz transmitters/receivers. (I wasn't able to get presence detection working reliably with WiFi, even with a long-range antenna.)
Anyway, it's a hobby with lots of fun puzzles and challenges, similar to designing a Rube Goldberg machine or building a model train set. It's nothing life-changing or super important, just something fun to work on.
At Home Assistant we're very excited about Matter.
Here are some highlights for us:
Open source reference implementation: Google, Apple, Home Assistant, we're all going to be running the same code to be a Matter controller. Chip manufacturers like Espressif and Nordic maintain implementations for their boards in there too, so anyone can now have the software to produce Matter compatible light bulbs. https://github.com/project-chip/connectedhomeip
It will be cheap: The software is freely available and works with a big audience. It's the same reason Android TVs from some manufacturers are cheap, the same will be the case for Matter lights and switches.
Multi-fabric: each Matter device is required to support 5 fabrics. A fabric is a Matter network. This means that you will be able to run multiple home automation controllers at the same time. So when run into the limitations of Google Home or Apple Home, you can try out Home Assistant without taking down your old system.
Local: all communication for Matter is happening local between a device, a thread border router (if thread-based Matter), and the controller. Note that your controller can still decide to store your data in the cloud (ie Amazon, Google).
Supported by major systems: Amazon, Apple, Google and Home Assistant are all building the open source Matter code into their systems. It means that for manufacturers it will be easy to pick Matter as the protocol they want to support to reach most users.
Works over IP: Matter works over IP and doens't care how that IP-based device communicates. It means that you can have Wi-Fi based and Thread-based devices co-exist on your network. Thread is not required if you don't care about such devices.
Bridges are part of the standard: Devices like Philips Hue hubs are going to get an upgrade to expose all the Hue lights over Matter via the hub. This makes integrating a whole ecosystem at once into Matter very easy.
Thread: Thread is a mesh networking standard that connects to your Wi-Fi network via border routers. Where Zigbee and Z-Wave need to mesh communicate all the way to your controller, Thread messages will be delivered via Wi-Fi/ethernet as soon as possible. This means it is a lot more reliable and less traffic is going over the mesh. Expect cheap border routers (open source reference implementations) but also expect them in your future Wi-Fi routers, voice assistants, Wi-Fi connected TVs etc.
> Open source reference implementation: Google, Apple, Home Assistant, we're all going to be running the same code to be a Matter controller. Chip manufacturers like Espressif and Nordic maintain implementations for their boards in there too, so anyone can now have the software to produce Matter compatible light bulbs. https://github.com/project-chip/connectedhomeip
Will have to go through that documentation later, but are there any chips like ESP32/ESP8266 that hobbyists can use? Specifically for Thread.
But you can also use ESP32s for Thread. If you have one that we support laying around, we have an installer website here that we use for testing https://nabucasa.github.io/matter-example-apps/
Brought to you by our $20k/year annual membership fee that Home Assistant, an open source project, pays to be a member of the CSA alliance and be able to contribute to the open source Matter reference implementation.
Thanks for showing up and advocating for the open side of the world.
This made me curious about how Home Assistant is funded. Looks like it's mostly through Nabu Casa, which is a SaaS backend for Home Assistant that costs $6.50/mo or $65/yr in the US https://www.nabucasa.com/pricing/
There are enough products and projects available to build a smart home based on just open source code: Home Assistant, ESPHome and WLED for example. And soon you can add Matter to that mix. Product manufacturers could publish their source if they wanted to.
For the Raspi images: the build pipelines are often hosted on GitHub and all the build logs and source is available. If anything, open source projects that are big enough to offer their own OS often receive more scrutiny than most closed source products do.
Is there a way to force devices to use the mesh instead of going over the network? Lots of folks in this thread have concerns about allowing every lightbulb direct access to the internet and for good reason.
Doesn't Matter require device attestation? To me, this says, "Matter will never be compatible with cheap DIY devices like ESP32 devices". And also makes me suspicious of being able to create a Chromecast competitor that removes ads, or whatever.
Matter certification requires that controllers do attestation (validate that the device says they are who they say they are) but you are allowed to offer an option to users to bypass it (like Apple does today for HomeKit today).
I think the thing that clued me in was the fact that there were two people wearing sweaters knotted at the neck. One, okay, I'll allow it. Two seems like a clear signal.
Yes! It's maintained by the members of the CSA alliance (which authors Matter). It means that Google, Apple and Home Assistant will all run the same controller code and benefit from bug fixes. Chip manufacturers like Espressif and Nordic maintain implementations for their boards in there too, so anyone can now have the software to produce Matter compatible light bulbs.
Having no idea what “ Matter™ ” is, this headline feels vaguely like somebody is declaring that reality is in fact Facebook-officially real, and you can expect to go out and explore it today if you wish.
I also found the headline annoyingly vague / completely lacking in any useful information, and presuming it to be a big deal somehow, I clicked and was immediately greeted by fullscreen Stacey-whatever-spam.
Not going to do that again, and I still have no idea what this crap is even after scrolling through a ton of comments to reach yours with a similar experience.
Edit: Now I see on the front page a second link, "Matter – The Foundation for Connected Things (csa-iot.org)" which at least has IoT in the URL. Three whole bytes across two separate front page items doing any work to convey what's going on...
This related article from the same blog, and its comment section, helped me understand the current state of matter and the trajectory of the standard after 1.0. It seems it will take some time to support the full range of typical devices. It’s also unclear what manufacturers will need to do to ease setup and interoperability within their own apps.
> There are 550 members of the CSA participating in the Matter standard development, and this summer 280 companies including Amazon, Signify, Google, SmartThings, and more met up to test their products working together in a series of test events.
Creating a specification is good, but it doesn't matter if no one will implement it. I haven't been following the development of Matter, but as an outsider this is a very good sign.
As an Home Automation consumer, that hates cloud required products
The list of companies in the alliance has given me great pause that it is good thing. It is a who's who of "evil" anti-consumer companies that love vendor and cloud lockin, many of which have been open hostile to projects like Home Assistance which puts the user/consumer in control of their data
I'm excited. But I really have no idea if it will be good or bad.
I'm sure devices will be phoning home, but I can accept that. What worries me is that they might brick themselves if the server goes down. Either intentionally, as a "This device can't get security updates so we won't let you use it" thing, or accidentally, as in "Oops, we never actually tested this feature without internet, sorry the lights are stuck on disco mode till you fix that".
Hopefully nobody will actually rely on direct device to server stuff, and Matter will standardize local versions of everything that might otherwise be done with the server.
And hopefully they don't phone home so much that the whole thing just becomes untrusted by the tech savvy crowd and disappears entirely.
I would have been fine with ZigBee, but if this gets as big as they want it to, the switch will be worth it. I'm still hopeful.
The name is awful though. Couldn't it be WebMatter or something? Can we stop naming things after ungoogleable common words?
"So while Matter makes it possible for Eve, a sensor and device company that historically only worked with Apple’s HomeKit ecosystem, to finally work on Android devices, it also means that Eve’s competitors can work with the same ecosystems while offering cheaper devices that may not cover all of Eve’s cool features such as energy monitoring."
I mean who wants more choice of devices, and cheaper ones at that?
I've been holding off buying any new smart bulbs etc. until this is finally a widespread thing, I just hope manufacturers are quick to get on board.
I have a few wifi bulbs in the house which are ok but you need a special app to use them and I can't see a way to integrate them into Home Assistant as it's some proprietary thing from TP-link ('TAPO') - I'm not making that mistake again!
> ... So while Matter makes it possible for Eve, a sensor and device company that historically only worked with Apple’s HomeKit ecosystem, to finally work on Android devices, it also means that Eve’s competitors can work with the same ecosystems ...
I'm struggling why this is a problem that we don't already mostly have, today. My smart speakers are Alexa devices[0]. I used to have a ridiculously complicated HomeAssistant setup that died when the server that the virtual was running on cratered. And yes, I'm missing some functionality that I had setup, but really -- I can program my thermostat, I can setup complicated routines for lights that are all different brands. When a person is detected on my front porch using my Wyze, my phone alerts me (wyze app), My echo dot notifies me that someone is on my porch, and I'm supposed to be able to make the Show display the feed (haven't bothered). I get that Matter brings to the table "they can talk to one another offline" -- that is a big deal -- my only issue is the idea that Matter introduces new market risks that don't already exist, today.
I buy the smart home product based on the specific need I'm trying to fill and whether or not it works with Alexa, which nearly everything does, so the only part of the ecosystem that I'm locked into is the Alexa side. I can, however, control my devices (a subset of features depending on what the vendor decided to expose) from my Echo Show, Alexa app and "talking to the lady". I say "Ziggy, Goodnight", my Belkin smart plug fires up, my two LIFX lights shut off, my Cree bulb shuts off. At 1:00 AM, my LG and Roku TVs shut off. I set this all up through Alexa routines, not the apps (which were needed to join the device to WiFi and pair with Alexa).
This post seemed more negative than it should be -- I'm not unhappy with Matter -- yes, it's got problems, but it's a good starting point toward "let me use the device from the manufacturer that makes the best one, not the one I'm stuck with because I use Amazon's ecosystem." Only time will tell if we see a myriad of devices that are Matter licensed which "interoperate with one another offline" but I'm hopeful.
[0] It's by accident ... I had a job that involved developing Alexa skills so it was helpful to work with one regularly; the kids liked them, so we bought more.
The best part about this is we finally have some kind of broad certification. Amazon has a similar process, but it is currently in its infancy. The process may not be perfect, but it is now in place, which means it can be augmented. I hope this means the free-for-all of insecure IoT devices starts to diminish.
Are the Bluetooth & WiFi required, or can it be just Matter?
I am all Zigbee currently because Z-wave proprietary nature and some technical limitations.
edit: welp "Matter aims to build a universal IPv6-based communication protocol for smart home devices." time to look for something to replace my zigbees. :/
Matter is higher level than both wifi and Bluetooth, so yeah you will need "something" to communicate over, which will be IP. Thread for example which is sort of zigbee.
What are the implications of Matter on the privacy of my household? Will implementations require me to connect to the "cloud" or send "telemetry" to it, or will I be allowed to run this system completely isolated from the internet?
> Originally, Matter was supposed to handle enough elements of provisioning and functionality so users wouldn’t have to download an app. In most cases, users will still need to do so
I see that the surveillance capitalists got their way.
This kind of response is harmful. Google is not all bad. Orgs are complex entities with a lot of competing interests. Using shit-colored shades exclusively to view anything is too limiting & sad a way to go.
Google is pretty bad, and there’s no way I would buy any Google manufactured device (hunk of e-waste?)
Your point is valid though, there are hundreds of other companies involved in this standard, many of them will make fantastic devices and there’s no reason to ignore them all because of one bad vendor.
If you want software to improve, you need to encourage companies working together on initiatives like this. Both Google and Apple suffer from this lack of communication, and it's led to shitty protocols time-after-time. If we start with Matter, maybe we can break down other arbitrary barriers like iMessage and the App Store/Play Store. Then we don't have to resort to antitrust litigation!
The "one bad vendor" is the gatekeeper for 50% of the mobile device hardware space.
If you take a wild guess and assume that most people will interact with home automation through their handhelds, and 100% of them will when away from home and their house hubs, then that "one bad vendor" could seriously crater the health of the ecosystem.
No, it's a warning. If Google's enthusiasm for this protocol makes or breaks Android compatibility with Matter, what happens when (not if) they walk away?
I don't trust Apple and Amazon to keep the faith either, but Mountain View is the weakest link here.
How many companies are involved in the USB-C debacle? It seems to me like there's many companies involved with different and competing interests, yet nobody is sounding the alarm bell over USB-C 5 Pro Max SuperSpeed 2x2 10G.
Yeah, look at the insanity in Chrome. It is open source but that's just the lip service. I want Google nowhere near my home gadgets. It might play a docile role and then eventually devour the entire project with funds/influence.
Apparently, most people are happy enough with Chrome. If not, it would be relatively easy for a competitor to enter the market with a more attractive offering. And that's only because Chrome (and Firefox) are open source.
I'm sure there are many valid reasons to be critical of Google's business ethics, but keeping an important project like this almost entirely open source surely is not one of them.
Android, on the other hand, is a different case, with Google moving more and more basic functionality into the proprietary Play Services and proprietary apps.
Amazon is influential enough in home automation that it won't happen. Alexa is the most likely home assistant to respond in American homes.
Apple is a long ways behind, but they have enough stubbornness and power to keep their influence in the decision making as well.
Edit: I've been told that this article is the better one so am going to merge the thread hither.