I am planning on migrating from a ConBee II / Deconz setup over to Sonoff Zigbee 3 / Z2M. I have network of various Aqara, IKEA, Philips and Sunricher devices. Since the ZBDongle-E Z2M is not yet fully supported should I buy the “-P” version or wait a bit? I guess the support on “-E” might be some time off?
They are so inexpensive so a tip is to buy one of each (or better yet a few of each) because it is recommended to use ZBDongle-E and ZBDongle-P adapters as very good Zigbee Router devices by flashing these adapters with Zigbee router firmware to join in order to act as dedicated signal repeaters in your make your Zigbee network mesh to achieve best possible range and coverage. That way you will also have spares adapters at home and in use without being wasted, so you can always take on and repurposed by flashing back to Zigbee Coordinator firmware and then restore Zigbee network from backup in case your Zigbee Coordinator becomes corrupt or faulty.
Anyway, see Zigbee2MQTT discussion → https://github.com/Koenkk/zigbee2mqtt/discussions/13373
Summary;
The is nothing wrong with the ZBDongle-E hardware as this and other Silicon Labs based EZSP (EmberZNet Serial Protocol) adapters are very stable in Home Assistant’s ZHA integration as well as in other open-source applications such as OpenHAB and Domoticz, but Zigbee2MQTT’s “ezsp” adapter software code is not quite mature enough yet to be recommended to everyone, so it depends if you have an “early adopter personality” and are willing to help the community by acting as a tester who not only report all bugs/issues you find in a constructive manner to the Zigbee2MQTT project but also try to work with your fellow community members with narrow down those bugs in order to help the developers.
The lack of maturity of Zigbee2MQTT “ezsp” adapter is really a catch-22 problem because the “ezsp” adapter support has already been available in Zigbee2MQTT (zigbee-herdsman) for a long time however it still does not have many users who are active in the community, which is probably because it is not listed as “recommended”, so that it holding back the developnment of the “ezsp” adapter for Zigbee2MQTT (zigbee-herdsman) since not enough users in the community is actively helping the developers finding the remaining issues by working with them by reporting bugs and assisting in troubleshooting. This has meant that the “ezsp” adapter has remained experimental and kept alpha-stage maturity since the implementation was merged:
Much more deeper troubleshooting here → https://github.com/Koenkk/zigbee-herdsman/issues/319
Regardless, remember that Zigbee2MQTT (and zigbee-herdsman) is a free and open source project with only a few volunteering developers who work on that code as a hobby for fun in their spare time without getting paid for working on Zigbee2MQTT (and zigbee-herdsman). As such there is no deadlines or prioritization other than those that the developers put on themselves, which in FOSS/FLOSS project is usually only what falls under their own personal interests, so will be very individual.
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.
1 Like
I took the advice of @Hedda and bought one of each so that I can set up Z2M with the “P” version and also start some testing with the “E” version and contribute with testing and feedback.
1 Like
I purchased a -E last week and had nothing but issues with pairing using z2m. Purchased a -P a few days ago and it’s working perfectly.
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.
Anyway, see Zigbee2MQTT discussion → https://github.com/Koenkk/zigbee2mqtt/discussions/13373
How is that really going to work?
The linked spec appears to only be for the low level stick network data.
I see moving stick to stick within a platforn, but how is all the off-stick data stored in each db’s translated?
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.
Read the primary use case here → https://github.com/zigpy/open-coordinator-backup#rationale
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.
I don’t see how you get out of re-pairing or the functional equivalent if moving between ZHA/Z2M.
Seems like you’d have a functional mesh during transition, but at some point the devices would need to be interviewed to know what they are. Maybe an interview could be triggered as devices check in?
I guess we’ll see soon enough.
FYI, HA 2022.9 has now been released and release notes on news blog mention the new ZHA feature:
https://www.home-assistant.io/blog/2022/09/07/release-20229/#zigbee-backup-and-restore–migration
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:
https://youtu.be/wmYocYd0wts?t=309
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.
From other posts, it looks like they come back with default auto generated names.
We will still be running around the house figuring out what sensor is where.
It’s a great feature and improvement.
Docs should be edited to set expectations. Folks with existing nets are still effectively down for extended periods.
There are no docs about this feature/function as of yet, please feel free to contribute info about this:
HA is on my no-coding (or PR) list. It’s a crude method, but only way to manage my time.
Not completely opposed to tweaking some docs, but I can’t document what I haven’t personally tested.
I had been looking at the rc docs and had not realized they removed the line from the release docs.
Will wait and see what the powers that be officially bless.
Hi all,
Reading this, I see some people have flashed ZBDongle-E. Have anyone flash it for router in Zigbee2MQTT?. Is it working well?
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.
He is specifically asking about using ZBDongle-E as Zigbee Router, not as a Zigbee Coordinator (NCP).
https://github.com/itead/Sonoff_Zigbee_Dongle_Firmware/tree/master/Dongle-E/Router
vs.
https://github.com/itead/Sonoff_Zigbee_Dongle_Firmware/tree/master/Dongle-E/NCP
I flashed it with Zigbee Router firmware to repurpose it as a Zigbee signal repeater / Zigbee range extender device in ZHA but not Zigbee2MQTT, however, on paper it should be great for it. Ask here:
https://github.com/Koenkk/zigbee2mqtt/discussions/13373
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:
- Elelabs Firmware Update Utility (multi platform Python based command line tool)
- agners silabs-flasher - Silicon Labs Firmware flashing utility (multi platform Python based command line tool)
- walthowd husbzb-firmware script (community maintained multi platform bash script)
- Manual Xmodem sending commands over a terminal console (note that any terminal application with “Xmodem(N)” send can be used)
- Silicon Labs Simplicity Studio included “Flash Programmer” (instructions) (can’t find your device? read below!)
1 Like
And once again I’ve misread the question 
So still an unknown for Z2M at the moment?
Thank you for taking the time and elaborateing on the zigbee-topics @Hedda 
I have a [“ZBDongle-E” (“Sonoff Zigbee 3.0 USB Dongle Plus V2”)
I finally managed to install Python on my win11 laptop, using a USB2 hub and the Elelabs Firmware Update Utility → GitHub - Elelabs/elelabs-zigbee-ezsp-utility: Elelabs Zigbee EZSP Utility to perform firmware update on a range of Elelabs EZSP products as well as other generic EZSP adapters..
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/
ELE_MG13_ot_rcp_115200_120_211116.gbl
ELE_MG13_ot_rcp_123_220206.gbl
ELE_MG13_zb_ncp_115200_610_211112.gbl
ELX0X3_MG13_6.0.3_ezsp_v6.gbl
ELX0X3_MG13_6.7.0_ezsp_v8.gbl
In the folder /data/EFR32MG21/
ELU0141_MG21_ot_rcp_123_211204.gbl
ELU0141_MG21_zb_ncp_6103_211204.gbl
ELU0143_MG21_ot_rcp_123_211211.gbl
ELU0143_MG21_zb_ncp_6103_211211.gbl
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.
Thanks!
Yes unknown for know and Z2M usually need a converter for zigbee-herdsman for each new device → GitHub - Koenkk/zigbee-herdsman-converters: Collection of device converters to be used with zigbee-herdsman
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.