Matter - smart home connectivity standard (formerly Project CHIP)

I felt there remained some ambiguity as to whether this only applied to ‘this year’ while the focus is on Matter controllers, or indefinitely.

3 Likes

I suppose if I put my optimistic glasses back on you are correct :slightly_smiling_face:

3 Likes

I was initially quite frustrated with Samsung’s responses and, sans the Zigbee dongle & no Zigbee → Matter bridge, these two points make more sense:

  • Samsung’s already-launched non-Matter-device appliances: not in the Matter spec
  • Samsung’s already-launched non-Matter-device displays: same as Google & Amazon. Just controllers, not devices.

Most interesting to me:

  1. a hint of future Thread support.
  2. confirmation that zwave and zigbee devices will not be exposed to other Matter controllers. Neither will Samsung appliances.

I don’t know if this is new or not, but Tizen has confirmed it’ll support Matter and hinted at Thread:

Supporting latest connectivity standards : Tizen supports novel connectivity standards. The latest Wi-Fi standards like Wi-Fi Aware, Wi-Fi Easy Connect are supported by the platform and it adds support for new standards continuously. Matter and Thread protocols are the next generation IoT protocol for smart home devices. Especially, Tizen will support Matter protocol from the first release (1.0) of the open source matter SDK.

Emphasis mine.

//

Concern #1:

The confirmed lack of a Matter bridge is disappointing, as Philips Hue and Aqara are implementing Zigbee → Matter bridges Perhaps the Z-Wave → Matter bridge requires newer / additional hardware compatible (?) with Silicon Labs Unify SDK, but bridging at least Zigbee would’ve thrown a bone.

//

Concern #2:

I’m also disappointed that Samsung is releasing a Zigbee dongle in 2022 instead of a Zigbee / Thread dongle, which would’ve meant that all these devices could’ve worked seamlessly with any Matter controller.

Even Home Assistant Yellow has confirmed their Zigbee chip will additionally support Thread + Matter, yet Samsung’s dongle is still up in the air.

Notably, I don’t think HA Yellow supports Zigbee + Thread concurrently yet, but Silicon Labs + HA are are considering it. Still, the choice (SmartThings / other Zigbee hubs vs all Matter controllers) would’ve been the progressive choice for Samsung’s dongle.

3 Likes

When weighing how all of this will “benefit the consumer”, consider in the balance how vendor lock-in works with this model as well as product interdiction.

As an example, any popular product will create a market for knock-offs, and every year boatloads of knockoffs are interdicted/destroyed. When trade groups bring up “verified vendor”?

Is their concern about the consumers first and foremost? Not entirely.

And as to the right to repair devices you own?

Without a consumer guarantee of opt-out, the DCL is a license/copyright/etc enforcement tool that limits the rights of consumers.

Your diagram is missing an example of how a device can be “dual-homed”; while only one thread border router can exist on a network, any number of devices can have network interfaces that directly communicate on ethernet/wifi and thread.
For example a Smartthings hub could join a matter network that was commissioned by a Google hub and obviously vice verse. Direct communication between devices in this manner is spelled out in the design of Thread.

FWIW this is something that z-wave networking has been, and does support; Zigbee’s support for this has been more theoretical.

1 Like

Interesting conversation!

1 Like

An interesting article, though having Google talking about the proactive home is not comfortable reading as it isn’t exactly a strong point of their current offerings.

1 Like

Ah, sure: I was more exploring the “why blockchain” angle, but there’s also the “why have an authentication database at all” question.

No disagreement that Matter’s biggest companies are all major proponents of anti-repair scaremongering.

That is an interesting point. The certificates that DCL checks are all in soldered storage, i.e., the DAC & PAI are added there during manufacturing. Storage isn’t necessarily a major failure point in IoT devices, I would say?

From what we know now, DCL only verifies the certificates on the soldered internal storage and no other hardware. You’re thinking there will be trip wires, e.g., replacing the infrared LED on a motion sensor will trigger a “non-certified device” issue? That would be terrible: the e-waste problem would only multiply.

All Matter devices will be shipped with a unique Device Attestation Certificate (DAC). This certificate guards you against fakes: You can say with confidence the device comes from the brand on its box. This device identity authentication comes from the certificate chain of the DAC.

The DAC is signed by the Product Attestation Intermediate (PAI) certificate. This certificate will be typically held by the device manufacturers. …

The DAC and the PAI is burnt to the persistent storage of the device during manufacturing.

//

I do think the DCL’s general theme of trusted vendors (e.g., not commenting DCL as a blockchain here) was definitely designed with vendors also in mind: protect their upfront costs, support, brand, etc. Having the verification at the last step (e.g., commissioning) is sort of a “final check” against MITM / rogue manufacturers.

On the flip side, if the attestation is beyond just storge, having an opt-out is important: to tinker, repair, salvage, etc. But it’d be a terrible decision by the CSA to tie authentication beyond the storage: locking down $30 light switches full set of hardware components sounds both difficult and like a bad idea.

Ah, yes: that’s discussed in Espressif’s article. The initial question was posed that if a user only owns SmartThings devices (none which support Thread, but will claim Matter support only as controllers at best) and then that user buys a Matter device based on Thread, that consumer will now need to purchase additional hardware, even though it’s all “Matter”.

That is, if people buy Matter device that are only Thread Full End Devices (instead of Border Routers or REEDs), then those devices will stay stuck in the Thread side of Matter without any interface to the Wi-Fi side.

In short, how Matter explains Thread border routers & their importance will be crucial: it’s not necessarily intuitive. More a consumer pain point than a technical limitation.

1 Like

Google has released a good bit of preview docs + tools for Matter at Google I/O. A few notes:

Zwave is harder than the others because most implementations are NOT IP-based.

It’s not impossible, but it means more work for the bridge device to build out proxy addresses for each device.

1 Like

Still, has a list of support devices, but it’s missing a few

No sensors other than thermostats?

1 Like

Still waiting to see that first zwave to Matter bridge announced…

2 Likes

No sensors other than thermostats?.

According to The Verge, sensors are / were part of Matter 1.0. Google’s list is a bit shorter than The Verge shared for Matter 1.0,

  • Lightbulbs, light switches, lighting controllers (Google, too)
  • Plugs and outlets (Google, too)
  • Door locks (Google, too)
  • Thermostats and other HVAC controllers (mini-splits etc.) (Google, too)
  • Blinds and shades (Google, too)
  • Home security sensors (motion, contact, CO / smoke detectors)
  • Garage door controllers
  • Wireless Access Point and bridges
  • Televisions and streaming video players (Google, too)

Mostly there, but also light:

  • Home security sensors: not even listed. Can’t explain why. However, Google’s support for sensors has been rather lacking even before Matter, but they are a proper device type in Google Home now.

  • Garage doors: maybe under locks?

  • Wireless access points: TBH, I don’t quite understand how you’d commission a Wi-Fi router. Maybe once they’re commissioned as controllers, they also become devices, like auto-reboot automations?

  • Fans: Huh, surprise inclusion. Not in The Verge’s list. Maybe part of HVAC? Or light bulbs / light switches?

Unusual omissions, though: Google sells & already supports in Google Home sensors, smoke detectors, and wireless access points. Surely these devices should be supported in Google Home’s Matter implementation.

1 Like

Pretty sure it’s going to work just like HomeKit. They will be listed as bridges and you’ll be able to tell what, if any, child devices they are bringing in with them, but you can’t do anything with the bridge itself except add it or remove it.

SmartThings has released early access to some select brands to their Matter implementation

Aqara and eve. jump out at me in particular since they have never offered official SmartThings support. Others either currently offer Thread products (eve., netatmo, nanoleaf, wemo) or have announced future Thread products (Aqara, sengled) so I’m curious to see if those will pair directly to SmartThings or need to go through a Matter compliant border router.

3 Likes
1 Like

Just curious does Matter mean we have to use a stock driver?

For example Nanoleaf has very basic integration in the ST, just a color bulb profile.
While the Nanoleaf application and API provides much more features

the same is going to happen with other manufacturers, they can implement basic on/off profile and put all the colorful stickers on their boxes (Works with Smartthings, Matter … )

1 Like