Great, thanks a lot!
However, if I understand correctly, that only works for an existing user who wants to switch to Ember?
A new user who selects Ember with a key on an older firmware won’t get this warning, because Zigbee2mqtt will never be able to start, right?
Yes, you’re right. I’ll check the logs then to detect and display the message.
That way we’ll cover all scenarios.
In my opinion, if we just detect this kind of logs, it can be done quite easily!
In the long run we could even detect the errors we see most often on this forum, to provide even more transparency to the user
Hello,
I’ve implemented the log reading (as with updates) and built an image.
I can’t test our specific case (because my dongle is up to date) but I’ll run some tests with other patterns in the logs.
The AI review gave some feedback about missing resets and I think the test coverage isn’t perfect. I’m looking into that.
Do you want to wait for the full PR or already deliver the first part (without the logs)?
Looks good to me (coverage and PR feedback).
Thanks @cicoub13, I’ll test it!
Quick question :
I have a Sonoff dongle that has never been updated. In what order should I do that?
@cicoub13 Tested just now, and I don’t see any messages in the UI 
The API call « status » returns:
{
"usbConfigured": true,
"mqttExist": true,
"mqttRunning": true,
"zigbee2mqttExist": true,
"zigbee2mqttRunning": true,
"gladysConnected": false,
"zigbee2mqttConnected": false,
"z2mEnabled": true,
"dockerBased": true,
"networkModeValid": true,
"coordinatorFirmware": {
"maintrel": "1 ",
"majorrel": "7",
"minorrel": "3",
"product": 12,
"revision": "7.3.1.0 build 176",
"type": "EZSP v12"
},
"z2mContainerError": null
}
Zigbee2mqtt logs:
Starting Zigbee2MQTT without watchdog.
[2026-02-24 17:19:21] info: z2m: Logging to console, file (filename: log.log)
[2026-02-24 17:19:21] info: z2m: Starting Zigbee2MQTT version 2.7.1 (commit #6d30fa156cf208189edbbd7db8422a6fc657fb9e
)
[2026-02-24 17:19:21] info: z2m: Starting zigbee-herdsman (7.0.4)
[2026-02-24 17:19:21] info: zh:ember: Using default stack config.
[2026-02-24 17:19:21] info: zh:ember: ======== Ember Adapter Starting ========
[2026-02-24 17:19:21] info: zh:ember:ezsp: ======== EZSP starting ========
[2026-02-24 17:19:21] info: zh:ember:uart:ash: ======== ASH Adapter reset ========
[2026-02-24 17:19:21] info: zh:ember:uart:ash: RTS/CTS config is off, enabling software flow control.
[2026-02-24 17:19:21] info: zh:ember:uart:ash: Serial port opened
[2026-02-24 17:19:21] info: zh:ember:uart:ash: ======== ASH starting ========
[2026-02-24 17:19:22] info: zh:ember:uart:ash: ======== ASH connected ========
[2026-02-24 17:19:22] info: zh:ember:uart:ash: ======== ASH started ========
[2026-02-24 17:19:22] info: zh:ember:ezsp: ======== EZSP started ========
[2026-02-24 17:19:22] error: z2m: Error while starting zigbee-herdsman
[2026-02-24 17:19:22] error: z2m: Failed to start zigbee-herdsman
[2026-02-24 17:19:22] error: z2m: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start_crashes-runtime.html for possible solutions
[2026-02-24 17:19:22] error: z2m: Exiting...
[2026-02-24 17:19:22] 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)
Makes sense, I added the readZ2mContainerLogs only to the container installation 
I’ll add it somewhere else
The Gladys update does not break existing installations, but if you want to migrate to the new driver:
(legacy ezsp) in Gladys@cicoub13 by the way I’m thinking, if the error is unknown, I think we can even display the « raw » error in the interface, that will prevent us from asking beginners to go check the logs 
I’m watching tonight
Ok, available tonight to do tests if needed
I pushed a new image that handles both known errors and unknown errors
I also changed the log reading to stream mode
I think the file readZ2mContainerLogs deserves a proper review with a clear head.
I will test tomorrow on a Raspberry Pi
@cicoub13 I just ran a test and I have this in the logs:
2026-02-25T08:33:23+0100 \u003cwarn\u003e readZ2mContainerLogs.js:97 (Zigbee2mqttManager.readZ2mContainerLogs) Zigbee2mqtt: failed to read container logs: stream.on is not a function
I updated and tested this morning on RPI. It looks like it’s working 
I’m now listening asynchronously for 30 seconds with forward:true
If we encounter a known error (the ember firmware one), we stop listening and surface the error. Otherwise, we wait for the 30 seconds to finish and surface the last raw error in the frontend.
I couldn’t test the specific ember firmware case, but I generated other errors
We could imagine surfacing the first error for faster reactivity but it’s not very meaningful 
For the block
[2026-02-25 10:31:08] error: z2m: Error while starting zigbee-herdsman
[2026-02-25 10:31:08] error: z2m: Failed to start zigbee-herdsman
[2026-02-25 10:31:08] error: z2m: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start_crashes-runtime.html for possible solutions
[2026-02-25 10:31:08] error: z2m: Exiting...
[2026-02-25 10:31:08] error: z2m: Error: Failed to start EZSP layer with status=HOST_FATAL_ERROR.
at EmberAdapter.initEzsp (/app/node_modules/.pnpm/zigbee-herdsman@7.0.4/node_modules/zigbee-herdsman/src/adapter/ember/adapter/emberAdapter.ts:666:19)
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)
Thanks @cicoub13, that’s really cool!
Tested just now and it works perfectly:
I think this will really help newcomers to Gladys, beyond the Ember aspect Well done 
Just one remark — couldn’t the error message be improved to indicate the different options: update the dongle’s firmware, or select the legacy ezsp driver?
Also, I tested something and I don’t understand why this happens: if I roll back to « ezsp » (I select the old driver + click save), I get this:
It’s only when I click the toggle « disable » + « enable » that I see the services turn green again.
Any idea?
When changing the Dongle, the Z2M container is restarted (with the new configuration file) and not recreated.
So the logs still contain the previous errors and the containers are in an unstable state.
I pushed a commit and a Docker image to recreate the container in case of a Dongle change. I think that’s cleaner. I couldn’t test it in real life and I won’t be able to look at it tomorrow (Thursday).
Yes, I changed it to this “Warning: The firmware of your Ember coordinator is outdated. Version 7.4.x or higher is required. You can follow this guide to update it. Otherwise, select the dongle (legacy ezsp) in the configuration.”
Thanks!
Perfect
I just tested, I have a different error now 
The only way to switch from one dongle to another is to do a deactivation + re-activation between each dongle change.
I think that’s already the behavior today. I’ll run tests on Friday to improve it.
