Zigbee stick migration - Just a little help - Has anyone used 'Migrate Radio' yet?

Configuration Zigbee
1

So I want to migrate from an old conbee to a new Sonoff 3 (verified supported). However, I cannot find much in the way of instructions for moving to a new stick.
Question one : does anyone know of a specific procedure out there? Something like. (not saying this is correct, but is an example of what I’m questioning).

  1. Plug in the new stick while the old stick is still in the system
  2. Select the configuration option for the existing ZHA integration.
  3. Select Migrate Radio.
  4. Remove Old Stick
  5. Reboot HA
  6. Live happy in a wonderful world

I have bee searching but have either been finding pre 2022.9 information or just a statement that the option is there and here is a list of supported sticks…

2 Likes
2

Ok, just decided to pull the trigger. Based on my experience…

  1. Go to the configuration on your current ZHA.
  2. Select “Download Backup” to get a current backup saved somewhere.
  3. Select “Migrate Radio”.
  4. In the next section tell it you want to change devices.
  5. It will wipe your old device and tell you to unplug it.
  6. I unplugged my old device and plugged in my new device
  7. The process asked me which device I wanted to add and I picked the new Sonoff.
  8. It asked if I wanted to restore a recent backup or upload one myself, I uploaded the backup I downloaded in step 2.
  9. It said I needed to change the IEEE address and that this was a permanent change, I said yes.
  10. Everything is working. No reboot of HA… Just worked!

Thank you to all the people who made this function work! I’ve wanted to replace this stick with a newer one for years now!

14 Likes
3

Unfortunately, my experience was not as smooth.

I bought a new Sonoff ZBPlus Dongle-E.

I’ve been using a ZBBridge (Wi-Fi). So I planned to migrate from ZBBridge → ZBPlus Dongle-E.

  1. I clicked on the “Migrate Radio” button. When it came to choosing the new radio, well it wasn’t there because I didn’t know I had to plug it in prior, I plugged it in, but the whole migrate process broke and gave unexpected errors. Eventually I hard reset my Pi 4 because rebooting from GUI did not want to work anymore.

  2. After reboot I clicked “Migrate Radio” and I did everything according to the on-screen instructions. I unplugged my old ZBBridge when prompted. And when I had to choose my new radio ("/dev/ttyACM0 - SONOFF Zigbee 3.0 USB Dongle Plus V2, s/n: 202207190xxxxx - ITEAD"), it picked it up flawlessly. Unfortunately uploading an automatic backup gave an unexpected error, sigh, hard reboot again.

  3. After reboot I first clicked “Download Backup” and opened it in text editor to confirm my Zigbee devices are defined in it, before continuing with steps from (2). This time it said it wanted to change the IEEE address, I confirmed. It gave a success popup.

Unfortunately, none of my Zigbee is working. not sure what I did but half of my devices are working, the other half not. Only the Aqara H1 switches reconnected when I quickly tapped their buttons 5 times in a row, other Sonoff and Aqara devices are refusing to reconnect/re-pair ???

The co-ordinator address is also still showing the old one??

Reboot did not help.

Will update here if I can get to the bottom of this.

4

I just migrated from the ZBBridge WiFi device this evening. Fortunately, I plugged in the new USB radio before starting. Followed all instructions, no problems encountered. Tested a few Zigbee devices, and everything appears to be working well. :slight_smile:

5

I have a question about the backup. All I see is the ConBee II coordinator, but I have a network with 51 devices and 310 entities.

image

But this is the content of the backup:

{
    "backup_time": "2022-11-09T16:16:48.985847+00:00",
    "network_info": {
        "extended_pan_id": "00:21:2e:ff:ff:07:15:4c",
        "pan_id": "4A79",
        "nwk_update_id": 0,
        "nwk_manager_id": "0000",
        "channel": 15,
        "channel_mask": [
            15
        ],
        "security_level": 5,
        "network_key": {
            "key": "31:35:32:37:32:61:62:37:31:34:33:66:35:66:36:32",
            "tx_counter": 6106511,
            "rx_counter": 0,
            "seq": 0,
            "partner_ieee": "ff:ff:ff:ff:ff:ff:ff:ff"
        },
        "tc_link_key": {
            "key": "5a:69:67:42:65:65:41:6c:6c:69:61:6e:63:65:30:39",
            "tx_counter": 0,
            "rx_counter": 0,
            "seq": 0,
            "partner_ieee": "00:21:2e:ff:ff:07:15:4c"
        },
        "key_table": [],
        "children": [],
        "nwk_addresses": {},
        "stack_specific": {},
        "metadata": {
            "deconz": {
                "version": 645400320
            }
        },
        "source": "[email protected]"
    },
    "node_info": {
        "nwk": "0000",
        "ieee": "00:21:2e:ff:ff:07:15:4c",
        "logical_type": "coordinator"
    }
}

Do I need to create Groups before this will work for me?

6

I’m looking to do this, and I’m curious if your zigbee channel changed during the process.

I WANT my channel to change, to get away from WiFi interference. I can’t find any way to set the channel in ZHA, and when i did it in Z2MQtt I had to re-pair all of the devices because they don’t realize the channel changed. I have another stick that I’ve configured on another Pi onto the channel that I want, so when I move it is that going to change when I restore the backup?

I wish I knew what I know now when I started down this path. I’ve migrated back and forth between ZHA and Z2MQTT so many times… Now I think I’m done using Z2MQTT and I’m going to ZHA permanently … I think.

Thanks.

7

I do not know if the channel changed for zigbee, but I do manually set my wifi channel so it avoids the zigbee frequency bands…

8

@snormonster

Any update? I have a similar issue. Just migrated from an old HUSBZB-1 to new Sonoff Dongle-E using the migrate radio button. All of my devices seem to be working without issue, but the coordinator itself shows as the old device.

When I select manage zigbee device and try to read the manufacturer and other attributes it fails (red exclamation). I selected to restore the automatic backup, and I wonder if I should have used the manual backup instead and removed the old coordinator details from it?

ETA - I removed the ZHA integration and re-added. The Sonoff device was discovered correctly, but I then restored an automatic update and it reverted to the old name again. I am testing removing the manufacturer info from the backup .json, or will resort to cleaning up and creating a new network / repairing devices.

Edit 2 - I reset the Sonoff (selected reset and create a new network). Home Assistant sees the USB device correctly, but when I add the ZHA integration, even after creating a new network, it comes in as the old HUSBZB-1 name… so aggravating.

9

I’m having the exact same issue with the name migrating from a conbee II to the new skyconnect. Tried rebooting, restoring automatic backup and restoring manual backup. I also get the red exclamation mark when trying to read info through the basic cluster.

I also had an issue with zigbee devices showing up but commands not going out to them that was fixed with restoring the manual backup instead of the automatic one.

edit: tried deleting the ZHA integration and setting it up from scratch, name is now correct but I still can’t read attributes from the coordinator, that might be unrelated then? New issue is that uploading the backup does nothing in this scenario and every zigbee device has to be re-added, oh well.

10

Deleting the ZHA integration hasn’t worked for me. Delete ZHA, reboot, discover ZHA as available via the Sonoff dongle…but when I complete setup (new radio, not pulling in any backup) the device changes to the old name.

I deleted all of the zigbee files in ./config. Maybe there is something in core.config or core.devices that I need to remove? It may be worth creating a new thread on the name issue at this point instead of continuing this solved topic which just happened to include the improper name reference.

11

If things work ie you have all devices reporting correctly you can rename the zha device to whatever you want , can’t you?

12

I may not have been clear on the issue - the device shows as the old hardware info even in core.device_registry. Or maybe I just misunderstand what I am seeing…

Home Assistant sees it as the Sonoff device at the hardware level, but once added / used by ZHA everything changes and the Sonoff references are gone.

Yes everything is working and I have sort of given up on fixing this for now, but it still bothers me. I can’t read attributes from the coordinator to try and force any updates. A few other ZHA threads showed screenshots of Sonoff coordinators showing the Sonoff details in ZHA so I went down the route of “something is broken” even though the zigbee network itself is functional.

13

I just went through the ZHA Migrate Radio procedure to go from a Conbee II to a Sonoff USB 3.0 (Itead) radio. I followed in guidance in this thread and the instructions in this article from The Smarthome Journey and everything worked exactly as expected. I don’t know if my Conbee II was beginning to fail or if my network had just grown too large for it, but the Sonoff is working like an absolute champ.

I did not need to restart HASS or remove the integration. I did not edit the backup file (although I later renamed the ZHA integration via the UI) and just used it as-is. The backup file appears to be just describing the network and the coordinator. I believe ZHA’s zigbee.db has all of the other network devices, which don’t need to change.

I’m very grateful for this functionality from whomever built it, such a nice feature and saved me several hours of re-pairing over a hundred devices.

1 Like
14

Just my experience.
Moved from Sonoff Zigbee 3.0 to the new SkyConnect on my HAOS running as a VM on a Synology.

I went to the Sonoff Integration > Configure > Download Backup > Migrate Radio > When it gets to “radio has been reset and you can unplug it” LEAVE THIS OPEN AT THIS WINDOW > Unplug Sonoff > Plug in SkyConnect > Go to Synology VM manager in DSM and navigate to the VM instance USB > Select the USB device Silabs (or SkyConnect) in the name > Return to HA > You can then progress to the next window by clicking submit > Select SkyConnect > Restore automatic back > Once it shows success > Click on Update Configuration > Voila done.

I added the extra step for the Synology VM aspect.
As others, the name of the integration remains Sonoff and not SkyConnect.
Not sure if this will have a bearing on future firmware updates.

15

Pls. correct it to “I went to the ZHA Integration”…

16

I had a lot of issues trying to go from the Nortek HUSBZB-1 to the SkyConnect. Since I’m still using the Nortek for z-wave devices I tried both leaving it plugged in and removing it, then adding it after the success messages. I don’t think ZHA plays well when there’s two hubs due to the IEEE addresses and looking at my device map it’s now showing both of the hubs as active. For now I removed the SkyConnect since there’s no matter devices and I still need the Z-Wave functionality. I had to hard reset about five of my twenty devices to get them pointing to the right hub and working again.

I figure I’ll tackle it later when I actually need Matter capabilities but thinking replacing the Nortek with a dedicated z-wave would be the easiest.

17

You’re correct about the ieee conflict.

When migrating the SkyConnect was given the ieee of the husbzb-1.

Unfortunately, I don’t think there is any way to “turn off” the zigbee side of the husbzb-1. If it is powered it will conflict. You would need to change the ieee on the husbzb-1 for the two to coexist.

Worst, from various forum traffic, I think changing the ieee on a SI Labs chip is a one time only option. So now that the ieee has been changed, the SkyConnect may never be able to be used along with the husbzb-1, even for Thread, unless you can change the ieee on the husbzb-1.

I know when testing with my Sonoff Dongle-E there was a not scary enough warning about it being “permanent” so I declined.

I hope I’ve misunderstood, and would be happily corrected.

18

So I wish I would have come across this thread before I tried migrating but here I am now, I was also migrating from a Nortek HUSBZB-1 to the SkyConnect. I’m still using the Nortek for z-wave devices so I need to keep it, but thought oh I will just remove the device from the docker container and all will be well. Not the case as now I think that since the IEEE address was changed on the Skyconnect to be the same as the HUSBZB, it still sees the HUSBZB as the coordinator, I guess through the Skyconnect? Anyways, does any one know how I can change the IEEE address of the Skyconnect, I don’t care at this point about re-adding devices (should have just done that to start). I think once I can do that it will not see the HUSBZB anymore since I will have removed any instance of the IEEE address that it had. Thanks.

19

I don’t think you can undo the address change on the SkyConnect. If you’ve already migrated, and the address of the SkyConnect has already been changed, the only option may be to change the address of the husbzb1.

See bellows/README.md at 94489cbc46e9e7b6b6562775d4f03cefae7de17e · zigpy/bellows · GitHub

20

Reading through this thread, I gave it a shot, migrating from a Sonoff Bridge (Wifi) to a Sonoff Dongle. I followed the steps from @Fronobulax 's post and got all the way through successfully. It even indicated something similar to this “Success … if you’re not using your existing gateway, turn it off now”. But when I examined the integration page, the old integration is still there, and it seems that nothing has changed, the devices are still connected to the old gateway. Need there be another step to remove the old integration and add another ZHA integration for the new dongle for this migration to work?
What if instead of doing the migration, can I just create a save of the existing “backup”, remove the existing integration, add a new integration with the new dongle, then restore the backup. Will this work?
Really hate to have to pair 57 devices all over again.