Matter (formerly Project CHIP / Connected Home over IP) Application Layer support in ESPHome? #1430
Comments
|
I tried to ascertain how hard it would be to implement this, but there doesn't seem to be a getting-started guide, and I couldn't understand how the |
|
FYI, for reference; there looks to be some indirectly related discussion in espressif/esp-idf#8215 about Matter (CHIP) with ESP-IDF: It sounds as if Espressif is working on an upcoming Matter (Project CHIP) specific SDK which will generate an external component? Again, the Matter-specific SDK is not quite ready for Thread/OpenThread yet but for reference you can refer to all-clusters-app example and matter cmake in shell environment. Espressif’s IoT Development Framework (ESP-IDF) now include OpenThread Border Router and OpenThread RPC for Thread radio: https://www.espressif.com/en/products/sdks/esp-idf https://github.com/espressif/esp-idf https://github.com/espressif/esp-idf/tree/master/examples/openthread
This folder contains following the OpenThread examples:
ESP32-H2 has as well passed "Thread Certified Component” certification and will surely also be aiming for Matter certification now: https://csa-iot.org/newsroom/matter-march-update/ PS: At least sounds as if another benefit of ESPHome migrating to ESP-IDF https://esphome.io/changelog/2021.10.0.html#esp-idf |
|
FYI, CSA is also working on "OSKI" (Operating System Kernel Interface) as a OSAL (Operating System Abstraction Layer) platform: https://github.com/project-chip/osal Only for reference, but understand it is meant to allow different firmware frameworks to run on different hardware platforms: |
|
Not ESPHome related, but also cool to see this progress in Home Assistant: https://www.home-assistant.io/blog/2022/05/29/matter-in-home-assistant-workshop-announcement/ Will be great to be able to add very simple yaml config to add matter support right to the ESP32 device config. |
|
FYI, ESP-IDF (Espressif IoT Development Framework) look to now have posted an OpenThread RCP (Radio Co-Processor) example: https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_rcp I think that is needed for ESPHome to support OpenThread and Matter over Thread on ESP32-H2 with its IEEE 802.15.4 radio? https://www.espressif.com/en/news/ESP32_H2 At least if that could be built so firmware provides OpenThread RCP (Radio Co-Processor) mode with SPI interface over the Spinel protocol (spinel+hdlc+uart serial protocol) and tunnel that serial stream to agners OTBR addon (OpenThread Border Router add-on via OpenThread adapter in RCP mode) from Home Assistant addons-development repository for testing Thread/Matter support inside Home Assistant: https://community.home-assistant.io/t/chip-matter-support-including-thread/305633/88 https://github.com/home-assistant/addons-development/tree/master/openthread_border_router https://github.com/openthread/ot-br-posix/ https://openthread.io/platforms/co-processor https://community.home-assistant.io/u/agners/summary Matter upstream SDK also have support for ESP32 (but not sure if that is only over WiFi?): https://github.com/project-chip/connectedhomeip/tree/master/examples/lighting-app/esp32 The main reason for OpenThread RCP (Radio Co-Processor) support in an "RPC" firmware with OTBR (OpenThread Border Router) support will make ESP32-H2 with its IEEE 802.15.4 radio compatible with the upcoming Thread stack / IEEE 802.15.4 radio based "Matter" (Project CHIP / Connected Home over IP) devices if used in Home Assistant with their other add-ons for the that is also in development. That addon by agners requires that the IEEE 802.15.4 radio have a OpenThread firmware in "RPC" mode instead of the no traditional "NCP" mode of OpenThread stack running on the IEEE 802.15.4 radio: https://github.com/home-assistant/addons-development/tree/master/chip_controller_repl https://github.com/home-assistant/addons-development/tree/master/chip_tool https://github.com/project-chip/connectedhomeip https://csa-iot.org/all-solutions/matter/ Also having optional OpenThread "NCP" border router firmware would allow users to alternatively use other existing OpenThread applications that use "NCP" mode instead of the newer "RPC" mode which require additional component running on the host. Ex: https://github.com/openthread/wpantund Note that as far as I read so far agners has only worked with Silicon Labs based adapter with OpenThread "RPC" firmware for Thread / EEE 802.15.4 radio based Matter (as well as ESP32-C3 based devkit for Matter over WiFi) and that is only because it is a Silabs EFR32MG21 chip based adapter that will ship inside the official Home Assistant Yellow (formerly Home Assistant Amber) hardware as well as the upcoming official Home Assistant SkyConnect USB Stick dongle: https://github.com/home-assistant/addons-development/tree/master/silabs-multiprotocol https://www.home-assistant.io/blog/2021/09/13/home-assistant-yellow/ |
|
Duplicate of #1397 |
|
@nagyrobi No, this is not a duplicate at all because #1430 is only a request for Matter support which can be done over just Wi-Fi and Ethernet, while #1397 is a request for Zigbee and Thread/OpenThread via the 802.15.4 radio on the new ESP32-H2 SoC (which does not even support WiFi as it only has a 802.15.4 radio). Also note that Matter is at the application layer while the Zigbee/Thread/OpenThread goes down to transport protocol layer. True that these two requests have some things in common since Matter can be used over WiFi/Ethernet or Thread, but fact is that not all Matter devices will use WiFi or Ethernet and not all Thread/OpenThread devices will use Matter, thus these two feature request should still be kept as separate issues for tracking and different the discussions. PS: IMHO, even the #1397 should also be split up as well to separate Zigbee request discussion there from Thread/OpenThread. |
|
Matter has gone final, and espressif has released an SDK and programming guide here: |
|
Yeah, Matter 1.0 specification and SDK have now been released for general availability and is now supported via Espressif ESP-IDF. Espressif as a company is now going full steam ahead with the release of an all-in-one Matter bridge solution (development platform) + support in official ESP-IDF and including many examples for their new ESP32-H2 SoC (ESP32-H2-DevKitC-1 V2.1 board) with 802.15.4 Thread/Zigbee (+ Bluetooth Low Energy). However, a Matter bridge solution would be more interesting as a separate project as indirectly related to a concept similar to Tasmota's Zigbee2Tasmota (Z2T) project and the ideas behind ESPHome Bluetooth Proxy, Espressif has recently posted a lot of news on Espressif's ESP Matter Solution (e.i. "esp-matter") which uses ESP32 as a Matter-bridge for non-Matter devices such as Zigbee, Thread, and Bluetooth devices, as well as the related news about ESP32-H2 SoC (and ESP32-H2 DevKitC Board) with more news from Espressif about newly established support for Thread/OpenThread (e.i. "esp-thread") + ZBOSS Open Initiative (ZOI) and Zigbee certification announcements (e.i. "esp-zigbee"). In essence, it seems like Espressif as a company is currently fully focusing on their Matter bridge implementation (with an all-in-one two-SoC gateway/bridge solution combining a ESP32-H2 for Zigbee/Thread with an ESP32-S3 for Wi-Fi and/or Ethernet). For that Zigbee/Thread/BLE to Matter-bridge solution they now even have two reference hardware designs that I linked below. "We offer both Matter-Zigbee and Matter-BLE Mesh bridge solutions with full functional software SDK support. A Matter-Zigbee Bridge uses two SoCs (Wi-Fi + 802.15.4), they are connected via a serial interface like UART or SPI, while a Matter-BLE Mesh Bridge can be done on single SoC with both Wi-Fi and BLE interfaces."
Espressif ESP Matter news:https://www.espressif.com/en/news/ESP_Matter_Solution https://www.espressif.com/en/solutions/device-connectivity/esp-matter-solution https://www.espressif.com/en/news/ESP32_H2 https://www.espressif.com/en/news/ESP32-H2_Thread_and_Zigbee_certified https://en.dsr-corporation.com/news/espressif-joins-zoi esp-matter (Matter / Project CHIP) solutions:https://medium.com/the-esp-journal/matter-bridge-for-non-matter-devices-d3b7f003a004 https://blog.espressif.com/matter-thread-border-router-in-matter-240838dc4779 https://docs.espressif.com/projects/esp-matter/en/main/esp32/ https://github.com/espressif/esp-matter https://github.com/espressif/esp-matter/tree/main/examples/zigbee_bridge https://github.com/project-chip/connectedhomeip/tree/master/examples/lighting-app/esp32 https://github.com/project-chip/connectedhomeip/tree/master/examples/chip-tool esp-thread:https://openthread.io/guides/border-router/espressif-esp32 https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_rcp https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_cli https://github.com/espressif/esp-thread-lib https://github.com/espressif/esp-thread-br https://openthread.io/vendors/espressif esp-protocols:esp-protocols including esp modem (for AT commands, etc.), esp websocket client, mDNS (Zeroconf and DNS-SD), Asio, and more: https://espressif.github.io/esp-protocols/ https://github.com/espressif/esp-protocols https://github.com/espressif/esp-protocols/tree/master/components/esp_modem https://github.com/espressif/esp-protocols/tree/master/components/esp_websocket_client https://github.com/espressif/esp-protocols/tree/master/components/mdns https://github.com/espressif/esp-protocols/tree/master/components/asio Other indirectly related tools from Espressif:https://github.com/espressif/esptool https://github.com/espressif/openocd-esp32 https://github.com/espressif/esp-usb-bridge Hardware Platforms"ESP32-H2 DevKitC" ("ESP32-H2-DevKitC-1 V2.1") board with "ESP32-H2-WROOM-1" radio module:
The ESP Thread Border Router consists of two SoCs:
https://github.com/espressif/esp-thread-br#hardware-platforms https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_br https://openthread.io/guides/border-router/espressif-esp32 ESP Thread Border Router BoardThe ESP Thread border router board provides an integrated module of an ESP32-S3 SoC and an ESP32-H2 RCP.
The two SoCs are connected with following interfaces:
Standalone ModulesThe SDK also supports manually connecting an ESP32-H2 RCP to an ESP32 series Wi-Fi SoC.
The following image shows an example connection betwe Add a package diagram. ES32-H2 and ESP32:
In this setup, only UART interface is connected, so it doesn't support RCP Update or RF Coexistence features. You can refer to ot_br example in esp-idf as a quick start. https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_br https://openthread.io/guides/border-router/espressif-esp32 Provided FeaturesThese features are currently provided by the SDK:
In the future releases, the following features will be added:
Post note:FYI, it looks like Espressif ESP32-C Series SoCs (ESP32-C3 and ESP32-C2) and their official reference implementation based on Espressif’s "ESP-Matter" SDK for Matter have now passed certification for the Matter over Wi-Fi standard according to the relevant certification issued by CSA (Connectivity Standards Alliance): https://csa-iot.org/csa_product/esp32-c-series/ "Further more, ESP-ZeroCode Modules will provide a ready-made, plug-and-play solution for building common lighting and electrical devices, such as LED lights, outlets, switches, dimmers, relays, and fans." https://www.espressif.com/en/solutions/device-connectivity/esp-matter-solution PS: I believe those with contacts can get such ESP32-H2 DevKitC boards for evaluation upon request(?) -> sales@espressif.com |
|
FYI, just for reference, ESP32-C6 SoC, module and development board has now been launched with WiFi 6, BLE 5.0, and 802.15.4, ink. OpenThread (and Zigbee), so those could in the future be perfect for ESPHome as a Thread Board Router: https://www.espressif.com.cn/en/news/ESP32-C6_Available Espressif launched ESP32-C6 WiFi 6, Bluetooth 5.0 LE, and 802.15.4 IoT microcontroller by making ESP32-C6-WROOM-1 module: https://www.cnx-software.com/2021/04/11/esp32-c6-wifi-6-and-bluetooth-le-risc-v-soc-for-iot-devices/
Espressif Systems has finally launched the ESP32-C6 WiFi 6, Bluetooth 5.0 LE, and 802.15.4 IoT microcontroller by making the ESP32-C6-WROOM-1 module available on Aliexpress for $14.25 for a pack of 5 modules as well as the ESP32-C6-DevKitC-1 development board that’s out of stock on the official store at the time of writing. but somehow listed in another store for $16.22 plus shipping. Besides the availability announcement, another surprise is the 802.15.4 radio for Zigbee and Thread that was not part of the original ESP32-C6 announcement in April 2021. The ESP32-C6-DevKitC-1 development board comes with a module with 8MB flash, exposes most of the I/O’s from the ESP32-C3, and comes with two USB-C ports, two buttons, and an RGB LED. ESP32-C6-DevKitC-1 development board specifications:
The new ESP32-C6 module and development board work with the ESP-IDF v5.1, currently under development (see progress report), and some basic documentation can be found on read the docs. If you can’t purchase an ESP32-C6 module or board just yet due to limited supplies, don’t despair as more are coming very soon as Espressif tells us to expect more products on Adafruit, Akizuki, Digikey, and Mouser. |
|
Tip if early adopters don't want to wait for ESPHome Matter support is to check out Tasmota's initial experimental development: https://tasmota.github.io/docs/Matter/ Another alternative could be to run the node-matter project on ESP32 (FYI, the node-matter project has recently been merged and moved upstream to become a part of the official project-chip/matter.js project and the code for node-matter will very soon fully be moved to matter.js/packages/matter-node.js) https://github.com/project-chip/matter.js/tree/main/packages/matter-node.js https://github.com/project-chip/matter.js/blob/main/README.md#matterjs-usage |
|
FYI, there are now several pull requests related to IPv6 support which is something that the Matter standard/protocol depends on:
By the way, if ever wanted to prepare ESPHome for a real certification of a Matter device then I understand that the current best practice is to have automated tests that GitHub actions can check if code passes all "CHIP Tool" ( https://github.com/project-chip/connectedhomeip/tree/master/examples/chip-tool https://github.com/project-chip/connectedhomeip/blob/master/docs/guides/chip_tool_guide.md |
|
Any news about Matter support over WiFi for ESPHome on ESP32 (for at least feature-parity of previous Matter workshop?)? Matter 1.1 specification/SDK been released bringing enhancements for developers (but no features from end-users point-of-view): https://csa-iot.org/newsroom/matter-1-1-release-enhancements-for-developers-and-devices/ Off-topic but great to read about the development of the Matter (BETA) integration for Home Assistant keep moving along nicely: https://building.open-home.io/success-of-the-open-home/ https://staceyoniot.com/hands-on-with-the-matter-beta-for-home-assistant/ https://www.theverge.com/23641940/home-assistant-skyconnect-thread-matter-zigbee-smart-home Also interesting from an early-adoptors point-of-view is that the CSA has certified 1000+ Matter devices/products and seen 60+ new members joining the Connectivity Standards Alliance since the initial release of the Matter 1.0 specification in October 2022. https://www.theverge.com/23568091/matter-compatible-devices-accessories-apple-amazon-google-samsung |
|
FYI, Espressif ESP-IDF v5.1 which include Thread support for ESP32-C6 and ESP32-H2 has now been released upstream: |
|
There's this project that might be helpful: https://github.com/Yacubane/esp32-arduino-matter |
|
Sonoff managed to pull it off in their new minir4m! https://sonoff.tech/product/diy-smart-switches/minir4m/ |
I have it and it works great. Though I'�d prefer Thread over WiFi. |
|
@jesserockz @kbx81 has anyone at Nabu Casa begun working on it or planning to add Matter support over WiFi in ESPHome?
Only seen/read/heard updates on Home Assistant's Matter controller integration but none about ESPHome's Matter support: https://www.home-assistant.io/blog/2023/12/04/nabu-casa-at-the-matter-member-meeting/ https://www.home-assistant.io/blog/2023/02/08/state-of-matter-and-thread/ |
|
FYI, other manufacturers including Espressif have kept updating their Matter examples, check out for example: https://github.com/espressif/esp-matter/tree/main/examples Silicon Labs even has a few EFR32 examples specific to the Thread protocol so wonder if may be portable to ESPHome on ESP32? |
Espressif maintain two different sets of example apps. The ones linked above are using the esp-matter SDK. The ones in the CHIP repo are pure esp-idf SDK only. For example |
|
FYI, Matter 1.3 specification has been announced and it adds support for Energy Management, Water Management, EV (Electric Vehicle Charging managenment, and management of some household appliances (including kitchen appliances such as ovens, cooktops and cooker/extractor hoods/vents, as well as laundry dryers). It also includes improvements for Media Players and TVs, including enhancements to the "Matter Casting" (MatterCast) universal casting standard for local audio/video streaming which development is led by Amazon (i.e. for future Alexa/Echo based products): |
|
Finally, I have a plan working on this based on the matter SDK https://www.espressif.com/en/solutions/device-connectivity/esp-matter-solution#sdk-for-matter esphome:
name: matter_smart_device
platform: ESP32
board: esp32dev
# Enable Wifi
wifi:
networks:
- ssid: '!secret wifi_ssid'
password: '!secret wifi_password'
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: matter-device
ap_timeout: 1min
captive_portal:
# Example configuration entry for enabling Matter
matter:
project_id: "example-project-id"
node_id: "example-node-id"
fabric_id: "example-fabric-id"
device_type: "example-device-type"
# Additional Matter configuration options...
# Enable Home Assistant API
api:
logger:
ota:
# Enable the web server to display the Matter pairing QR code
web_server:
port: 80
version: 2
local: true
# Custom sensor to expose the Matter pairing code to Home Assistant
sensor:
- platform: custom
lambda: |-
auto matter_pairing_code = new MatterPairingCodeSensor();
App.register_component(matter_pairing_code);
return {matter_pairing_code};
sensors:
name: "Matter Pairing Code"
# Custom text sensor to expose the Matter QR code to Home Assistant
text_sensor:
- platform: custom
lambda: |-
auto matter_qr_code = new MatterQRCodeSensor();
App.register_component(matter_qr_code);
return {matter_qr_code};
text_sensors:
name: "Matter QR Code" |
This is exciting! Do you have a repo up for it? |
@omaramin-2000 if your solution depend on Espressif’s Matter SDK then does it then also delend on ESP-IDF? If so should it be asssumed that it will only work on the ESP32 platform or should it still also work on other platforms for ESPHome so that it can be used on a SoC not made by Espressif as well? That is, I believe that all ESPHome platforms supported uses the Arduino framework by default, (not ESP-IDF framework by default though that is supported as an alternative base framework for ESP32 chips, however ESP-IDF is for example not used or supported used for ESP8266 platform, RP2040 platform, or LibreTiny platform). https://esphome.io/components/esp32.html https://esphome.io/components/esp8266.html https://esphome.io/components/rp2040.html https://esphome.io/components/libretiny.html FYI, there is also an open pull request for a nRF52 / nRF53 platform (Nordic Semiconductor nRF5 familiy of SoCs): |
This is just a conceptual example of how we might enable Matter on ESPHome using YAML configuration. Matter works only on ESP32 directly, but when connecting it with other devices remotely using HTTP requests so these non-matter devices can be converted to matter. However, for using the Arduino framework, this is the Matter IoT protocol library for ESP32 working on the Arduino framework, which can help with implementing matter on esphome like in TASMOTA as well: https://github.com/Yacubane/esp32-arduino-matter |
I don't think a dynamically created pairing code is ideal. With this approach, you'd need to pair with Home Assistant over WiFi in order to find the Matter pairing code and it's not forwards-compatible with a potential future implementation of Thread-only connections. It also seems like the code would change between device firmware updates, requiring re-pairing every time. I think the pairing code would make more sense as part of the # Example configuration entry for enabling Matter
matter:
project_id: "example-project-id"
node_id: "example-node-id"
fabric_id: "example-fabric-id"
device_type: "example-device-type"
pairing_code: ABCD-1234-XYZ
# Additional Matter configuration options...This way, you could print a label and stick it to the device if you wanted, or view the QR code in the ESPHome web interface (or maybe even the terminal), as well as (potentially) having Home Assistant display it in the device information. |
Still exploring... |
I second this. |
Would it be an option to use the MAC-address of the device (as default)? It's unique anyway. |
I don't think MAC-address would be a good idea ...
looks to be mutch simpler & discriptive ... |
If an attacker only needs knowledge of the MAC to determine the pairing code of a device, you could have quite a few issues depending on how easy it is to trigger a (re-)pair of a device. Ideally the pairing code would be something that is random and unique per device and very hard to change without user consent. |
Describe the problem you have/What new integration you would like
Request native support for Matter (formerly Project CHIP / Connected Home over IP) Application Layer in the ESPHome firmware.
Add a minimal Matter framework to ESPHome that enables building Matter end-devices using ESP32 platform over WiFi/Ethernet.
Matter is a new high-level IoT device connectivity standard owned and governed by the CSA (Connectivity Standards Alliance, formerly the Zigbee Appliance) that aims to improve interoperability and compatibility between different manufacturer using standardized security for devices that can be controlled and updated locally via non-proprietary gateway/hubs/bridges/controllers, without internet or cloud access, nor requiring users to registering any accounts at third-parties.
Note that the network layer of Matter application-layer connectivity standard is based on IPv6 (IP version 6 using both TCP and UDP), so will, in theory, be able to use different transport media, including Wi-Fi, Ethernet, and Thread (OpenThread), however, as this feature request is for high-level Matter Application Layer support, so requesting that consider first scope any initial projects to focusing on basic IoT device control over just WiFi and Ethernet transport links to achieve MVP (Minimum Viable Product) functionality on one of the ESP32 SoCs that already has mature support in ESPHome and loads of resources needed for development (e.g. ESP32-C3 and ESP32-S3), and as such not yet put focus on adding Thread (OpenThread) support for Matter nor ESP32 chips with resource constraints, or at least not initially.
Check out these Matter device code examples:
Also check out CSA's project-chip (Matter) project's "ZAP" to generate clusters and attributes or other entities. ZAP (which stands for "ZCL Advanced Platform" ) is a generic generation engine and user interface for applications and libraries based on Zigbee Cluster Library, the specification developed by the Connectivity Standards Alliance to configure Matter (and Zigbee Pro) applications.
The other incentive for wanting native Matter support in ESPHome to allow users to make DIY Matter devices is that it is likely to attract more developers and expand the userbase if implemented as once future Matter specification device type feature set have matured a bit more then upcoming versions of the Matter standard has the potential of being adopted by most other major manufacturers because it was originally founded by Amazon (developers of the Alexa/Echo ecosystem ), Apple (developers of HomeKit ecosystem), Google (developers of the Google Home/Nest/Android ecosystems), Samsung (developers of other SmartThings ecosystem), and the Zigbee Alliance, (now the Connectivity Standards Alliance), and subsequent number of members that have since joined in collaboration of this Matter standard project have been huge and include IKEA, Signify/Philips, Schneider, Siemens Eve by ABB), and perhaps more importantly for ESPHome, also MCU SoC manufacturers like Espressif, Nordic Semiconductor, and Silicon Labs.
There articles are good summaries why this "Matter" smart home standard matters or more importantly will matter in the future:
While the initial Matter standard (e.i. version 1.0) specification will take a lot of inspiration from the upcoming ZCL (Zigbee Cluster Library) specifications I understand that the very first version will still be very limited in amount of device types and attributes/features/functions it can support in the beginning, however, more device types and attributes/features/functions will be added later in each future revision/version.
As such it will in the beginnig not be close to being as flexible as just using ESPHome without the Matter protocol (or even using a other existing standard IoT protocol like Zigbee). This will limit the initial Matter 1.0 standard to at first only supporting simpler device types with control features, such as Switch or Outlet (On/Off), Lights (including dimming + color control), Fans, Window Covering, Thermostats, Locks, and basic sensors like Temperature, Humidity, Pressure, Flow, Occupancy, and Contact sensor, as well as speaker volume.
https://csa-iot.org/all-solutions/matter/matter-faq/#:~:text=Which%20device%20categories%20does%20Matter%20support%3F%C2%A0
(CSA does already have other additional device types on its roadmap and plans on introducing more in each future version, and some of those future device types mentioned are for example; Energy management, Garage door and gate controller sensors, Home security cameras, Smoke and CO detectors, other Environmental quality sensors and controls such as indoor air quality monitors and air purifiers).
Anyway, the core concept/idea behind this new Matter is a long-term future vision to end proprietary communication protocols for basic home automation devices so that users should be able to buy any Matter device from any manufacturer and use it in any third-party ecosystem from other manufacturers as long as it supports Matter. As such the main benefit of Matter being device interoperability is cross-manufacturer compatibility, as in devices that fully comply with the Matter standard will be directly supported natively by third-party ecosystems, including the most popular ones from large companies for example; Google Home / Googe Nest (Google Assistant), Amazon Echo (Amazon Alexa), and Samsung SmartThings. This would mean that if a user could configure an ESPHome-based firmware as a standard Matter device then it will be possible to commission/join/pair that device directly to any ecosystem without going through a bridge or proxy application/integration that converts it is messages to a proprietary protocols (like for example Apple's HomeKit).
Espressif Systems which makes ESP32 (and ESP8266) is already part of the CSA / Connectivity Standards Alliance (formerly known as the Zigbee Alliance governs the Matter/CHIP standard), with Espressif ESP32 Wi-Fi series hardware platforms will be one of the first reference platforms for Matter/CHIP, and Espressif also have announced that they will have upcoming Thread/OpenThread based ESP32 series on their roadmap soon and those will support Matter over Thread at their launch.
For more details on exactly how developers can use Matter on ESP32 read Hrishikesh Dhayagude's blogpost on the ESP Journal:
FYI, Home Assistant developers have been experimenting with the Matter standard on ESP32 (though not based on ESPHome):
https://www.home-assistant.io/integrations/matter#experiment-with-matter-using-a-esp32-dev-board
Also see:
While still a work-in-progress you can find the ESP32 code in the Matter/CHIP SDK here:
Please describe your use case for this integration and alternatives you've tried:
Additional context
Not sure if it is still the case but Project CHIP initially mandated the use of IPv6 addresses, so not sure if IPv6 support will still be a hard requirement or if when the 1.0 version of the Matter Application Layer specification is released will also support Matter over IPv4. Also, see IPv6 support request -> #718 (EDIT: Apparently this might no longer be applicable since IPv6 is supported on ESP32 and Matter/CHIP will officially only be supported on ESP32 anyway and no upstream support for ESP8266/ESP82xx?).
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 that is focused on lighting might contain logic to handle turning
on/off the bulb as well as its color characteristics.
help support the functionality of the application. The Application operates
on these data structures when there is an intent to interact with the device.
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.
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.
constructed, it is sent to the underlying transport protocol for IP
management of the data.
PS: Off-topic but FYI, Thread (OpenThread) devices been proven to be faster than Zigbee and Bluetooth Multicast (Bluetooth Mesh):
https://www.reddit.com/r/homeautomation/comments/nxmehn/clearing_up_confusion_thread_is_much_faster_than/
The text was updated successfully, but these errors were encountered: