Chip / Matter support (including Thread)

Way too much debate over what’s an open standard, but I’ll weigh in ….

The big kahunas are what will make it work. Suddenly devices will be able to work on hundreds of millions of Apple, Amazon, Google hubs already in peoples houses, and billions of mobiles already in people’s pockets. Who can pass up a market that sized?

This should be two potentially separate requests:

  1. The existing HomeKit bridge is fantastic and hugely increases the WAF in my house. Suddenly anyone can talk to Siri to control things. Let’s get a similar Matter bridge going! Many households are mixed, and it would be even higher WAF if suddenly people could also talk to Alexa or Ok Google to control things (I haven’t looked into those integrations yet). It shouldn’t matter what voice assistant you prefer but we know less technical people want to use a voice assistant or their favorite phone or watch app. At the same time, a Matter bridge could eventually replace somewhat duplicate work for the three individually.

  2. Application hub, I don’t know what you’d call it, but HA has always been fantastic with including everything, being open. As Matter devices and border routers come out, let’s also support them. HA has the advantages of diversity and the long tail of existing devices. This is just one more integration for HA to be the one hub to rule them all

  3. Ok, the more I think about it, this could also spawn many smaller feature requests to implement the common data model of Matter, for existing devices

1 Like

Thread can be installed with docker Run OTBR Docker  |  OpenThread or in other ways in a Raspberry pi. In the Openthread web there are few hardware to do it, and fortunatly there are at less one stick CC2652R stick -

You can access to the thread Network throw IP adress so I think it would be sooo easy to access in home asistant with the card website and duckdns.

Also one app was released in Android, called thread.

It would be awesome if we could integrate that on de home asistant in other way like with an addon.

This is the Openthread API التطوير باستخدام واجهات برمجة تطبيقات OpenThread

One add-on which brings the OpenThread Border Router is the Silicon Labs Multiprotocol Add-on. It supports running Zigbee and OpenThread on a single (Silicon Labs) radio (with the Multi-PAN firmware flashed). It is rather experimental though at the moment.

Matter is postponed again

Thread and matter are different things please vote only for thread integration here!!!

I’ve been doing a lot of research and benchtop testing of Thread & Matter/CHIP with the goal of pulling the IoT ecosystem into the IP Automation world.

I am finally somewhat confident in my benchtop lab system that is based on the Nordic nRF series chips. I have an OTBR on RaspberryPi with the nRF52840 dongle as an RCP. Three nrf52840dk and one nrf5340dk dev kits. A couple of Afafruit nrf52840 Feather Express boards. I have some nRF Thingy:52 devices too but they seem like a bad purchase now as they don’t support Thread.

I’ve been using the sample firmware code in the nRF Connect SDK such as the OpenThread Coap Server/Client and the Matter Light Bulb/Switch examples. It is time for me now to start working on the interfacing of the Thread or Matter network into the Home Assistant ecosystem.

I’ll do more reading here to catch up.


I just hope Home Assistant Yellow (the board being developed) can be able to support Matter out-of-the-box (the hardware, since it’s not very upgradable I guess)

1 Like

I have been playing with matter (via openthread) for about 2 months now here are some things i discovered:

With a USB RCP dongle (mine uses nrf52833), any linux computer can become a border router for matter.
My border router runs on Openwrt on Xiaomi Router R3, “router”, of course.

USB appears as a Network device - wpan0. Matter messages go through this interface and are TCP messages.

I really want the matter (openthread) border router and home assistant to run on the same router and that’s it, just like zigbee now.


Just added the OpenThread Border Router add-on to the development add-on repository

It is built directly from the upstream OpenThread sources, specifically the OpenThread Border Router for POSIX platforms. So far I joined nRF52840-Dongle based CLI devices (ot-cli-ftd, basically Thread devices with a CLI for testing). I’ve tested it using Nordic Semiconductor with the USB nRF52840-Dongle as well as with Silicon Labs EFR32 MGM210P flashed with OpenThread RCP firmware (the radio on Yellow).

