ITead’s “Sonoff Zigbee 3.0 USB Dongle Plus V2” (model "ZBDongle-E") based on Silicon Labs EFR32MG21 radio SoC/MCU

[Twig_Bark]

Yes, but i follow step 1 then It start immediately uploading and then i got error for transfering.

[rockets]

Sorry can’t help further. You might want to contact Sonoff to see if they can help.

Also the first post has links to other flashing methods you can try, eg using https://github.com/Elelabs/elelabs-zigbee-ezsp-utility/

[Twig_Bark]

Yeah i saw that. But i dont know where to start, I don’t understand python at all.

[klantin]

I tried this method too but without success… Like you

[Twig_Bark]

I got mine working. I follow this
https://sonoff.tech/wp-content/uploads/2022/08/SONOFF-Zigbee-3.0-USB-dongle-plus-firmware-flashing-.pdf ](https://sonoff.tech/wp-content/uploads/2022/08/SONOFF-Zigbee-3.0-USB-dongle-plus-firmware-flashing-.pdf)

Initially I didn’t notice that I was missing command window, where you need press keys. And then i got similar Gecko Bootloader v1.12.00 like tutorial was showing.

[Hedda]

@rockets

What exactly are you trying to do? If you are wanting to flash firmware the easiest way is to get access to the TI smartRF flash tool.

@Twig_Bark

I want flash router firmware. I tried that but unfortunately TI smartRF 2 cant open router firmware .gbl file. And there is no target device for EFR32MG21.

ITead’s naming schema is a bit confusing but please understand that you can not flash a Silicon Labs based adapter like the “ZBDongle-E” (“Sonoff Zigbee 3.0 USB Dongle Plus V2”) with flashing software made for Texas Instruments based adpters like the “ZBDongle-P” (“Sonoff Zigbee 3.0 USB Dongle Plus” that is not the “V2” varient).

Note that you either need to stop Home Assistant to flash it or better yet unplug the USB dongle and plug it into another computer instead where you install the drivers and the flashing tool to flash it from there. You will of course also need to install WCH CH9102 device drivers to access the USB adapter.

If you have the “ZBDongle-E” (“Sonoff Zigbee 3.0 USB Dongle Plus V2”) then highly recommend that you use the Elelabs Firmware Update Utility → https://github.com/Elelabs/elelabs-zigbee-ezsp-utility (or walthowd’s updater image which uses it → https://github.com/walthowd/husbzb-firmware ).

Yes those are Python-based tools but you do not need to know how to read/script Python code to use them as all you need to do is install Python for Windows or Python for Mac/MacOS and copy the commands from their README.md documentation into the command prompt / command line tool.

[Hedda]

@Hedda

FYI, looks like Home Assistant will soon support automatic USB discovery for the new ITead’s “Sonoff Zigbee 3.0 USB Dongle Plus V2” model “ZBDongle-E” based on Silicon Labs EFR32MG21 if merge:

/homeassistant/components/zha/manifest.json

  {
      "vid": "1A86",
      "pid": "55D4",
      "description": "*sonoff*plus*",
      "known_devices": ["sonoff zigbee dongle plus v2"]
    },

/homeassistant/generated/usb.py

    {
        "domain": "zha",
        "vid": "1A86",
        "pid": "55D4",
        "description": "*sonoff*plus*"
    },

The board of this new ZBDongle-E adapter uses a WCH CH9102F USB-to-UART/Serial converter chip (and CH9102/CH340 device drivers) which has VID (Vendor ID) “1A86 ” and PID (Product ID) 55D4 as well as the new USB product description identifier “sonoff zigbee dongle plus v2” on this variant.

Zigbee Home Automation - Home Assistant

Community help wanted to whitelist all compatible Zigbee and Z-Wave dongles/adapters for automatic USB Discovery in Home Assistant

FYI, pull request https://github.com/home-assistant/core/pull/77523 has now been merged into the Home Assistant core dev branch (and matching ZHA docs PR https://github.com/home-assistant/home-assistant.io/pull/23929 has also been merged into the next branch), so the ZHA integration in the upcoming Home Assistant 2022.9 release should hopefully be able to automatically detect this new “ZBDongle-E” USB adapter.

By the way, the ZHA integration in the upcoming Home Assistant 2022.9 release should also have new features for Zigbee network backup and restore function that will enable cross-migration between different Silicon Labs (ezsp), Texas Instruments (znp), and ConBee/RaspBee (deconz) based Zigbee Coordinator adapters.

Check out this related cummunity forum discussion regarding backups, restoring, and migrating Zigbee network from a to the same or different Zigbee Coordinator adapters:

https://community.home-assistant.io/t/zha-integration-to-do-nightly-backup-of-both-zigbee-coordinator-adapter-dongle-stick-and-zigbee-network-database/357558/

ZHA integration to do nightly backup of both Zigbee Coordinator adapter/dongle/stick and Zigbee network/database?

Request the ZHA integration run backup every night of your Zigbee network + Zigbee Coordinator. Needed to achieve a full backup as though ZHA configuration is stored in a zigbee.db database file, all Zigbee node, network and keys info are stored on the physical Zigbee Coordinator adapter/dongle/stick. Backups can also be used to allow users to easily migrate from ‘old’ to ‘new’ Zigbee adapter hardware. Preferably such a Zigbee Coordinator and Zigbee network backup feature should be enabled by…

[Gow2ii (Mohammed Bukannan)]

Hello,

Can you please explain to me how you got it to work ? I still get transferring error, I would highly appreciate details steps as I am really noob on the subject.

Thanks,

[norsemanGrey]

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?

[Hedda]

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.

[jerrm]

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.

[norsemanGrey]

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.

[WhimsySpoon]

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.

[Hedda]

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

[jerrm]

@Hedda

It should even make migrations to or from ZHA and Zigbee2MQTT or vice versa between them relatively easy

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?

[Hedda]

@jerrm

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.

[jerrm]

@Hedda

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.

[Hedda]

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

@jerrm

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?

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.

[jerrm]

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.

[Hedda]

@jerrm

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:

home-assistant/home-assistant.io/blob/4bc775083b8e7ced72d162fde629e295e874a302/source/_integrations/zha.markdown

Koenkk/zigbee2mqtt.io/blob/4b3a7ad00340d2af9ecc1de6098acd35c3825898/docs/guide/faq/README.md