Follow-up to the conversation regarding the migration required for Zigbee dongles linked to the ezsp driver.
I think an automatic migration is dangerous and I prefer that users switch themselves, notably because of the firmware that needs to be updated.
I was thinking of doing the following on Gladys’s ZIgbee2Mqtt configuration page
replace ITead Sonoff Zigbee 3.0 USB Dongle Plus V2 model \"ZBDongle-E\" with Sonoff Zigbee 3.0 USB Dongle Plus V2 model \"ZBDongle-E\" (driver ezsp deprecated)
add an entry Sonoff Zigbee 3.0 USB Dongle Plus V2 model \"ZBDongle-E\" (driver emberznet)
check the firmware version installed on the dongle (accessible in the topic zigbee2mqtt/bridge/info)
if the version is < 7.4.x, disable the emberznet option and display a message saying « You should update your Zigbee dongle’s firmware, here is the procedure to follow: »
if the version is >= 7.4.x, display the message « You should update the driver used by z2m by selecting in the list above Sonoff Zigbee 3.0 USB Dongle Plus V2 model \"ZBDongle-E\" (driver emberznet) » with maybe a link to a Gladys doc that explains the why and impacts
Changing the model and saving by the user updates the configuration (without impact on the network/link with devices) => to be verified
Problem, there are 6 dongles in this case.
I don’t know how to handle the case for a new installation, as the firmware version information is not accessible
You can put a yellow message that appears above if the user selects the driver « Ember »: « Warning, your dongle must have firmware version > XX, here is the procedure to check your firmware version: XXXXXX »
I don’t know whether I should flash my ZBDONGLE-E; I’m afraid it might no longer be recognized in Gladys.
The dongle loses devices under zigbee2mqtt fairly regularly and it’s annoying to have to redo the pairing, especially with the ZBMINI-L2 modules that are in the flush-mounted box…
Otherwise there’s the option of buying the ZBDONGLE-P, but it can now only be found second-hand.
Hello. Indeed, I haven’t finished the development, because you need to take into account all cases so as not to update the driver while the firmware isn’t up to date.
As many people seem affected by this delay, I finished developing the z2m ember driver and the Docker image is available for testing here: docker pull cicoub13/gladys:z2m-ember
Details:
to allow people who haven’t updated, I kept the (legacy) driver ezsp
Migration is automatic for people who have a dongle from the list (without firmware verification). I think the majority of people won’t have any issues, but this may break setups of people who do not have firmware > 7.4.x @pierre-gilles we can revisit this choice
new installations choose their dongle from the list and have the ember driver
I’ll test all scenarios today or tomorrow on my RPI4
In my opinion, we should forget automatic migration, because it will break installations, and the stability of the project is a very important value for me
If the update runs while a user is on holiday, it will break their home automation in their absence, which will create a feeling in the future that Gladys « are not safe », and will push users to disable automatic updates, or even to leave Gladys.
Also, there is little point in modifying installations that are working well!
Tested this morning on Beelink S13 + Sonoff ZBDongle-E!
It’s a good thing we didn’t enable automatic updates, because on my setup the move to Ember doesn’t work (firmware too old, even on a dongle bought in 2025!):
[2026-02-20 09:00:00] info: z2m: Starting zigbee-herdsman (7.0.4)
[2026-02-20 09:00:00] info: zh:ember: Using default stack config.
[2026-02-20 09:00:00] info: zh:ember: ======== Ember Adapter Starting ========
[2026-02-20 09:00:00] info: zh:ember:ezsp: ======== EZSP starting ========
[2026-02-20 09:00:00] info: zh:ember:uart:ash: ======== ASH Adapter reset ========
[2026-02-20 09:00:00] info: zh:ember:uart:ash: RTS/CTS config is off, enabling software flow control.
[2026-02-20 09:00:00] info: zh:ember:uart:ash: Serial port opened
[2026-02-20 09:00:00] info: zh:ember:uart:ash: ======== ASH starting ========
[2026-02-20 09:00:01] info: zh:ember:uart:ash: ======== ASH connected ========
[2026-02-20 09:00:01] info: zh:ember:uart:ash: ======== ASH started ========
[2026-02-20 09:00:01] info: zh:ember:ezsp: ======== EZSP started ========
[2026-02-20 09:00:01] error: z2m: Error while starting zigbee-herdsman
[2026-02-20 09:00:01] error: z2m: Failed to start zigbee-herdsman
[2026-02-20 09:00:01] error: z2m: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start_crashes-runtime.html for possible solutions
[2026-02-20 09:00:01] error: z2m: Exiting...
[2026-02-20 09:00:01] error: z2m: Error: Adapter EZSP protocol version (12) is not supported by Host [13-18].
at EmberAdapter.emberVersion (/app/node_modules/.pnpm/zigbee-herdsman@7.0.4/node_modules/zigbee-herdsman/src/adapter/ember/adapter/emberAdapter.ts:1408:19)
at EmberAdapter.initEzsp (/app/node_modules/.pnpm/zigbee-herdsman@7.0.4/node_modules/zigbee-herdsman/src/adapter/ember/adapter/emberAdapter.ts:670:9)
at EmberAdapter.start (/app/node_modules/.pnpm/zigbee-herdsman@7.0.4/node_modules/zigbee-herdsman/src/adapter/ember/adapter/emberAdapter.ts:1539:24)
at Controller.start (/app/node_modules/.pnpm/zigbee-herdsman@7.0.4/node_modules/zigbee-herdsman/src/controller/controller.ts:143:29)
at Zigbee.start (/app/lib/zigbee.ts:70:27)
at Controller.start (/app/lib/controller.ts:101:13)
at start (/app/index.js:149:5)
Using '/app/data' as data directory
Otherwise, the PR works as intended, the update wasn’t automatic, I had to trigger the update manually!
However, I wonder if the update experience could be improved, because as it stands there’s no way to test the update without access to the logs — it’s very obscure for the user.
I wonder if there would be a way to access this error to display it in the UI?
Error: Adapter EZSP protocol version (12) is not supported by Host [13-18].