Zigbee2MQTT ASH_NCP_FATAL_ERROR or HOST_FATAL_ERROR: Ember adapter recovery

Direct answer: Stop Zigbee2MQTT, confirm no other service is using the coordinator, and verify the serial path and Ember adapter configuration before power-cycling or flashing anything. ASH_NCP_FATAL_ERROR and HOST_FATAL_ERROR mean communication between zigbee-herdsman and a Silicon Labs Ember coordinator failed; they do not automatically mean the Zigbee network database is lost.

This guide targets Silicon Labs EmberZNet coordinators used by Zigbee2MQTT, including USB and network-connected adapters. It does not apply to Texas Instruments zStack or deCONZ adapters, and it is separate from an individual device interview failure.

Symptoms and affected scope

Zigbee2MQTT fails during startup with ASH_NCP_FATAL_ERROR or HOST_FATAL_ERROR.
Logs show exceeded ACK timeouts, CRC errors, ASH disconnected, adapter reset, or inability to open the serial port.
The error began after a reboot, USB renumbering, firmware update, migration, or enabling another Zigbee integration.
A network coordinator works intermittently and disconnects under load.

These symptoms can look similar even though their causes sit in different layers. The safest approach is to preserve the current working state, identify the first failing layer, and change one variable at a time. This prevents a recoverable Zigbee2MQTT ASH_NCP_FATAL_ERROR problem from turning into lost pairings, lost entities, or an inaccessible installation.

Ranked likely causes

1. The configured serial path changed or points to a transient /dev/ttyUSB number.
2. ZHA, another Zigbee2MQTT instance, firmware tools, or host software already owns the adapter.
3. The adapter type or flow-control setting is wrong for the coordinator.
4. USB power, cabling, interference, pass-through, or virtualization is unstable.
5. Coordinator firmware is incompatible, corrupted, or not recommended for the adapter.
6. A TCP coordinator has packet loss, an unstable address, wrong port, or competing client.

Before changing anything

Make a current backup, record versions and installation type, capture the exact first error, and remove secrets from any notes. Do not delete integrations, reset devices, erase databases, or reflash firmware as an opening move. If equipment is hot, swollen, wet, arcing, smoking, or connected to mains wiring that must be opened, stop and use qualified help.

Least-destructive diagnostic order

