Are there Disadvantages using RCP Multi-PAN over EmberZNet NCP?

[supaeasy]

I am currently using EmberZNet NCP on a Sonoff Dongle-E as coordinator along with a second one as a router. This is working very fine for me using Zigbee2MQTT in Home Assistant. I do have one Thread enabled device that is currently connected over Wifi (Nanoleaf).
I would like to tryout Thread/Matter and wonder if there would be any disadvantages when using multipan firmware over the Zigbee-only Firmware:

• Will there be performance or range downsides since the chip has to handle two protocols instead of one?
• Will it still work with Zigbee2MQTT? EDIT: It should work according to this post
  • I guess I would have to repair each and every device then, right?
    • If so: will Z2M remember my Devices if I switch the Dongle to a Mutlipan-Test-Dongle and switch back to the original one?

[Hedda]

Dongles are relatively inexpensive so recommend follow KISS principle and buy/use a separate dedicated radio adapter for each protocol.

• Check out this Zigbee buyer’s guide -> https://community.home-assistant.io/t/zigbee-buyers-guide/654695
  • If using Zigbee2MQTT then buy a ITead’s “Sonoff Zigbee 3.0 USB Dongle Plus” (model “ZBDongle-P” based on Texas Instruments CC2652P) to use a dedicated Zigbee Coordinator (flashed with latest Z-Stack-coordinator firmware).
  • Also buy several of ITead’s “Sonoff Zigbee 3.0 USB Dongle Plus V2” (model “ZBDongle-E” based on Silicon Labs EFR32MG21 to convert into dedicated Zigbee signal repeater / Zigbee range extenders by flashing them with Zigbee Router firmware and powering them with a simply USB-chargers, as while maybe not the prettiest solution to look at, if you make sure they are permanently powered then joining/pairing three or more to your Zigbee network and spreading them around in your home will create an extremely stable backbone in your Zigbee network.

• Will it still work with Zigbee2MQTT? EDIT: It should work according to this post

Yes it will work however the dependencies and support matrix is complexed since Zigbee2MQTT does not include the Silicon Labs CPC deamon running on the host that the solution is dependent on so you need to have something like the Silicon Labs Zigbee/OpenThread Multiprotocol Add-on for Home Assistant running on the computer with the adapter (and that addon in turn is only supported on Home Assistant Operating System), but regardless note that Silicon Labs EmberZNet Zigbee (EZSP) support in Zigbee2MQTT is still experimental so it not yet listed as recommended, instead it is currently recommended to use a radio adapter based on Texas Instruments CC2652P -> https://www.zigbee2mqtt.io/guide/adapters/ ...however many users are successfully using Silicon Labs EmberZNet Zigbee (EZSP) based adapters with Zigbee2MQTT (and IoBroker), see -> Koenkk/zigbee-herdsman#319 (it is still in "alpha" development stage after several years, mainly because backup and restore is still missing, though believe someone might be looking into that now)

• I guess I would have to repair each and every device then, right?
  • If so: will Z2M remember my Devices if I switch the Dongle to a Mutlipan-Test-Dongle and switch back to the original one?

Since there is not yet any backup and restore support for Silicon Labs EmberZNet Zigbee (EZSP) in Zigbee2MQTT there is not official way to migrate between different adapters, but there is an unofficial third-party workaround way described here Koenkk/zigbee2mqtt#16478

• Will there be performance or range downsides since the chip has to handle two protocols instead of one?

Yes there are downsides with RCP Multi-PAN and it is still also experimental, so it is instead highly recommended to have separate radios with one dedicated Zigbee Coordinator radio adapter and one or more dedicated Thread Border Routers (Thread Border Router adapter).

FYI, be ware that the RCP MultiPAN in multiprotocol mode is no longer recommended because running multi-protocol with multiple active networks on a single radio adapter has proven to not be stable when using Zigbee and Thread network protocols simultaneously on the same radio adapter, it also increases the complexity of software componennt dependencies needed, so if already using RCP Multi-PAN then it is highly recommended that you plan to migrate to separate dedicated radio adapters instead, (using Zigbee NCP and Thread RCP firmware respectively), even if using RCP MultiPAN on a single radio adapter dongle has been working fine for you so far.

I have write a more detailed explanation here -> https://community.home-assistant.io/t/zigbee-utilization-90-normal-for-130-devices/689065/15

So while using RCP Multi-PAN firmware does not technically affect range (as that is meant to be solved by having a proper Zigbee network mesh), but running in RCP Multi-PAN mode with both Zigbee and Thread protocols active at the same time does seriously affect the total amount of devices your can connect. There are many variables but I do not advise connecting more than 30 devices if using RCP Multi-PAN mode.

PS: They mentioned during the Home Assistant 2024.2 Release Party that the RCP Multi-PAN effort will be put on the backburner for now:

https://www.youtube.com/watch?v=8-YwXkgD3CY

[darkxst]

It does not affect range (as that is meant to be solved by having a proper Zigbee network mesh), but running in RCP Multi-PAN mode with both Zigbee and Thread protocols active at the same time does seriously affect the total amount of devices your can connect. There are many variables but I do not advise connecting more than 30 devices if using RCP Multi-PAN mode.

Fast channel switching introduced in 4.4.0 probably would cause a slight reduction in range if Zigbee and Thread channels are not the same. However prior to this Zigbee/Thread must share same channel or it would break things. But again you should have a proper mesh anyway.

Apart from limititing network size main disadvantages are

• Requires constant updating of firmware as each major 4.x release breaks ABI
• There have been recent stability issues with 4.4 and to some extent 4.3
• Matter/Thread support is still very experimental (but this applies equally to using standalone Openthread Firmware). I think its still generally recommended to use a external border router via Apple, Google or Amazon.

[Hedda]

PS: They mentioned during the Home Assistant 2024.2 Release Party that the RCP Multi-PAN effort will be put on the backburner for now:

https://www.youtube.com/watch?v=8-YwXkgD3CY

The reason why Home Assistant SkyConnect's firmware developer is putting RCP Multi-PAN effort on backburner is further explained here:

• https://www.home-assistant.io/blog/2024/01/25/matter-livestream-blog
  • https://community.home-assistant.io/t/the-state-of-matter/679508

There is a third, experimental, firmware option that supports multiprotocol, which allows the Silicon Labs chip in these products to connect to both Zigbee and Thread networks with one radio. We announced our intent to release a firmware supporting multiprotocol when we launched Home Assistant Yellow and Home Assistant SkyConnect, and this firmware has been available since December 2022. It integrates the Silicon Labs SDK, which adds this support for multiprotocol. During the further development and testing of the multiprotocol firmware, we have concluded that while Silicon Labs’ multiprotocol works, it comes with technical limitations. These limitations mean users will not have the best experience compared to using dedicated Zigbee and Thread radios. That is why we do not recommend using this firmware, and it will remain an experimental feature of Home Assistant Yellow and Home Assistant SkyConnect. If you currently have the multiprotocol firmware installed but don’t actively use it to connect to Thread devices, we recommend that you disable multiprotocol.

[Hedda]

FYI, Home Assistant has now updated their documentation to reflect this change with new recommendations not to use RCP Multi-PAN:

https://skyconnect.home-assistant.io/about-firmware-options/

https://skyconnect.home-assistant.io/about-multiprotocol/

https://skyconnect.home-assistant.io/procedures/disable-multiprotocol/

[jaztim]

For SkyConnect, it seems like an easy task to disable multiprotocol support, with no impact to the Zigbee network (ie no need to repair, etc).

I am using Sonoff dongle-e. How do I go about disabling multiprotocol and instead use it dedicated for the EXISTING Zigbee network? I am using zigbee2mqtt.

Will simply reflashing the dongle, replacing the Multi-PAN (RCP) firmware with Zigbee (EZSP) firmware do it... or will it kill the existing Zigbee configuration?

[darkxst]

For SkyConnect, it seems like an easy task to disable multiprotocol support, with no impact to the Zigbee network (ie no need to repair, etc).

Thats probably only true when using ZHA.

Will simply reflashing the dongle, replacing the Multi-PAN (RCP) firmware with Zigbee (EZSP) firmware do it... or will it kill the existing Zigbee configuration?

Yes it will wipe the network and require repairing all devices. However if you are using the new ember backend, it may take backups and later restore (not 100% sure on this though). Otherwise (and safest) you need to backup your current configuration using bellows or zigpy-cli, see this post here:

#84 (comment)

But in the case of multiprotocol, for the first step you should provide the network socket to bellows (instead of tty/COM device):

socket://<hostname-from-addon>:9999

[Hedda]

I am using Sonoff dongle-e. How do I go about disabling multiprotocol and instead use it dedicated for the EXISTING Zigbee network? I am using zigbee2mqtt.

Will simply reflashing the dongle, replacing the Multi-PAN (RCP) firmware with Zigbee (EZSP) firmware do it... or will it kill the existing Zigbee configuration?

If using Zigbee2MQTT then best ask in their community for latest recommendations -> https://github.com/Koenkk/zigbee2mqtt/discussions

I am not sure how well backup and restore is working today if using the ezsp adapter in Zigbee2MQTT but at least until recently there was no ability to restore from backup if using the ezsp adapter in Zigbee2MQTT, see -> Koenkk/zigbee-herdsman#319

Workaround before if using ezsp adapter in Zigbee2MQTT was to backup and restore with zigpy-cli, see Koenkk/zigbee2mqtt#16478

I believe that the new ezsp adapter in Zigbee2MQTT has full native support for backup and restore but I am not sure about migrations.

The new ember adapter is however suppose to replace old ezsp adapter Koenkk/zigbee-herdsman#918 and Koenkk/zigbee2mqtt#21462

FYI, Zigbee2MQTT has now also marked ezsp adapter as deprecated, see -> Koenkk/zigbee-herdsman#1039

Deprecated means it will no longer maintained and that users now have a grace period to migrate to the new ember adapter.

UPDATED: So their new ember adapter is suppose to fully replace old ezsp adapter but it does require EmberZNet 7.4.0.0 or later firmware.

PS: Note that all Silicon Labs based adapters are still "experimental" in Z2M -> https://www.zigbee2mqtt.io/guide/adapters/#experimental

[jaztim]

Thanks... it didn't seem easy so I took the opportunity to change channel and already started moving device by device to an existing dongle-p I had spare...

[bobloadmire]

I have the dongle-e with multiprotocol firmware. Can I just flash the regular zigbee firmware without destroying my zigbee network? or will I have to start from scratch?

[Hedda]

I have the dongle-e with multiprotocol firmware. Can I just flash the regular zigbee firmware without destroying my zigbee network? or will I have to start from scratch?

Backup to file before flashing and then restore backup from file after. If you do that then there should be no need to re-pair devices