An interview with Stefan Bauer-Schwan, Vice President Research and Development at the smart home manufacturer Eve Systems (link). It’s about the Thread radio protocol. Why cross-manufacturer use in the Matter standard is not yet perfect – and what the ecosystems of Amazon, Apple, Google & Co. have to do with it.
Dies ist die Übersetzung eines deutschen Interviews.
Zum Original bitte hier entlang.
The expectations for the Thread standard are clear. It is supposed to create a common, manufacturer-independent wireless network that devices at home can connect to, similar to Wi-Fi. Currently, however, Border Routers from Amazon, Apple, Google, and others often set up their own thread networks, which compete with each other in the worst case. What’s the reason?
Stefan Bauer-Schwan: This is not the desired condition. On the contrary: The problem has been known for a long time and was already solved in the Thread standard before the Matter standard was released. The reason lies not in the Thread protocol, but in the platforms that are using it. Amazon, Apple, Google & Co. have to agree on how they exchange Thread credentials among each other, in other words the access data to the network. So that new devices can join an existing Thread installation.
Technically, the standard does indeed allow a large shared network to be formed in which Border Routers from different manufacturers complement each other and help each other out, for example if one of them goes offline. It is even physically possible to have several Thread networks in the house, which are then logically combined into one. This can be helpful if there are many floors. Each floor has its own Border Router, but together they form a logical network.
Why don’t all manufacturers take advantage of these opportunities?
Bauer-Schwan: Because we are dealing with two different security mechanisms. On the one hand, there are the network properties of Thread. Similar to Wi-Fi, there is a network name and a password so that the communication is secure. In addition, there is other information such as PAN ID and XPAN ID that describe the Thread network. In Matter, the aim is to exchange these credentials securely between the platforms. However, there is no standardized way to do this so far.
“There is no standardized way to exchange Thread credentials between platforms so far.”
But sometimes it seems to work anyway. Then newly added devices end up in a shared network …
Bauer-Schwan: That’s right. If an installation uses Border Routers from Apple, Google and SmartThings that are set up with an operating system on which all three platforms are visible – meaning iOS – then they all use the same Thread credentials. Simply because Apple stores this data in its keychain and makes it accessible to the other systems.
Android lacks this overarching solution?
Bauer-Schwan: There is also a corresponding solution for Android, but it cannot, of course, access parameters that are exclusively available on an Apple device. As we know, a HomePod can only be administered via iOS, which is why the case described above cannot be transferred to Android.
However, efforts are underway to improve this situation. The operators of the platforms are keeping a low profile in this regard. But I know from many personal conversations that none of them has any interest in allowing the current situation to continue for a long time.
And what are users to do who have already put their devices into operation under Android? Reset them and set them up again?
Bauer-Schwan: There is theoretically the possibility to change the assignment to a Thread network later on. In the Matter standard, this is even mandatory and part of the certification. I can tell a product like Eve Energy – and all other Matter devices – at any time: Here is another network, take this one from now on.
Current apps do not make use of it, which is why we are considering adding this functionality to our Eve app. However, this would have to be solved in such a way that technical details like PAN ID & Co. do not appear at all. The challenge is less in the technical implementation than in the self-explanatory user guidance. Ideally, the app would automatically recognize all end devices in its networks and offer them for transfer on request. Only Border Routers like the Nest Hub would then have to be reset to factory settings and set up again.
“The assignment to a Thread network can be changed later on. Current apps do not make use of this.”
That sounds like a development effort. Currently, the information in the Eve app is rather decreasing. For example, the overview of the Thread network does not show the names of third-party Matter devices..
Bauer-Schwan: This is due to the privacy guidelines of the Matter standard. In HomeKit, it is possible to find out what the name is via Apple’s unencrypted Bonjour protocol. With Matter, you can’t do that anymore because Matter devices on the network don’t have clear names. For good reason, because that way no one can figure out what kind of product it is. Door lock, power socket, smart home hub or window contact, it’s not recognizable to potential attackers – an additional security barrier that obscures possible targets of attack.
Does this mean that the proven network overview from HomeKit days will no longer exist with Matter in the Eve app?
Bauer-Schwan: We have other ways of identifying a Matter device, because the unique node ID of a device is, after all, transmitted by the network. The fact that it hasn’t happened so far is mainly because we can’t do everything at the same time. In the past six months, there has been so much to do that it was impossible in terms of workload. But we’re taking it step by step to get the best possible user experience.
Does it make a difference which Border Router I run my Thread product on? Some manufacturers say that the battery life of sensors can vary depending on the router model.
Bauer-Schwan: If this is the case, the manufacturer has done a bad job. It is true that the platforms request a status report from sensors at different intervals. A controller from Apple, for example, asks every seven seconds whether the end device is still there, Google every two minutes, and the interval is three minutes for SmartThings. However, it is up to the sensor whether it complies with this request. In idle mode, it can just as well report every five minutes. This saves energy.
It’s a different story when I have multiple platforms that want to know alternately, with multiple apps on top of that. If five programs have subscribed to the status of one sensor, it will consume more energy than with one app. In this context, I would like to give a shout out to Apple. They did exactly the right thing with their new HomeKit architecture in iOS 16.3. Since then, the sensor is only connected to one instance in the Apple ecosystem – the active hub. All apps get their status information from this one HomePod or Apple TV. And because the hub is connected to the mains, it doesn’t matter how many apps want to communicate with it over the course of a day.
“If the battery life depends on the platform, the manufacturer has done a bad job.”
Could this point not have been standardized?
Bauer-Schwan: The use of such sleepy end devices, i.e. devices that wake up briefly when needed and otherwise remain asleep, is actually not yet optimally implemented in the current specifications of Matter 1.0 and 1.1. This must and will improve significantly with upcoming versions, think of devices like smoke detectors or wireless pushbuttons with a coin cell.
Is it possible to give a time forecast?
My personal opinion is that we will see progress on both very long runtime battery devices and Thread credential sharing between Matter platforms as early as next year.
What then remains is the topic of operating with multiple platforms. Because these also have a negative impact on the battery life and consume resources in the device. But here, too, efforts have been underway for quite some time to improve the situation. In any case, the criticisms we’ve been discussing today are temporary. They will be solved, and in the interest of the customers.
Mr. Bauer-Schwan, thank you very much for this interview.
“The criticisms we’ve been discussing today are temporary. They will be solved, and in the interest of the customers.”
Share this information:
