Home Assistant Zigbee devices unavailable? Don’t reset or re-pair them yet. First count how many devices failed at the same time. Every device points to the coordinator or the integration. One room points to a lost router path. One sleepy sensor may have only missed its reporting threshold.
That split takes about ten minutes. It also protects the one clue that a factory reset would erase: the shape of the failure.
Start here: filter the entity list to Zigbee and unavailable, note the count, then manually wake one affected battery device. Change nothing until you know whether the failure affects the whole network, one branch, or one endpoint.
Zigbee isn’t a set of devices that each talk straight to Home Assistant. The coordinator owns the network. Mains-powered routers relay messages for the rest. Battery-powered end devices sleep. A failure high in that chain can make many healthy endpoints look broken.
This is why “replace the battery” and “add a repeater” are poor opening moves. Either might help one case, but neither explains the scope. Start with the layer shared by every affected device.
| What became unavailable | Check first | Don’t do yet |
|---|---|---|
| Every Zigbee device | ZHA or Zigbee2MQTT status, then coordinator access | Reset individual devices |
| Several devices after a restart | Startup log and whether the radio came back | Change the Zigbee channel |
| One room or cluster | A mains-powered router that lost power | Re-pair the entire cluster |
| One mains-powered device | Device power and its last successful command | Buy a new coordinator |
| One battery sensor | Manual wake, battery, and last-seen time | Treat a missing map line as proof |
The table isn’t a parts diagnosis. It selects the next observation. That keeps a dead coordinator from being mistaken for twenty dead sensors, and it keeps a quiet door sensor from triggering a network rebuild.
Home Assistant Zigbee devices unavailable scope test
Use one short pass before restarting anything. A restart changes timestamps and can make a temporary recovery look like a fix.
- Count affected devices. Open Home Assistant’s entity list, filter by your Zigbee integration and the unavailable state, and write down the count. Group the results by room if you can.
- Mark the power type. Pick one unavailable mains-powered device and one unavailable battery device. If only battery devices appear, reporting thresholds deserve attention before radio hardware.
- Wake one endpoint. Use the device manufacturer’s normal wake action, such as opening a contact sensor or pressing its permitted test button. Don’t factory-reset it.
- Check the shared layer. For ZHA, confirm the Zigbee integration is loaded. For Zigbee2MQTT, confirm the bridge is online before judging any endpoint.
- Record the last change. Note whether the problem began after a Home Assistant restart, host move, USB change, power cut, router unplugging, or Wi-Fi channel change.
Ten minutes is enough to classify the fault, not always to repair it. Say the sensor you woke reports at once, though its old state read unavailable. The radio path exists. Now compare its reporting behavior with the availability setting instead of erasing and joining it again.
“When I move the device further away it becomes unavailable again.” — a Home Assistant Community symptom report
That report is useful because distance changed the result. Run the same kind of controlled comparison with your device in place: wake it once, then inspect whether a new event appears. Don’t carry every sensor to the coordinator and call the network fixed. That test removes the route you need to judge.
Fix an all-device outage at the coordinator
If every Zigbee entity went unavailable together, endpoints are the wrong place to work. Check whether the integration or bridge started, whether the coordinator appears at its expected connection, and whether another application claimed the same radio.
For ZHA, the official guide notes that startup can fail when Home Assistant can’t access the USB device. It recommends a stable path under /dev/serial/by-id for locally attached radios. If the host or container changed, verify the device mapping against the actual hardware shown by Home Assistant rather than copying an old path from a forum post.
For Zigbee2MQTT, look at the bridge state and startup log. Its official troubleshooting FAQ separates adapter crashes, host power problems, and interference from endpoint pairing failures. A bridge that never came online can’t receive a battery sensor’s report, no matter how many times that sensor is reset.
Stop after the shared layer returns. Send one command to a powered device and wake one battery device, then give the mesh time to settle. A wall of returning entities is stronger evidence than a green integration badge alone.
If the outage began after moving the host, also inspect the coordinator’s physical position. Zigbee2MQTT’s official range guide says even a 50 cm USB extension cable can reduce interference, and it advises keeping the adapter away from Wi-Fi radios and SSDs. That is a positioning test, not a reason to order a stronger coordinator immediately.
One room offline usually means one lost path
A room-shaped failure suggests a router in the middle stopped relaying. Think about what lost mains power: a smart plug removed for cleaning, a bulb switched off at the wall, or a powered repeater moved to another outlet. Restore that known router first, then wake one affected endpoint.
Use the map as supporting evidence. Home Assistant’s ZHA documentation says its network topology view can identify poor links. It also warns that missing links for battery end devices are common. A blank line from a sleeping sensor isn’t a verdict. The map matters more when several affected devices previously depended on the same powered router.
Don’t change the Zigbee channel during this check. A channel change touches the whole network, and older devices don’t support every channel. The official ZHA guidance says to try a static Wi-Fi channel first when overlap is suspected rather than moving Zigbee as the opening step.
This is also where the smart home troubleshooting guide helps: it separates device power, local radio, controller state, and app display. Keep those handoffs separate so a dashboard symptom doesn’t become a shopping decision.
When a single device deserves re-pairing
One device can still fail for three different reasons: it has no power, it has a weak route, or Home Assistant hasn’t heard the report needed to refresh its state. Check those in that order.
ZHA’s current documentation lists two defaults. A mains-powered device with no activity is marked unavailable after 7,200 seconds. The battery default is 21,600 seconds. The official ZHA guide says the battery threshold can be raised for sleepy sensors that report only when triggered. An unavailable label can describe silence past a timer; it doesn’t prove the device has left the mesh.
For a battery endpoint, use its normal wake action and watch for a fresh event. If nothing arrives, test a known-good battery of the exact required type. If it works near its normal parent router but not where it lives, improve the mesh path. Don’t leave it beside the coordinator and assume the repair will hold.
For a mains-powered endpoint, confirm it actually has power and responds locally if the product provides a safe local control. Don’t open line-voltage equipment. If a switched-off bulb was acting as a router, restoring power may also recover other devices that depended on it.
Re-pair only after the coordinator is healthy, the route has power, and the endpoint still won’t report. Zigbee2MQTT notes that a selected join router may not remain the long-term route. Success beside the coordinator doesn’t prove the installed route is sound.
Replacement comes later. A powered repeater can help a real coverage gap. Buy one before you know which branch failed and you may just add another router, while the coordinator, host power, or interference stays broken. Use the model-first checklist in the home installation guide before adding hardware: exact coordinator, integration, device model, firmware, and installed location.
Save the evidence before the next restart
If the problem returns, the useful record is small: affected count, rooms, power type, last-seen times, coordinator status, and the last change before failure. Save the integration diagnostics and relevant logs before restarting. ZHA’s official reporting instructions ask for debug logs, the exact coordinator model and firmware, plus device diagnostics and signature for a device-specific issue.
That record turns “Zigbee is flaky” into a testable statement such as “six devices behind the office plug stopped reporting after that plug lost power.” It also tells you when a forum answer applies to your network and when it doesn’t.
Open the entity list now and filter home assistant zigbee devices unavailable. Write down how many failed together and wake one affected battery device. Make that one observation before you restart, re-pair, or buy anything.
Bolt & Bulb covers what goes wrong after the unboxing: devices that drop off Wi-Fi, dimmers that flicker with LED bulbs, locks that will not fit a rental door. The site draws on manufacturer documentation, platform support pages and release notes, and attributed owner reports in public forums.