Direct answer: This message means communication between Home Assistant and a Silicon Labs Zigbee coordinator became unstable. Stabilize the serial connection and power before changing the Zigbee network or re-pairing devices.
Symptoms
- ZHA becomes unavailable after startup or at random.
- Logs contain “NCP entered failed state” or an application-controller restart.
- Every Zigbee device drops at once.
Prerequisites
Record the coordinator model, firmware, connection path, and recent changes. Back up Home Assistant and the Zigbee network if your installation supports it.
Diagnostic steps
- Confirm the coordinator has stable power and a data-capable cable.
- Move USB radios onto a short shielded extension cable, away from USB 3 ports and Wi-Fi equipment.
- Use a stable /dev/serial/by-id path when Home Assistant runs in a container or VM.
- Confirm the host has passed the USB device through to the Home Assistant environment.
- Check that ModemManager or another host service is not claiming the serial adapter.
- Avoid transporting the EZSP serial connection over Wi-Fi, WAN, or VPN.
- Enable ZHA debug logging, reproduce one disconnect, and save the relevant log window.
Verify the fix
Restart Home Assistant once, confirm ZHA initializes without errors, then observe whether several mains-powered and battery devices report normally.
Recovery and rollback
Do not delete ZHA, erase the radio, or re-pair the mesh while diagnosing a serial transport problem. Revert the cable, port, firmware, or VM mapping change that introduced the failure.
Prevention
Keep the coordinator local to the host, use stable device paths, document firmware versions, and change one infrastructure layer at a time.
Sources
Last reviewed: September 4, 2026.
Related Troubliq guides
Find your next troubleshooting path
Use the related guide that matches the next confirmed layer of the failure. Avoid changing unrelated systems at the same time.
Detailed evidence checklist for ZHA coordinator keeps disconnecting with NCP entered failed state
Before another change, create a short incident record. Include the exact time the symptom appeared, what the system was doing, the last successful action, and every update or network change made during the previous day. Record the Home Assistant release, installation type, integration version, device model, firmware, connection method, current address, and relevant entity IDs. Screenshots are useful for visible states, but copy the exact error text because screenshots may crop the detail needed to search logs.
Compare the failing item with one known-good item that uses the same path. If both fail, move outward toward shared services such as the integration, coordinator, add-on, DNS, router, cloud account, or Home Assistant host. If only one fails, stay close to that device: power, signal, address, credentials, firmware, permissions, and configuration. This comparison prevents a single-device problem from turning into an unnecessary system-wide rebuild.
Network tests that prove the failing layer
Use tests in layers. Confirm the address is current in the router or DHCP server. Confirm the Home Assistant host or container resolves the same name and reaches the intended address. Then test the actual documented service, port, or protocol. A dashboard loading on a phone proves only the phone’s path. A successful ping proves basic reachability, not authentication, WebSocket upgrades, multicast discovery, API encryption, event subscriptions, or application permissions.
For segmented networks, document source VLAN, destination VLAN, direction, protocol, and port before editing a firewall rule. Test the smallest temporary exception and remove it if it did not help. Discovery traffic and control traffic may use different mechanisms. Seeing a device in discovery does not prove Home Assistant can maintain a working session.
Configuration comparison procedure
Export or photograph the current configuration without exposing secrets. Compare it with official documentation field by field: host, port, account, region, project, encryption setting, device identifier, and optional switches. Watch for trailing spaces, uppercase versus lowercase account names, obsolete hostnames, restored encryption keys, or an account belonging to the wrong home or region.
Use Reconfigure or Reauthenticate before deleting an integration. Preserve entity IDs and note every automation, dashboard, script, scene, or helper that refers to them. If replacement becomes necessary, take a backup and map old entities to replacements. That makes rollback controlled rather than leaving broken references.
Power, radio, and timing checks
Do not interpret every unavailable state as software failure. Low-voltage devices may stay partly online while unstable power causes resets. Battery devices sleep and report on their own schedule. Wi-Fi and Bluetooth devices can associate yet fail at the application layer. Zigbee and Z-Wave devices depend on routes, radio conditions, and powered repeaters. Match the test to the technology instead of repeatedly pressing Reload.
Allow enough time after each test. Cloud polling, sleepy devices, retained MQTT messages, mesh repair, Bluetooth advertisements, and DHCP changes do not update instantly. Define the expected interval, then wait through at least two normal cycles. If availability returns briefly, capture the next disconnect in logs instead of declaring success.
Log-reading workflow
Synchronize clocks and reproduce the problem once. Start with the first warning or error at that timestamp; later messages may be consequences. Group errors by layer: name resolution, timeout, refused connection, TLS certificate, unauthorized account, invalid token, missing permission, unsupported capability, malformed payload, device timeout, or rate limit. Each group suggests a different next action.
Turn debug logging off after reproduction. Large files consume storage and bury the event. Redact tokens, passwords, keys, email addresses, public addresses, precise locations, and unnecessary unique identifiers. Keep the unredacted copy private for comparison with later tests.
Safe change order
- Correct time, power, cabling, or an obviously stale address.
- Reload only the affected integration when documentation supports it.
- Use Reconfigure or Reauthenticate without deleting the entry.
- Restart only the affected device or add-on during a safe window.
- Restart Home Assistant when several components share the symptom or a change requires it.
- Update software after reading release notes and preserving rollback.
- Delete, exclude, reset, or rebuild only after safer checks prove it necessary.
Post-repair validation
Verify both directions. Confirm Home Assistant receives a fresh state, send one harmless command, and confirm the physical response. Check the returned state, logbook, history, and automation trace. Restart the affected component and verify automatic reconnection. During a maintenance window, confirm the repair survives a normal Home Assistant restart.
Monitor long enough to cover the original pattern. If failure occurred overnight, after DHCP renewal, deep sleep, or token expiry, a five-minute test is insufficient. Record the confirmed cause and exact corrective change. Remove temporary firewall rules, extra logging, duplicate test integrations, and unused credentials.
When to stop and escalate
Stop if hardware overheats, power is unstable, storage reports errors, a controller backup fails, credentials are rejected across services, or firmware may be damaged. Escalate with versions, timestamps, topology, redacted logs, the first meaningful error, and results of each safe test. Do not repeat destructive steps while waiting for help.
A strong report answers four questions: What still works? What exactly fails? What changed immediately beforehand? Which test most clearly separates the causes? Those answers help maintainers diagnose the correct layer.
Verification checkpoint 1 focuses on stable by-id path. Observe the relevant state, event or log through two normal cycles and write down the timestamp. If the result is unchanged, undo the experimental change before testing another layer so the diagnosis remains controlled and reversible.Validation note 1: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
For checkpoint 2, inspect USB power rather than relying on the dashboard icon alone. Confirm the expected input, the system response and the returned state. Preserve the evidence, reverse any ineffective adjustment and move to the next checkpoint only after the current result is clear.Validation note 2: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
Checkpoint 3 — host detection: reproduce the original symptom once and record the result at the expected update interval. Compare it with the last known-good behavior. Keep the change only when this specific checkpoint improves the failure without creating a new warning; otherwise restore the previous value.Validation note 3: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
Verification checkpoint 4 focuses on radio type. Observe the relevant state, event or log through two normal cycles and write down the timestamp. If the result is unchanged, undo the experimental change before testing another layer so the diagnosis remains controlled and reversible.Validation note 4: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
For checkpoint 5, inspect serial ownership rather than relying on the dashboard icon alone. Confirm the expected input, the system response and the returned state. Preserve the evidence, reverse any ineffective adjustment and move to the next checkpoint only after the current result is clear.Validation note 5: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
Checkpoint 6 — container passthrough: reproduce the original symptom once and record the result at the expected update interval. Compare it with the last known-good behavior. Keep the change only when this specific checkpoint improves the failure without creating a new warning; otherwise restore the previous value.Validation note 6: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
Verification checkpoint 7 focuses on adapter firmware. Observe the relevant state, event or log through two normal cycles and write down the timestamp. If the result is unchanged, undo the experimental change before testing another layer so the diagnosis remains controlled and reversible.Validation note 7: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
For checkpoint 8, inspect extension-cable placement rather than relying on the dashboard icon alone. Confirm the expected input, the system response and the returned state. Preserve the evidence, reverse any ineffective adjustment and move to the next checkpoint only after the current result is clear.Validation note 8: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
Checkpoint 9 — initialization trace: reproduce the original symptom once and record the result at the expected update interval. Compare it with the last known-good behavior. Keep the change only when this specific checkpoint improves the failure without creating a new warning; otherwise restore the previous value.Validation note 9: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
Verification checkpoint 10 focuses on network backup. Observe the relevant state, event or log through two normal cycles and write down the timestamp. If the result is unchanged, undo the experimental change before testing another layer so the diagnosis remains controlled and reversible.Validation note 10: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
For checkpoint 11, inspect restart persistence rather than relying on the dashboard icon alone. Confirm the expected input, the system response and the returned state. Preserve the evidence, reverse any ineffective adjustment and move to the next checkpoint only after the current result is clear.Validation note 11: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.
Identify what “NCP failed” means for this coordinator
NCP refers to the network coprocessor used by many Zigbee coordinators. A failed state can come from a missing serial device, another process holding the port, an incorrect radio type, unstable USB power, firmware trouble or a coordinator that is still booting. Record the coordinator model, chipset, firmware, connection type and the exact ZHA initialization error before changing the configuration.
For USB coordinators, use the stable by-id device path rather than a changing ttyUSB or ttyACM number. Confirm that the host still detects the adapter after a full power cycle and that the device has not been passed to another container, add-on or virtual machine. Zigbee2MQTT and ZHA must not open the same coordinator simultaneously. For network coordinators, verify the documented socket address and confirm that only the intended Zigbee service is using it.
Check power and USB behavior safely
Move the coordinator away from USB 3 ports, storage devices and Wi-Fi radios using a quality extension cable. Inspect host logs for disconnects or resets. Do not flash firmware simply because initialization failed once. First rule out a loose connector, inadequate power, a changed device path and a second process holding the serial interface.
If firmware work becomes necessary, export a Home Assistant backup and preserve the Zigbee network information supported by the adapter and ZHA. Confirm the firmware image matches the exact chipset and bootloader. An incorrect image can make the coordinator unavailable and may prevent network recovery.
Prove that the Zigbee network recovered
- ZHA initializes without repeated radio or serial errors.
- The coordinator remains connected through a normal Home Assistant restart.
- Existing routers and end devices return without creating duplicates.
- A nearby device reports a fresh attribute and accepts one harmless command.
- No other add-on or container opens the coordinator port.
If ZHA cannot start but the operating system sees the adapter consistently, collect the full initialization trace and compare its protocol and baud settings with the adapter documentation. If the adapter disappears at the operating-system level, focus on hardware, USB passthrough and power rather than repeatedly reloading ZHA.