For z2m, get the “P” and don’t look back. The TI chipset is what the primary z2m dev uses and will likely always be first among peers for z2m.
For ZHA, the opposite is true. The SI Labs chip used in the “E” is the same chip Nabu Casa chose for the Yellow and upcoming Skyconnect USB stick. It will likely be first for ZHA and HA Thread developments.
The Yellow/Skyconnect status should help bring parity between the two to z2m, but I wouldn’t wait.
I don’t think either chip has a clear advantage looking at the spec sheets.
FYI, the upcoming 2022.9 version of Home Assistant will feature a new UI and backend/core functions for backup and restore/recover in Home Assistant’s native ZHA integration to export/save or import/restore Zigbee network ZHA backup images from within Home Assistant’s UI (in the GUI for the ZHA integration) to make migration to a new adapter easy in ZHA.
It should even make migrations to or from ZHA and Zigbee2MQTT or vice versa between them relatively easy compared to how it has been in the past since both ZHA and Z2M now use support the same “Open ZigBee Coordinator Backup Format” standard that was developed in collaboration between ZHA/zigpy and Zigbee2MQTT developers.
I am however now sure if and how well Zigbee2MQTT itself handle migrations (backup and restore) between different radio adapters such as zstack/znp and ezsp when they are not of the same type to “upgrade” adapter in Z2M without migrating to ZHA.
Sorry if I was unclear, I did not mean to imply that the application level data would be migrated between the different applications or that the Zigbee network backups contain data about what you named your devices in the application layers of Home Assistant or Zigbee2MQTT. This type of Zigbee network backup will only backups and restores the “Zigbee network” (Zigbee network layer), meaning the Zigbee devices already joined/paired to your Zigbee Coordinator, so you should at least not need to go around your house in order to re-join/re-pair all your Zigbee devices with the Zigbee Coordinator, but the ZHA backup files using this “Open Zigbee Coordinator Backup Format” so it does not contain any data about application layers which technically have nothing to do with the Zigbee networking parts.
Zigbee2MQTT and vice versa will only be able to restore the backup of the Zigbee level, not a backup at the application level. To clarify; this new backup feature in Home Assistant’s ZHA integration will obviously never be specifically made to be a “ZHA to Zigbee2MQTT migration tool” nor a “Zigbee2MQTT or ZHA migration tool”. It is only that ZHA and Zigbee2MQTT both support saving the Zigbee network part of their backups using the same “Open ZigBee Coordinator Backup Format” standard which makes their “Zigbee network backups” compatible with each other for restoring/recovering the “Zigbee network” without having to re-join/re-pair all Zigbee devices.
The fact remains that this will still make migration between ZHA to Zigbee2MQTT or vice versa much easier than before since you do not need to re-join/re-pair all your Zigbee devices, which is not something that would usually take a very long time if have many devices and you have to first reset them all to factory default and then re-join/re-pair them one by one.
They have however updated text a little removing the mentioning of Z2M since the version was in beta, but Everything Smart Home took a screenshot of the beta release notes which as seen did mention it:
Yes the application will re-interview the device and that should be done automatically. That process would be the same if restoring a backup file “Open ZigBee Coordinator Backup Format” in ZHA or Zigbee2MQTT or any other Zigbee implementation supporting the same backup format.
Already joined/paired devices with properly coded Zigbee firmware should usually connect and be “re-interviewed” automatically within 24 hours but some devices, especially battery-powered devices may have to be manually woken up so that they will connect in order to send a state update, so if you for example have door/window sensors then you need to open the doors/windows and a button/remote device may need to have one of its button pressed in order to initiate a state change.
Some troublesome battery-powered devices with poorly written Zigbee firmware are however still known to need to have their battery removed and put back in in order to initiate a connection to the Zigbee Coordinator.
Still, the main point and purpose with these different applications using the same “Open ZigBee Coordinator Backup Format” standard is thjat that you should not have run around your house to factory reset any devices or go through the whole joining/pairing process with each and every one of your Zigbee devices when migrating from another playform that uses the same backup format standard if you restore from a valid backup made by either ZHA or Zigbee2MQTT, no matter if that backup was not generated in the same Zigbee implementation. So I think this compatibility will definitely be welcomed by many people with 100+ Zigbee devices wanting to migrate from Zigbee2MQTT to ZHA or vice versa.
Again, if you migrate from Zigbee2MQTT ot ZHA or vice versa then your automations and scripts will not automagically be updated and it does not restore the application layer which contains your device names and entities names, so you would still have a to manually fix your automations and scripts to use the newly given names or rename all your device names and entities names to match your old names.
The built-in restore of a backup file to migrate will as such not be automagic “next next finish” process.
Sorry no. I only have the dongle-p. As far as I can tell there isn’t really any benefit choosing the e over the p other than the configurable power level. P dongles are well supported and I can’t see any reason for anyone to change their coordinator out.
EFR32MG2x (and EFR32xG1) chip adapters like these then it will have the newer Gecko Bootloader (GBL) that has the ability to enter bootloader mode automatically via software (also known as Auto-BSL) without the need to press holding physical BTL/reset button or short circuit any GPIO/soldering-pads. Silicon Labs can also be flashed over USB/UART by manually putting them in bootloader / BSL mode (also known as boot mode or firmware recovery mode.
For flashing Silabs EFR32MGxx chips checkout these different methods:
With some trail and errors, I manged to get the xmodem and serial connection fuctioning and were able to communicate with the stick, launching the probe command and gtting a readout.
The stick is already in use (having replaced a Conbee II). However I don’t know which firmware to choose.
in the Elelabs repo there are several firmwares in the folders /data/EFR32MG13/
In the folder /data/EFR32MG21/
Wich one of these sould I flash the Dongle-E V2 with? It will be the only coordninator on a rpi with latest home assistant version, running zha connected through a usb2 hub.
Shoud I use one of rhese or preferabli one on the meny other firmwarws available on different gits?
As I have spent quite some time getting Python for win and the Elelabs tool to work, I hope to use this tool for flashing.
That tool is good to use but none of those includee firmware images are for ZBDongle-E as those included images are only for Elelabs own adapters. Instead get firmware image from the links in my original post above, so either the one from ITead’s GitHub or from community developers if feeling brave.
Ah so it was, so it looks like converter support for “ZBDongle-E” with Zigbee Router device firmware has been added to zigbee-herdsman-converters 7-days ago, so likely Zigbee2MQTT ”Edge” (dev branch) will support it now but not in the master branch (mainline) or any stable releases as yet, see:
If you want to track it further to see check when it will get added to Z2M stable release then also see: