Multiprotocol consistently mismatches channels

[Jonathanese]

Describe the issue you are experiencing

Addon: Silicon Labs Multiprotocol
Version: 2.2.0
Device: Sonoff Zigbee Dongle-E
Firmware: RCP Multi-Protocol

Every time I set up the SiLabs multiprotocol plugin and integrations, I immediately get an error saying the channels are mismatched. It sets the Zigbee channel to 25, and the Thread channel to 15.

I try to change the Thread channel by running Form on the OTBR page, setting it to 25. This tends to get rid of the error, but I can't pair anything via Matter. It finds the device, connects, generates the credentials, sends the credentials, then checks the connection. And it always fails at that last step, which I assume is a Thread issue because of a new network which perhaps the rest of the system hasn't detected.

I try to change the Zigbee channel, but rather than letting me change it, it says "This is configured by the Multiprotocol addon and must be changed in the hardware page". But there's no hardware page to set this. So it basically configures the channels wrong and prevents me from fixing it.

What type of installation are you running?

Home Assistant OS

Which operating system are you running on?

Home Assistant Operating System

Which add-on are you reporting an issue with?

Silicon Labs Multiprotocol

What is the version of the add-on?

2.2.0

Steps to reproduce the issue

1. Flash Dongle-E using the online flashing tool. Use the RCP Multiprotocol firmware.
2. Install the Multiprotocol addon. 460kbaud. Software flow control. OTBR enabled. Ports enabled.
3. Point ZHA to the multiprotocol virtual device
4. Thread and OTBR are auto-detected
5. Reboot Home Assistant OS to re-run detection
6. <Mismatched Channel" error usually occurs here as a settings notification>
7. In ZHA configuration, try to change channel. Prompt tells you you can't do so. References a page in "Hardware" that doesn't exist.

Try matter
8. Install Matter addon. Autodetected/Auto-Added to integrations.
9. On phone, try to add Nanoleaf A12 bulb.
10. Sequence: Finding Device -> Connecting to device -> Generating Matter Credentials -> Testing connection -> Connection failed

Try Change Channel
11. Open OTBR page
12. Go to "Form", and configure network for channel 25 with the name home-assistant. Defaults elsewhere
13. Click "Form"
14. After a bit, or perhaps a refresh, in the Thread integration -> Configure page, a second home-assistant network shows up with a border router. This time saying channel 25 instead of channel 15. Set this as the preferred network.
15. Retry the matter settings. Same failure condition.
...

System Health information

Raspberry PI 4
Sonoff Zigbee Dongle-E

Anything in the Supervisor logs that might be useful for us?

No response

Anything in the add-on logs that might be useful for us?

No response

Additional information

No response

[darkxst]

When using Home Assistant hardware, either Yellow or SkyConnect, then these devices will show up on the hardware page. This provides a config flow for these devices to setup MultiPAN. I assume the channel migration has been moved there as well. Previously it was possible to just set the channel in ZHA and reset Thread to pickup change.

Obviously the ZBDongle-E (and other generic dongles that support Multipan RCP) wont show up there, so I am not sure how to access the channel migration now. May need to work out a way to implement this for generic (i.e non HomeAssistant) dongles.

[agners]

When using Home Assistant hardware, either Yellow or SkyConnect, then these devices will show up on the hardware page.

From what I understand this is the only place when using Multiprotocol to change channels now.

@emontnemery thoughts? Do we have a work around/way to get this done for non-SkyConnect/Yellow users?

[darkxst]

I tested the SkyConnect integration with the ZBDongle-E (via updated USB filters) , which works well for channel migration. etc. I wonder if we could generalise this integration to also include support for the ZBDongle-E? However that doesnt really solve it for users of other dongles which lack sufficient USB data for auto-detection (i.e. EasyIot ZB-GW04 and Elelabs etc)

[pssc]

I too have this issue zigbee Mqtt is set to channel 22 but no way to set thread which seems to want to use 15 and is conflicting with my wifi bands... and was is fighting with zbmqtt? No luck with pairing devices (Nanoleaf Matter Essentials E27) but seems to be happy with the smartthings hub

[darkxst]

I can provide a rudimentry workaround until there is a better solution implemented.

Copy the following folder to `/config/custom_components'
https://github.com/home-assistant/core/tree/dev/homeassistant/components/homeassistant_sky_connect

Update the manifest.json with the usb data for zbdongle-E

{
  "domain": "homeassistant_sky_connect",
  "name": "Sonoff ZBDongle-E",
  "version": "0.0.1",
  "codeowners": ["@home-assistant/core"],
  "config_flow": true,
  "dependencies": ["hardware", "usb", "homeassistant_hardware"],
  "documentation": "https://www.home-assistant.io/integrations/homeassistant_sky_connect",
  "integration_type": "hardware",
  "usb": [
      {
      "vid": "1A86",
      "pid": "55D4",
      "description": "*sonoff*plus*",
      "known_devices": ["sonoff zigbee dongle plus v2"]
    }
  ]
}

You should now get a SkyConnect device show up in the hardware menu and you can use this perform the channel migration

[agners]

We'll add a Thread channel change feature in the Thread panel at one point. That will allow manually change the channels on Zigbee and Thread side.

Meanwhile, the API can be accessed internally, you can use curl to ask the OpenThread REST API directly to change the channel:

curl http://core-silabs-multiprotocol:8081/node/dataset/active | \
  jq '.ActiveTimestamp.Seconds = .ActiveTimestamp.Seconds + 1 |
       {
         ActiveDataset: select(.),
         Delay: 30000,
         PendingTimestamp: .ActiveTimestamp
       } | 
       .ActiveDataset.Channel = 20' | \
  curl -X PUT http://core-silabs-multiprotocol:8081/node/dataset/pending -d@-

After 30s the pending dataset will be applied. You can watch the delay counting down by getting the pending dataset.

curl http://core-silabs-multiprotocol:8081/node/dataset/pending

[darkxst]

allow manually change the channels on Zigbee

How do you manually change Zigbee channel though? ZHA no longer allows this when using multiprotocol, and instead refers you to the non-existent hardware integration.

[pssc]

allow manually change the channels on Zigbee

How do you manually change Zigbee channel though? ZHA no longer allows this when using multiprotocol, and instead refers you to the non-existent hardware integration.

zigbee2mqtt allows you to set the channel and use multiprotocol.

[agners]

How do you manually change Zigbee channel though? ZHA no longer allows this when using multiprotocol, and instead refers you to the non-existent hardware integration.

Good point, that use case is not covered currently 😢

[darkxst]

@emontnemery thoughts? Do we have a work around/way to get this done for non-SkyConnect/Yellow users?

I'd be happy to look at implementing a solution for this, but any thoughts on the best way forward to provide access to channel migration in this case?

[francisp2]

I want to change the channel too, but move the ZHA channel to the Thread channel, and not move the Thread radio to another channel, as it forms one network with another Thread radio on another device.

My work-around was :

• install Zigbee2MQTT
• set the desired channel
• stop Zigbee2MQTT
• do a radio migration

And Zigbee channel is set to the Thread channel

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[francisp2]

Still no solution

[agners]

In pure Thread mode you get this option:

@francisp2 is this missing/not working in your case?

Typically, with Multiprotocol we coordinate the channel change, in that case it is available through the hardware menu (Settings > System > Hardware > Configure, then "Configure IEEE 802.15.4 radio multiprotocol support"). But if the Zigbee side is not under the control of Home Assistant Core, the above menu should allow channel change, if I am not mistaken.

[francisp2]

This I get when I want to change the Zigbee channel, but there is no multiprotocol under hardware.

Thread changing works, aligning Zigbee with Thread does not.

[agners]

Changing channel on the Zigbee side is only possible through the EmberZNet serial protocol (EZSP). From what I understand you are using Zigbee2MQTT? So this needs to be initiated from Z2M...

Thread changing works, aligning Zigbee with Thread does not.

So how did you change the Thread channel then?

[francisp2]

I only used Zigbee2MQTT to change the Zigbee channel, and then used migrate radio to have the new channel in ZHA

Changing thread here:

but if you then add ZHA, it will install on channel 25, and no way to change it to the same channel as Thread, unless you take a detour through Zigbee2MQTT and then choose 'migrate radio' to install ZHA.

[agners]

Ok wait, so I better understand: Your goal is to use Thread and ZHA, and change the channel of both? But there is no way as the hardware config is missing for the hardware you are using, correct?

[francisp2]

But there is no way as the hardware config is missing for the hardware you are using, correct?

correct

[calwip]

I ran into this same issue. Strangely, the channel numbers seem to stay out of sync when reconfigured through Hardware -> Home Assistant SkyConnect (e.g. it starts with Thread/Zigbee at 15/25, then if I reconfigure it to 11 for example, it will switch to 11/15, and so on). Maybe something is done out of order? (e.g. code sets Zigbee to Thread's channel, then configures the new Thread channel)

The workaround that I came up with was to go to Settings -> Devices & services -> Zigbee Home Automation -> Configure, then click Download Backup. This creates a .json with your current Zigbee settings. Open the file with a text editor, and under network_info you'll find channel - change this to the same channel as the Thread network. Then click Migrate Radio -> Reconfigure the current radio, and Upload a manual backup. Select your modified .json file, and the Zigbee network will be on the correct channel (maybe needs a restart).

Obviously it'd be nice if it just worked out of the box as intended, but this is a fairly easy workaround. Hope this helps.

[Onepamopa]

I haven't been able to get Thread working... I mean - the Nanoleaf app sees HA thread network in settings, but if I try to assign that hetwork to a led strip (currently BT connected) - the "select" menu is empty ....

[jtbandes]

Is there any update on a long-term solution for this issue? I just encountered the same problem after following basically the exact same steps as the original report. This workaround worked for me to change my Thread channel (although I have not successfully commissioned any Matter over Thread devices yet so I can't claim that it's definitely working).

Is it a bug that the Thread and ZHA integrations don't let you change the channel when using multiprotocol firmware? And/or, is it a bug that nothing shows up on the Hardware page?

[laurynas-pliuskys]

I am also having the same issue, is there a solution being worked on?

[shoyu63]

I have the same problem too. No idea to solve it. Thank you for any help.

[Ston3s]

Same here

[radulyz]

That's the best solution!
Got it working with no problems: Matter and ZigBee (ZHA) working excellently!
Worked perfectly!!!

The only thing I did differently, was that I completely removed all ZigBee devices first, then removed the ZigBee integration also after I downloaded the ZigBee network settings into the .json file. Corrected the ch to 15 (or whichever the Thread used (you can find it out from the config/integrations/integration/thread then configure/change channel it will display the current Thread ch). After everything was removed (ZHA) I reinstalled ZHA service/integration and loaded the network configuration from the saved .yaml file (with the changed ch number)

Original post from calwip - wrote it perfectly!

#3124 (comment)

I ran into this same issue. Strangely, the channel numbers seem to stay out of sync when reconfigured through Hardware -> Home Assistant SkyConnect (e.g. it starts with Thread/Zigbee at 15/25, then if I reconfigure it to 11 for example, it will switch to 11/15, and so on). Maybe something is done out of order? (e.g. code sets Zigbee to Thread's channel, then configures the new Thread channel)

The workaround that I came up with was to go to Settings -> Devices & services -> Zigbee Home Automation -> Configure, then click Download Backup. This creates a .json with your current Zigbee settings. Open the file with a text editor, and under network_info you'll find channel - change this to the same channel as the Thread network. Then click Migrate Radio -> Reconfigure the current radio, and Upload a manual backup. Select your modified .json file, and the Zigbee network will be on the correct channel (maybe needs a restart).

Obviously it'd be nice if it just worked out of the box as intended, but this is a fairly easy workaround. Hope this helps.

[satmandu]

Sorry to interrupt, but I have a SkyConnect dongle, which I assume is supposed to be supported for switching channels with multiprotocol...

[core-ssh ~]$ lsusb | grep Silicon
Bus 001 Device 006: ID 10c4:ea60 Silicon Labs CP2102N USB to UART Bridge Controller

But I don't see the Settings -> System -> Hardware -> Configure Option.

Is there some additional step to get the Hardware Configure option to show up?

[radulyz]

It's not done through hardware configuration, but integration configuration (config/integrations/integration/thread then configure/change channel and respectively: Settings -> Devices & services -> Zigbee Home Automation -> Configure)

For these to work you do have to have the dual stack configured on the USB device and also installed and configured the Silicon Labs Multiprotocol add-on for the device AND configured ZHA to point to it instead of the USB device directly...

The add-on and configuration are close to this video https://www.youtube.com/watch?v=j6x43lC9TkM
but you may be able to find something more relevant to the SkyConnect USB dongle...

[digitalresistor]

I have two Zigbee networks, with one Thread network:

1. Sonoff E dongle
   • zigbee2mqtt
   • Thread
2. Sonoff P dongle for Zigbee alone (ZHA)

Because there are devices that are better supported by zigbee2mqtt, and then there are devices that work better with ZHA.

• z2m: channel 20
• thread: channel 15 (claimed in the HA interface)
• zha: channel 25

I need to switch Thread to channel 25 to match my Apple Border Routers so I can join them into a single thread network, I may eventually migrate all my ZHA to a different channel so there is no overlap, but for now I can live with the overlap, and I have fewer devices in z2m than in ZHA so re-pairing them isn't as big of a deal.

The web interface won't let me do anything saying that ZHA is on channel 15 (false) and to go to the hardware -> configure (which is non-existent for my setup). I can update the channel to 25 in z2m however the thread channel does not change in HA, and it refuses to join the existing thread network because it still says it is 15.

I tried some of the work-arounds but I don't seem to be getting anywhere. Anyone got any suggestions?

[vypergts]

The web interface won't let me do anything saying that ZHA is on channel 15 (false) and to go to the hardware -> configure (which is non-existent for my setup). I can update the channel to 25 in z2m however the thread channel does not change in HA, and it refuses to join the existing thread network because it still says it is 15.

I tried some of the work-arounds but I don't seem to be getting anywhere. Anyone got any suggestions?

I'm having this same issue with my Sonoff E dongle with multiprotocol configured and Z2M. Changing the channel to match the Apple network in Z2M doesn't resolve.

[PaulSD]

I also ran into this problem, but managed to fix it by deleting the "Thread" and "Open Thread Border Router" integrations, then restarting HA and reconfiguring them.

More specifics:

• I'm using HA OS in a VM with a ZBDongle-E.
• When I first plugged the radio in with the OEM firmware, HA detected it and offered to configure it with ZHA. I clicked IGNORE.
• I used https://github.com/darkxst/multipan_flasher to flash the MultiPAN firmware.
• After flashing the firmware, I installed the "Silicon Labs Multiprotocol" add-on. The "Open Thread Border Router" and "Thread" integrations were automatically configured on channel 15.
• I then configured the ZHA integration, which automatically selected channel 25.
• If I tried to change the channel in the ZHA integration config, I got a popup that said: "Multiprotocol addon in use" "Zigbee and Thread share the same radio and must use the same channel. Change the channel of both networks by reconfiguring multiprotocol from the hardware menu."
• If I tried to change the channel in the Thread integration config, I got a popup that said: "The Thread radio has multiprotocol enabled" "To change channel when the Thread radio has multiprotocol enabled, please use the hardware settings menu."
• Of course, I do not have a Settings -> Hardware screen. I did not try darkxst's workaround above to make the Hardware screen work with the ZBDongle-E. (I didn't find that workaround until after I got this working.)
• Trying "Reset border router" in the Thread integration config didn't help; Thread still used channel 15 after the reset.
• Rebooting HA OS didn't help.
• I deleted the Thread integration, then deleted the Open Thread Border Router integration, then restarted HA (I did not reboot the OS).
• After restarting, the Open Thread Border Router integration was automatically configured. The Thread integration was detected but not auto-configured. I clicked the CONFIGURE button in the detected integration to reconfigure it.
• After that, both ZHA and Thread were using channel 25.

After fixing this, I ran into several other problems during Thread device provisioning (not related to this issue, but listed here to help others who may stumble across this), although I did eventually get a bunch of Thread devices (Nanoleaf Essentials Matter A19 bulbs) to work with Multiprotocol:

• Thread devices must be added via the Android App. They currently cannot be added via the Web UI or iOS App. (If you have a bluetooth radio attached to HA then there is an unsupported work-around that may allow you to add a Thread device through the HA API: I can’t add my Nanoleaf essential matter smart bulb in any way core#103257 (comment))
• When adding a Thread device, the phone/tablet running the Android App must be able to connect to the Thread Border Router via the Matter protocol (IPv6 w/ Router Advertisements and mDNS). When using the "Silicon Labs Multiprotocol" add-on, this means that the phone/tablet must be able to reach the HA network interface (that is being used as the "infrastructure" interface for the OpenThread Border Router running in the add-on) via IPv6 w/ Router Advertisements and mDNS. After the Thread device is added, only HA needs to be able to connect to the Thread Border Router (the phone/tablet no longer needs access to it). If the App gets stuck on "Checking network connectivity..." and eventually says "Can't reach device" and "Make sure your phone is connected to Wi-Fi", then the Android App is having issues connecting to the Thread Border Router. In my case, I had a non-IPv6 router between my WiFi and HA networks, and I had to temporarily bridge the networks so that the Android App could reach HA over IPv6 while adding the Thread device. Question: Is this something that could be eliminated, such that the Android App only communicates with the device via Bluetooth and passes any necessary info to HA, such that only HA needs to talk to the Thread Border Router?
• If you have multiple network interfaces on your HA system, then the first interface with a default route is used as the "infrastructure" interface for the OpenThread Border Router, and the phone/tablet running the Android App must be able to connect to this interface via the Matter protocol; Enabling connectivity between the Android App and other HA interfaces will not enable you to add a Thread device. (I have submitted a PR to permit a different HA interface to be configured/used as the "infrastructure" interface: silabs-multiprotocol: Make the OTBR infrastructure network interface configurable #3416)
• Something in either the MultiPAN firmware or the Multiprotocol add-on seems to get stuck fairly regularly, causing the Multiprotocol add-on to log messages like otbr-agent[...]: ... [W] Platform------: [netif] Failed to transmit, error:Parse. Attempting to add a device when these log messages are present will not work. Restarting the Multiprotocol add-on usually fixes it.
• There is was a bug in the "Matter Server" add-on (bug in version 5.0.1, now fixed in 5.0.2) which cause "Something went wrong" in the Android App and associated errors in the add-on log: "Something went wrong" when commissioning through Android app home-assistant-libs/python-matter-server#463 This has been fixed in the beta release, which you can install using the "Use the latest beta version" setting in the "Matter Server" add-on config.
• The Android App frequently gets stuck in a broken state which causes a message that says "Cannot connect to your device" and "Check your device instructions." Once this happens, all attempts to retry or restart the process of adding a Thread device result in the same error. Rebooting the phone seems to be the only way to clear the broken state. (None of the following help: Restarting the HA app, force stopping the HA App in Android Settings, disabling and re-enabling WiFi and Bluetooth.)
• The Thread device also got stuck a few times depending on where in the commissioning process things failed, and I had to reset it (turn it off and on 5 times) in order to try again.
• After working through all of the above, I still ran into intermittent failures in the "Checking network connectivity..." part of the provisioning process. It seems a bit flaky even when nothing is getting in the way of the Android App talking to the device via Matter. However, after a couple attempts with everything else working properly, it successfully completed the process and added the device to HA.
• After successfully adding a device, I could not successfully add another device until after I restarted both the Multiprotocol and "Matter Server" add-ons. (I ran into this problem repeatedly while adding multiple devices.)

After provisioning, I also ran into a number of problems during normal usage (also not related to this issue, but again listed here to help others who may stumble across this):

• Similar to the above, the Multiprotocol add-on will occasionally (maybe once every few days) get stuck in a state that causes otbr-agent[...]: ... [W] Platform------: [netif] Failed to transmit, error:Parse log messages and connectivity problems. This also sometimes happens when I restart the Matter Server add-on for unrelated reasons. Restarting the Multiprotocol add-on usually fixes it.
• Occasionally (maybe once a week), the radio hardware seems to stop working (I assume because the RCP firmware has crashed). This causes Info : Failed to connect, secondary seems unresponsive log messages. This also sometimes happens when I restart the Multiprotocol add-on for unrelated reasons. Physically unplugging and replugging the USB port for the radio then restarting the Multiprotocol add-on usually fixes it.
• After restarting the Multiprotocol add-on, I often need to restart the Matter Server add-on to get the devices to come back. Due to both this and the above two bullets, I've gotten in the habit of always restarting both the Multiprotocol add-on and the Matter Server add-on any time I need to restart either of them. I usually restart the Multiprotocol add-on first, then restart the Matter Server add-on immediately after (so they both go down and restart at about the same time).
• I have two Thread devices that have good connectivity to each other but relatively poor connectivity to the rest of the mesh. One of these two devices usually has a decent direct connection to my radio, but occasionally it gets disconnected due to noise or something, although it comes back online a few minutes later. The second device has no decent connections except to the first device, so it usually connects to the mesh through the first device. However, if the first device disconnects and reconnects, the second device never seems to come back online. I haven't thoroughly investigated this, but I suspect what is happening is that this code (which changes the retry behavior after the back-off retry timer exceeds 10min) isn't working right, such that if the second device is unavailable for long enough that the back-off timer hits this limit then the device never comes back.
• OTA firmware updates do not seem to be working for Thread devices that are managed exclusively by HA. If I understand it correctly, it looks like the problem (or at least part of the problem) is that the "Matter Server" add-on (more specifically, python-matter-server) does not yet support the OTA DFU user consent/approval messages. (And even when it does, those will have to be wired into the HA UI.) For Nanoleaf Essentials bulbs, you can update the firmware via the Nanoleaf App using Bluetooth while the bulb remains connected to HA via Thread, so the lack of automatic OTA updates isn't much of a problem. However, for other Thread devices, this could be a problem.

[darkxst]

You should be able to change the Thread channel using the instructions in #3124 (comment)

[darkxst]

Once the 4.4.0 firmwares are available, devices using EFR32MG21 should be able to support Zigbee and Thread on separate channels.

A new feature called Concurrent Listening allows the Zigbee and Thread stacks to operate on independent 802.15.4 channels when used
with the 802.15.4 RCP. This feature works on xG21 and xG24 parts only.


It functions by using the RX antenna diversity hardware block to switch extremely rapidly between two channels, approximately every
48 µsec. If a preamble is detected, it stays on the channel until completion of the packet. Because the switching is so rapid, packets on
either channel are received. When enabling the concurrent listening feature the PHY performance is slightly degraded. The sensitivity of
the IEEE 802.15.4 PHY in this mode drops to around -98 dBm for both the xG21 and xG24.
No configuration is required to enable concurrent listening. It is enabled automatically for the RCP image when built for xG21 or xG24.


The host stacks can select any 802.15.4 channels independently and do not need to coordinate with each other. If they do use the same
channel, then the rapid switching is not used and there is no sensitivity degradation.

[baldisos]

We'll add a Thread channel change feature in the Thread panel at one point. That will allow manually change the channels on Zigbee and Thread side.

Meanwhile, the API can be accessed internally, you can use curl to ask the OpenThread REST API directly to change the channel:

curl http://core-silabs-multiprotocol:8081/node/dataset/active | \
  jq '.ActiveTimestamp.Seconds = .ActiveTimestamp.Seconds + 1 |
       {
         ActiveDataset: select(.),
         Delay: 30000,
         PendingTimestamp: .ActiveTimestamp
       } | 
       .ActiveDataset.Channel = 20' | \
  curl -X PUT http://core-silabs-multiprotocol:8081/node/dataset/pending -d@-

After 30s the pending dataset will be applied. You can watch the delay counting down by getting the pending dataset.

curl http://core-silabs-multiprotocol:8081/node/dataset/pending

I can't seem to get this running.
When executed, all i get back is a 404.
Is there something i'm doing wrong here?

[darkxst]

I can't seem to get this running

core-silabs-multiprotocol is an internal dns name only available within HA, so you need to run these commands in a HA terminal/ssh.

Also you might need to expose the API port in the add-on config, not sure if that is needed or not

[baldisos]

Weird. I ran this through the Terminal addon:

I also exposed the API port:

Still it only gives back a 400 Bad Request.

[Splurch]

Just adding that I'm having the same problem using a Sonoff Dongle E and being unable to change the radio frequency. Changing the channel in the ZHA backup as per calwip worked but I couldn't get the curl command to work to change the Thread channel (or trying to get the Sonoff to show up in hardware using the skyconnect info) which I need to do to match up with my other border routers. Going to look into using separate radios for Zigby/Thread and am pretty frustrated overall. Would be nice if the documentation or error messages mentioned that there's no easy way to change channels unless you're using Skyconnect or HA Yellow.

[ronschaeffer]

The workaround that I came up with was to go to Settings -> Devices & services -> Zigbee Home Automation -> Configure, then click Download Backup. This creates a .json with your current Zigbee settings. Open the file with a text editor, and under network_info you'll find channel - change this to the same channel as the Thread network. Then click Migrate Radio -> Reconfigure the current radio, and Upload a manual backup. Select your modified .json file, and the Zigbee network will be on the correct channel (maybe needs a restart).

Thanks. This worked to change the ZHA channel, but none of my Zigbee devices are now available. They still show in the device list as per the backup. Is it normal that I would need ot re-pair them or something after the channel change? If that's not normal, any suggestions?

(I don't have any Matter devices yet.)

I have tried multuple restarts. I have also tried following the @calwip method with the original channel number in ordert to (I thought) restore the network as-was, albeit with the channel mismatch.

[ronschaeffer]

Thanks. This worked to change the ZHA channel, but none of my Zigbee devices are now available. They still show in the device list as per the backup. Is it normal that I would need ot re-pair them or something after the channel change? If that's not normal, any suggestions?

(I don't have any Matter devices yet.)

I have tried multuple restarts. I have also tried following the @calwip method with the original channel number in ordert to (I thought) restore the network as-was, albeit with the channel mismatch.

This (magically?) fixed itself. I manuall restored the backup with the original channel of 15 then restored again with channel 25, and all of the devices reappeared.

[LookedPath]

We'll add a Thread channel change feature in the Thread panel at one point. That will allow manually change the channels on Zigbee and Thread side.

Meanwhile, the API can be accessed internally, you can use curl to ask the OpenThread REST API directly to change the channel:

curl http://core-silabs-multiprotocol:8081/node/dataset/active | \
  jq '.ActiveTimestamp.Seconds = .ActiveTimestamp.Seconds + 1 |
       {
         ActiveDataset: select(.),
         Delay: 30000,
         PendingTimestamp: .ActiveTimestamp
       } | 
       .ActiveDataset.Channel = 20' | \
  curl -X PUT http://core-silabs-multiprotocol:8081/node/dataset/pending -d@-

After 30s the pending dataset will be applied. You can watch the delay counting down by getting the pending dataset.

curl http://core-silabs-multiprotocol:8081/node/dataset/pending

I'm currently using the Sonoff Dongle E with the multiprotocol add-on.
I want to setup the OTBR add-on but I don't seem to be having any luck with it.
Knowing that Zigbee and Thread had to use the same channel I used the curl call to set the Thread channel to 25, which is the same channel I have configured in Z2M.

Now when I try to add the OTBR as the default, Home Assistant complains that there's a mismatch between ZHA's channel and Thread's channel.
Since I've never used ZHA I don't understand from where it's pulling the channel value.

Is there any way around this?

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.