The work is based on my previous SiliconLabs Zigbee/OpenThread Multiprotocol Add-on. This add-on uses the vanilla/upstream OTBR. It supports regular OpenThread RCP protocol radios (it does not support the SiliconLabs specific CPCd as the above add-on does). Ideally the SiLabs Multiprotocol add-on should be stripped of its forked version of OTBR and reuse the upstream OTBR version, however, for that to be possible upstream OTBR would need to gain CPCd support.


@agners Wondering if you could ask the other Nabu Casa developers what the plan is for the new Matter integration and if they will consider use re-use (or fork) the existing zigpy library (that the existing ZHA integration uses a dependency) in your Matter implementation for Home Assistant as well?

The reason for asking that specifically is because the existing zigpy library contains a “Zigbee Cluster Library” (ZCL) that follows the specification standards by Connectivity Standards Alliance (CSA, formerly Zigbee Alliance) which if I understand correctly also plays a part in the Matter standard for Thread based devices?

I am also wondering if you have considered what programming language that the Matter components and dependency libraries will be coded in? …will they be written primarily in Python like Home Assistant?

Reason for that question is that just read in the latest Home Assistant newsletter that Dominic Griesel (a.k.a. AlCalzone on GitHub) from the Z-Wave JS project will join Nabu Casa later this month to focus on further improving Z-Wave JS and will help Home Assistant in adopting the new Matter (formerly CHIP) standard.

I know that unlike zigpy which is written in Python (same as the Home Assistant core and other native integrationscomponents), the Z-Wave driver for Z-Wave JS project was instead written entirely in JavaScript/TypeScript project is written.

So the question is really if the existing zigpy library can be re-purposed in a Matter implementation for Home Assistant and by doing so hopefully be able to share developers with ZHA and other zigpy based projects and that way be maintained by more developers.

1 Like

Anyone got OpenThread Border Router firmware images built for CC2652P/CC2652 based adapters?

They are inexpensive and commonly available + loads of people in the community already got these:

And many more such Texas Instruments CC2652 (and CC1352) based adapters listed here:

@agners Do you or @jesserockz given have ideas about OpenThread Border Router on ESP32-H2?

The ESP32-H2 does have a 802.15.4 capable radio and should support OpenThread RCP firmware:

Example code is on their GitHub repo for esp-idf (OTBR example uses both ESP32-H2 and ESP32):

In this folder, it contains following OpenThread examples:

  • 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 example. It runs on an 802.15.4 SoC like ESP32-H2, to extend 802.15.4 radio.

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

ESP32-H2 is certified as a “Thread-Certified Component” as well as a “Zigbee-Compliant Platform”:

It is also assumed Espressif is working on preparing ESP32-H2 for Matter certification ahead of launch:

Did Espressif send you any ESP32-H2 devkit/boards (ESP32-H2-DevKitC-1 / ESP32-H2-WROOM-1)?

If anyone has any contacts at Espressif’s Sales or R&D then maybe Nabu Casa could get samples?

The Home Assistant Yellow project has some information about Matter support. The chip used in the Yellow will be updated to run Matter and Zigbee simultaneously once the firmware is available. I think you will find Matter support comes to Home Assistant then as it will be supported by their hardware.
Unfortunately the Matter release has been delayed a bit again recently, so a lot of things are still a little in the air with it.

Read the Home Assistant Yellow update and it is directly related to the OT add-on agners linked above.

It is also related to the development of his Home Assistant Add-on for Silicon Labs Multiprotocol stack:

Probably everyone reading here is already aware, but just in case:

On wednesday there will be a workshop on Matter, using the ESP32-C3. That’s definetely a good sign :slight_smile:

Is there some development I could follow anywhere on this?

Also, my main usecase for this would be to idiomatically expose my home assistant controls and devices to Matter-enabled hubs, allowing multiple of those home-app ecosystems to work with them. Basically something similar to the current HomeKit integration.

