migrating coordinator from ZBDongle-E to ZBDongle-P

[ctrld-pl]

I'm currently using Zigbee2MQTT 1.30.0 with SONOFF ZBDongle-E (EZSP v9; Coordinator revision, 7.1.1.0).

How can I migrate to ZBDongle-P controller?

1. I cloned coordinator IEEE address with cc2538-bsl.py as per faq
2. Changed serial option in the configuration (adapter=auto)

But after restart I still see in herdsman log that he is trying to use ezsp protocol.
Should I edit coordinator_backup.json?
Maybe is there something more I should do?

{
  "metadata": {
    "format": "zigpy/open-coordinator-backup",
    "version": 1,
    "source": "zigbee-herdsman@0.14.89",
    "internal": {
      "date": "2023-02-02T11:01:36.607Z",
      "ezspVersion": 9
    }
  },
  "stack_specific": {
    "ezsp": {
      "hashed_tclk": "2dbac2772d67e91224dd854ca2b0b538"
    }
  },

[Koenkk]

Backup is not supported for the EZSP adapter, to migrate to the Dongle-P you have to re-pair all devices (start from scratch)

[Hedda]

Backup is not supported for the EZSP adapter

@kirovilya can you clarify this? I thought ezsp adapter now had experimental backup support but no ezsp adapter restore yet support?

Koenkk/zigbee-herdsman#598

Koenkk/zigbee-herdsman#319

[kirovilya]

In ezsp adapter, a backup is made, but a restore is not. For example, my test instance backup.json:

  "metadata": {
    "format": "zigpy/open-coordinator-backup",
    "version": 1,
    "source": "zigbee-herdsman@0.14.89",
    "internal": {
      "date": "2023-02-04T12:53:23.964Z",
      "ezspVersion": 9
    }
  },
  "stack_specific": {
    "ezsp": {
      "hashed_tclk": "c2a9a4986b776c8077fa44b8020c9888"
    }
  },
  "coordinator_ieee": "385b44fffe003677",
  "pan_id": "a8e2",
  "extended_pan_id": "dddddddddddddddd",
  "nwk_update_id": 0,
  "security_level": 5,
  "channel": 15,
  "channel_mask": [
    11,
    12,
    13,
    14,
    15,
    16,
    17,
    18,
    19,
    20,
    21,
    22,
    23,
    24,
    25,
    26
  ],
  "network_key": {
    "key": "01030507090b0c0f00020406080a0c0d",
    "sequence_number": 0,
    "frame_counter": 1
  },
  "devices": []
}```

[hvorragend]

And do I have to repair everything if I want to migrate from SkyConnect-adapter to ConBee2? I am afraid so

[hvorragend]

Yes, so it is.
I kept my ieee address, so that I just had to change the serial device.

[Hedda]

@Koenkk Can this be true? You wrote zigbee-herdsman does not support backup and restore for deconz adapter like ConBee?

[hvorragend]

Both sticks were previously activated in ZHA. Because a few days earlier I had used the SkyConnect in the ZHA. Then I did a radio migration to the ConBee adapter. Thus, the ConBee should have received the IEEE from the SkyConnect coordinator. As I said: That was all still in ZHA.

But then I wanted to switch back. So in Z2M from SkyConnect to ConBee, because I wanted to use the SkyConnect again in ZHA. Here in Z2M I just swapped the serial device.
It was funny that both sticks with the same IEEE and the same channel were active in parallel in ZHA and Z2M for a very short time. ZHA has therefore found many devices by itself. With your help I had created before a coordinator backup of the SkyConnect (as it was active in Z2M before) with zigpy-cli and restored it in ZHA.

Currently I am using the ConBee2 in Z2M only for ZGP. And everything else in the ZHA.
This looks like a good solution to me at the moment. I just have to wait until ZGP is implemented at some point.

[Hedda]

OK so then it is still true that Zigbee2MQTT's zigbee-herdsman frmework not support backup and backup restore for ConBee/RaspBee by dresden elektronik so can not perform migration with just Zigbee2MQTT if have deconz adapter, see -> Koenkk/zigbee-herdsman#665

[hvorragend]

If I understand correctly, then that is correct. Because I ended up doing a coordinator backup from SkyConnect with zigpy-cli.
I have not performed a backup or restore for the ConBee itself.

[hvorragend]

Other question:
Is it possible to migrate from SkyConnect to SonOff Dongle-E without repairing?

[Koenkk]

@kirovilya do you know if this is possible?

[kirovilya]

at the moment there is no procedure for restoring from a backup for the ezsp adapter in zigbee2mqtt. so I don't know how :(

[ctrld-pl]

Other question: Is it possible to migrate from SkyConnect to SonOff Dongle-E without repairing?

I don't recommend Sonoff Dongle-E.
You will have to life with the disappearing devices after reboots.

Dongle-P is better option.

[Hedda]

I don't recommend Sonoff Dongle-E. You will have to life with the disappearing devices after reboots.

Dongle-P is better option.

I think that that is an off-topic discussion here in this thread, and the current documentation already makes it clear which type of adapters are recommended or not recommended at this time -> https://www.zigbee2mqtt.io/guide/adapters/

Please understand that no offense is meant, I just do not want to see this thread which is about migration between different types of adapters getting too much off-topic with other things which are not directly related.

[Hedda]

Note! Neither deconz (ConBee/RaspBee) or ZiGate backup/restore is supported yet in zigbee-herdsman for Zigbee2MQTT as far as I know(?).

I believe that Zigbee2MQTT's zigbee-herdsman framework currently only support backup and restore for zstack adapter/driver (e.i. TI ZNP)?

And ezsp adapter in zigbee-herdsman framework for Zigbee2MQTT is suppose to supports backup now but not yet restore to ezsp adapter?

• https://www.zigbee2mqtt.io/guide/faq/#how-do-i-migrate-from-one-adapter-to-another
  • https://www.zigbee2mqtt.io/guide/adapters/flashing/copy_ieeaddr.html
  • https://www.zigbee2mqtt.io/guide/faq/#how-do-i-move-my-zigbee2mqtt-instance-to-a-different-environment
  • https://www.zigbee2mqtt.io/guide/faq/#what-does-and-does-not-require-repairing-of-all-devices

Not tested myself to migrate to other radio types using Zigbee2MQTT however as a workaround I think it should be possible to do a same-manufacturer migration using a stand-alone third-party software such as zigpy-cli to the backup and restore, (i.e. backup and restore using zigpy's command line tool)?

https://github.com/zigpy/zigpy-cli

Again while not tested it myself for Zigbee2MQTT I believe that it should even be possible to do a cross-manufacturer migration with this zigpy-cli tool(?), and if you can choose to override/overwrite the EUI64 (e.i. the Extended Unique Identifier which is the unique MAC address for the Zigbee Coordinator) then might be that you do not even need to re-pair all of your devices?

zigpy/zigpy#1152

Note! You will first need to stop/disable Zigbee2MQTT or any other application that is connected to the adapter!

Anyway, I think that you should be able to install zigpy-cli as a stand-alone tool with pip like this:

$ pip install git+https://github.com/zigpy/zigpy-cli.git

You will then need to correct zigpy radio type for backup and restore.

https://github.com/zigpy/zigpy-cli/blob/dev/README.md#network-backup

https://github.com/zigpy/zigpy-cli/blob/dev/README.md#network-restore

In addition, might need to append/set baud-rate (which is not same for all adapters) that is only briefly mentioned in the zigpy-cli readme:

https://github.com/zigpy/zigpy-cli/blob/dev/README.md#network-commands

Note! baudrate set to 57600 or 115200 is used in most application firmware however some newer ones might use 230400 and older ones might use slower, (but when talking to the bootloader for flashing firmware then a baud rate speed of 9600 is more commonly used instead).

Here s first an example of a command to do a backup to file from an ezsp adapter (e.i. backup from Silicon Labs EmberZNet/EZSP adapter):

$ zigpy radio ezsp /dev/ttyUSB0 backup ezsp-backup.json

Again, might need to append a specific baud-rate if it does not connect even though you already stopped other applications. Example:

$ zigpy radio --baudrate 115200 ezsp /dev/ttyUSB0 backup ezsp-backup.json

Followed by an example of a command to after that then do a restore from that file to a znp adapter (e.i. restore to TI Z-Stack adapter):

$ zigpy radio znp /dev/ttyUSB1 restore ezsp-backup.json

Alternatively, here is example of a command to instead do a restore from that file to another ezsp adapter (e.g. SkyConnect to ZBDongle-E):

$ zigpy radio ezsp /dev/ttyUSB1 restore ezsp-backup.json

Note! zigpy do not refer the the radio types the same way as Z2M. Also note zigpy-cli does not yet support zigate or xbee backup/restore :

Radio Type	Zigbee Radio Hardware
ezsp	Silicon Labs EmberZNet Serial Protocol, i.e. EZSP (e.g., Home Assistant SkyConnect, ITead Sonoff ZBDongle-E, Elelabs)
deconz	dresden elektronik deCONZ protocol (e.g., ConBee I/II, RaspBee I/II)
znp	Texas Instruments (e.i., CC2530, CC2531, CC2538, CC2652, CC1352, e.g. ITead Sonoff ZBDongle-P)
zigate	ZiGate Serial protocol (e.g., ZiGate USB-TTL, PiZiGate, ZiGate WiFi)
xbee	Digi XBee ZB Coordinator Firmware protocol (e.g., Digi XBee Series 2, 2C, 3)

PS: zigpy-cli have relatively recently consolidated cross-manufacturer backup and restore for zigpy, as before that you had to use the individual tools inside each separate zigpy radio libraries for different radio types to backup and restore (though once you had the backup file it even then allowed you to do a cross-manufacturer restore as long as you used the correct zigpy radio library for the restore, which was not the same as you used when you did the backup if you wanted to do a cross-manufacturer migration).

https://github.com/zigpy/zigpy-znp/blob/dev/TOOLS.md#backup-and-restore

https://github.com/zigpy/bellows#nvram-backup-and-restore

[hvorragend]

I am using the SkyConnect adapter in Zigbee2MQTT and have tried to backup everything via zigpy-cli.
It was just try and it wasn't working. It appears the following error:

Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/tasks.py", line 492, in wait_for
    fut.result()
asyncio.exceptions.CancelledError

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

Traceback (most recent call last):
  File "/usr/local/bin/zigpy", line 8, in <module>
    sys.exit(cli())
  File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/click/decorators.py", line 38, in new_func
    return f(get_current_context().obj, *args, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/zigpy_cli/cli.py", line 19, in inner
    return loop.run_until_complete(cmd(*args, **kwargs))
  File "/usr/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete
    return future.result()
  File "/usr/local/lib/python3.9/dist-packages/zigpy_cli/radio.py", line 116, in backup
    await app.connect()
  File "/usr/local/lib/python3.9/dist-packages/bellows/zigbee/application.py", line 124, in connect
    self._ezsp = await bellows.ezsp.EZSP.initialize(self.config)
  File "/usr/local/lib/python3.9/dist-packages/bellows/ezsp/__init__.py", line 104, in initialize
    await ezsp._startup_reset()
  File "/usr/local/lib/python3.9/dist-packages/bellows/ezsp/__init__.py", line 95, in _startup_reset
    await self.reset()
  File "/usr/local/lib/python3.9/dist-packages/bellows/ezsp/__init__.py", line 124, in reset
    await self._gw.reset()
  File "/usr/local/lib/python3.9/dist-packages/bellows/uart.py", line 258, in reset
    return await asyncio.wait_for(self._reset_future, timeout=RESET_TIMEOUT)
  File "/usr/lib/python3.9/asyncio/tasks.py", line 494, in wait_for
    raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError

[Hedda]

@hvorragend FYI, Home Assistant's own ZHA integration uses zigpy-cli for backup so it should work with the right packages/setup.

In addition you could try cross-posting the question to zigpy-cli discussions too:

https://github.com/zigpy/zigpy-cli/discussions

Looks like someone recently asked a similar question for ConBee to SkyConnect migration:

zigpy/zigpy-cli#24

Note that before backup for migration you will always need to upgrade the firmware on your old ConBee/RaspBee adapter before doing a backup! (That is however not needed if backing up an old Silicon Labs or Texas Instruments based Zigbee Coordinator).

The first question is if you installed zigpy-cli with pip like this or if you just downloaded it without using pip install command?

$ pip install git+https://github.com/zigpy/zigpy-cli.git

The obvious next question is if you first stop Zigbee2MQTT so that it is not still connected to the adapter?

Again, I also think that for some adapters need to set a specific baud-rate speed that is only briefly mentioned in the zigpy-cli readme:

https://github.com/zigpy/zigpy-cli/blob/dev/README.md#network-commands

Note! baudrate set to 57600 or 115200 is used in most application firmware however some newer ones might use 230400 and older ones might use slower, (but when in bootloader mode for flashing firmware then a baud rate of 9600 is more commonly used instead).

$ zigpy radio --baudrate 115200 ezsp /dev/ttyUSB0 backup ezsp-backup.json

Note that need to change to the correct com-port operating system as could be /dev/ttyUSB0 or /dev/ttyAMA0 or other port.

Note that if using Docker or a virtual environment then the installation and commands may differ.

Update! zigpy-cli is now available on PyPI -> https://pypi.org/project/zigpy-cli/

Since you can not yet get zigpy-cli via pip from PyPI then not sure if the setup gets and install all needed dependencies automatically?

https://pypi.org/project/zigpy/

https://pypi.org/project/bellows/

https://pypi.org/project/zigpy-znp/

pip install zigpy bellows zigpy-znp

And did you run setup.py from zigpy-cli first so that it gets all dependencies?

https://github.com/zigpy/zigpy-cli/blob/dev/setup.py

If do not install via pip then it might not automatically install all needed dependencies for zigpy-cli, zigpy, bellows, zigpy-znp, etc.?

[hvorragend]

Thank you for your detailed help. Most of the points were clear to me. But in the end it was the baud rate.

[Hedda]

btw, note that you have to change serial config in Zigbee2MQTT's configuration.yaml accordingly to which adapter migrate to as well:

https://www.zigbee2mqtt.io/guide/configuration/

https://www.zigbee2mqtt.io/guide/configuration/adapter-settings.html#configuration-of-the-zigbee-adapter

https://www.zigbee2mqtt.io/advanced/remote-adapter/connect_to_a_remote_adapter.html

Specifying no adapter in Zigbee2MQTT's configuration.yaml should make it default to Texas Instruments Z-Stack adapter.

serial:
  port: /dev/ttyUSB0

Example for making Zigbee2MQTT to otherwise force the use of zstack adapter (Texas Instruments Z-Stack ZNP based dongle):

serial:
  port: /dev/ttyUSB0
  adapter: zstack

Example for making Zigbee2MQTT to force the use of ezsp adapter (Silicon Labs EmberZNet based dongle) example:

serial:
  port: /dev/ttyUSB0
  adapter: ezsp

Example for Zigbee2MQTT in combination with the Home Assistant SkyConnect adapter/dongle/stick:

serial:
  adapter: ezsp
  port: /dev/serial/by-id/usb-Nabu_Casa_SkyConnect_v1.0_-if00-port0
  baudrate: 115200
  rtscts: true

Example for Zigbee2MQTT in combination with older USB ezsp adapter that uses lower baud rate and software flow control:

serial:
  port: /dev/ttyUSB1
  adapter: ezsp
  baudrate: 57600

Example for making Zigbee2MQTT to force the use of deconz adapter with old ConBee II or RaspBee II (deCONZ based dongle) example:

serial:
  port: /dev/ttyUSB0
  adapter: deconz
  rtscts: true

advanced:
  # Optional: Set the adapter delay, only used for Conbee/Raspbee adapters (default 0).
  # In case you are having issues try `200`.
  # For more information see https://github.com/Koenkk/zigbee2mqtt/issues/4884
  adapter_delay: 0

Example for making Zigbee2MQTT to force the use of deconz adapter with new ConBee III / ConBee 3 (deCONZ based dongle) example:

serial:
  port: /dev/ttyUSB0
  adapter: deconz
  baudrate: 115200
  rtscts: false

advanced:
  # Optional: Set the adapter delay, only used for Conbee/Raspbee adapters (default 0).
  # In case you are having issues try `200`.
  # For more information see https://github.com/Koenkk/zigbee2mqtt/issues/4884
  adapter_delay: 0

Example for making Zigbee2MQTT to force the use of zigate adapter (ZiGate based dongle) example:

serial:
  port: /dev/ttyUSB0
  adapter: zigate

Note! In addition, might sometimes have to add a specific baud rate to force that as well (which can be different depending on firmware).

Example of ezsp with forced baudrate speed of 115200 (but might also want to test 9600, 57600, and 115200 as most common rates):

serial:
  port: /dev/ttyUSB0
  adapter: ezsp
  baudrate: 115200

PS: If you are using Home Assistant Operating System then you can find the port path information under Settings>System>Hardware.

If have a Home Assistant SkyConnect adapter then click there on the menu button, select All Hardware and search for "SkyConnect":

[Hedda]

Off-topic but FYI; Home Assistant can do migration from Zigbee2MQTT to ZHA + migration from old adapter in ZHA to new adapter in ZHA:

• https://skyconnect.home-assistant.io/zigbee-migration-selection/

https://skyconnect.home-assistant.io/migrate-zigbee-zha/ (Guide on how to migrate from a Zigbee2MQTT network to ZHA using ZHA).

https://skyconnect.home-assistant.io/migrate-zigbee-backup/ (Guide on how to migrate a backup from Zigbee2MQTT to ZHA using ZHA).

https://skyconnect.home-assistant.io/migrate-conbee/ (Guide on how to migrate from a deCONZ/Phoscon network to ZHA using ZHA).

https://skyconnect.home-assistant.io/migrate-zigbee-zha-only/ (Guide on how to migrate old adapter to new adapter if already using ZHA).

Note! Those guides were specifically written for Home Assistant SkyConnect (ezsp) adapter and are for migration to Home Assistant's ZHA.

Also take note that before backup for migration you will always need to upgrade the firmware on your old ConBee/RaspBee adapter before doing a backup! That is however not needed if backing up an old Silicon Labs or Texas Instruments based Zigbee Coordinator.

Might be usable for other purposes but those guides are not meant to be used for migrating from ZHA to Zigbee2MQTT, nor migrating between different adapters if continuing to use Zigbee2MQTT (e.g. not for migrating old to new Zigbee adapter if using Zigbee2MQTT).

PS: Again, Home Assistant's own ZHA integration depends for backup and restore command from zigpy/zigpy-cli to migrate Zigbee network, however both that ZHA integration and Zigbee2MQTT use the same "Open ZigBee Coordinator Backup Format" standard for its backup files.

[hvorragend]

Absolutely awesome. Top!

[Hedda]

FYI, in related news ChrisHae posted he will look into "Open ZigBee Coordinator Backup Format" export and import in deCONZ/Phoscon API:

dresden-elektronik/deconz-rest-plugin-v2#12

PS: Also see related request -> Koenkk/zigbee-herdsman#665

[Tul47]

Any news on this? I should receive a ZBDongle-P soon, but converting from my ZBDongle-E will take me a week of splitting the house to get to all devices... Would be awesome if Z2MQTT could just do a backup/restore.

[nonamejuju]

Same here but from a conbee 2

[Hedda]

No news on ConBee/RaspBee backup from the deconz adapter developer, see/follow -> Koenkk/zigbee-herdsman#665

However if stop Zigbee2MQTT then you can migrate manually with zigpy-cli by following the other posts in this thread.

Note that before backup for migration you will always need to upgrade the firmware on your old ConBee/RaspBee adapter before doing a backup! (That is however not needed if backing up an old Silicon Labs or Texas Instruments based Zigbee Coordinator).

[Hedda]

Any news on this? I should receive a ZBDongle-P soon,... ...Would be awesome if Z2MQTT could just do a backup/restore.

zigbee-herdman does do backups for ezsp adapter, so you should be able to restore that to znp adapter -> #16478 (reply in thread)

Limitation with ezsp is that it can not restore to ezsp adapter, as so fart only znp adapter supports restore -> Koenkk/zigbee-herdsman#319

Same here but from a conbee 2

As for ConBee/RaspBee the zigbee-herdman library that Zigbee2MQTT depends on is still missing backup -> Koenkk/zigbee-herdsman#665

Until then can only do a partial migration from deconz using zigpy-cli as described in my comment above linked here -> #16478 (comment)

Note! There is currently no migration path to migrate all settings and devices for deconz (ConBee/RaspBee). This procedure with zigpy-cli only helps migrate the Zigbee network (i.e. the paring with devices). This means you at least will not have to re-pair all your devices again with the znp adapter. However, none of the higher-level settings will be migrated, so elements such as device names will be lost and will need to be manually entered again. There is currently no migration path to migrate all the settings. At least most powered devices like lightbulbs should be automatically re-connect over time (you can speed this up by rebooting the device) but your battery-powered devices may need to be re-joined to the network for the migration to complete.

[Tul47]

Hi Hedda,

So going from ezsp(ZBDongle-E) to znp (ZBDongle-P), can be done without zigpy?
Then I just do...

• Backup from zigbee2mqtt-tools
• Shutdown zigbee2mqtt
• Swap the coordinators, and change port name in zigbe2mqtt config.
• Restore by copying all the files to my 'config/zigbee2mqtt' folder
• ?

My new dongle is updated and ready to go... Would be amazing if I could get all devices back without re-pair. Some of them requires a 5m ladder to get to, and I no longer have one!

And thanks for the support here - Much appreciated!

[Hedda]

So going from ezsp(ZBDongle-E) to znp (ZBDongle-P), can be done without zigpy? Then I just do...

• Backup from zigbee2mqtt-tools
• Shutdown zigbee2mqtt
• Swap the coordinators, and change port name in zigbe2mqtt config.
• Restore by copying all the files to my 'config/zigbee2mqtt' folder
• ?

Yes I believe so, though probably also need to change adapter (radio type) from ezsp to z-stack in configuration.yaml at some point.

serial:
  adapter: ezsp

serial:
  adapter: z-stack

Tip: I think that if you just remove that completely from the configuration then Zigbee2MQTT should also default back to z-stack.

Anyway, since ezsp adapter supports backup but not restore, but zstack adapter supports both, it should work, (though not tested it).

https://www.zigbee2mqtt.io/guide/faq/

https://www.zigbee2mqtt.io/guide/faq/#how-do-i-migrate-from-one-adapter-to-another

(most mains-powered devices should reconnect relatively quickly, at least if they are Zigbee Router devices, however, battery-powered devices will take longer as they usually require a state change before reconnecting, but some devices like old Aqara/Xiaomi will almost always need to be manually re-paired/re-joined due to them having buggy firmware).

https://www.zigbee2mqtt.io/guide/faq/#requires-repairing

https://www.zigbee2mqtt.io/guide/faq/#doesn-t-require-repairing

PS: Again, it is it is another way that is not possible since ezsp adapter is still missing restore from backup, but you can follow development on that too here -> Koenkk/zigbee-herdsman#319

[Tul47]

Fantastic. I will give it a go and report back, over the coming days!

[Tul47]

Okay, first attempt was not successful... Maybe I am a little clueless.
I had to change setup in z2mqtt config AND in configuration.yaml, otherwise it would still say ezsp and look for this.
I didn't restore anything, because the files were still unchanged in the config/zigbee2mqtt folder after having changed adapter and restarted...
It doesn't seem to matter if I write the full dongle address or just /dev/ttyUSB1

I get this error:
Error: network commissioning timed out - most likely network with the same panId or extendedPanId already exists nearby

Then I deleted coordinator_backup and configuration.yaml - Now everything is generated new and database is clean, save for coordinator.
Adding everything back manually in these files, It still doesn't work... The devices appear, but there's no network route to them and they're not really connected.

I've gone back to the ezsp and backed up - So up and running again.
Any suggestions for next attempt? Zigpy backup?

[Tul47]

Ah, got it.
I didn't realize the zigbee adapter itself also held network data. Maybe that was why my manual file edit didn't succeed.
I'll give this a try - Thanks a lot.

[Hedda]

I didn't realize the zigbee adapter itself also held network data.

Yes the physical Zigbee Coordinator radio adapter dongle that runs in NCP ("Network Co-Processor") mode stores some of the Zigbee network config information, most importantly the security keys and well as the unique IEEE-address of an adapter to which the devices were joined/paired (that unique IEEE-address works kind of like a MAC-address of a network adapter), and when you restore ("copy") that same config to a other Zigbee Coordinator radio adapter then the devices will try to reconnect to whichever adapter which is online with that unique IEEE-address using the same network key. This is why you with this method do not need to re-pair your devices. So to clearify, Zigbee2MQTT is a Zigbee Gateway host application but the actual Zigbee stack runs self-contained on the NCP ("Network Co-Processor") which in this case is an MCU and 802.15.4 radio transciever SoC (System-on-Chip) from example Silicon Labs or Texas Instruments.

Note! Because the restore copies the unique IEEE-address it will cause a conflict if you ever bring the old adapter with the exact same unique IEEE-address. So if you plan on convert and reuse your old adapter as a Zigbee Router device on the same Zigbee network then you will first need to change the unique IEEE-address of the old adapter first, but that is really another topic (see example https://www.zigbee2mqtt.io/guide/adapters/flashing/copy_ieeaddr.html ).

[Tul47]

I've found this procedure described in more detail now, but they specifically state that it will only restore to the same type of adapter... I may be wishing for too much, trying to go from ezsp to znp with this... Don't want to brick my new adapter.

As an alternative, going to ZHA might allow me to do this without losing all devices.

I sometimes wish I had just built a dumb electric system in this house...

[Tul47]

Trying to follow any of these are an exercise in frustration... Half the commands are not recognized, it's Linux commands (sudo, dmesg, etc.), and I don't have a Linux setup to run them on...

EDIT: Tried Flash programmer 2 and Zigstar to change secondary IEEE address. Install driver, enter BSL mode, Both fail. On 2 different PC's. Nothing is easy...

[Hedda]

I've found this procedure described in more detail now, but they specifically state that it will only restore to the same type of adapter

I already made it clear above that the backup and restore function in zigpy-cli support cross different radio types, so it allow backup and restore to and from ezsp, znp (Z-Stack), and deconz (ConBee/RaspBee).

Note that before backup for migration you will always need to upgrade the firmware on your old ConBee/RaspBee adapter before doing a backup! (That is however not needed if backing up an old Silicon Labs or Texas Instruments based Zigbee Coordinator).

And again you do not have to the backup and restore in Linux, instead just move the physical radio adapter to a Windows or Mac computer and do that from it, all it needs is Python for Windows/Mac and correct USB-to-serial converter/bridge drivers for both adapters, but yeah it still require some basic knowledge of how to use a command line interference and using parametets to command.

Maybe you could ask a friend who is more computer savvy and have already used some Python script? It is really too hard nd time consuming for me to try to guide someone step by step. All the information is there but assume that you figure out how to get Python working yourself with access to the serial com ports.

As an alternative, going to ZHA might allow me to do this without losing all devices.

It is a little easier to go from Zigbee2MQTT to ZHA than the other way around since the latter (which depends on zigpy and zigpy-cli) has existing backup and restore support for all those radio types -> https://skyconnect.home-assistant.io/migrate-zigbee-zha/ (the method described above is practically the reverse process)

[Tul47]

I really appreciate all the help - I know I'm coming across a bit frustrated, I'm usually savvy enough to make most work, but this defeats me...

• I've managed to get zigpy up and running (had only installed zigpy before, was missingzigpy-cli).
• I've installed the relevant drivers for the interfaces, and they're recognized.
• On running the backup command (zigpy radio ezsp COM3 backup testfile.json) I'm now met with an asyncio exception.
• Tested on 2 PC's, several USB ports (USB 2/3) on each PC exactly the same result. Run in powershell as admin and without. Same result trying other zigpy commands (eg. info). With/without USB2 extension cable.

Any suggestions to what could cause this error? I can't google this...

EDIT: Okay, I think I did it... Among 1000 things tried, adding '--baudrate 115200' to the ezsp adapter call only, seemed to do all the difference. Backup file created and looks right. Pressing on tomorrow...

[Tul47]

Okay, I managed to do it - Thanks to the help gotten in here. Very grateful for that!
Just in case someone else is looking for how to migrate from ZBDongle-E to ZBDongle-P (for dummies), here's my full list of steps:

---

Remember to do a full backup before thinking about doing anything.

On the windows machine:
Install Python - I went with an older version (9.3), to avoid pesky issue with building wheels for aiohttp.
Install windows drivers for both dongles.
Stop z2mqtt on the HA machine and plug the ezsp dongle in the Windows machine.
Check in device manager under ports that driver is ok and note which COM-port it uses.
Open an elevated command prompt (admin priv.) and run the following commands:
pip install zigpy
pip install zigpy-cli (don't know if both are necessary, but that's what I did)
zigpy radio --baudrate 115200 ezsp COM3 backup mybackup.json (remember correct COM-port)
Switch out the dongles, and check again that znp driver is ok and which COM-port this uses.
Back to the command prompt and execute:
zigpy radio znp COM4 restore mybackup.json (again with correct COM-port)

On the HA machine:
Install file editor in HA, if not already there.
In file editor: download configuration.yaml, database.db and coordinator_backup.json, all from the config/zigbee2mqtt/ folder.
Make sure zigbee2mqtt is stopped, and disable start at system startup.
Shut down system and switch out the ezsp adapter for the znp.
At wakeup, find the port of the new adapter under settings/system. Mine was: /dev/ttyUSB1
In file editor, edit configuration.yaml and correct this address. Also change the adapter from ezsp to zstack
Rename database.db and coordinator_backup.json to different names - Or delete them (you have the backup).
In settings/addons/z2mqtt, edit the configuration to match the port and adapter as done in configuration.yaml
Start zigbee2mqtt, and wait a minute
If it fails to start giving some error about another network with same pan_ID likely exists nearby, unscrew the antenna from the adapter and try again.
When it has run to the point you can enter the webinterface, stop it again. It will have created a new database.db and coordinator_backup files.
In file editor, edit the database.db file. The first line is the coordinator, leave that. Any other lines are devices found, delete them, then paste from your backup of database.db, from line 2 to the end.
Start z2mqtt, and hopefully, everything works.

[Hedda]

zstack is the default, so simply removing ezsp in the configuration should make Zigbee2MQTT go with the default instead.

Note that there is much more detailed information about Zigbee2MQTT adapter configuration in one of my posts above.

[CaliPilot]

Thanks for this lifesaver! I've bought by accident the Sonoff P instead of the E and was always thinking that I'm using the Sonoff E and yes.. even with the EZSP-adapter setting didn't ring the bell hehe. Your walkthrough of the migration worked like charm but to get Z2M up again (after many failed attempts and even after waiting 2 hours) I had to switch off all my devices and routers - after that Z2M started up and I was able to add my devices to the Database.

Thanks!

Chris

[SkimmingGalaxies]

@Tul47 - Thanks for your write-up. I'm keen to make this work for myself too.

I have got to the point where I am getting the panID error, I have unscrewed the antenna, rebooted HA, unplugged and plugged back in as well as trying to restart z2mqtt multiple times but still get the panID error. Any thoughts on how to get past this?

Thanks!

[Tul47]

Hm, the point is to avoid it connecting to anything in your network as you (briefly) start Z2MQTT. Try wrapping the coordinator in aluminum foil or getting it physically removed from the rest of your network... You just need it to start up long enough for the files to generate.

[SkimmingGalaxies]

Just tried moving it physically to somewhere slightly different and waited a while and it worked! Thanks a lot for your time in responding.

[Shellazo]

Thanks, all of you. I just migrated from SkyConnect (EZSP) -> Sonoff Dongle-P (Stack/znp). I have 70 devices. Everything seems to have worked, perhaps a few small issues here or there, but otherwise good to go.

[Mikkooooo]

I have also switched over from Sonoff E to P with success.
Many thanks for all.
Now I will try from Sonoff P to SLZB-06.
Do I have to do the same procedure or is it easyer because the two have the same chip CC2652 P ?

[Hedda]

Now I will try from Sonoff P to SLZB-06. Do I have to do the same procedure or is it easyer because the two have the same chip CC2652 P

It will work doing the same produre using zigpy-cli (and that might be easier now that you know how and have everything prepared for that) but Zigbee2MQTT actually already have built-in support to backup and restore Texas Instruments Z-Stack radio adapters if both old and new adapter is based on CC2652/CC1352/CC2538, (it is only backup and restore for other radio adapters that is missing in Z2M), however you do also need to copy the ieee address of the old adapter into the new one if following Zigbee2MQTT’s official method, see FAQ -> https://www.zigbee2mqtt.io/guide/faq/#how-do-i-migrate-from-one-adapter-to-another

[MathijsG]

Just wondering, why would you switch from E to P? Doesn't The E have the newer/better chipset with possible future matter support as well?

[Hedda]

Texas Instruments CC2652/CC1352 based adapters are recommend for Zigbee2MQTT while Silicon Labs based adaptets are still listed as experimental (because still missing backup and restore function so not in feature parity), see:

https://www.zigbee2mqtt.io/guide/adapters/

And

Koenkk/zigbee-herdsman#319

If and when full support for backups and restore process is added to the ezsp adapter in zigbee-herdsman then I think you can expect that Silabs gets listings changed to recommend as well. At least I believe that is really the major showstopper for that now.

PS: As for Thread protocol support it has already been proven that it much better and far less complicated to simply use dedicated radio adapters for Zigbee and Thread protocols than having a single multi-protocol radio adapter (with or without Matter support).

[Hedda]

FYI, should now be easy to migrate (backup and restore) adapter via TubesZB Zigpy-CLI Tools add-on if using Z2M with Home Assistant:

https://github.com/tube0013/tubeszb_addons/blob/main/tzb-zigpy-cli-tools/DOCS.md

https://community.home-assistant.io/t/new-add-on-for-running-zigpy-cli-commands-like-energy-scans/669727/

Note! If plan on migrating to a Texas Instruments or Silicon Labs adapter then best upgrade firmware on new adapter before migrating.

PS: Tip is to use respective CC2652 Flasher or Silabs Flasher from TubesZB add-ons or ZigStar add-ons for upgrading adapter firmware:

https://github.com/tube0013/tubeszb_addons

https://github.com/mercenaruss/zigstar_addons

[Hedda]

You of course also need to change both the serial port as well as the baud rate speed in Zigbee2MQTT configuration file.

I believe that ConBee II uses 57600 baudrate and the new ConBee III uses 115200 baudrate.

Example from:

serial:
  port: /dev/ttyACM0
  adapter: deconz
  baudrate: 57600

to

serial:
  port: /dev/ttyUSB0
  adapter: deconz
  baudrate: 115200

[Mikkooooo]

Now I will try from Sonoff P to SLZB-06. Do I have to do the same procedure or is it easyer because the two have the same chip CC2652 P

It will work doing the same produre using zigpy-cli (and that might be easier now that you know how and have everything prepared for that) but Zigbee2MQTT actually already have built-in support to backup and restore Texas Instruments Z-Stack radio adapters if both old and new adapter is based on CC2652/CC1352/CC2538, (it is only backup and restore for other radio adapters that is missing in Z2M), however you do also need to copy the ieee address of the old adapter into the new one if following Zigbee2MQTT’s official method, see FAQ -> https://www.zigbee2mqtt.io/guide/faq/#how-do-i-migrate-from-one-adapter-to-another

Hi,
I want to migrate from Sonoff donle P to SLZB-06 and I want to do it the following way because I don't want to open the SLZB-06 and I don't want the need to repair all devices :

Install Python - I went with an older version (9.3), to avoid pesky issue with building wheels for aiohttp.
Install windows drivers for both dongles.
Stop z2mqtt on the HA machine and plug the ezsp dongle in the Windows machine.
Check in device manager under ports that driver is ok and note which COM-port it uses.
Open an elevated command prompt (admin priv.) and run the following commands:
pip install zigpy
pip install zigpy-cli (don't know if both are necessary, but that's what I did)
zigpy radio --baudrate 115200 znp COM3 backup mybackup.json (remember correct COM-port)
Switch out the dongles, and check again that znp driver is ok and which COM-port this uses.
Back to the command prompt and execute:
zigpy radio znp COM4 restore mybackup.json (again with correct COM-port)

Is it possible this way ???

[Hedda]

I want to migrate from Sonoff donle P to SLZB-06 and I want to do it the following way because I don't want to open the SLZB-06 and I don't want the need to repair all devices

Yes you can use zigpy-cli, however as mentioned a few times above, when both adapters are based on CC2652 (or CC1352) Texas Instruments adapters like those two are then you should not need to use zigpy-cli, Zigbee2MQTT does have built-in backup and restore support for CC2652/CC1352 Texas Instruments adapters, but you do need to change the IEEE address if you do not want to repair devices (which zigpy-cli also does as part of its restore process):

https://www.zigbee2mqtt.io/guide/faq/#how-do-i-migrate-from-one-adapter-to-another

Also see:

#20724

PS: Regardless, it is generally recommended to upgrade Zigbee Coordinator firmware on the new adapter before restoring backup:

https://www.zigbee2mqtt.io/guide/adapters/#flashing-cc1352-cc2652-cc2538-based-adapters

https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin

https://github.com/Koenkk/Z-Stack-firmware/discussions

[Mikkooooo]

Thanks, ist ist nessecary that the two coordinators have the Same FW ? Hedda ***@***.***> schrieb am Fr., 19. Jan. 2024, 14:21:

…

I want to migrate from Sonoff donle P to SLZB-06 and I want to do it the following way because I don't want to open the SLZB-06 and I don't want the need to repair all devices Yes you can use zigpy-cli, however as mentioned a few times above, when both adapters are based on CC2652 (or CC1352) Texas Instruments adapters like those two are then you should not need to use zigpy-cli, Zigbee2MQTT does have built-in backup and restore support for CC2652/CC1352 Texas Instruments adapters, but you do need to change the IEEE address if you do not want to repair devices (which zigpy-cli also does as part of its restore process): https://www.zigbee2mqtt.io/guide/faq/#how-do-i-migrate-from-one-adapter-to-another Also see: #20724 <#20724> PS: Regardless, note that it is generally recommended to upgrade Zigbee Coordinator firmware on new adapter before restoring backup: https://www.zigbee2mqtt.io/guide/adapters/#flashing-cc1352-cc2652-cc2538-based-adapters https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin — Reply to this email directly, view it on GitHub <#16478 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APJM4IWKXSSN76AWIHQVIC3YPJXMPAVCNFSM6AAAAAAUO46MFCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DCOBRGQYTG> . You are receiving this because you commented.Message ID: ***@***.***>

[Hedda]

No, that is why it is generally recommended to upgrade Zigbee Coordinator firmware on the new adapter before restoring backup. That is, suggest that you take the opportunity to upgrade it to the latest firmware recommended for Zigbee2MQTT (which is usually the latest from the "master" branch) before you migrate/restore to it.

PS: Regardless, it is generally recommended to upgrade Zigbee Coordinator firmware on the new adapter before restoring backup:

https://www.zigbee2mqtt.io/guide/adapters/#flashing-cc1352-cc2652-cc2538-based-adapters

https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin

https://github.com/Koenkk/Z-Stack-firmware/discussions

[Mikkooooo]

Now I will try from Sonoff P to SLZB-06. Do I have to do the same procedure or is it easyer because the two have the same chip CC2652 P

It will work doing the same produre using zigpy-cli (and that might be easier now that you know how and have everything prepared for that) but Zigbee2MQTT actually already have built-in support to backup and restore Texas Instruments Z-Stack radio adapters if both old and new adapter is based on CC2652/CC1352/CC2538, (it is only backup and restore for other radio adapters that is missing in Z2M), however you do also need to copy the ieee address of the old adapter into the new one if following Zigbee2MQTT’s official method, see FAQ -> https://www.zigbee2mqtt.io/guide/faq/#how-do-i-migrate-from-one-adapter-to-another

Hi, I want to migrate from Sonoff donle P to SLZB-06 and I want to do it the following way because I don't want to open the SLZB-06 and I don't want the need to repair all devices :

Install Python - I went with an older version (9.3), to avoid pesky issue with building wheels for aiohttp. Install windows drivers for both dongles. Stop z2mqtt on the HA machine and plug the ezsp dongle in the Windows machine. Check in device manager under ports that driver is ok and note which COM-port it uses. Open an elevated command prompt (admin priv.) and run the following commands: pip install zigpy pip install zigpy-cli (don't know if both are necessary, but that's what I did) zigpy radio --baudrate 115200 znp COM3 backup mybackup.json (remember correct COM-port) Switch out the dongles, and check again that znp driver is ok and which COM-port this uses. Back to the command prompt and execute: zigpy radio znp COM4 restore mybackup.json (again with correct COM-port)

Is it possible this way ???

Thanks again Hedda,

My Sonoff dongle P is connected via USB so I will do backup:

zigpy radio --baudrate 115200 znp COM3 backup mybackup.json (COM3 is the COM of my Sonoff dongle P)

but my SLZB-06 is connected via ethernet so I will restore :

zigpy radio znp socket://ip:6638 restore mybackup.json (the ip is the ip of my SLZB-06)

Is it OK so ?

Best regards,
Fischi

[Hedda]

I have no personal experience with such Ethernet-connected Zigbee Coordinator adapter, however it should work as that should just work as a serial proxy server that creates a TCP/IP relay tunnel to the UART port of the Zigbee Coordinator chip/module, but note that it is possible that the baudrate can be different (and yes you probably also need to use baudrate for Ethernet-connected Zigbee Coordinator adapters). You can read more about Ser2net (server-side) and Socat (client-side) for information on how the serial tunnling proxy works:

https://linux.die.net/man/8/ser2net

https://linux.die.net/man/1/socat

[Mikkooooo]

Thanks again, Hedda,

**I've got it working without zigpy cli.
The SLZB-06-team pointed me in the right direction, they wrote:

You need to install Python and and download the firmware CC1352P2_CC2652P_other_coordinator_20230507.hex from here https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin and download flasher script https://github.com/JelmerT/cc2538-bsl

The firmware command will look like this python3 cc2538-bsl.py -evw --ieee-address xx:xx:xx:xx:xx:xx:xx:xx -p socket://ip:6638 ./CC1352P2_CC2652P_other_coordinator_20230507.hex

replace xx:xx:xx:xx:xx:xx:xx:xx with the your IEEE and replace IP with IP of your SLZB-06

Also read the instructions on the Z2M website https://www.zigbee2mqtt.io/guide/adapters/flashing/copy_ieeaddr.html**

[KipK]

This thread is a jewel of good intels. Thanks @Hedda for your input. Saved me lot of headaches

[mspray]

[Hedda]

Yes it works great using the Zigbee Router firmware from ITead (then power it via USB-changer to make it into a stand-alone device), again as long as you change the IEEE address so that it does not have same IEEE address as your Zigbee Coordinator if you did a migration from it:

https://github.com/itead/Sonoff_Zigbee_Dongle_Firmware/tree/master/Dongle-E/Router

https://sonoff.tech/wp-content/uploads/2023/02/SONOFF-Zigbee-3.0-USB-dongle-plus-firmware-flashing.pdf

But please respect that it is very much off-topic here so please try discuss that elsewhere so not to hi-jack this thread, instead see example here:

#13373

And here:

https://community.home-assistant.io/t/itead-s-sonoff-zigbee-3-0-usb-dongle-plus-v2-model-zbdongle-e-based-on-silicon-labs-efr32mg21-20dbm-radio-soc-mcu/442695

[KipK]

so, I could migrate successfully from ezsp to zstack following also @Tul47 guidelines by generating a new database and editing it, and most important, shutdown all the routers for the first startup to generate a fresh db.
All works ok
Thanks a lot guys.

[spaggi]

I have done a successful migration from Sonoff E to P, thanks everyone!

Apart from some hickups, all devices work fine. However, what doesn't work anymore is pairing new devices.
Does someone have an idea that could help me?
Thank you!

[stich86]

looks like -E to -E is not possible right? IEEE address is not overwritten when restore the backup.

So the only way to go -E to -E (also with zigpy) is a full re-pairing of devices?

[danielponte]

So far, I believe thats correct. I believe there are no utilites to rewrite -E physical address (IEEE).

[Hedda]

I believe there are no utilites to rewrite -E physical address (IEEE).

I believe that NabuCasa's universal-silabs-flasher has support for it on paper is deprecated so not recommended:

• https://github.com/NabuCasa/universal-silabs-flasher

  • Write ieee fails NabuCasa/universal-silabs-flasher#64

    • AttributeError: can_write_custom_eui64 not found in COMMANDS  NabuCasa/universal-silabs-flasher#55 (comment)

[Hedda]

FYI, if you have an EFR32MG21 or newer Silcon Labs adapter then it can now be made to work more stable if migrate to new "ember" driver:

• Improved Ember (EZSP) driver (experimental) #21462

New "ember" driver for Zigbee2MQTT's zigbee-herdsman targets EmberZNet v7.4 firmware or later (that in turn uses EZSP v13 and above):

• New ember adapter implementation targeting EZSP 13 and above zigbee-herdsman#918

However if you still want to migrate to zstack then be aware that if you have an EFR32MG21 or newer adapter an option is to first migrate from the old "ezsp" driver configuration in Zigbee2MQTT to the new "ember" driver configuration then Zigbee2MQTT has native support for Zigbee network backup/restore for it, so be aware that if so then it should at least on paper be possible to migrate to zstack, (though as I am not longer using Zigbee2MQTT I have not tried the new "ember" driver and I have thus not either tested migrating from it to zstack). Check out:

• https://smarthomescene.com/guides/how-to-use-ember-driver-with-efr32mg21-zigbee-adapters/

• Migrate 1.37 sonoff zbdongle-e ezsp to ember tutorial ?  #22409

Note! I believe you first need to have EmberZNet v7.3 (EmberZNet 7.3.x.x) firmware while still using your old "ezsp" driver before can migrate to "ember" driver, and then after the migration from "ezsp" to "ember" I believe you might need upgrade to at least EmberZNet v7.4 (EmberZNet 7.4.x.x) firmware before try migrating to zstack. (Again, I am not longer using Zigbee2MQTT so have not tried migration to "ember" myself, nor from it to zstack). In theory once you upgrade the firmware to EmberZNet v7.3 (EmberZNet 7.3.x.x) Zigbee2MQTT should be able to make Zigbee network backup from the Zigbee Coordinator while still using the "ezsp" driver, and after it has created a backup you can stop Zigbee2MQTT and change the configuration to the new "ember" driver so you can start it with that instead, lastly Zigbee2MQTT with the new "ember" driver be able to create a new Zigbee network backup which then (in theory) can be restored to zstack (I think?).

PS: By the way; new "ember" driveror (Silabs) adapters is officially only supported with EmberZNet v7.4 and later firmware.

• https://www.zigbee2mqtt.io/guide/adapters/emberznet.html

• How to upgrade/migrate ZBDongle-E from 6.x firmware to 7.4? #22919

[Hedda]

I believe that Zigbee2MQTT's zigbee-herdsman framework currently only support backup and restore for zstack adapter/driver (e.i. TI ZNP)?

And ezsp adapter in zigbee-herdsman framework for Zigbee2MQTT is suppose to supports backup now but not yet restore to ezsp adapter?

• https://www.zigbee2mqtt.io/guide/faq/#how-do-i-migrate-from-one-adapter-to-another

  • https://www.zigbee2mqtt.io/guide/adapters/flashing/copy_ieeaddr.html
  • https://www.zigbee2mqtt.io/guide/faq/#how-do-i-move-my-zigbee2mqtt-instance-to-a-different-environment
  • https://www.zigbee2mqtt.io/guide/faq/#what-does-and-does-not-require-repairing-of-all-devices

Not tested myself to migrate to other radio types using Zigbee2MQTT however as a workaround I think it should be possible to do a same-manufacturer migration using a stand-alone third-party software such as zigpy-cli to the backup and restore, (i.e. backup and restore using zigpy's command line tool)?

https://github.com/zigpy/zigpy-cli

Again while not tested it myself for Zigbee2MQTT I believe that it should even be possible to do a cross-manufacturer migration with this zigpy-cli tool(?), and if you can choose to override/overwrite the EUI64 (e.i. the Extended Unique Identifier which is the unique MAC address for the Zigbee Coordinator) then might be that you do not even need to re-pair all of your devices?

zigpy/zigpy#1152

Note! You will first need to stop/disable Zigbee2MQTT or any other application that is connected to the adapter!

FYI, you can now alternatively also use the new ember-zli utils tool by @Nerivec to backup and restore EmberZNet (EZSP) based adapters:

• https://github.com/Nerivec/ember-zli

Ember ZLI depends on zigbee-herdsman's 'ember' driver (also by Nerivec) and its backups uses the "open coordinator backup" format:

• https://github.com/zigpy/open-coordinator-backup

Optionally it can also be used to backup and restore NVM3 tokens. Be sure to read the ember-zli wiki regardless:

• https://github.com/Nerivec/ember-zli/wiki
• and the Zigbee network

[apydo]

I'm currently working on a high availability setup to run Z2M on, and this discussion is somewhat related to.
The setup I imagine is based on 2 Proxmox LXC containers running Z2M on two Proxmox nodes (2-node cluster) using the same type adapters. In my test setup it's Sonoff ZBDongle-E.
Of course, the data (filesystem) is shared among these two Z2M instances and there is only one Z2M instance running at the same time.
When running Z2M container has any kind of hardware failure, it should restart on the second node to continue working with the same Zigbee network (no repairing here) and vice versa.
I wonder what I have to do to get this setup to work. Is IEEE address copy something I should care about while switching between two same adapters (ZBDongle-E <-> ZBDongle-E) ?

So... Is this the right place to discuss it? Should I open a feature request / an issue to discuss about it ?
Thank you for your help.

[Hedda]

So... Is this the right place to discuss it? Should I open a feature request / an issue to discuss about it ?

@apydo Highly recomment that you start a new discussion thread instead as it is only partially related, starting a long and off-topic discussion here would probably considered thread-jacking or at the very least going off on a tangent.

I wonder what I have to do to get this setup to work. Is IEEE address copy something I should care about while switching between two same adapters (ZBDongle-E <-> ZBDongle-E) ?

Suggest you get two Sonoff ZBDongle-P dongles instead as the CC2652P with TI Z-Stack firmware they are based on allow you to add/write a secondary IEEE address which is used instead, and that is harder to achieve on Silicon Labs EmberZNet based adapters like the ZBDongle-E.

PS: Off-topic but recommend reflashing your Sonoff ZBDongle-E adapters with Zigbee Router firmware and use as dedicated Zigbee repeaters/extenders.

[jerrm]

Someone had posted some failover scripts in the HA forums. Not sure how effective they are.

One issue is two sticks with the same address cannot be powered on at the same time, even if one is not in active use. That means some way to power off/on both sticks would be needed. If "Node 1" goes down, you you can't assume "Stick 1" is also down, there coulde be some sort of hardware issue where the system hung, but still powered. You would need to be able to cut power to it from "Node 2."

Another option would be a network attached coordinator shared between both nodes. There would still be coordination issues, and then the coordinator becomes the SPOF.

If I were to do it, I'd probably have two network attached coordinators attached through a managed POE switch where I could manage power at the POE ports, but I already have the switch.