There are still a lot of unknowns with regard to the new Matter interoperability standard, but we have a much better sense of what we don’t know in the wake of a panel hosted this week by Silicon Labs. During the event, which I moderated (and was paid by Silicon Labs to both create and moderate), we heard from product developers about their concerns. We also received some new information from Michelle Mindala-Freeman, head of marketing for the Connectivity Standards Alliance (CSA), which was formerly known as the Zigbee Alliance and which oversees the Matter protocol.
I am not snarking about our lack of knowledge. There is real value in seeing where the limits of the current standard are and what we still need to build before Matter-certified products hit the market at the end of the year (or even more likely, in early next year). I was impressed at how open the panelists were with their concerns over the number of certifications they might need, the speed of the certification process, how Matter might affect their product strategies, and whether or not it will “drive a wedge between products and the ecosystem providers,” as Wyze’s Senior Director of Technology and Services Frederik Delacourt suggested.
Certifications
Let’s start with what we know about certifications, in particular the certification process. Mindala-Freeman said that so far about 30 devices have gone through testing events, which were focused on testing individual devices for compliance. But the next testing event will focus on testing devices as part of a cluster of Matter products, with a goal of producing a published standard by the end of this year.
What we don’t know on the certification front is whether a developer will still need to get certifications for their devices in addition to the one they get from Matter. If you have a Matter device that uses Thread, you may need a Thread certification and a Matter certification. Indeed, Frederik Delacourt, senior director of technology and services at Wyze, said that right now some ecosystem players (by which he means Amazon, Apple, and Google) still want to get products certified for their ecosystems even if they are Matter-compliant. “The message we’re getting is for the moment they don’t know exactly what it means to have Matter compliance, so they are still maintaining some of their position in terms of certification,” he said. “And over time we think they will adjust their programs.”
Apple this week said Matter-certified devices will work with HomeKit, so Delacourt’s fears about needing ecosystem certifications may be addressed sooner rather than later. Mindala-Freeman also added that the CSA is working with other standards organizations to help reduce the certification load. “A lot of these finer points are still in discussion,” she said. “The goal is simple. The goal is to make it as easy as possible, to not duplicate efforts, and to try to keep costs down.”
Security
We also got more details on the security practices enshrined within Matter. Mindala-Freeman discussed the distributed ledger and clarified that because the devices will have encryption, people getting onto your Wi-Fi network will neither have the ability to see which devices are on the network nor what they talk to. But that will add complexity for developers, said Nathan Dyck, a product manager with Nanoleaf. He said that building devices and getting them on the distributed ledger will take work.
His points were underscored by Johan Pedersen, product marketing manager from Silicon Labs, who said that device makers will have to learn how to take advantage of silicon improvements — such as secure vaults — and figure out how to manage the certificates associated with Matter’s security needs. We also covered how Matter will handle over-the-air security updates, which remains unclear.
The Multi-Admin Feature
Now for the things that we don’t yet know. Many of the biggest questions about Matter are around the multi-admin feature. By promising a common data model for devices to talk to each other, Matter will let companies address and control devices made by other vendors. That means many popular smart home devices — such as lights, locks, blinds, TVs, HVAC systems, security sensors, and controllers — will work across multiple ecosystems (the multi-admin feature). It also means that consumers should be able to take a Matter-certified light bulb and control it from both Amazon and Google.
But we don’t know how, exactly, that is going to work. Dyck from Nanoleaf said that yes, one device will be able to talk to all ecosystems, but “how all of the flows that go in between them, a lot of that is being fleshed out.” Nor do we know if Matter-compliant devices will work as part of a service or network with non-Matter-compliant devices.
This may seem academic, but for something like a home security monitoring service that relies on cameras, it’s a big deal. Cameras aren’t covered under the current Matter specifications, and won’t be for some time. Wyze’s Delacourt, which makes cameras and offers a security service, said, “There is no way you can bring…a device that’s not defined by Matter into a Matter network. That’s not going to work.”
If that turns out to be the case, it could leave consumers with bifurcated networks and developers wondering how to adopt Matter and keep some of their services in the short term.
The future of Zigbee and Z-Wave
One thing I did take away from this event is that Zigbee devices, especially newer ones, will likely get an update that brings them into Matter compliance. Jim Kitchen, VP of product management at Comcast, is confident its existing smart home infrastructure, which is already in its customers’ homes, will be upgraded via a software update. He also said it will be easier to update to Matter because Comcast is built on top of the 802.4.15 radio standard that Zigbee and Thread use.
I asked Pederson if Silicon Labs was planning a chip to help bridge Z-Wave and Matter (it already offers one to bridge Zigbee and Matter). His reply? “For Z-Wave, we have exciting things coming both on the silicon side but also for the bridging capability, because being able to bridge between Z-Wave and Matter will be important.”
However, Mark Jenner, director of technology alliances at Allegion, expressed doubt that all of his company’s locks would be updated or even updateable. So I expect we’ll see some stranded devices in the Z-Wave and Zigbee camps.
In conclusion, for all that we’ve learned so far this year about Matter, it’s clear that a project this ambitious will need some time to get everything together and deliver a specification that will tell us what we want to know. Namely, how will Matter help us clean up the mess that is the smart home today?
My top 10 questions…
1) definitions for cameras, smart speakers, tv sticks and multi-room audio. Will the big three (Apple/Amazon/Google) conveniently never get around to defining these? Hint, you could wrap ONVIF in a Matter proxy with a few weeks work.
2) A demo of Google/Amazon/Apple managing Matter devices in their platforms
3) Multi-admin. Can a device maker ship a device without an app and entirely manage it via Coogle/AmazonApple?
4) Blockchain and certification chain of trust. Is encryption going to be used to lock open source out of Matter? For example the source code for Chromecast is available, but it is useless because Google won’t give you an encryption key to participate in the ecosystem.
5) Bluetooth. Bluetooth mesh has been shipping for a couple years now and most Matter devices have a Bluetooth radio. Why is the existing Bluetooth mesh not proxied into the Matter world?
6) How can individual consultants participate?
7) Shadow proxies. Say a battery powered temp sensor only sends a reading once an hour. Now you log in five minutes after it sent that value. How do you know what the temperature is? Personally I think all intermittently connected battery devices should be proxied as a continuously connected device. There should be a defined type: shadow proxy, that always exists in front of the battery powered devices.
8) Where are the Amazon people? I don’t see anything from them in the commit logs. Is Amazon really backing this or did they join just so their marketing people can track the developments?
9) One stop shopping for software certifications, or even better, pre-certified code blocks from chip vendors. Don’t make a light bulb manufacturer who took code from a chip maker and modified 100 lines of it to drive LEDs, and then put it into 50 different housings and configurations – certify 50 different products. Consider that they will have no clue if you tell them they failed, it is the chip manufacturer that wrote the code.
10) Define an industry standard multi-room audio protocol that can survive patent attacks.
I like your idea of including a shadow proxy for sleepy devices. I’d like it even more if it could also function as a virtual device, which would allow an interface to some nonMatter systems much as virtual/dummy devices do now for IFTTT, SmartThings, and HomeKit (via Homebridge).
On other topics, I can point to the probable answer for 5, about Bluetooth mesh: both Zigbee and Thread scale up more efficiently than Bluetooth mesh in terms of both number of devices and number of messages.
See the comments section for the May 8 article from this site, “Why not Bluetooth instead of Thread?” I included links to some technical references on this issue there.
https://staceyoniot.com/why-not-bluetooth-in-the-smart-home-instead-of-thread/
The Thread people look at Thread as having a single border router and then the mesh forms and spans the entire structure. And you are correct in saying that Thread is better for that.
Consider another model. Say you have a smart light switch in each room. That light switch is mains powered (doesn’t have to be a light switch, anything mains powered works). That mains powered device has a BLE radio in it so that it can be configured via a phone.
Now put various BLE sensors into the room. Say a temp sensor, a motion sensor, maybe a door/window contact sensor. Those devices implement the BLE mesh protocol. Now form a zero hop mesh directly to the mains powered device. Proxy the battery powered BLE devices there. This also works for BLE light bulbs that are in mass production. The BLE lights in the room can directly connect to the Matter proxy, or they can mesh to the proxy.
The fundamental difference, the Thread people want the mesh to span the entire structure and have a single border router. I would rather have tiny, zero hop BLE networks in each room with Matter proxies implemented in the mains powered devices. In the BLE model there is no border router, just the standard BLE mesh GATT proxy running in the mains powered device. And then the Matter proxy interacts with the standard GATT proxy.
I forgot to mention that the main powered devices are on wifi and they are first class IP network devices.
One issue with making a home automation system WiFi-dependent is an issue that engineers designing for mass market products are usually very aware of, but people with a strong technical background looking at systems for their own home may not be as familiar with. This is the device limits on Wi-Fi systems in budget setups.
One of the primary reasons that lighting manufacturers first chose zigbee as their most popular protocol was that it could easily handle hundreds or even thousands of end devices.
Most residential Wi-Fi routers have a hard limit of 255 Devices, which sounds pretty good, but the inexpensive routers, the ones you get for less than $100, are commonly much lower than that. For example, many Linksys router models ship with a default max of 50.
And budget Internet plans often limit the number of concurrent WiFi connections you can have to around 10. This is less for technical or engineering design reasons than it is to give customers a motivation to move up to the more expensive plans. But it’s real.
If you want to put a Wi-Fi switch in every room just to enable a Bluetooth mesh network with zero hops, you’re going to put a pretty big dent in some of those device caps. A typical US three-bedroom house now has about 15 room spaces not counting front and backyard.
If you yourself have a high-quality router and a gig speed Internet plan, you’re probably allowed at least 255 Wi-Fi devices and you may even be able to get around that with a private LAN.
But your typical Amazon shopper is likely to be in a very different situation. And the design engineers are aware of that.
Sure, but then you are requiring that mains powered Bluetooth/WiFi switch in every room. And many mass market consumers aren’t buying anything that requires wiring.
The existing home automation organizations, including CSA and Samsung SmartThings, have years of data on this. SmartThings staff have said publicly that their typical consumer has 15 or fewer smart devices, mostly light bulbs, smart plugs, and battery operated sensors.
Even video doorbells had to offer battery powered options to gain market acceptance.
For professionally installed systems like Control 4 or Crestron then, sure, the master device in every room might make sense. But your typical Alexa or Google Assistant user doesn’t start out with the idea of replacing a light switch in every room that has a window sensor. That would add cost, complexity, and customer resistance.
Look at Wyze, who participated in this panel. They don’t even make a light switch.
And there are still the technical issues of triangular routing and native ipv6 support.
So can Bluetooth Mesh be made matter-compliant? Probably, with the addition of more devices, more cost, and more complexity. But it looks like Thread still makes more sense as the featured low power protocol aimed at the typical Echo owner who is complaining to Amazon because they can’t tell which devices work together.
We’ll see what the market ends up favoring.
Do you think that Thread mesh going to work without mains power? No way you are making a whole house mesh without AC power at most of the nodes. Protocol does not matter.
If you don’t want to wire a light switch in, you can use a smart speaker or a plug-in outlet. You could even build the wifi-BLE proxy into a lightbulb. Maybe a camera. Lots of places to put it. And all of those devices already have BLE radios and not 802.15.4. The basic difference in concept — lot’s of little BLE meshes vs a large 802.15.4 one.
I have a decade of experience designing with both BLE and 802.15.4. And I used to be a big 802.15.4 supporter. I’m the person who first added 802.15.4 support to the Linux kernel. But I’ve switched over the years to believing that BLE is the better solution for a few simple reasons. 1) it is in every phone 2) because of phones most wifi modules have BLE 3) standalone BLE chips are dirt cheap. and 4) we don’t need yet another PHY layer.
Sorry, but what does the internet connection have to do with how many devices can be connected to your router?
That’s a very odd connection to make.
However, you are correct that not all routers can handle an infinite amount of devices on Wi-Fi and this is mainly due to the wireless chips and the computation power of the router, not a limit of the Wi-Fi protocol or internet connection. Your 255 limit seems to be a confusion of IP address ranges, as you’d have to use multiple IP address ranges to connect more than 255 devices to any single IPv4 network, as that’s how the standard is designed to work. It’s not a huge problem for most home users though.
Personally I have three Wi-Fi AP’s in my home, the main router and one AP on each floor, as although I live in a small house, it has three floor and is built out of metal and concrete which means poor Wi-Fi signal between the floors. As such, I spread the load of the Wi-Fi devices between three AP’s, which makes your point quite moot. Anyone with a large-ish home, would have more than one Wi-Fi AP in their home.
As more and more people are buying into mesh based Wi-Fi setups, they’re bypassing this issue as well.
I also don’t think you understood what Jon was suggesting here based on your answers.
It wouldn’t be particularly costly to make a small Bluetooth to Wi-Fi bridge or Ethernet bridge for that matter, although I personally don’t believe Bluetooth is the correct standard to use for most home automation devices, mostly because their home automation focus has been lacking and that’s putting it nicely. There are not enough device classes when it comes to Bluetooth today to make it a good replacement for already existing standards, but Bluetooth is familiar to consumers and they buy Bluetooth based devices based on that familiarity.
What I would like to see is a standard that includes Bluetooth as it does make sense for certain things and it shouldn’t be excluded just because.
As always, you have a lot of interesting questions.
Having attended a few of these standards discussion meetings in the past, I don’t have a high hope for this new addition, as the Open Connectivity Foundation has been working on something similar for years now and all they seem to do is agree to disagree on how things should be implemented.
It’s four or five years since I attended one of their meetings last and they don’t seem to have made any major progress since then, as it’s still very much a draft specification.
Hopefully matter won’t take that long to matterilase (pun intended), but you have some very obvious points that a lot of these big and small tech companies seem to be missing.
The most obvious one of course is Bluetooth, even though I would say that the mesh implementation pre 5.2 is pretty poor, it should still be a standard that should be included, especially as it is such a big part of Apple’s ecosystem if nothing else.
As to weather you can participate or not, well, snipped from Wikipedia “Although the Matter code repository is open-source under Apache license, the Matter specification is licensed by CSA.”
I very much doubt we’ll see pre-certified code, you know as well as I do that this isn’t how these companies work. They make hardware and provide the bare minimum code and then send you on your way with their best wishes. It would make it far too easy for anyone to join this little community, something they seemingly don’t want, regardless of what they say publicly. If they wanted more companies to get involved, they would lower the barriers, instead of raising them.
I’m very much a pessimist when it comes to this stuff, regardless how much I would love to see it succeed, as I’ve been working in the business for close to a decade now and very little has changed. We were supposed to have $10 sensors by now and that didn’t happen, unless you count IKEA’s range of products, but no-one else seems to be there as yet.
3) Yes, a device maker can ship a device without an App. The best indication of this is the Apple Developer video on integrating matter into HomeKit where they explicitly talk about this. https://developer.apple.com/videos/play/wwdc2021/10298/
4) Matter uses BLE only for initial connection to the network. I think they believe that Thread is superior to BLE.
7) Using Thread, there are various concepts of end devices depending on, basically, how much power you want to use. One version is that, using your example, the temperature changes it then sends a signal through the Thread Mesh. That is, it is push, not pull.So if you log in after the last update, that is what the temperature is. If the temp changes, teh sensor wills end another update.
Understood, and you’re right that there are other device options. But the primary consumer market isn’t people who want to do their whole house. It’s people who want 6 to 8 battery powered sensors, a smart speaker, a smart thermostat, and some smart lighting but not a lot, maybe some LED strips or color changing bulbs. And porch lights that come on when they get home.
I think it’s pretty clear that the smart speakers are likely to be the thread border routers: Apple HomePod mini already is, and it looks like Amazon is planning to do that for Echo. And Google for the nest home hub.
It might be interesting to look at Eve’s reasons for switching away from Bluetooth to Thread for their HomeKit devices since they have live field experience.
https://www.evehome.com/en/blog/discover-your-thread-network
I heard one discussion from them where they said that on a practical basis they were very excited about thread’s dynamic routing as the network gets busier, something that Bluetooth doesn’t offer. Thread even has this weird bumblebee dance where it switches from having one partition to multiple partitions back to one partition again As network traffic rises and falls. It’s really cool to watch and again, based on reports from companies like eve, has real world impact in terms of QOS for perceived device reliability.
I may be mistaken on this next part, but my understanding is that the original project chip mission statement was limited to protocols with native IPv6 support, plus zigbee which promised that it could offer that when needed.
But again, we’ll see what plays well in the marketplace. Maybe two years from now a lot of Matter devices will be using Bluetooth mesh, there’s nothing to prevent that if it turns out to have high consumer acceptance.
Wifi routers do not have a 255 device limit. That is simply because the come configured with an address of 192.168.0.1 and a NETMASK of 255.255.255.0. All routers shipped by cable companies in the last six or seven years are configured with 10.0.0.0 and a NETMASK of 255.0.0.0 so 16M devices. I am not certain how currently shipping routers come configured.
You can go into your router UI and change it from 192.168.0.1 NETMASK 255.255.255.0 to 192.168.0.1 NETMAST 255.255.0.0 if you want and you can have 65,000 devices.
We had this discussion on a previous thread, but I’m not sure if you saw the reply.
Just because you can enter a higher address does not mean that the router will support more device connections. Many routers designed for residential use, particularly the lower cost ones, have a hard limit. You can ask the router manufacturers about their limits.
For example, the popular linksys Model: WRT1200AC device has a hard limit of 32 devices, regardless of what their address is.
As one of my network engineering professors once said “Renumbering the addresses doesn’t make the street longer.“ two separate issues.
Submitted with respect.
Just for fun, go try an debug a mesh network that is having intermittent connection problems. They are almost impossible to debug. We once had one that kept failing until we figured out that an elevator was passing though a weak mesh connection causing it to sporadically break and split the net into two pieces.
LOL! Love the elevator example.
I was a field tech for a number of years, so I understand exactly the issues you’re talking about. My favorite is always cars in the garage versus cars not in the garage. As in if you want me to diagnose an intermittent problem and you call me in in the middle of the day, you better let me park the same number of cars in the garage as you have at night. or diagnosis will be fruitless.
By the way, the split into two pieces is exactly the thing I was talking about with the bumblebee dance for Thread. They have a built-in mechanism for that situation. The partition will break itself into multiple partitions as long as there is a border router on each side.
I’m not up-to-date on all the new stuff that’s being deployed in limited installations, but I don’t know of another widely adopted consumer mesh network that does that in real time.
Of course your zero hop configuration With a Wi-Fi bridge device in each room would have the same effective result, but I think would require more devices to accomplish it.
The zero hop model is far easier for a consumer to debug. The wifi nodes are zero hop to the router. They either connect or they don’t. And then the BLE nodes are zero hop to the wifi nodes, same binary relationship — connect or not. Easy to debug.
Mesh == need a PhD and RF sniffers to debug.
What’s frustrating with say Z-Wave as an example, is that there is a tool just to find issues like this, but the Z-Wave Alliance doesn’t allow consumers access to it. I guess this is in part because their members want this to be a “secret” that only their engineers are allowed to use so they can turn up and charge money for fixing problems like this.’
I have admittedly not seen similar tools for ZigBee, but I would guess there must be similar tools for other standards.
Zwave changed a couple of years ago after SI Labs bought it and opened everything up much more. They published the specification and are well on their way to becoming an open standard.
Anyone can now buy the diagnostic tool you mentioned. It’s intended for professional installers so it’s not cheap, but it’s often on sale for $150 at
https://www.zwaveproducts.com/products/zwp-tbx-z-wave-toolbox
This is a self-contained system consisting of hardware with the diagnostic software installed.
Read the docs there to see what reports you can get, but it’s quite useful if you understand how a mesh network functions.
As far as Zigbee, I don’t know of a similar all-in-one product but you can at least map the routes with Digi’s XCTU software. Hopefully you already get RSSI and LQI from your primary coordinator.
And the official Zwave Alliance announcement on the shift in Zwave to a more open standard:
https://z-wavealliance.org/z-wave-specification
If you watch the Apple Developer video at around 5:45 it suggests that there is no extra Apple certification. Indeed, if you watch teh video, they talk about recognising Matter QR codes as equal to HAP QR codes.
https://developer.apple.com/videos/play/wwdc2021/10298/
Quite a detailed example is given from around 08:15
Later on still, you will see a discussion on multi-admin
Hell, Amazon can’t even seem to make Ring and Blink work together…