Global OpenThread and Matter questions

[Steven]

Hi,

I work in a start-up and we are currently developing a connected radiator. We studied the different communication protocols that existed and we finally chose OpenThread, in particular for its future compatibility with Matter. Overall, OpenThread is quite a surprising protocol because it is little used yet so powerful. Additionally, we will be using Bluetooth for commissioning. OpenThread is a totally new protocol for us. One of the objectives of my work, besides the electronic development, is to make sure that our product is compatible with Matter in the future. Unfortunately, we only have few information today about how Matter works. Of course, it is in the hypothesis that Matter come out one day !

One of the company's policies was to avoid developing two products: A radiator and a gateway. The company does not want to burden the user with a gateway. This therefore requires having a gateway within the radiator. Thus, in order not to develop two different electronics, we started from the principle that all radiators can be a gateway. This comes out of the classic operation of Zigbee, OpenThread, etc. networks. Stop me if I'm wrong, but in the OpenThread world, something called a "Gateway" is a "Border Router". For a device to be a Border Router, you need an OpenThread compatible microcontroller with RCP firmware and a host microcontroller connected to the Internet. Thus, all radiators have a Host microcontroller that can connect to the Internet, this is an ESP32, and a communication microcontroller with RCP firmware. In the network, only one or two radiators will be in Border Router mode, the others will simply be Routers or Nodes. Do you find the idea of ​​being able to integrate a gateway into each of our radiators completely absurd ? In particular the obligation to use RCP firmware in each of these.

One of the problems we are facing is related to the RCP firmware. Indeed, there is no RCP OpenThread + Bluetooth firmware. So for commissioning, we were thinking of using the Bluetooth of the ESP32. Unfortunately, we are afraid of not being 100% Matter compatible regarding commissioning because of this. In case we use an FTD Openthread + Bluetooth image, commissioning Matter would work but we must use an RCP image for the Border Router. Do you think it is possible to use an RCP image and be Bluetooth compatible and therefore at the Commissioning Matter level ?

A last question concerns external communication. We want radiators to communicate with our servers, but we're having trouble figuring out how to do that. There are two approaches, direct communication between the radiators and the server as the radiators are "connected" to the internet via IPV6. Or the more classic option, communication between the server and the gateway (like Zigbee). Starting from the first option, a radiator can currently perform UDP communication to the server. Unfortunately, MQTT does not support UDP. The module we are using has not yet implemented TCP and perhaps the use of TCP would drastically increase the consumption of objects on battery power. When researching, many people use the second approach which is to implement MQTT at the gateway level. This approach therefore implies having a "proprietary" gateway. Am I correct or am I on the wrong track ? Are there other solutions ?

I'm sorry for all these questions, these are new and recent technologies so we have a lot of questions. Anyway, thank you for paying attention to our message, I wish you my sincere greetings.

Steven

[Jonathan Hui]

HI Steven,

Thanks for reaching out and sharing with us your project and goals - it sounds very interesting!

See my responses below:

On Fri, Feb 11, 2022 at 9:47 AM Steven <bebin....@gmail.com> wrote:

I work in a start-up and we are currently developing a connected radiator. We studied the different communication protocols that existed and we finally chose OpenThread, in particular for its future compatibility with Matter. Overall, OpenThread is quite a surprising protocol because it is little used yet so powerful. Additionally, we will be using Bluetooth for commissioning. OpenThread is a totally new protocol for us. One of the objectives of my work, besides the electronic development, is to make sure that our product is compatible with Matter in the future. Unfortunately, we only have few information today about how Matter works. Of course, it is in the hypothesis that Matter come out one day !

If you want to learn more about Thread and participate in the Thread Group, I suggest applying for the Thread Group Innovation Enabler Award, which is a program to help provide Thread Group membership to startups like yours.

One of the company's policies was to avoid developing two products: A radiator and a gateway. The company does not want to burden the user with a gateway. This therefore requires having a gateway within the radiator. Thus, in order not to develop two different electronics, we started from the principle that all radiators can be a gateway. This comes out of the classic operation of Zigbee, OpenThread, etc. networks. Stop me if I'm wrong, but in the OpenThread world, something called a "Gateway" is a "Border Router".

The difference between a "Gateway" and "Thread Border Router" is that the former often implies application-layer proxying. A Thread Border Router is very similar to a Wi-Fi Access Point, they provide end-to-end IP connectivity. The benefit of a Thread Border Router (like Wi-Fi APs) is that devices communicate with whatever application layer protocol they want, end-to-end, without having to deploy and maintain application-layer functions on the Thread Border Router.

 

For a device to be a Border Router, you need an OpenThread compatible microcontroller with RCP firmware and a host microcontroller connected to the Internet. Thus, all radiators have a Host microcontroller that can connect to the Internet, this is an ESP32, and a communication microcontroller with RCP firmware. In the network, only one or two radiators will be in Border Router mode, the others will simply be Routers or Nodes. Do you find the idea of being able to integrate a gateway into each of our radiators completely absurd ? In particular the obligation to use RCP firmware in each of these.

Not at all. We believe Thread and Thread Border Routers can be seamlessly integrated into any product. This is why we've implemented OpenThread in a way that can work for both Linux-class and RTOS-class environments. Note that the split between host and RCP is not strictly required, but is a common architecture since there are not many Wi-Fi/Thread combo chips available on the market. However, there are tri-radio (Wi-Fi/Thread/Bluetooth) combo chips that are just now coming to market.

That said, serving as a Thread Border Router does have certain power requirements (e.g. enabling Wi-Fi interface for IP connectivity, Thread Routers must keep radio receiver enabled). Is your product battery-powered or otherwise limited in energy capacity?

One of the problems we are facing is related to the RCP firmware. Indeed, there is no RCP OpenThread + Bluetooth firmware. So for commissioning, we were thinking of using the Bluetooth of the ESP32. Unfortunately, we are afraid of not being 100% Matter compatible regarding commissioning because of this. In case we use an FTD Openthread + Bluetooth image, commissioning Matter would work but we must use an RCP image for the Border Router. Do you think it is possible to use an RCP image and be Bluetooth compatible and therefore at the Commissioning Matter level ?

Thread RCP and Bluetooth do not need to run on the same chip. In fact, in a host-RCP environment, it is probably easier to leverage the host's Bluetooth capabilities, if available. I would suggest taking a look at Matter's open-source implementation for examples on how to integrate Matter and OpenThread.

A last question concerns external communication. We want radiators to communicate with our servers, but we're having trouble figuring out how to do that. There are two approaches, direct communication between the radiators and the server as the radiators are "connected" to the internet via IPV6. Or the more classic option, communication between the server and the gateway (like Zigbee). Starting from the first option, a radiator can currently perform UDP communication to the server. Unfortunately, MQTT does not support UDP. The module we are using has not yet implemented TCP and perhaps the use of TCP would drastically increase the consumption of objects on battery power. When researching, many people use the second approach which is to implement MQTT at the gateway level. This approach therefore implies having a "proprietary" gateway. Am I correct or am I on the wrong track ? Are there other solutions ?

We just added an implementation of TCP in OpenThread, you might find that helpful. Othewrise, I would strongly lean on your module provider to provide TCP if that is something you need. You could also consider UDP-based approaches, like CoAP, but I understand that many IoT cloud solutions do not support CoAP.

I'm sorry for all these questions, these are new and recent technologies so we have a lot of questions. Anyway, thank you for paying attention to our message, I wish you my sincere greetings.

Thanks again for reaching out!

--

Jonathan Hui

[Steven]

Hi,

First of all, I would like to thank you for your answer which enlightened us and allows us to learn more about OpenThread.

We really had doubts about the usefulness and the ability to integrate a border router in all our radiators. Your answer has really confirmed our choice and we will continue with this idea. Since our heaters are mains powered, not battery powered, this won't be a problem.

We decided to put Matter aside for the moment because it seems to be quite complex for development and we are constrained by time. However, we will have Bluetooth at the host level and at the RCP level, so we can integrate it later with an update.

We were not aware that the CoAP was directly in the OpenThread stack. That's why we decided to use this protocol to communicate with our servers. Thank you so much for sharing !

We have made good progress on the project, particularly on the border router, and we have some integration problems. We will create another post so as not to mix with this last one.

Thank you very much again for your help,
Sincerly,

Steven