1. Preserve the Zigbee2MQTT data directory, configuration.yaml, coordinator backup, and network key before changing firmware or creating a new network. Do not press a coordinator reset button. After this step, stop and interpret the result before moving on. A positive result narrows the fault to this layer; a negative result preserves the current configuration and justifies the next check.
2. Stop Zigbee2MQTT cleanly. Also stop ZHA or any second Zigbee service that may open the same coordinator. One coordinator must have one active owner. After this step, stop and interpret the result before moving on. A positive result narrows the fault to this layer; a negative result preserves the current configuration and justifies the next check.
3. Check the configured serial port. Prefer a stable /dev/serial/by-id path for local USB hardware rather than /dev/ttyUSB0 or /dev/ttyACM0, which can change after reboot. After this step, stop and interpret the result before moving on. A positive result narrows the fault to this layer; a negative result preserves the current configuration and justifies the next check.
4. Confirm the configured adapter family matches the hardware. For current Silicon Labs coordinators, follow Zigbee2MQTT’s EmberZNet adapter guidance. Do not copy an adapter value from a guide for different silicon. After this step, stop and interpret the result before moving on. A positive result narrows the fault to this layer; a negative result preserves the current configuration and justifies the next check.
5. Review flow-control settings for the exact model. For hardware that expects software flow control, enabling RTS/CTS can produce startup failures. Use the manufacturer and Zigbee2MQTT documentation rather than guessing. After this step, stop and interpret the result before moving on. A positive result narrows the fault to this layer; a negative result preserves the current configuration and justifies the next check.
6. Inspect the host log for USB disconnects, resets, or pass-through errors. On a virtual machine, confirm the coordinator is attached to the guest after every host reboot. After this step, stop and interpret the result before moving on. A positive result narrows the fault to this layer; a negative result preserves the current configuration and justifies the next check.
7. Move a USB coordinator away from USB 3 ports, SSDs, and Wi-Fi radios using a quality shielded extension cable. Replace a suspect cable or underpowered hub before reflashing firmware. After this step, stop and interpret the result before moving on. A positive result narrows the fault to this layer; a negative result preserves the current configuration and justifies the next check.
8. For a network coordinator, reserve its address, test packet loss, verify the documented TCP port, and ensure only one client connects. Do not expose an unencrypted coordinator socket to untrusted networks. After this step, stop and interpret the result before moving on. A positive result narrows the fault to this layer; a negative result preserves the current configuration and justifies the next check.
9. Perform one controlled power cycle: stop the service, remove coordinator power for a short interval, reconnect it, confirm the stable path, then start Zigbee2MQTT. Repeated rapid cycling can obscure a power or ownership fault. After this step, stop and interpret the result before moving on. A positive result narrows the fault to this layer; a negative result preserves the current configuration and justifies the next check.
10. Compare coordinator firmware with the adapter vendor’s recommended Ember firmware and Zigbee2MQTT’s compatibility guidance. Flash only after backups exist and simpler causes are excluded. After this step, stop and interpret the result before moving on. A positive result narrows the fault to this layer; a negative result preserves the current configuration and justifies the next check.
11. Start Zigbee2MQTT and read the first complete startup sequence. Record the first error, not only the final fatal line; the first serial, permission, firmware, or socket error usually identifies the layer. After this step, stop and interpret the result before moving on. A positive result narrows the fault to this layer; a negative result preserves the current configuration and justifies the next check.
12. If the error persists on known-good power, cabling, configuration, and firmware, test the coordinator on a supported host without forming a new network. Hardware failure becomes more likely only after those controls pass. After this step, stop and interpret the result before moving on. A positive result narrows the fault to this layer; a negative result preserves the current configuration and justifies the next check.

Choose the correct branch

Local USB: prioritize stable device path, exclusive ownership, permissions, extension cable, power, and VM pass-through.
Ethernet/PoE coordinator: prioritize address reservation, TCP port, latency, packet loss, firmware, and single-client ownership.
Error after migration: restore the original Zigbee2MQTT data directory and coordinator settings; do not create a fresh network unless recovery has failed and you accept re-pairing.
CRC or ACK errors under load: investigate cable quality, USB interference, power, flow control, and firmware before blaming end devices.

How to interpret the results

If the evidence points to the configured serial path changed or points to a transient /dev/ttyUSB number. Correct only that layer, then repeat the smallest relevant test. If the result does not change, restore the prior value and continue; do not stack speculative fixes.

If the evidence points to ZHA, another Zigbee2MQTT instance, firmware tools, or host software already owns the adapter. Correct only that layer, then repeat the smallest relevant test. If the result does not change, restore the prior value and continue; do not stack speculative fixes.

If the evidence points to the adapter type or flow-control setting is wrong for the coordinator. Correct only that layer, then repeat the smallest relevant test. If the result does not change, restore the prior value and continue; do not stack speculative fixes.

If the evidence points to USB power, cabling, interference, pass-through, or virtualization is unstable. Correct only that layer, then repeat the smallest relevant test. If the result does not change, restore the prior value and continue; do not stack speculative fixes.

If the evidence points to coordinator firmware is incompatible, corrupted, or not recommended for the adapter. Correct only that layer, then repeat the smallest relevant test. If the result does not change, restore the prior value and continue; do not stack speculative fixes.

If the evidence points to a TCP coordinator has packet loss, an unstable address, wrong port, or competing client. Correct only that layer, then repeat the smallest relevant test. If the result does not change, restore the prior value and continue; do not stack speculative fixes.

Verified repair and final checks

A successful recovery produces a clean adapter startup, loads the existing network, preserves the PAN and devices, allows one harmless device read or command, and remains connected through a Zigbee2MQTT restart. Verify several routers and sleepy devices over time.

A repair is not verified merely because an error banner disappears. Confirm the underlying connection or service, observe fresh state data, and test after a controlled restart where appropriate. Keep the previous configuration until the new state has remained stable.

Rollback and recovery

If a configuration change fails, restore the recorded serial block. If firmware flashing fails, use the adapter vendor’s recovery method and the backed-up coordinator/network data. Never erase the data directory as an initial fix.

Write down each change before making it. Reversibility matters: a documented URL, service setting, serial path, integration state, or firmware version is much easier to restore than a configuration changed in several places at once.

Prevention

Use stable serial paths, one coordinator owner, off-device backups, documented firmware versions, reliable power, USB extension cables, reserved network addresses, and change logs for coordinator updates.

Review this setup after platform, firmware, router, certificate, or host changes. Backups should exist off the device and should be periodically checked for visibility and required encryption material.

Privacy and safety

Never publish access tokens, API keys, encryption keys, Wi-Fi credentials, public IP addresses, precise locations, camera URLs, door-lock states, alarm details, or complete unsanitized diagnostics. Do not weaken TLS, firewall rules, authentication, or network isolation simply to make an error disappear.

Testing disclosure

This guide is based on the current official documentation and linked upstream reports. Troubliq did not physically test every device, adapter, network, phone, host, or installation variant described. Device-specific behavior can differ; preserve backups and follow the manufacturer’s safety instructions.

Sources

Last reviewed: September 24, 2026.

Next: use the Home Assistant Error Decoder to match the exact message, or return to the current Home Assistant problems hub.

Detailed diagnostic reference

Preserve coordinator identity

The Zigbee network depends on its PAN identifiers, network key, coordinator state, and Zigbee2MQTT database. Back up the entire data directory and coordinator backup before firmware work. A newly starting coordinator is not useful if it forms a different network.

Find the first error

HOST_FATAL_ERROR is often the terminal message after a more specific serial, CRC, ACK, permission, or socket failure. Read the startup log from the first adapter line and troubleshoot the earliest failure, not the last summary.

Prove exclusive ownership

Stop ZHA, other Zigbee2MQTT instances, firmware flashers, serial monitors, and host discovery services that may open the adapter. Restart only one owner. Simultaneous access can mimic firmware or hardware failure.

Use stable device paths

Map a USB coordinator through /dev/serial/by-id where supported. In virtual machines and containers, confirm that the stable host device is passed through, not only a transient tty number. Recheck the mapping after host reboots.

Measure the physical layer

Inspect host logs for disconnects and resets, test a short known-good extension cable, remove an unpowered hub, and separate the coordinator from USB 3 storage and radios. Change one physical variable at a time.

Respect model-specific flow control

RTS/CTS requirements differ by coordinator and firmware. A copied serial configuration can open the port yet fail the ASH exchange. Confirm adapter type, baud rate, and flow control against the exact vendor model.

Diagnose network coordinators

Reserve the coordinator address, verify the TCP scheme and port, measure packet loss, and prevent multiple clients. For PoE units, inspect switch power events. Keep the coordinator interface on a trusted network.

Treat firmware as a controlled change

Record the current firmware build and hardware revision. Use only vendor- or project-recommended firmware for that adapter. Do not flash merely because a fatal error appears once; eliminate ownership, path, power, and transport causes first.

Verify the old network

After recovery, confirm the coordinator reports the expected network, devices remain listed, routers respond, and battery devices check in naturally. Do not start mass re-pairing until network identity and backup restoration are confirmed.

Completion criteria

Zigbee2MQTT completes startup without ASH errors, retains the existing devices and network identifiers, survives a service restart, and stays stable during normal traffic. Preserve the final configuration and firmware record.