- C++ 50.5%
- Python 17.6%
- Kotlin 9.6%
- Java 8.5%
- Objective-C 5.3%
- Other 8.3%
3a300777e1* [jf-admin] Split Linux example into shared jfa-common + Linux-specific layer
OS-agnostic Joint Fabric Administrator logic now lives in
examples/jf-admin-app/jfa-common/, and examples/jf-admin-app/linux/
Shared layer: examples/jf-admin-app/jfa-common/
- include/JFAPlatform.h: new platform-hook interface (JFAInitCommissioner,
JFAGetDeviceCommissioner). Shared code never includes CommissionerMain.h.
- include/JFARpc.h: moved from linux/.
- include/JFADatastoreSync.h: moved from linux/.
- src/JFADatastoreSync.cpp: moved from linux/. Internal rewiring;
- include/JFAManagerBase.h + src/JFAManagerBase.cpp: moved from linux/JFAManager.{h,cpp}
and renamed class to JFAManagerBase. Members are now protected so a subclass
can access shared state. New virtual extension points for future platform
ports (default implementations keep the Linux example behavior unchanged).
The OnConnectedAction enum reserves kFirstPlatformAction = 32 for subclass use.
JFAMgr() is declared extern in the base and defined per platform.
- BUILD.gn: adds two source_set targets:
* jfa-datastore-sync (JFADatastoreSync + JFAPlatform.h + JFARpc.h)
* jfa-manager-base (JFAManagerBase)
Linux layer: examples/jf-admin-app/linux/
- include/JFAManagerLinux.h + JFAManagerLinux.cpp: new thin derived class
JFAManagerLinux : public JFAManagerBase, singleton via GetDefaultInstance(),
and the Linux definition of chip::JFAMgr().
- JFAPlatformLinux.cpp: implements the two JFAPlatform.h hooks by wrapping the
existing CommissionerMain.h helpers (InitCommissioner / GetDeviceCommissioner).
- main.cpp: swapped #include "JFAManager.h" -> #include "JFAManagerLinux.h".
All JFAMgr() call sites keep working; return type is still JFAManagerBase &.
- BUILD.gn: drops JFAManager.{h,cpp} from sources, adds JFAManagerLinux.{h,cpp}
and JFAPlatformLinux.cpp, and adds deps on jfa-common:jfa-datastore-sync and
jfa-common:jfa-manager-base.
Pigweed RPC service: examples/common/pigweed/rpc_services/JointFabric.h now
includes JFAManagerBase.h instead of JFAManager.h. It keeps calling
chip::JFAMgr().FinalizeCommissioning(...) through the base; no behavior change.
Future ports: the architecture is ready for other platforms to
drop in a sibling JFAManagerX.{h,cpp} + JFAPlatformX.cpp providing their own
chip::JFAMgr() and overriding the virtual hooks they need. No further changes
to jfa-common are required for a new port.
* [jf-admin] Share JFA RPC server via response-signal shim
Move the Joint Fabric Administrator pigweed RPC server into
examples/jf-admin-app/jfa-common/src/RpcServer.cpp and factor the
wait/signal/reset for the ICAC CSR response out behind the
JFAResponseSignal.h shim. Linux links the POSIX shim
(JFAResponseSignalPosix.cpp, std::condition_variable).
Only the wait/signal mechanism is platform-specific, so other operating
systems can provide their own JFAResponseSignal.h implementation (for
example a FreeRTOS semaphore or a Zephyr k_sem) and reuse the shared RPC
server unchanged.
* [jf-admin] Share JFA init wire-up via common JFAInitialize()
Move the shared steps of Joint Fabric Administrator server wire-up into
examples/jf-admin-app/jfa-common/src/JFAInit.cpp behind a new
JFAInitialize(Server &) entry point declared in JFAInit.h.
JFAInit.cpp owns the OS-agnostic setup: the DeviceInstanceInfoProvider
wrapper, the commissioning / DNS-SD event handler (covering
kDnssdInitialized), and the common delegate/provider wiring. Each
platform calls JFAInitialize() and performs only its own extra,
platform-specific steps around it, so a new port reuses the shared setup
rather than copying it.
|
||
|---|---|---|
| .agents | ||
| .claude | ||
| .devcontainer | ||
| .gemini | ||
| .githooks | ||
| .github | ||
| .vscode | ||
| build | ||
| build_overrides | ||
| config | ||
| credentials | ||
| data_model | ||
| docs | ||
| examples | ||
| integrations | ||
| scripts | ||
| src | ||
| third_party | ||
| zephyr | ||
| zzz_generated | ||
| .actrc | ||
| .clang-format | ||
| .clang-tidy | ||
| .default-version.min | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .gn | ||
| .matterlint | ||
| .mergify.yml | ||
| .pre-commit-config.yaml | ||
| .prettierrc.json | ||
| .pullapprove.yml | ||
| .restyled.yaml | ||
| .shellcheck_tree | ||
| .spellcheck.yml | ||
| AGENTS.md | ||
| BUILD.gn | ||
| CLAUDE.md | ||
| CODE_OF_CONDUCT.md | ||
| CODEOWNERS | ||
| CONTRIBUTING.md | ||
| GEMINI.md | ||
| gn_build.sh | ||
| iwyu.imp | ||
| kotlin-detect-config.yaml | ||
| lgtm.yml | ||
| LICENSE | ||
| NOTICE | ||
| pigweed.json | ||
| pyproject.toml | ||
| README.md | ||
| REVIEWERS.md | ||
| SECURITY.md | ||
| SPECIFICATION_VERSION | ||
Documentation links
- Matter SDK documentation page
- Matter SDK Coverage Report
- CI REPL Tests Dashboard
- Nightly Tests Dashboard
Matter
Builds
Tests
Tools
Documentation
About
Matter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.
What is Matter?
Matter is a unified, open-source application-layer connectivity standard built to enable developers and device manufacturers to connect and build reliable, and secure ecosystems and increase compatibility among connected home devices. It is built with market-proven technologies using Internet Protocol (IP) and is compatible with Thread and Wi-Fi network transports. Matter was developed by a Working Group within the Connectivity Standards Alliance (Alliance). This Working Group develops and promotes the adoption of the Matter standard, a royalty-free connectivity standard to increase compatibility among smart home products, with security as a fundamental design tenet. The vision that led major industry players to come together to build Matter is that smart connectivity should be simple, reliable, and interoperable.
Matter simplifies development for manufacturers and increases compatibility for consumers.
The standard was built around a shared belief that smart home devices should be secure, reliable, and seamless to use. By building upon Internet Protocol (IP), Matter enables communication across smart home devices, mobile apps, and cloud services and defines a specific set of IP-based networking technologies for device certification.
The Matter specification details everything necessary to implement a Matter application and transport layer stack. It is intended to be used by implementers as a complete specification.
The Alliance officially opened the Matter Working Group on January 17, 2020, and the specification is available for adoption now.
Visit buildwithmatter.com to learn more and read the latest news and updates about the project.
Project Overview
Development Goals
Matter is developed with the following goals and principles in mind:
Unifying: Matter is built with and on top of market-tested, existing technologies.
Interoperable: The specification permits communication between any Matter-certified device, subject to users’ permission.
Secure: The specification leverages modern security practices and protocols.
User Control: The end user controls authorization for interaction with devices.
Federated: No single entity serves as a throttle or a single point of failure for root of trust.
Robust: The set of protocols specifies a complete lifecycle of a device — starting with the seamless out-of-box experience, through operational protocols, to device and system management specifications required for proper function in the presence of change.
Low Overhead: The protocols are practically implementable on low compute-resource devices, such as MCUs.
Pervasive: The protocols are broadly deployable and accessible, by leveraging IP and being implementable on low-capability devices.
Ecosystem-Flexible: The protocol is flexible enough to accommodate deployment in ecosystems with differing policies.
Easy to Use: The protocol provides smooth, cohesive, integrated provisioning and out-of-box experience.
Open: The Project’s design and technical processes are open and transparent to the general public, including non-members wherever possible.
Architecture Overview
Matter aims to build a universal IPv6-based communication protocol for smart
home devices. The protocol defines the application layer that will be deployed
on devices and the different link layers to help maintain interoperability. The
following diagram illustrates the normal operational mode of the stack:
The architecture is divided into layers to help separate the different responsibilities and introduce a good level of encapsulation among the various pieces of the protocol stack. The vast majority of interactions flow through the stack captured in the following Figure:
- Application: High-order business logic of a device. For example, an application that is focused on lighting might contain logic to handle turning on/off the bulb as well as its color characteristics.
- Data Model: The data layer corresponds to the data and verb elements that help support the functionality of the application. The Application operates on these data structures when there is an intent to interact with the device.
- Interaction Model: The Interaction Model layer defines a set of interactions that can be performed between a client and server device. For example, reading or writing attributes on a server device would correspond to application behavior on the device. These interactions operate on the elements defined at the data model layer.
- Action Framing: Once an action is constructed using the Interaction Model, it is serialized into a prescribed packed binary format to encode for network transmission.
-
Security: An encoded action frame is then sent down to the Security Layer to encrypt and sign the payload to ensure that data is secured and authenticated by both sender and receiver of a packet.
-
Message Framing & Routing: With an interaction encrypted and signed, the Message Layer constructs the payload format with required and optional header fields; which specify the message's properties and some routing information.
- IP Framing & Transport Management: After the final payload has been constructed, it is sent to the underlying transport protocol for IP management of the data.
Current Status of Matter
Matter’s design and technical processes are intended to be open and transparent to the general public, including to Working Group non-members wherever possible. The availability of this GitHub repository and its source code under an Apache v2 license is an important and demonstrable step to achieving this commitment. Matter endeavors to bring together the best aspects of market-tested technologies and redeploy them as a unified and cohesive whole-system solution. The overall goal of this approach is to bring the benefits of Matter to consumers and manufacturers as quickly as possible. As a result, what you observe in this repository is an implementation-first approach to the technical specification, vetting integrations in practice. The Matter repository is growing and evolving to implement the overall architecture. The repository currently contains the security foundations, message framing and dispatch, and an implementation of the interaction model and data model. The code examples show simple interactions, and are supported on multiple transports -- Wi-Fi and Thread -- starting with resource-constrained (i.e., memory, processing) silicon platforms to help ensure Matter’s scalability.
Note: The applications under
examples/are reference implementations intended for development and testing. They are not production-ready and are not intended to be shipped as-is in a commercial product.
How to Contribute
We welcome your contributions to Matter. Read our contribution guidelines here.
Building and Developing in Matter
Instructions about how to build Matter can be found here .
Directory Structure
The Matter repository is structured as follows:
| File/Folder | Content |
|---|---|
| build | Build system support content and built output directories |
| build_overrides | Build system parameter customization for different platforms |
| config | Project configurations |
| credentials | Development and test credentials |
| docs | Documentation, including guides. Visit the Matter SDK documentation page to read it. |
| examples | Example firmware applications that demonstrate use of Matter (not production-ready) |
| integrations | 3rd party integrations |
| scripts | Scripts needed to work with the Matter repository |
| src | Implementation of Matter |
| third_party | 3rd party code used by Matter |
| zzz_generated | ZAP generated template code - Revolving around cluster information |
| BUILD.gn | Build file for the GN build system |
| CODE_OF_CONDUCT.md | Code of conduct for Matter and contribution to it |
| CONTRIBUTING.md | Guidelines for contributing to Matter |
| LICENSE | Matter license file |
| REVIEWERS.md | PR reviewers |
| gn_build.sh | Build script for specific projects such as Android, EFR32, etc. |
| README.md | This file |
License
Matter is released under the Apache 2.0 license.