For example, I’d want to be able to give someone the ability to control a homekit-enabled device with their google home app, via home assistant, by exposing all of the device’s controls through Matter, basically “converting” a legacy homekit product to matter.

Suggest you follow @agners activity here + follow his development on GitHub + his posts on Twitter:

If you are a developer or very advanced system engineer yourself then could check there out:

Still experimental and pre-alpha so not sure if can ask for help yet but some posted bug reports here:

There are also some indirect discussions about Thread radio hardware adapter compatibility here:

So far only add-ons supports Silicon Labs EFR32 (EFR32MG21/EFR32MG13/EFR32MG12) adapters:

As I understand it that is not the main use case currently in focus by Home Assistant developers, but rather the reverse, as at least to begin with the focus is on an Matter/CHIP Controller integration for Home Asistant that will allow you to connect Matter-certified accessories with the “Matter” logo (such as for example however not exclusive to upcoming Thread-based low-powered wireless sensors which today are more commonly using Zigbee or Z-Wave wireless protocols or upcoming Wi-Fi based devices compatible with Matter/Thread) to Home Assistant.

All the development efforts so far are focusing on Home Assistant being able to control other Matter compatible devices, including Thread-based low-power Matter devices and WiFi-based Matter devices.

So the short-term goal is for Home Assistant to be able to communicate and control with upcoming DIY and commercial Matter/CHIP compatible devices such as wireless sensors.

Just like how Home Assistant currently already support controlling Zigbee devices via the ZHA integration and Z-Wave devices via the Z-Wave JS integration, …but Home Assistant itself does not have integrations can not act as Zigbee router/end-device or a Z-Wave client device and present that to other proprietary Zigbee and Z-Wave hubs.

You can see it as Home Assistant will first become a Matter/CHIP compatible controller/hub, (and not a Matter-compatible client). However in the future someone might also make a separate Matter/CHIP integration which would allow allows you to make your Home Assistant entities available to other Matter/CHIP compatible controllers.

By the way, please note that you should really not expect that all manufacturers of proprietary hubs to all of the suden will allow you to connect just any Matter/CHIP-compatible to their hub. Vendor lock-in is still in the mind-set of most manufacturers of proprietary hubs and companies like for example Philips and IKEA have said that while they will make their hubs Matter-compatible they have clearified that they will only present their devices over the Matter/CHIP protocols but will not allow their hubs to act as a controller for third-party Matter-compatible devices.

PS: Yes I am aware that Home Assistant has two separate integrations for acting as either as HomeKit Client or HomeKit Controller (“The HomeKit controller integration allows you to connect accessories with the “Works with HomeKit” logo to Home Assistant. This integration should not be confused with the HomeKit integration, which allows you to control Home Assistant devices via HomeKit.”)


FYI, Nabu Casa Business Development Manager has also announced on Twitter that Home Assistant founders are working on an official Home Assistant SkyConnect USB Stick (ie. a radio adapter/dongle):

FYI, Espressif as a company looks to currently be going full steam ahead with an all-in-one Thread/Zigbee to Matter bridge solution + 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).

Most interestingly as indirectly related to a concept similar to Tasmota’s Zigbee2Tasmota (Z2T) project and 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 are currently fully focusing on embedded Zigbee gateway and Zigbee/Thread to 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). 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:

esp-matter (Matter / Project CHIP) solutions:




esp-protocols including esp modem (for AT commands, etc.), esp websocket client, mDNS (Zeroconf and DNS-SD), Asio, and more:

Other indirectly related tools from Espressif:

Hardware Platforms

“ESP32-H2 DevKitC” (“ESP32-H2-DevKitC-1 V2.1”) board based on “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.

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

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.

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


PS: I think esp-zigbee support is of interest for ESP32-based Zigbee remote adapter bridges, like ex. Tube’s and ZigStar Gateways: