[REQUEST] Seperate repository with OpenThread Border Router (OTBR) RCP and NCP firmware images?

[Hedda]

Please consider if you might be interested in also providing OpenThread Border Router (OTBR) "RCP mode" firmware images well as "NCP mode" firmware images (with support for the OpenThread spinel+hdlc+uart protocol) for Silicon Labs EFR32MGxx adapters?

Short term goal would be to provide firmware for existing Silabs EFR32MG1x and EFR32MG1x based adapters that should be compatible with the "SiliconLabs Zigbee/OpenThread Multiprotocol Add-on" and "OpenThread Border Router Add-on" that Home Assistant developer agners (Nabu Casa employee Stefan Agner) is currently developing. Check out:

https://github.com/zigpy/zigpy/discussions/894

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

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

https://github.com/agners

https://community.home-assistant.io/u/agners/summary

https://groups.google.com/g/openthread-users/

FYI; Elelabs are already providing OpenThread RCP firmware with Spinel for their EFR32MG13 + an upcoming EFR32MG21 based adapter:

https://github.com/Elelabs/elelabs-zigbee-ezsp-utility

OTBR have a list of certified chips under "Thread Certified Component" which currently lists EFR32MG12, EFR32MG13. and EFR32MG21:

https://github.com/openthread/ot-efr32

https://github.com/openthread/openthread/tree/main/examples/platforms

https://openthread.io/vendors/silicon-labs

https://www.threadgroup.org/What-is-Thread/Thread-Benefits#certifiedproducts

The main reason for this request is that an "RPC" firmware with OTBR (OpenThread Border Router) support will make your adapter will be compatible with upcoming Thread 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. This addon by agners requires that the radio hard a firmware in "RPC" mode instead of the no traditional "NCP" mode:

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 so far agners has only worked with Silicon Labs based adapter with OpenThread "RPC" firmware for Thread 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:

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

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

PS: By the way, you might be interested in the the "Matter" workshop that Home Assistant is holding on the 15th of June even if they are in that specific workshop will not use a Thread based controller or devices and instead use a WiFi (+ Bluetooth) based "Matter" devices:

https://www.home-assistant.io/blog/2022/05/29/matter-in-home-assistant-workshop-announcement/

https://www.youtube.com/watch?v=9fOHBl5w0_k

https://community.home-assistant.io/t/matter-in-home-assistant-workshop-announcement/426129/

[MattWestb]

MG12 and 13 is supported and some MG2X chips / modules (IKEA Marcus is not working looks like UATR problems but tuya MG12 modules looks working OK) and MG1P (Billy) is still one reference design for thread so is working but MG1B (tuya ZBGW and many other devices) is having zero support (or more true its deleted in GSDK 4.X or never implanted).

Silabs is closing the door for other manufacture chips in OTR by ditching direct Spinel protocol and tunneling it with there new CPC can only using Silabs RCP for Zigbee and Thread.

By the way great grating to our down under master firmware cooker Gary !!!

[grobasoz]

I'm a little reluctant to spend time with the current V7.1.x code base due to the fact it is very "new" and subject to change, and I currently have enough work on my plate with just Zigbee products and firmware. I normally test each firmware release but with Multiprotocol that's a rather big task. Now to the big issue I have with Multiprotocol - and my personal opinion only. A "normal" Zigbee Coordinator on a "significant" network (ie 100+ devices) actually spends quite a bit of radio time managing the network, let alone handling the device messaging. Thread/Openthread is just as demanding. I'm not entirely sure using a single RCP device is going to effective on anything but small/neat networks. I found this was the case with Zigbee/Bluetooth multiprotocol. The networks were just too unreliable. I would rather just slap another radio into the Coordinator...

[grobasoz]

Following on from the above comment. I did manage to get all the bits together to do a Zigbee and Bluetooth (no Thread yet) test using RCP multiprotocol. I wasn't impressed. When the Bluetooth did scanning for devices, Zigbee ground to a stop. Not sure whether it was something I was doing wrong as I'm still working my way through the code. I'll get Openthread running as well and see what happens when all protocols are running :D

[MattWestb]

I think the Zigbee - OTR RCP is in beta stage in the last GSDK but the RCP with BT (with Zigbee and / or OTR) is in alpha stag and all things is not working OK or not implemented in it.

Channel scan is problematic and if i remember right have Silabs disabling it in production the Zigbee stack because its blocking the network and the routeing is broken then the scan is running and with it it cant being Zigbee 3 certified.

Also OTR and Zigbee is using one fixed channel and BT is one jumper so its sounds as one not good combination with only one radio in the system. Zigbee and OTR shall working OK in the theory as long being on the same channel and using different pan- and extended pan-IDs.

For most of your system is not good running one RCP then if the host system is down then the Zigbee network is not working OK (TC is off line) compared with NCP then the trust center is still working if the host system is offline.

All the best form the sauna north to the cold south !!!

[Hedda]

Following on from the above comment. I did manage to get all the bits together to do a Zigbee and Bluetooth (no Thread yet) test using RCP multiprotocol. I wasn't impressed. When the Bluetooth did scanning for devices, Zigbee ground to a stop. Not sure whether it was something I was doing wrong as I'm still working my way through the code. I'll get Openthread running as well and see what happens when all protocols are running :D

I think that Silicon Labs meant only to use Bluetooth Low Energy (BLE) in combination with Thread/OpenThread for the new Matter/CHIP standard in the initial commissioning of new devices(?), so that an end-user can for example configure a new sensor device using Bluetooth on their mobile phone just to tell it which Thread network it should join?

Read example "Step 2" in https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/matter/chip_tool_guide.html#using which mentions commissioning a Matter/CHIP device via Bluetooth LE and then "Step 4" mention you enter credentials that will be used in the device commissioning procedure to configure the device with a network interface, such as Thread (or Wi-Fi).

So doubt that you are really meant to be able to use it with Bluetooth devices for anything other than the initial commissioning.

Believe however I read that @agners who is the Home Assistant developer of the Home Assistant Yellow/Amber (and the upcoming Home Assistant SkyConnect USB Stick) is not actually using the Bluetooth on the EFR32MG21 but are instead relying on a separate Bluetooth adapter (or the Bluetooth chip built-into the Raspberry Pi) when doing the initial commissioning of Thread-based Matter/CHIP standard devices?

Maybe better to ask him here -> https://github.com/zigpy/zigpy/discussions/894

[grobasoz]

As part of a firmware release I like to make sure the software actually works... and perhaps provide some test software. That's why I went down the Silabs Multiprotocol rabbit hole. Stefan (@agners) seemed to be making progress with his endeavors so I thought it time to try deliver some mcp firmware. However, I think I may wait a little longer for some of the "kinks" to be ironed out by Silabs?

[agners]

Now to the big issue I have with Multiprotocol - and my personal opinion only. A "normal" Zigbee Coordinator on a "significant" network (ie 100+ devices) actually spends quite a bit of radio time managing the network, let alone handling the device messaging.

Agreed, I think the multiprotocol solution might not be for large networks. A person with that many devices, likely will have multiple coordinator/border router capable 802.15.4 radios in the house already :sweat_smile:

It is mainly a good solution for new users: People don't have to choose between Thread and Zigbee at the start, they can mix and match. For power users Thread and Zigbee networks on separate channels definitely make sense (along with dedicated radios).

That said, I like the concept of having a rather dumb radio and most of the protocol on the host. So it still might make sense to have the (Multi-)PAN firmware running along with zigbeed on the host. We'll see how well that works in practice.

Also OTR and Zigbee is using one fixed channel and BT is one jumper so its sounds as one not good combination with only one radio in the system. Zigbee and OTR shall working OK in the theory as long being on the same channel and using different pan- and extended pan-IDs.

:100: I honestly did not look into Multiporotcol with Bluetooth for exactly that reason: Having the radio doing Bluetooth frequency hopping while doing Zigbee and Thread is just asking for troubles. Furthermore, I think just having Bluetooth at the coordinator location is also not that useful. Matter onboarding should be done through the phone.

[Hedda]

It is mainly a good solution for new users: People don't have to choose between Thread and Zigbee at the start, they can mix and match. For power users Thread and Zigbee networks on separate channels definitely make sense (along with dedicated radios).

I totally agree for now the general recommendation should at least be to use a dedicated adapter for Zigbee if the user has more than X amount of Zigbee devices. Alternatively recommend always using a dedicated adapter for Zigbee in "production" (so only suggerst that Zigbee and Thread be used at the same time in a non-critical test-environment.

I honestly did not look into Multiporotcol with Bluetooth for exactly that reason: Having the radio doing Bluetooth frequency hopping while doing Zigbee and Thread is just asking for troubles. Furthermore, I think just having Bluetooth at the coordinator location is also not that useful. Matter onboarding should be done through the phone.

Maybe me overcomplicating things, however I think it could perhaps make sense to have a multiprotocol adapter that supports the combination of Thread and Bluetooth LE, where the BLE part can be used for Bluetooth commissioning Matter/CHIP devices directly in Home Assistant without using a mobile phone, so that way a Matter/CHIP implementation with a Thread radio is guaranteed to also have access to a Bluetooth radio without the end-user having to buy a separate Bluetooth USB adapter.