Amazing! Thanks!
Hi all,
Trying to update my ZBDongle-E from 6.10.3 to something newer.
I’ve tried both 7.2.3 and 7.1.4 and can’t get Z2MQTT to start.
At first, I figured the serial port name in config had changed, and I set it to the new name.
Still won’t start. Same error on both versions:
´´´
Zigbee2MQTT:error 2023-07-10 00:12:23: Error: Connection not initialized
at Ezsp.execCommand (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/ezsp.ts:551:19)
at Ezsp.version (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/ezsp.ts:349:35)
at Driver.startup (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/driver.ts:141:25)
at EZSPAdapter.start (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/adapter/ezspAdapter.ts:165:16)
at Controller.start (/app/node_modules/zigbee-herdsman/src/controller/controller.ts:132:29)
at Zigbee.start (/app/lib/zigbee.ts:58:27)
at Controller.start (/app/lib/controller.ts:101:27)
at start (/app/index.js:107:5)
´´´
Any ideas? I’m new to this, could be a simple error…
If using Zigbee2MQTT with a Silicon Labs based dongle then you should really always manually backup Zigbee network with zigpy-cli command tool before flashing firmware and restore that backup after flashing firmware. The reason is that Zigbee2MQTT does not yet support backup and restore of Silicon Labs, see this related discussion with info on how to backup and restore:
However, I guess probably wrong serial port configuration or something related to serial comminicatiln. You did not write your configuration but many Zigbee2MQTT users new using Silicon Labs EmberZNet based dongle to forget to add ”adapter: ezsp”, see example:
serial:
port: /dev/ttyUSB0
adapter: ezsp
Note that different firmware can use different bautrates so check firmware description.
You may also need to add the baudrate and/or rtscts if using a firmware with other baudrate and/or hardware flow control setting depending on firmware and hardware, see example:
serial:
port: /dev/ttyUSB0
adapter: ezsp
baudrate: 115200
rtscts: false
Anyway, better to ask in the Zigbee2MQTT community here instead if have issues with Z2M → Koenkk/zigbee2mqtt · Discussions · GitHub
1 Like
Thanks a lot for the reply. I tried adding baudrate and rtsccts, but still no avail.
I i guess I’ll revert to 6.10.3 then.
My config is here:
@Tul47 Are you sure that serial port is for the ZBDongle-E? It looks like its some other device to me.
fwiw, I have tested 7.2.3 and 7.3.0 ezsp builds with Z2M and they should work fine.
Also make sure to use NCP firmware and not RCP (or MultiPAN) firmware for Zigbee2MQTT as otherwise you need additional dependencies which makes it complicated.
@Tul47 Yeah that CP2102N USB-to-Serial bridge chip makes it look like you might instead have a Sonoff ”ZBDongle-P” and not a ”ZBDongle-E” which uses a other USB-to-Serial bridge chip, if so then it uses a different Zigbee radio chip too and this a other config. See → ITead's "Sonoff Zigbee 3.0 USB Dongle Plus" (model "ZBDongle-P") based on Texas Instruments CC2652P +20dBm radio SoC/MCU
I suspect its probably some other generic device. ZBDongle-P should show up with manufacturer strings, something like:
/dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_xxxxxxxx_if00-port0
No I suspect it is probably a Sonoff ZBDongle-P from very first batch that ITead released as not any other manufacturers I know of uses the CP2102N USB-to-Serial bridge chip. It is well known that ITead missed writing their custom USB description to the EEPROM of that chip in the very first batch and they even released a script that write that to it, for more details on that see Community help wanted to whitelist all compatible Zigbee and Z-Wave dongles/adapters for automatic USB Discovery in Home Assistant and there is also more on that if dig in the the Sonoff ZBDongle-P thread at ITead's "Sonoff Zigbee 3.0 USB Dongle Plus" (model "ZBDongle-P") based on Texas Instruments CC2652P +20dBm radio SoC/MCU
Not many zigbee dongles use it (apart from SkyConnect ), but it is fairly common in other devices, for example users of ESPHome probably come across it quite often in various dev kits etc.
For those using my RCP Multipan firmwares, I am testing a new way to distribute firmware updates.
This is a fork of the official Silabs Flasher HA Addon, but is shipped with my firmware builds. Once configured, It will automatically update dongle firmware on next reboot of HA, or you can manually run it after installing/updating. Currently supports ZBDongle-E and a few others.
If you test it now, it will install the 4.3.1 firmware update, released yesterday.
If you have any issues with it please create an issue here:
4 Likes
Just started my setup and was wondering if it’s safe to update the Dongle-E to the latest firmware before connecting Zigbee devices.
If using the native ZHA integration then it does automatic backups of your Zigbee network so it os always ”safe” to upgrade the firmware, however if using Zigbee2MQTT (Z2M) then you should do a manual backup your of your Zigbee network before upgrading firmware because Zigbee2MQTT does not yet fully support backup and restore of Silicon Labs EZSP based Zigbee Coordinator adapters.
With Zigbee2MQTT you can stop it and use zigpy-cli as a stand-alone command line tool for manual backup and restore of your Zigbee network from Zigbee Coordinator adapter as a workaround until it can do it → GitHub - zigpy/zigpy-cli: Command line interface for zigpy
Note that the Sonoff ZBDongle-E ships woth a very stable firmware so should not need to upgrade firmware unless get issues that following the best practices does not solve, read this → Zigbee networks: how to guide for avoiding interference and optimize for getting better range + coverage
I use Z2M intergration but my Sonoff ZB-Dongle E is now running on 6.10.3 and I was wondering if there’s any benefits to upgrade it to 7.2.3 before starting to connect devices to prevent bugs that may appear.
If using Zigbee2MQTT then this is not the best place to ask as it depends on their EZSP implementation and not the physical adapter, so better if you read and follow the development discussion in this zigbee-herdsman issue → [WIP]: EFR32 EZSP adapter implementation and test · Issue #319 · Koenkk/zigbee-herdsman · GitHub and if you get a specific problem in Zigbee2MQTT then post a new discussion in that community here → Koenkk/zigbee2mqtt · Discussions · GitHub
Newer firmware will probably have better device compatible but also introduce new bugs that no one else have stumbled onto yet, so if using newer firmware than most other then be prepared to act as a beta tester and help report issues to Zigbee2MQTT developers.
@netregha check out the experimental fork official Silabs Flasher HA Addon linked above by @darkxst for updating inside HAOS, or use Universal Silicon Labs Flasher (by Nabu Casa) for manual off-line update, e.i. disable Zigbee implementation then removing dongle to update on another computer. There are also other tools and methods mentioned + linked in my original post in this thread.
1 Like
thank you, i will take a look 
@Hedda
Using the dongle-E as a router at the moment. I have a network in ZHA based on dongle-P, it is pretty stable, I have around 60 router devices, 2 Sonoff Ps and 1 Sonoff E as routers, the rest are Ikea bulbs, tuya/samsung/sonoff switches.
Any reason to migrate to the Sonoff E as the main coordinator since I am on ZHA? Also will using the migrate feature actually mean I cant use the sonoff P as a coordinator again? I read somewhere around IEEA address constraints with the dongle E, couldnt find the post again, wasnt sure if it was only for 1 particular scenario.
Thanks in advance and apologies if this was already answered before
If things are stable, I’d leave it be.
The only advantage of the E isyou can potentially use it with the multiprotocol stack for thread. It’s not worth risking zigbee stability to test a few thread devices if you ever get any. Just use the E as a second thread specific controller.
Changing the ieee address on the SILabs chip is a one time, almost irreversible process. Supposedly it can be reset using a jtag programmer, but it is probably easier and less expensive to just buy a new E at that point.
The replaced P could still be used as a new router though. Unlike SILabs, the TI chip address can be changed repeatedly using normal firmware update software tools.
Anecdotally, I found the P to be the more stable coordinator, but there have been firmware updates since then.
2 Likes
Thanks @jerrm
I was planning on getting another E to be specific for thread/matter, having 2 protocols on one sounds like trouble 
Seeing more on the forum people complaining of stability when they have it enabled.
The have both dongles as routers but seems like the E has a better connections compared to the P. I am on the new router firmware for the P dongle and have tried multiple power levels but they dont really make any difference.
I’ll leave it alone for now, enough tinkering , there are still some IKEA Styrbar battery remotes that become unavailable after 24h for some reason. They still work though when I press them, not sure why this is the case. I thought signal was the issue but might be something else.
1 Like
Because of these same issues, I’m rethinking to re-flash the E to a coordinator and the current P as Router. The P coordinator is quite a disappointment atm due to the low LQI and disconnecting routers and end devices. Using the Zstack 20221226 P coordinator firmware.