Investigate protocol: matter

[krwq]

Investigate support for Matter:

• figure out what's required to support this
• idea of how much work that is
• do we need any refactoring?
• do we need to support all versions or just one? What does market currently support?
• does nano framework support it? if not we should consider making it easy to port

More info: https://csa-iot.org/all-solutions/matter/

[krwq]

[Triage] Marking investigation as pri-1, work itself is not critical for release though but protocol is part of our roadmap

[krwq]

Adding links from yesterday triage meeting:

• https://github.com/project-chip/matter.js
• https://github.com/project-chip/connectedhomeip/tree/master/src/controller/python

[kevinchalet]

Wooo, Matter support would be awesome! ❤️

Not sure if it's something you're considering supporting, but being able to expose "virtual" Matter devices from .NET would be insanely useful to create Matter/[other protocol] bridges (i.e like Matterbridge... but in .NET 😄). It's definitely something I'd use myself!

[krwq]

@kevinchalet we'd really love to have it, so far after initial investigation we're a little overwhelmed with number of docs. We're definitely going to be doing some more investigation as this has been one of our two main subjects recently.

Please let us know if you're interested in helping - we can help kick this off.

I think it might be easier to go the other way though - start with reading existing devices so that we can play around and understand the protocol better and once we do that we will already have testing in place so it will much more solid start. We already do have https://github.com/dotnet/iot/tree/main/src/devices/System.Device.Model so we might be able to generate some code for devices once we have infrastructure in place (possibly some modifications will be needed).

Here are some more links:
https://developers.home.google.com/matter/primer/device-data-model

[kevinchalet]

@kevinchalet we'd really love to have it, so far after initial investigation we're a little overwhelmed with number of docs. We're definitely going to be doing some more investigation as this has been one of our two main subjects recently.

Yeah, the Matter stack is absolutely massive (some people think that just because Matter is built on top of IP means that it's as easy as sending some simple HTTP w/ JSON requests but it's absolutely not that at all 😅)

I think it might be easier to go the other way though - start with reading existing devices so that we can play around and understand the protocol better and once we do that we will already have testing in place so it will much more solid start. We already do have https://github.com/dotnet/iot/tree/main/src/devices/System.Device.Model so we might be able to generate some code for devices once we have infrastructure in place (possibly some modifications will be needed).

Makes total sense: the Matter stack has so many aspects to cover that even implementing a "Matter client" MVP is going to require a massive design stage and a lot of energy.

You mentioned the data model - which is largely inspired by Zigbee's ZCL model, BTW - but it's likely not going to be the most complicated part: there are of course lots of clusters to cover if you want to have complete device support - specially if you want to include the new clusters introduced in Matter 1.2 and 1.3 - but it's more time-consuming than difficult.

I'd say the most complicated aspects of Matter are the security (session establishment, message confidentiality, replay detection/prevention, etc.) and transport parts (some Matter devices support TCP but low-power devices often don't and use Matter's Message Reliability Protocol - built on top of UDP - instead). It's likely out-of-scope for now, but device commissioning is also an important aspect that involves a lot of protocols.

All of this is fairly complicated, which is why many projects generally prefer implementing something on top of matter.js (or using a silicon-vendor-specific SDK): .NET having "native" support for Matter will surely make it an almost unique offering on the market 🤯

Please let us know if you're interested in helping - we can help kick this off.

As much as I'd love to (I'm an absolute home automation fan and Matter is definitely the new guy in town!), this will require a massive initial design phase that only a dedicated team will be able to do efficiently. I'm sure there will be great opportunities to contribute a bit more efficiently later 😃

/cc @dotMorten (IIRC, you mentioned last year that you were building something around Matter?).

[kevinchalet]

I don't see it listed in the OP, but the Matter 1.0 core specification is probably one of the best sources to learn more about the protocol: https://csa-iot.org/wp-content/uploads/2022/11/22-27349-001_Matter-1.0-Core-Specification.pdf (paracetamol highly recommended! 🤣)

[dotMorten]

@kevinchalet I was trying yes, but gave up. The protocol is too complicated and doc too lacking. The better approach would be to get someone to build the Matter libraries for Windows and we write a .NET wrapper for the C-API.

[raffaeler]

@dotMorten Windows is definitely not a viable solution because most of the people use Linux on these boards.
My personal perspective:

• Given the overcomplicated Bluetooth Windows API, which still result in a poor user experience, I am not enthusiast to have a similar experience with Matter.
• Hopefully the implementation should be shared (at least a part of it) with NanoFramework

I believe that, given the complexity of the Matter protocol, we should look at this implementation from a different perspective.
My point is to identify the top use-cases for Matter in our library and try to define a new library that provides an efficient solution to those use-cases while leaving some open doors to a more complete future implementation.

For example, during the triage I suggested the idea to create a generic HomeAssistant integration that can be used from any device running our library. With the adoption of Matter this could be far easier than defining a custom protocol. I believe this scenario restricts the amount of work while providing great value.

[dotMorten]

Windows is definitely not a viable solution

Are you saying that having an app on Windows that controls your matter devices is not viable?
For those of you that want to run on IoT devices, just use the Matter SDK as is. The same C# bindings I'm advocating for would work with those native runtimes too.

[raffaeler]

I am saying that Windows IoT is (no more) a viable solution to run directly an app or a device/sensor on a small board. In this case, the great majority of people doing IoT uses Linux and therefore a Windows-based library would not provide the expected value.
If you know any existing Linux implementation for Linux in C or .NET (Core), it would be more than welcome a link so that we can just integrate it.

If you instead are suggesting to leave a Windows destkop machine turned on 24/7 to act as a bridge. In my opinion this is also a no-go because because of the consumed energy, the hardware cost and Windows Updates longer reboots.

Just to clarify what I mean, nowadays the de-facto standard to control home devices are Home Assistant and the Alexa/Google assistants. The Matter protocol is supported by all of them and is (another) good way to interface those assistants to other appliances and devices. In my opinion we should look at theses use-cases with the simplest possible software and hardware.

[dotMorten]

I think you're misunderstand the Windows scenario. The Windows side of things is mainly for client applications wanting to control the devices, and secondary for simulating test devices (like we did extensively in the AllJoyn days).
There are plenty of examples of taking an android/linux .SO as well as a Windows DLL and even an iOS XCFramework and accessing the same C-API they all expose from C# via p/invoke. The work on the .NET side of things is the same for all of them.

Nowadays the de-facto standard to control home devices are Home Assistant and the Alexa/Google assistants.

Disagree and those are very limited in capability. The defacto is the proprietary 3rd party apps that come with each of the devices (which granted Matter is hoping to solve). What I want is a 3rd party app to control them all. In addition if you are building for a device, for fast inner dev-loop it's much easier to build these on Windows first during the prototyping stage.

Or maybe I do want my Windows PC to emit some sort of matter information, so I can automate turning it off at night.

[raffaeler]

I would say we are talking about totally different things.
The dotnet/iot realm is a library controlling devices through bindings (drivers).
Most of the users who adopted this library created an app that runs on a Linux board. The most popular board is of course the Raspberry PI.
I strongly believe that, whatever solution we find, it should prioritize Linux because our users are there. Should we find a solution that runs cross-platform, it would be, of course, very welcome,
For example, the new camera binding I created to take advantage of the new LibCamera features is a Linux-only solution as its library and tools exist only on Linux.

Said that, I repeat that we should first find the most popular use-cases and only after having identified those scenarios it makes sense to decide the nature of the solution.

Disagree and those are very limited in capability. The defacto is the proprietary 3rd party apps that come with each of the devices (which granted Matter is hoping to solve). What I want is a 3rd party app to control them all.

We indeed disagree. You may not like the architecture of HA and Alexa/Google assistant but the market is there and they have a huge ecosystem of compliant devices. The chinese stand-alone devices with their proprietary app have a large market but they can only work alone unless you hack the protocol (as I did for some of them) and make your own integration. I would not enter in this field as it is like fighting the windmills.

What I want is a 3rd party app to control them all

This is what HA is for. And it does not just "control" but it orchestrate them which is far more powerful.

In addition if you are building for a device, for fast inner dev-loop it's much easier to build these on Windows first during the prototyping stage

My experience on Ubuntu during the last year is very different, especially in compiling time cycles.

Or maybe I do want my Windows PC to emit some sort of matter information, so I can automate turning it off at night.

Nice plus, but in this case we should at least consider the Mac (if not Ubuntu) that nowadays is used from many developers, including many Microsoft devs. We need to find a cross-platform implementation.

But let's go back to the main topic please.
Any suggestion that makes our users happy and allows to start covering the common use-cases with Matter would be welcome.

[dotMorten]

You may not like the architecture of HA

I have home assistant and happy with it. But it's not a mass consumer product, but only for people who like to tinker and write yaml (ie people like us).

Nice plus, but in this case we should at least consider the Mac

The approach I propose also works great on mac. Writing a C-API wrapper for .NET is the best way to go, even if we don't get a windows-version of the matter library.
It also has the added benefit of not having to try and keep up with Matter, but just reuse what they already built.

[raffaeler]

I have home assistant and happy with it. But it's not a mass consumer product, but only for people who like to tinker and write yaml (ie people like us).

They are anyway (together with Alexa/Google) the most popular home automation solutions. We should just look at that.

The approach I propose also works great on mac.

I don't get how. You previously said: "The better approach would be to get someone to build the Matter libraries for Windows and we write a .NET wrapper for the C-API". And this could only work (by definition) on Windows.

It also has the added benefit of not having to try and keep up with Matter, but just reuse what they already built.

I don't get if you are talking about a real library or a something new that still need to be written.
Also, if it runs on a Mac it should be even easier to run it on Linux which should be our primary choice for the OS.

Assuming that Linux or cross-platform library for matter already exists, and that that someone should write the code, it would more desirable to write C# directly. And given that specs are too large, let's address only the scenarios that make sense for the majority of our users (users of the dotnet/iot library). This could run everywhere, probably even on NanoFramework which would be a great plus.

[dotMorten]

Matter already builds as a library. We just need to call into it. What is missing is a C# wrapper for that native C library. It's a write once, run everywhere where there's a native build of matter available (which currently excludes Windows).

[raffaeler]

If it runs on Linux it is important info. Could you please provide the link?
We have to verify that it is a C library and not C++ because of the ABI issues.

We already had this problem with LibCamera. I could not write a C# wrapper for LibCamera because the versioning of the C++ ABI could become a nightmare.

Said that, I don't get what you meant in your first sentence about a Windows only solution.

[krwq]

I'd imagine that we'd want to implement i.e. JSON over TCP/IP if it's not too hard but if it involves a lot of work then calling into C-wrapper sounds good to me (although I cannot see why it would be super complex). For i.e. zigbee/BTLE or other things we'd probably want wrappers and only implement common layer in .NET but can't tell to any details because haven't investigated.

I personally find the docs for matter a bit cumbersome - I'd prefer at least one page showed example communication. I.e. if you look at the hardware devices they always have something like this and it makes it much easier to reason about the protocol. For matter it's 800 pages and it's not clear where to start to read (that's just core 1.0)

[MarcusWichelmann]

Being able to expose matter devices from .Net code would be awesome. Maybe there is a more manual, but easier to implement (than e.g. BLE) commissioning method for the beginning?

In my case, the use case would be to expose all my lights and blinds through matter, since my home automation is entirely written in C#.

What do you think, how big would be the minimal subset of the protocol that needs to be implemented to make a device controllable through Homekit/Google Home with TCP only and maybe a more tedious commissioning?