If Zigbee2MQTT was running fine, you updated packages or rebooted, and now it refuses to start with a serial-adapter timeout in the log, you are probably not dealing with a dying dongle. A maintainer-diagnosed GitHub issue traces this failure to a bug in a Node.js library rather than to your hardware, and Zigbee2MQTT shipped a patch for it on 1 September 2026. The fix is an update, not a downgrade. This covers how to confirm you are hitting this particular bug, what to do about it, and what to fall back on if you cannot update yet.
This applies to Ember/EZSP-family coordinators — Silicon Labs EFR32-based adapters such as the Sonoff ZBDongle-E and the SkyConnect/ZBT-1. The report behind it is on a ZBDongle-E; whether the same failure reaches every Ember adapter is not established in the source issue.
The symptom: it worked yesterday, then an update broke it
The reported sequence is narrow. Zigbee2MQTT was running normally, the host took a routine update — a Node.js version bump, an OS package upgrade, or an unattended-upgrade reboot — and afterwards Zigbee2MQTT will not initialize its coordinator. No config changes, no new devices, nothing touched physically on the USB adapter.
That sequence is the thing to check first, ahead of the adapter itself. If you did not change Zigbee2MQTT’s configuration and the failure lines up with a reboot or a package update, the fault is more likely somewhere in the software stack underneath Zigbee2MQTT than in the coordinator hardware.
ASH_ERROR_TIMEOUTS is not a signature — read the sequence, not just the string
Two different Ember/EZSP timeout errors circulate in forum threads and they get treated as interchangeable. They are not, and neither one identifies a single cause on its own.
| Log string | What it indicates | Does this article apply? |
|---|---|---|
| ASH_ERROR_TIMEOUTS | The ASH/EZSP handshake with the adapter timed out. Multiple causes on record: the Node.js serialport bug covered here, crashes during an OTA update (GH #23704), and marginal or failing adapters (GH #30891) | Only if the failure began right after a host update or reboot |
| ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT | A different named error in the same family, with its own older issue history and its own unrelated causes | No — this article is not about that error |
Both sit in the same general family: Zigbee2MQTT waiting on a response from the coordinator’s EZSP/ASH serial protocol and not getting one. That is why they get confused. But the discriminator for this article is not the string, it is the sequence. Working, then a host-level update, then broken.
The mechanism, per the GitHub report: Zigbee2MQTT repeatedly waits for an “RSTACK” response from the adapter during EZSP/ASH initialization, gets nothing back, and logs the timeout after roughly a 14-second wait. A stalled handshake at startup, not a mid-session disconnect.
Failed to start zigbee
Error: Failure("Error: ASH_ERROR_TIMEOUTS")
at ... (ember adapter init)
The root cause: a Node.js serialport bug, not your adapter
GitHub issue #32580, “Unable to start Z2M on Node.js versions after v26.2”, reports Zigbee2MQTT v2.12.1 failing to start after a routine Node.js upgrade and reboot. The reporter’s hardware is a Sonoff ZBDongle-E v2 — Silicon Labs EFR32 chip, ember/EZSP driver family, adapter firmware 7.4.4.0 — the same adapter family covered in our ZBDongle-E vs ZBDongle-P comparison.
Two details in the report rule out the obvious suspects. Downgrading Zigbee2MQTT itself did not help; only reverting Node.js did, which points away from a Zigbee2MQTT-side regression. And a maintainer, Nerivec, posted a pinned comment attributing the cause to a bug in the Node.js serialport package, triggered by changes introduced in Node.js releases after v26.2. That comment also notes the problem is not Zigbee2MQTT-specific: other Node.js projects depending on serialport are affected, with Z-Wave integrations named as sharing the same blast radius.
So the layer that broke is the Node.js runtime’s serial-port handling, several layers below Zigbee2MQTT’s own code. Your ZBDongle-E is very likely fine.
If your failure matches the update-then-broken sequence above, do not respond by swapping adapters, reflashing coordinator firmware, or re-pairing devices. None of those is the fix here, and you risk losing network state — PAN ID, device bindings — for a problem that is not hardware-side. If you have already started down that road, or your failure does not match the sequence, our guides on recovering a coordinator after a failed flash and whether to update coordinator firmware at all are the better starting points.
Why the official troubleshooting page does not list this
Zigbee2MQTT’s “fails to start / crashes at runtime” page is thorough. It lists roughly 19 distinct causes covering USB permissions, PAN ID conflicts, port locking, TI coordinator reset quirks, pnpm version mismatches, underpowered Raspberry Pi hardware and more, and it remains a good first stop for most startup failures. It does not mention Node.js versions or the serialport library.
That is not a documentation failure, and it is not a gap waiting to be filled. A runtime regression of this shape does not become a permanent entry in a general troubleshooting list; it gets patched in a release and recorded in the changelog, which is where this one ended up. For Ember-specific behaviour the project also maintains a dedicated EmberZNet adapters page. If you searched the troubleshooting doc and came up empty, that is consistent with hitting a version-specific bug, not evidence you are doing something else wrong.
How readers ended up on the affected Node.js version
This is worth tracing, because the path runs through advice the project gave deliberately.
Zigbee2MQTT’s supported Node.js versions are an allowlist of accepted majors, not a minimum floor — a release newer than the list fails the same startup check as one older than it. Version 2.13.0 removed Node.js 20, which had reached end of life, and its release notes pointed bare-metal users at Node 24 or Node 26. We covered that migration in our Node.js 20 removal guide.
Readers who took the Node 26 option, and then took a routine point upgrade within it, are the ones who landed on v26.3 or later and into this bug. Note the direction: this is not the same problem as being on a Node version that is too old. Zigbee2MQTT’s own version check produces a clear, quotable error naming the accepted range. ASH_ERROR_TIMEOUTS is what you get when the version check passes and the serial layer underneath fails anyway.
The fix: update Zigbee2MQTT first
Zigbee2MQTT 2.14.0, released 1 September 2026, includes a patch to serialport‘s bindings-cpp for Node v26.3+. Lined up against the issue title (“versions after v26.2”), that identifies v26.3 as the first affected Node release and 2.14.0 as the version that handles it.
So the order of operations is:
- Check your Zigbee2MQTT version. If you are below 2.14.0, update — that is the fix, and it does not require touching your Node.js install.
- Read your release’s changelog entry for the
serialportpatch to confirm it is present in the build you installed, rather than assuming it from a version number. - Only if you cannot update Zigbee2MQTT should you pin Node.js to v26.2 or earlier as a holding measure.
One caveat for anyone reading the source issue: #32580 itself has stayed open. That is normal. Maintainers frequently fix a regression in a release and move on without closing the loop in the thread, so an open issue is not evidence that the problem is unfixed. The release history is the better authority.
Pinning Node.js system-wide affects every other service sharing that runtime — Home Assistant add-ons, other Node-based integrations. Check what else on your host depends on Node.js before reverting it, especially on a shared Home Assistant OS or Docker host. This is the main reason updating Zigbee2MQTT is the better route, not merely the faster one.
Docker and Home Assistant add-on installs are a different situation: the image ships its own runtime, so your host’s node -v is not what Zigbee2MQTT is running on. Updating the container or add-on is the whole procedure.
What to check before you assume you have this bug
A short checklist, in order:
- Confirm the log string is
ASH_ERROR_TIMEOUTSand notERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNTor an unrelated port or permission error. - Confirm the failure began right after a system update or reboot, rather than after a config change, a device addition, or moving the adapter. This is the real discriminator.
- Confirm your coordinator is Ember/EZSP family — Silicon Labs EFR32-based, so a ZBDongle-E, a SkyConnect/ZBT-1, or an SLZB-06/07 running in Ember mode — rather than a Texas Instruments coordinator such as the CC2652-based ZBDongle-P, which uses a different driver stack.
- Check your Node.js version. v26.3 and later are the affected releases.
- Check your Zigbee2MQTT version against 2.14.0 before you change anything about Node.js.
If all five line up, this bug is a better explanation than a failing coordinator, a corrupted network backup, or a USB power problem — the more common causes the official troubleshooting page already covers well.
What this research verified, and what it does not cover
This article is built from GitHub issue #32580, Zigbee2MQTT’s 2.14.0 release notes, and the project’s official troubleshooting documentation. It is research-synthesis, not a hands-on reproduction. Nothing here was tested on Private Home Lab’s test bench, and we have not reproduced the failure ourselves.
Verified from those sources: the issue and its status, the error string and its RSTACK-timeout mechanism, the maintainer’s attribution of the cause to the Node.js serialport package rather than to Zigbee2MQTT or the adapter, and the 2.14.0 changelog entry patching serialport‘s bindings-cpp for Node v26.3+.
Two things stay open. First, Zigbee2MQTT patching serialport downstream is not the same as upstream serialport publishing a fixed release, and the second is what would clear the problem for every other Node.js project affected. If you run Z-Wave JS or another serialport consumer on the same host, check that project’s own release notes rather than reading Zigbee2MQTT’s patch as an all-clear. Second, whether this reaches Ember adapters beyond the ZBDongle-E — SkyConnect/ZBT-1, SLZB-06/07 in Ember mode — is not established by the single report behind the issue. Treat that as unconfirmed rather than ruled out.