Hedda commented 3 years ago

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.

https://en.wikipedia.org/wiki/Matter_(standard)

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.

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

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.

https://github.com/project-chip/connectedhomeip/blob/master/README.md
- https://github.com/project-chip/connectedhomeip/blob/master/README.md#architecture-overview

Check out these Matter device code examples:

https://github.com/project-chip/connectedhomeip/tree/master/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.

https://github.com/project-chip/zap

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.

https://csa-iot.org/members/

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:

https://blog.espressif.com/announcing-matter-previously-chip-on-esp32-84164316c0e3
- https://medium.com/the-esp-journal/announcing-matter-previously-chip-on-esp32-84164316c0e3

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:

https://github.com/project-chip/connectedhomeip/search?q=esp32

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 -> https://github.com/esphome/feature-requests/issues/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: 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.

2) 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.

4) 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.

7) 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.

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/

oxan commented 2 years ago

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 temperature-measurement-app works (where does it actually report a value?).

Hedda commented 2 years ago

FYI, for reference; there looks to be some indirectly related discussion in https://github.com/espressif/esp-idf/issues/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

The new Matter standard) need many "Thread Board Router" (OpenThread Border Router, a.k.a. OTBR) to connect to a Thread network in order to make it both more redundant and more stable, as a Thread Board Router acts as a network bridge to connect your normal LAN network to the Thread network and it also uses network mesh technology so having more Thread devices will add better range and coverage.

This folder contains following the OpenThread examples:

ot_br is an OpenThread Border Router example. It runs on a Wi-Fi SoC such as ESP32, ESP32-C3 and ESP32-S3. It needs an 802.15.4 SoC like ESP32-H2 running ot_rcp example to provide 802.15.4 radio.
ot_cli is an OpenThread Command Line example, in addition to the features listed in OpenThread CLI, it supports some additional features such as TCP, UDP and Iperf over lwIP. It runs on an 802.15.4 SoC like ESP32-H2.
ot_rcp is an OpenThread RCP (co-processor) example. It runs on an 802.15.4 SoC like ESP32-H2, to extend 802.15.4 radio.

ESP32-H2 has as well passed "Thread Certified Component” certification and will surely also be aiming for Matter certification now:

https://youtu.be/bS9Ch7k_GK0

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

Hedda commented 2 years ago

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:

https://github.com/project-chip/osal/blob/main/README.md

jhansche commented 2 years ago

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.

matter:
  ... node info, endpoints, services, etc

Hedda commented 2 years ago

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

https://github.com/esphome/feature-requests/issues/1397

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://github.com/agners

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://buildwithmatter.com

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/zigpy/zigpy/discussions/894

https://github.com/home-assistant/addons-development/tree/master/silabs-multiprotocol

https://www.home-assistant.io/blog/2021/09/13/home-assistant-yellow/

https://www.crowdsupply.com/nabu-casa/home-assistant-yellow

https://community.home-assistant.io/t/home-assistant-skyconnect-usb-stick-announced-will-be-compatible-with-both-zigbee-and-thread-including-matter-chip-over-thread/433594

nagyrobi commented 2 years ago

Duplicate of https://github.com/esphome/feature-requests/issues/1397

Hedda commented 2 years ago

@nagyrobi No, this is not a duplicate at all because https://github.com/esphome/feature-requests/issues/1430 is only a request for Matter support which can be done over just Wi-Fi and Ethernet, while https://github.com/esphome/feature-requests/issues/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 https://github.com/esphome/feature-requests/issues/1397 should also be split up as well to separate Zigbee request discussion there from Thread/OpenThread.

southalladam commented 2 years ago

Matter has gone final, and espressif has released an SDK and programming guide here: https://docs.espressif.com/projects/esp-matter/en/main/esp32/index.html

Hedda commented 2 years ago

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."

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:

An ESP32 series Wi-Fi SoC (ESP32, ESP32-C, ESP32-S, etc) loaded with ESP Thread Border Router and OpenThread Stack.
An ESP32-H 802.15.4 SoC loaded with OpenThread RCP.

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 Board

The 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:

UART and SPI for serial communication
RESET and BOOT pins for RCP Update
3-Wires PTA for RF coexistence

Standalone Modules

The SDK also supports manually connecting an ESP32-H2 RCP to an ESP32 series Wi-Fi SoC.

ESP32 pin	ESP32-H2 pin
GND	G
GPIO17	TX
GPIO18	RX
GPIO4	RST
GPIO5	GPIO9 (BOOT)

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 Features

These features are currently provided by the SDK:

Bi-directional IPv6 Connectivity: The devices on the backbone link (typically Wi-Fi) and the Thread network can reach each other.
Service Discovery Delegate: The nodes on the Thread network can find the mDNS services on the backbone link.
Service Registration Server: The nodes on the Thread network can register services to the border router for devices on the backbone link to discover.
Multicast Forwarding: The devices joining the same multicast group on the backbone link and the Thread network can be reached with one single multicast.
NAT64: The devices can access the IPv4 Internet via the border router.
RCP Update: The built border router image will contain an updatable RCP image and can automatically update the RCP on version mismatch or RCP failure.
Web GUI: The border router will enable a web server and provide some practical functions including Thread network discovery, network formation and status query.

In the future releases, the following features will be added:

SPI Communication
RF Coexistence

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/

https://api.knack.com/v1/applications/54e658034b4f44e42fb18201/download/asset/635b9bc49c2eb30024590776/picsesp32.tar.gz

https://www.espressif.com/en/news/Matter-compatible_Device_Certificate_Generation_and_Pre-provisioning_Services

"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

Hedda commented 1 year ago

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

https://espressif-docs.readthedocs-hosted.com/projects/espressif-esp-dev-kits/en/latest/esp32c6/esp32-c6-devkitc-1/index.html

https://github.com/espressif/esp-idf/issues/10423

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:

Wireless module – ESP32-C6-WROOM-1 with
- ESP32-C6 single-core 32-bit RISC-V clocked up to 160 MHz 320KB ROM, 512KB SRAM, low-power RISC-V core @ up to 20 MHz
- Wireless – 2.4 GHz WiFi 6, Bluetooth 5.0 LE, 802.15.4 radio for Zigbee 3.0 and Thread. Matter compatible. PCB antenna 8MB SPI flash
USB – 1x USB Type-C host port, 1x USB Type-C port via UART console
I/Os – 2x 16-pin headers with GPIO, UART, SPI, ADC, SDIO, USB, I2S, etc…
Misc – Reset and BOOT buttons, RGB LED, J5 header/jumper for current measurement
Power Supply (mutually exclusive options)
- 5V via USB-UART port (recommended)
- 5V and GND pin headers
- 3V3 and GND pin headers
Dimensions – 51.8 x ~20 mm

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._

Hedda commented 1 year ago

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/

https://github.com/arendst/Tasmota/discussions/17872

https://github.com/arendst/Tasmota/discussions/13020

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/mfucci/node-matter/discussions/272

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

https://github.com/mfucci/node-matter/pull/273

Hedda commented 1 year ago

FYI, there are now several pull requests related to IPv6 support which is something that the Matter standard/protocol depends on:

https://github.com/esphome/feature-requests/issues/718
- https://github.com/esphome/esphome/pull/4865 https://github.com/esphome/esphome/pull/2953 https://github.com/esphome/esphome/pull/4759 https://github.com/esphome/esphome/pull/4729 https://github.com/esphome/esphome/pull/4865 https://github.com/esphome/esphome/pull/4759 https://github.com/esphome/esphome/pull/4729

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" (chip-tool a.k.a. Chiptool) tests.

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

Hedda commented 1 year ago

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

https://csa-iot.org/csa-iot_products/?p_keywords=&p_type%5B%5D=14&p_program_type%5B%5D=1049&p_certificate=&p_family=

Hedda commented 1 year ago

FYI, Espressif ESP-IDF v5.1 which include Thread support for ESP32-C6 and ESP32-H2 has now been released upstream:

https://github.com/espressif/esp-idf/releases/tag/v5.1

DoomHammer commented 1 year ago

There's this project that might be helpful: https://github.com/Yacubane/esp32-arduino-matter

mvgijssel commented 12 months ago

Sonoff managed to pull it off in their new minir4m! https://sonoff.tech/product/diy-smart-switches/minir4m/

reinisb commented 12 months ago

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.

Hedda commented 11 months ago

@jesserockz @kbx81 has anyone at Nabu Casa begun working on it or planning to add Matter support over WiFi in ESPHome?

Any news about Matter support over WiFi for ESPHome on ESP32 (for at least feature-parity of previous Matter workshop?)?

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/

https://nabucasa.github.io/matter-example-apps/

https://github.com/NabuCasa/matter-example-apps

Hedda commented 11 months ago

https://nabucasa.github.io/matter-example-apps/

https://github.com/NabuCasa/matter-example-apps

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?

https://github.com/SiliconLabs/matter_applications

darkxst commented 11 months ago

Espressif have kept updating their Matter examples, check out for example:

https://github.com/espressif/esp-matter/tree/main/examples

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 https://github.com/project-chip/connectedhomeip/tree/master/examples/all-clusters-app/esp32

Hedda commented 6 months ago

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).

https://csa-iot.org/newsroom/matter-1-3-specification-released/
- https://www.cnx-software.com/2024/05/20/matter-1-3-specification-adds-support-for-water-and-energy-management-electric-vehicle-chargers-and-various-household-appliances/
- https://www.matteralpha.com/industry-news/matter-1-3-levels-up-your-smart-home

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):

https://www.engadget.com/amazon-wont-support-airplay-or-chromecast-but-will-adopt-matter-casting-instead-161933813.html

omaramin-2000 commented 5 months ago

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"

brotherdust commented 5 months ago

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?

Hedda commented 5 months ago

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

@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):

https://github.com/esphome/esphome/pull/6075

omaramin-2000 commented 5 months ago

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

@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):

https://github.com/esphome/esphome/pull/6075

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

andyearnshaw commented 5 months ago

# 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"

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 matter configuration options:

# 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.

omaramin-2000 commented 5 months ago

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?

Still exploring...

stefa168 commented 5 months ago

I don't think a dynamically created pairing code is ideal

I second this.

dominik4545 commented 4 months ago

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.

Would it be an option to use the MAC-address of the device (as default)? It's unique anyway.

graphichasan commented 2 months ago

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.

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 ...

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

looks to be mutch simpler & discriptive ...

kquinsland commented 2 months ago

Would it be an option to use the MAC-address of the device (as default)? It's unique anyway.

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.

esphome / feature-requests

Matter (formerly Project CHIP / Connected Home over IP) Application Layer support in ESPHome? #1430

Architecture Overview

Espressif ESP Matter news:

esp-matter (Matter / Project CHIP) solutions:

esp-thread:

esp-protocols:

Other indirectly related tools from Espressif:

Hardware Platforms

ESP Thread Border Router Board

Standalone Modules

Provided Features

Post note: