Community feedback on migrating adapter with different chips

[antoinelibert]

Hello,

I have written a guide about an unofficial and unsupported method to migrate from one coordinator to another one with a different chip (like Conbee 2 to Sonoff P). This uses a third-party tool (zigpy, used in ZHA Home Assistant).

This discussion is to get feedback and to record successful migration attempts (most importantly, the combinations of chips used).

As a reminder, this method is highly experimental and is NOT supported by Z2M.

⚠️ It is recommended to read the entire guide before proceding.

Migrate to another adapter with zigpy

Warning

Migration from one adapter to another in Z2M requires backup and restore support which is so far only implemented for the zstack (Texas Instrument) and ember adapters. Backup and restore is not officially supported for any other adapters (conbee, ezsp, zboss and zigate). Please don't open issues about this method.

Migrating with zigpy is highly experimental and has only been tested on a few occasions. Migrating from, say, a "Conbee" adapter to "Zstack" is possible. This requires careful reconfiguration of Z2M to avoid breaking everything. This method is based on zigpy, a tool / library used by the native ZHA integration of Home Assistant, which supports migrating between all major adapter brands.

Be aware that this process essentially clones Zigbee network data. You will end up with two adapters with the same network address, and you will not be able to use the old adapter alongside the new one until you reset it and assign it a new network address.

This should work for any of the following combinations, but you might want to wait for more feedback:

• Conbees with firmware 0x26720700 or newer
• EmberZNet with firmware 7.4.0.0 or newer
• Z-Stack

This will not work with:

• ZiGate (can't set the PAN ID or export the network key)
• ZBOSS (no support of this adapter)

Current reported successful migration

Source	Destination	Tools/Notes
Conbee 2	Sonoff Dongle P	zigpy-cli 1.1.1, z2m 2.1.3
Conbee 2	SLZB-07	ezsp
Z-Stack	EmberZNet	z2m 2.1.3
Conbee 2	SLZB-06M
Z-Stack	SLZB-06M (EmberZNet)	zigpy-cli 1.1.0, z2m 2.2.1, SLZB-06M fw: 20250220
Conbee 2 (0x26780700)	SLZB-07mg24 (8.0.2 [GA])	zigpy-cli 1.1.0, z2m 2.3.0
RaspBee II (0x26780700)	Sonoff ZBDongle-E (7.4.4.0)	Z2M: v2.3.0
Conbee 2	SLZB-06 (CC2652P)	OS 20240710, ZigBee Firmware v2.9.2, z2m 2.4.0-1

Many thanks to all returning with feedbacks!

How to migrate

1. ❗ Backup your Zigbee2MQTT configuration and data. (THIS IS IMPORTANT, DO NOT SKIP IT. YOU MIGHT NEED TO RESTORE a file later to continue the process.)
2. Make sure you are running the latest version of Zigbee2MQTT.
3. Stop Zigbee2MQTT.
4. Install the latest firmware on both your current adapter and future adapter.
   • For Deconz (from or to), you must be using at least version 0x26780700 (latest for Conbee II).
   • Please refer to your adapter's documentation for firmware update instructions.
5. Install zigpy-cli on a computer. This requires Python 3.
   • Note on zigpy-cli installation: see Community feedback on migrating adapter with different chips #26716 (comment)
   • (Alternative) Use an HASS addon to run zigpy-cli (see Community feedback on migrating adapter with different chips #26716 (comment))
6. Unplug all adapters if any are still connected (just to be sure).
7. Connect your source coordinator (the adapter you are migrating from).
8. Backup your source coordinator with zigpy radio deconz /dev/ttyUSB0 backup deconz-backup.json.
   • This is an example using a Deconz adapter; please adjust accordingly. Some adapters may require additional parameters—refer to the zigpy-cli documentation.
   • (for ezsp), use this additional parameter --baudrate 115200
   • Tip: Run zigpy commands with the -v flag (e.g., zigpy -v radio ...) for verbose output, which helps in troubleshooting.
   • This command saves the important parts of your Zigbee network configuration, which currently reside inside your Zigbee stick.
   • Some warnings may appear; warnings like Unexpected transmit confirm or Unknown device AddrModeAddress can generally be ignored if you still obtain the backup JSON file at the end.
   • An empty devices section in the backup JSON file might be concerning but doesn't necessarily indicate a problem for the migration.
9. Disconnect the source coordinator and connect the target coordinator.
10. (optional) You can also backup your target coordinator before with the same command. You will be able to restore it to its original state if needed.
11. Restore the source coordinator backup to the target coordinator with zigpy radio znp /dev/ttyUSB1 restore deconz-backup.json.
    • This is an example using a Zstack adapter; please adjust accordingly. Some adapters may require additional parameters—refer to the zigpy-cli documentation.
    • This command converts and sends your Zigbee network configuration to your new target coordinator.
    • The restore process may take several minutes. DO NOT INTERRUPT.
    • If you get "Table full" errors during restore, try a complete power cycle of the target coordinator (not just unplugging/replugging).
12. Unplug and reconnect the target coordinator to your Z2M computer, even if it's the same computer.
    • For network-connected coordinators (like PoE devices), perform a complete power cycle.
13. Do not start Z2M yet.
14. Open Z2M's configuration.yaml file:
    • Update the adapter configuration section so it matches your new adapter.
    • This is located under serial. The important fields are port and adapter. Refer to Z2M configuration for details.
    • Double-check the port, as this is very likely to change with your new adapter.
    • If you use Docker, don't forget to update your container configuration.
    • If you had other fields configured under serial for your previous coordinator, comment them out. You might not need them anymore, and it's better to start with a default configuration for your new coordinator.
15. If necessary, rename coordinator_backup.json to coordinator_backup.json.backup to avoid Z2M complaining about backup file not correct for the new adapter
    • If Z2M complains about configuration mismatch after migration, you may need to manually specify the network settings from your backup:

      pan_id: 0xNNNN  # From your zigpy backup
      ext_pan_id: [xx, xx, xx, xx, xx, xx, xx, xx]  # From your zigpy backup
      channel: NN  # From your zigpy backup
      network_key: [xx, xx, xx, xx, xx, xx, xx, xx, xx, xx, xx, xx, xx, xx, xx, xx]  # From your zigpy backup

16. Start Z2M. Everything should work as before, and you won't need to re-pair devices.

Troubleshooting:

• If Z2M complains about the configuration being not consistent with state / backup
• If you encounter "Table full" errors when restoring to a network-connected coordinator (like PoE devices), try a complete power cycle rather than just disconnecting/reconnecting the USB.
• If most devices work but a few need re-pairing, this is normal. Some device types might be more sensitive to the coordinator change.

Sources:

• Add guide to migrate adapter including unsupported ones zigbee2mqtt.io#3586 (comment)
• Community feedback on migrating adapter with different chips #26716 (comment)
• Community feedback on migrating adapter with different chips #26716 (comment)

[ArneRanvik]

I was eventually successful migrating from deconz (ConBee2) to EZSP (SLZB-07), Z2M version 2.1.3:
When starting Z2M after change of adapter config, it said in logs that config differs from the adapter config and then created a new network. Here are steps that worked:

1. Follow guide, make sure to take z2m backup before starting
2. After fail, stop z2m and restore backup files
3. Manually change the coordinater_backup.json with data you pulled from your deconz. This includes IEEE address and any other fields that are different.
4. Make sure to put in your new adapter/serial config in z2m configuration.yaml
5. Start z2m again

[ArneRanvik]

Also, for all zigpy CLI commands for radio ezsp use --baudrate 115200

[antoinelibert]

Thank you for the feedback. I have updated the guide.

[SHxKM]

@ArneRanvik - I think I'm probably gonna pull a similar move soon with SMLight SLZB-06 (or newer). I'm currently on Conbee II which is working just fine but since backup/restore is not tested well with Z2M I'd rather take the leap right now and make the move to an environment where backup/restore has greater chance of working. How does SLZB-06 backup/restore flow look like?

[yozik04]

I have successfully migrated from Z-Stack to EmberZNet (7.4.4) without re-pairing by following the guide above. Z2M version 2.1.3.

One addition. I had to remove coordinator_backup.json. Otherwise I got error: z2m: Error: [BACKUP] Current backup file is not for EmberZNet stack..

[antoinelibert]

Thank you for the feedback. I have updated the guide.

[krzakx]

Hi!
What would be latest method of migrating from Z-Stack CC2531 to EmberZnet (Sonoff ZBDongle-E ?
I am asking because in table 3rd column I can see a needed tool is z2m 2.1.3 - so my understanding is that I do not need zigpy cli ?

[antoinelibert]

You still need zigpy cli because you need to copy the network configuration data from one stick to another. zigpy was not mentioned because OP didn't give the version.

[macraspberrypi]

Hi
I migrated my conbee2 to an SMLight SLZB-06M, then from Deconz to Ember, following this guide.
I didn't have to re-pair anything, and my 45 devices are working, thank you.

[SHxKM]

@macraspberrypi - Thanks for sharing. I think I'm probably gonna pull a similar move soon with SMLight SLZB-06 (or newer). I'm currently on Conbee II which is working just fine but since backup/restore is not tested well with Z2M I'd rather take the leap right now and make the move to an environment where backup/restore has greater chance of working. How does SLZB-06 backup/restore flow look like?

[art103]

Hi,
I've just migrated from zstack to ember (SLZB-06M, FW: 20250220).

It was not straight forward and I tried a mix of FW versions and manual merge of backup to coordinator_backup.json.

In the end, I think a power cycle is what was needed!
Although the instructions specify unplugging and re-plugging the target device, I was using an Ethernet connected PoE SLZB-06M.
Sure enough, power cycling via the PoE switch fixed the "Table full" errors I was seeing when restoring.

The next error was a z2m configuration one.
At some point I must have set a non-default extPanId and z2m was previously happy reading that from the old zstack stick.
I managed to get z2m to stop complaining about a configuration mismatch by setting the following in configuration.yaml:

pan_id: 0xNNNN
ext_pan_id: [<my pan id>]
channel: 11
network_key: [<my network key>]

Those values are in the zigpy backup, so no problem finding them.
Without this, z2m would create a new network each time, which meant I had to restore the stick each iteration.

Once the correct network was up, most devices came across without issue. A few Moes lights needed re-pairing, the majority didn't, and one device is refusing to (re)pair (Moes socket).
I suspect it is because I tried re-pairing the socket with the interim network - this had the same IEEE address but different key and pan_ids.

Despite the hour or so faffing, this was still much easier than re-pairing 50 odd devices - thank you!

Versions:
z2m: 2.2.1
SLZB-06M: v2.8.5.dev12 / 20250220
zigpy-cli: 1.1.0

[kiler129]

🎉 Reporting another successful migration in a network with over 100 devices:

• Source: Conbee II (running 0x26780700)
• Target: SMLIGHT SLZB-07mg24 (running 8.0.2 [GA])
• Zigpy-cli: v1.1.0
• Z2M: v2.3.0; didn't need to change config beyond the serial & adapter
• All passive devices appear to be reporting, did one OTA which succeeded, and "random" ~20 devices are controllable without an issue

A few notes:

• zigpy-cli installation
  • The official guide specifies using pip install zigpy-cli, which isn't ideal by itself, unless it's a separate dev machine/container. This installs the package in the global context of the whole system, which can potentially conflict with other packages.
  • On modern Linux distributions or on macOS this will cause an error saying that packages are externally managed (e.g. via apt). This should not be ignored as it can lead to a big mess in the system, despite the message suggesting ways around it.
  • A way safer way, which is very non-obvious for people not developing in Python is using python virtual environments that encapsulate a project:
    • Create: python3 -m venv someName
    • Activate: source someName/bin/activate (if not using bash/zsh see correct command in table)
    • Now the console prompt should change from e.g. john@desktop:~$ to (someName) john@desktop:~$
    • Use pip install zigpy-cli and any zigpy commands as normal
    • Exit environment: deactivate (should change prompt back to normal)
    • Remove: rm -rf someName as it's just a folder
• When running zigpy run it in verbose mode (zigpy -v) as it gives way more details about any problems and list full device addresses
• Warnings about Unexpected transmit confirm or Unknown device AddrModeAddress can truly be ignored; I've got both and "affected" devices work perfectly after migration
• My Conbee II backup has empty devices section, which was initially concerning but it doesn't seem to matter in this case

All in all, this should probably land in the official docs. Even if it's a bit of a "here be dragons" method it certainly works on any stack that is able to import/export addresses & keys.

[auanasgheps]

Happy to report that I successfully migrated from a RaspBee II, wich was undocumented until now!

• Source: RaspBee II (running 0x26780700). It runs the same chip as ConBee 2, but only connects to a Raspberry Pi via GPIO.
• Target: Sonoff ZBDongle-E (running 7.4.4.0)
• Z2M: v2.3.0; where I updated the config of serial & adapter
• 25 devices migrated

All tasks have been done on the Raspberry Pi4 running Home Assistant OS, no external devices are required.
To accomplish this, I have to tank tube0013 who made an add-on for Zigpy-cli, which you can find here

Proud to report this so you can add it to the main post!

Some considerations:
This add-on does not have the correct baudrate to work with the Raspbee II. I have submitted a PR to fix this.

I have followed the same steps in the main message, just adapted for this process. Here's an overview:

• Install the add-on
• Stop Z2M
• Make a bakup of Z2M configuration
• Configure the add-on to execute the backup command on the RaspBee II
• Run the add-on
• Verify that the data was backed up. The data will be in /config/tzb-zigpy-cli-tools
• Connect the new adapter
• Update the add-on configuration to restore the backup on the Sonoff
• Run the add-on
• Update the Z2M configuration.yaml, by editing the serial section like this:

  - serial:
  adapter: ember

• Just to make sure I also disabled start on boot.
• Shut down the Raspberry
• Remove the RaspBee II from the Raspberry
• Turn on the Raspberry
• Started Z2M manually
• ENJOY!!!

[ChrissHF]

Wow thanks for the guide! The migration worked great for me!
I used it to migrate deconz to zstack

• Source: Conbee II (running 0x26720700).
• Target: SLZB-06 (CC2652P) | OS 20240710 and ZigBee Firmware v2.9.2
• Z2M: 2.4.0-1
• Migrated 20/20 devices successfully

My Process and some notes:

• Installed the HASS zigpy-cli add-on
• Basic setup and update of SLZB-06
• Back-up Conbee2 via zigpy-CLI add-on
• zigpy-CLI Add-On couldn't connect to the SLZB via Network for some reason, so I used USB connectivity for the migration
• Restored the backup to SLZB-06
• Updated the Z2MQTT configuration and renamed the Backup-Files to [...].yaml.bak
• Tested everything with the SLZB still connected via USB
  • (had to powercycle the SONOFF ZBMINIR2, everything else immidiately worked. I mainly have IKEA buttons, Aqara sensors and some SONOFF switches)
• Changed the SLZB-06 and the Z2MQTT configs over to network connectivity

[DieselFuel147]

Smooth migration here from Sonoff Dongle-E to SLZB-MR1. (ember to zstack)

• Source: Sonoff Dongle-E (v8.0.2.0) - USB
• Target: SLZB-MR1 (Radio: CC2652P7) (v20250321) - Ethernet
• Z2M: v2.4.0
• TubesZB Zigpy-CLI Tools: v0.3.1.0
• Migrated 25/25 devices successfully

My notes:

• Followed guide as written using the HASS zigpy-cli addon.
• Also powered off all zigbee router devices at step 9 before disconnecting the source dongle, then repowered at step 16 before starting Z2M.
• When using zigpy-cli add on you need to always have both a "Device" radio option checked as well as something in the "Network Device" text field regardless of which one is being used. For source sonoff dongle E connected via USB, selected the port with "/dev/serial/by-id/usb-ITEAD_SONOFF_XXX". Then also used this same string in the "Network Device" field, but left the "Use Network Device" option unchecked. When restoring to the target SLZB coordinator, an unused device port was selected then the correct network device IP:PORT (10.200.1.100:7638) was entered.
• Updated Z2M "configuration.yaml" using suggested config from SLZB OS web interface of my adapter.
• No errors on startup, all devices reconnected fine, just had to "wake" some battery powered temp/humidity sensors for them to start reporting again.

[antoinelibert]

Hello,

FYI, you didn't need to do this for ember<>zstack. Migration is officially supported.

Thanks.

[DieselFuel147]

Ah okay thanks for the confirmation, I wasn't too sure if that included the backup/restore function as it does say "Note that when switching from zstack -> ember or ember -> zstack re-pairing might not be required, however results might vary as this is not officially supported."

[obones]

Just to report that I successfully migrated from Bitronvideo AV2010/10 using ezsp to a Sonoff Zigbee 3.0 USB Dongle Plus E (7.4.4 firmware) using ember

A few notes:

• I tried backing up the content of the Sonoff but I received an error message: raise NetworkNotFormed("Node is not part of a network")
  I figured out that's because I never used that adapter for anything, I migrated to it right after having taken it out of its box.
• I had to indicate ember in the configuration.yaml file, it was not properly detected by zigbee2mqtt if left empty
• After the first restart of zigbee2mqtt, I received various errors in the log:
  • Failed to ping 'Some device'
  • Failed to read state of 'Power socket' after reconnect
  • Failed to execute LQI for 'Another power socket'
• Clicking on some devices in the devices list was not opening the device page

Restarting zigbee2mqtt once more solved those issues.

I'll keep looking for oddities in the upcoming hours, but right now, it looks successful for my network with 30 devices

[accelle17]

I have migrated using this procedure from conbee2 to slzb-06 core 2.9.4 / zb coordinator firmware 20240710. The z2m add-on started ok and control most of the zigbee devices.
However there were a couple of downside:

• like most of tradfri switches (E1743) suddenly didnt report, the batteries went to zero and had to replace them to re-pair again.
• pairing using routers didn't work, had to use all.
• 2nd point might be due to missing_routers (almost all routers are on the list) when I did coordinator_check since I've tested joining via recently added 3rd reality switch and it works fine.
• the devices on the missing_routers are still controllable
• tested removing and adding a router listed on the missing_routers and I'm not able to join them (might be related to Not able to pair any device anymore, not even previously working ones (2.2.0 and up) #26948)
  I'm still looking for a way before I try to repair 100+ devices.

[antoinelibert]

Thank you for the report.

• like most of tradfri switches (E1743) suddenly didnt report, the batteries went to zero and had to replace them to re-pair again.

I can report a similar issue but I don't think this is related to the migration process but more some bugs with the coordinator chip (Zstack).

The E1743 seems to drain its battery when the connection to the router is lost for a certain time. I have burned 2 batteries in less than a month before noticing this when I migrated (it didn't occur with a Conbee 2 and even fully reset and re-pair, it would drain the battery each time I had a long enough power cut).

[accelle17]

Probably and maybe since most of my routers are reported offline by the coordinator, it keeps on looking and getting drained

[Ap0ph1s-W4ite]

Source: Sonoff Dongle-P (Z-Stack 20230507) - USB
Target: SLZB-06M (Radio: EFR32MG21) (v20250220) - PoE
Z2M: v2.6.0
TubesZB Zigpy-CLI Tools: v0.13.1

I have followed the guide to migrate my coordinator from a ZBDongle-P to SLZB-06M, but without success. I perform the backup from the ZBDongle-P (Z-Stack) and receive an error when I try to restore it to the SLZB-06M (Ember).

2025-08-06 19:07:25.785 d0f5a498-tzb-zigpy-cli-tools bellows.ezsp.protocol DEBUG Sending command  importLinkKey: () {'index': 15, 'address': 44:e2:f8:ff:fe:03:44:d7, 'key': 86:67:db:dd:b1:7e:36:5b:3e:53:6c:45:bd:79:61:9b}
2025-08-06 19:07:25.785 d0f5a498-tzb-zigpy-cli-tools bellows.ash DEBUG Sending frame DataFrame(frm_num=3, re_tx=False, ack_num=3, ezsp_frame=b'2\x00\x01\x0e\x01\x0f\xd7D\x03\xfe\xff\xf8\xe2D\x86g\xdb\xdd\xb1~6[>SlE\xbdya\x9b') + FLAG
2025-08-06 19:07:25.785 d0f5a498-tzb-zigpy-cli-tools bellows.ash DEBUG Sending data  337021a95a2b7d3a651d97b4da52b7d6cffb95fa7d3a93f83cb5aeaa2634851fa476ea7e
2025-08-06 19:07:25.816 d0f5a498-tzb-zigpy-cli-tools bellows.ash DEBUG Received data 3470a1a95a2b32b25994516c7e
2025-08-06 19:07:25.816 d0f5a498-tzb-zigpy-cli-tools bellows.ash DEBUG Received frame DataFrame(frm_num=3, re_tx=0, ack_num=4, ezsp_frame=b"2\x80\x01\x0e\x01'\x00\x00\x00")
2025-08-06 19:07:25.816 d0f5a498-tzb-zigpy-cli-tools bellows.ash DEBUG Sending frame AckFrame(res=0, ncp_ready=0, ack_num=4) + FLAG
2025-08-06 19:07:25.817 d0f5a498-tzb-zigpy-cli-tools bellows.ash DEBUG Sending data  8430fc7e
2025-08-06 19:07:25.817 d0f5a498-tzb-zigpy-cli-tools bellows.ezsp.protocol DEBUG Received command importLinkKey: {'status': <sl_Status.INVALID_INDEX: 39>}
2025-08-06 19:07:25.817 d0f5a498-tzb-zigpy-cli-tools bellows.ezsp.v13 WARNING Couldn't add Key(key=86:67:db:dd:b1:7e:36:5b:3e:53:6c:45:bd:79:61:9b, tx_counter=1003, rx_counter=0, seq=0, partner_ieee=44:e2:f8:ff:fe:03:44:d7) key: sl_Status.INVALID_INDEX

What could be the reason and solution for WARNING Couldn't add Key ... key: sl_Status.INVALID_INDEX?

[antoinelibert]

Hello, you don't need to follow this migration guide for zstack <> ember migration (both direction). Migration is officially supported directly by Z2M: https://www.zigbee2mqtt.io/guide/faq/#how-do-i-migrate-from-one-adapter-to-another

[npitts5397]

@antoinelibert thanks for the response. I tried the normal migration path first, but when I started up Z2M (2.6.2), it complained my zstack coordinator backup wasn't compatible. I don't recall the exact message, but since I backed out, I'll report back next time I give this migration a shot.

Edit: it's the error @Tediore shared below.

[Tediore]

@antoinelibert

I tried to move from a zstack adapter to an ember one using the method in the z2m docs, but z2m version 2.6.2 didn't allow it, saying that the coordinator backup is not from an emberznet coordinator. Not sure where to go from here. Do you have any suggestions?

[Tediore]

Update: I came across this guide and figured I'd give it a try with some modification. I appear to have successfully migrated from a zstack adapter to an ember adapter by doing this:

1. Stop z2m and make a backup of the z2m configuration directory.
2. Unplug the zstack adapter and plug in the ember adapter.
3. Copy the IEEE address of the zstack adapter to the ember adapter.
4. Delete coordinator_backup.json.
5. Update the z2m config with the ember adapter settings.
6. Start z2m.

All of the devices were still there when I started z2m (which makes sense since I didn't delete the database). I did have to reboot a few routers, and one of my Tuya contact sensors that was connected directly to the old coordinator was announcing itself every 30 seconds, so I assume it was a bit sensitive to the coordinator change. I re-paired it and it's behaving normally now.
(@npitts5397 you might be interested in this)

[kaechele]

I hit the same issue when doing a ZStack to Ember migration.
What ended up working for me:

1. Stop Z2M and Backup Config folder
2. Unplug ZStack Adapter, plug in Ember Adapter
3. Configure Z2M to point to the Ember Adapter
4. Delete coordinator_backup.json
5. Start Z2M (at this point all my devices were gone).
6. Stop Z2M
7. Z2M will now have generated a new coordinator_backup.json. Copy the metadata and stack_specific section of that JSON file.
8. Restore backed up config directory
9. Manually edit the coordinator_backup.json (which is now the old one, as we just restored this from the backup), replacing the metadata and stack_specific sections with the ones from the coordinator_backup.json that was newly generated earlier.

EDIT: I don't think it makes a difference, but somewhere in between I also installed this firmware on my SLZB-06M: https://github.com/Nerivec/silabs-firmware-builder/releases/download/v2025.6.2/smlight_slzb06m_zigbee_ncp_8.2.2.0_115200_sw_flow.gbl

[s8k3]

Had success with migrating from Slae.sh CC2562R Stick (zstack) to Raspbee II (deconz). The Raspbee II is connected to an ESP32 running esphome, which acts as a TCP to serial bridge.

Latest zstack firmware on the CC2562R, firmware 0x26780700 on the Raspbee II. Zigbee2MQTT version 2.6.1 and zigpy-cli version 1.1.
Had to use --baudrate 38400 on the Raspbee II. Took a couple of times to restore without errors, but I suspect the placement of the Raspbee II was the problem (behind a cupboard with lots of ethernet cables and a modem).

Updated zigbee2mqtt config to point to the new adapter and set baudrate, and that was it.

[Hedda]

For refererence, wrote instructions in many replies here in the past on migrating with zigpy-cli (contains more technical details + back-story):

• migrating coordinator from ZBDongle-E to ZBDongle-P #16478

• migrating coordinator from Conbee 2 to Conbee 3 #19785

• Sonoff Dongle P with Zigbee2mqtt can’t be swapped / replaced #20724

• Replace a Conbee II #14861

• Migrate from ZHA #16739

• Migrating back and forth between ConBee II (ConBee 2) and ConBee III (ConBee 3) using zigpy backup and restore? zigpy/zigpy-cli#41

Maybe you like to add those as sources for reference.

[gritting]

Success migrating from a source Conbee 2 (0x26780700) to a target SONOFF Dongle-P CC2652.

• zigpy-cli version: 1.1.0
• z2m version: 2.6.3

I will note that in optional step 10, I had to run the following commands in order to successfully backup the target coordinator (it was fresh out of the box and never previously used). Maybe it's a bit overkill to backup a brand new stick, but I wanted to do it anyway, just in case I wanted to restore back.

zigpy radio znp /dev/ttyUSB0 reset
zigpy radio znp /dev/ttyUSB0 form
zigpy radio znp /dev/ttyUSB0 backup sonoff-backup.json

And in step 14b, the documentation link led to 404. The location of the guide pages may have changed. I found this alternative instead: Refer to Z2M configuration for details.

Thanks for sharing this write-up, you saved me a lot of time not having to re-pair my devices!

[hajar97]

Anyone has migration experience from Conbee to EmberZNet, specifically Conbee III and ZBT-2? Would appreciate any feedback.

[Popoboxxo]

Hey everyone,
I’ve been trying to migrate from SLZB-MR1 (CC2652P7) to ZBT-2, but so far without success.
I’d like to keep using Zigbee2MQTT, so I’m looking for advice specific to that setup.
Has anyone gone through this process and could share tips or a step-by-step guide with me?
Any help would be greatly appreciated!

[samsam-rolon]

cross-posted on zigpy/zigpy-cli#58
Hello

I'm trying to migrate from deConz Conbee II (0x26780700) with Zigbee2MQTT (v2.6.3 on Hassio) to SLZB-06M (v3.1.3)
I'm facing this issue. I have the same issue on my Mac (ARM M2) AND my HassIO device (a smart board Odroid C2, ARM also)

Any idea ?

Same issue with restore and info

((zigpy-cli) ) ➜  ~ zigpy radio --baudrate 115200 ezsp /dev/ttyUSB0 info
((zigpy-cli) ) ➜  ~ zigpy radio --baudrate 115200 ezsp /dev/ttyUSB0 restore deconz-backup.json

((zigpy-cli) ) ➜  ~ pip list | grep zigpy
zigpy                     0.87.0
zigpy-cli                 1.1.0
zigpy-deconz              0.25.5
zigpy-xbee                0.21.1
zigpy-zboss               1.2.0
zigpy-zigate              0.13.4
zigpy-znp                 0.14.2

((zigpy-cli) ) ➜  ~ zigpy radio --baudrate 115200 ezsp /dev/ttyUSB0 reset
Traceback (most recent call last):
  File "/root/someName/lib/python3.12/site-packages/bellows/uart.py", line 105, in reset
    return await self._reset_future
           ^^^^^^^^^^^^^^^^^^^^^^^^
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/root/someName/bin/zigpy", line 8, in <module>
    sys.exit(cli())
             ^^^^^
  File "/root/someName/lib/python3.12/site-packages/click/core.py", line 1485, in __call__
    return self.main(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/someName/lib/python3.12/site-packages/click/core.py", line 1406, in main
    rv = self.invoke(ctx)
         ^^^^^^^^^^^^^^^^
  File "/root/someName/lib/python3.12/site-packages/click/core.py", line 1873, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/someName/lib/python3.12/site-packages/click/core.py", line 1873, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/someName/lib/python3.12/site-packages/click/core.py", line 1269, in invoke
    return ctx.invoke(self.callback, **ctx.params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/someName/lib/python3.12/site-packages/click/core.py", line 824, in invoke
    return callback(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/someName/lib/python3.12/site-packages/click/decorators.py", line 46, in new_func
    return f(get_current_context().obj, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/someName/lib/python3.12/site-packages/zigpy_cli/cli.py", line 20, in inner
    return loop.run_until_complete(cmd(*args, **kwargs))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/asyncio/base_events.py", line 691, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "/root/someName/lib/python3.12/site-packages/zigpy_cli/radio.py", line 161, in reset
    await app.connect()
  File "/root/someName/lib/python3.12/site-packages/bellows/zigbee/application.py", line 188, in connect
    await self._ezsp.connect(use_thread=self.config[CONF_USE_THREAD])
  File "/root/someName/lib/python3.12/site-packages/bellows/ezsp/__init__.py", line 159, in connect
    await self.startup_reset()
  File "/root/someName/lib/python3.12/site-packages/bellows/ezsp/__init__.py", line 141, in startup_reset
    await self._startup_reset()
  File "/root/someName/lib/python3.12/site-packages/bellows/ezsp/__init__.py", line 131, in _startup_reset
    await self.reset()
  File "/root/someName/lib/python3.12/site-packages/bellows/ezsp/__init__.py", line 164, in reset
    await self._gw.reset()
  File "/root/someName/lib/python3.12/site-packages/bellows/uart.py", line 104, in reset
    async with asyncio_timeout(RESET_TIMEOUT):
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/asyncio/timeouts.py", line 115, in __aexit__
    raise TimeoutError from exc_val
TimeoutError

[samsam-rolon]

Okay ... It was soooo a stupid issue ...
it works well when I set correctly the SLZB-06M in USB mode.
Regards