Short Answer: Prove the Broken Path First

If Home Assistant says a device or entity is unavailable, it usually means Home Assistant cannot reach the device, service, or integration path right now. The device may still have power. It may still work from its own wall switch, vendor app, or local web page. The broken part is the path Home Assistant uses to talk to it. In Home Assistant, an entity is one visible switch, sensor, light, lock, value, or control, while an integration is the software connection that talks to the device or service.

Start with the boring checks because they fix the most houses: confirm Home Assistant itself is online, open the affected device outside Home Assistant if it has a local web page, check whether the router gave it a new IP address, and read Settings > System > Logs for the integration name. If many Wi-Fi or LAN devices disappeared after router work, use DHCP reservations, which are router rules that give important devices the same local IP address every time, and reconfigure integrations with the current address. If only Zigbee, Z-Wave, Matter, MQTT, or ESPHome devices are affected, troubleshoot that stack instead of resetting everything.

The rule is simple: one unavailable device is usually a device or integration problem; many unrelated unavailable devices are usually a network, radio, broker, or cloud reachability problem.

Do not delete first. Removing devices can break entity IDs, dashboards, automations, and history. Treat deletion or re-pairing as a last resort after you know the device really cannot be recovered in place.

Why This Question Keeps Coming Up

The demand signal is current and practical. In r/homeassistant, a homeowner described many devices becoming unavailable after restarting networking equipment; the thread quickly narrowed toward changed IP addresses and DHCP reservations. Home Assistant Community threads show the same pattern from different angles: multiple unrelated integrations timing out together, ESPHome devices that still appeared alive on Wi-Fi but dropped from Home Assistant, and MQTT devices that showed unavailable after a Home Assistant restart.

Home Assistant's own direction also makes the topic worth a fresh guide. The July 1, 2026 Home Assistant 2026.7 release added an Update all button and improved ZHA Zigbee device management. Those are useful improvements, but they are not a substitute for diagnosis. If your house is offline because the router reassigned addresses, clicking more updates only adds more variables. If ZHA has weak routes, the new device-management view can help you inspect the network, but it does not mean every unavailable state is a Zigbee problem.

What Unavailable Actually Means

Home Assistant's state docs separate unknown from unavailable. unknown means Home Assistant has the entity but does not know the value right now. unavailable means the entity cannot be reached at all, often because a device is offline or an integration failed to load.

The developer docs reinforce that behavior: integrations should mark an entity unavailable when they cannot fetch data from the device or service, and they should log when a device or service becomes unreachable and when it comes back. For a homeowner, this means an unavailable state is not a moral judgment about the device. It is a clue about communication.

That clue still needs context. A cloud appliance can be unavailable because the vendor API is down. A WLED or ESPHome device can be unavailable because its IP address changed. An MQTT device can be waiting for discovery to be resent. A battery Zigbee sensor can be asleep, out of route, or actually dead. The red state looks the same, but the fix is different.

The Five-Minute Triage Order

Use this order before you reset anything. It is intentionally plain because most unavailable-device problems are solved by narrowing the failure, not by trying dramatic fixes.

Question What it tells you Likely next step
Is it one device or many unrelated devices? One device points at that device or integration. Many unrelated devices point at the network, broker, radio, Home Assistant host, or vendor cloud. Do not re-pair a whole network for one device, and do not blame one device when the network changed.
Did the router, access points, VLAN, DNS, or Home Assistant host restart? Changed addressing and discovery are common after network work. Check router DHCP leases, Home Assistant's IP, device IPs, and mDNS/Bonjour visibility.
Can the device be reached outside Home Assistant? If its app, web page, ping, or local controls work, the device may be fine and the integration path is broken. Reconfigure the integration, update the stored host, or troubleshoot discovery.
What do logs say? Timeout, authentication, DNS, MQTT discovery, cloud API, and radio errors point in different directions. Use Settings > System > Logs, and search for the integration name.
Which control path is this? Wi-Fi, Ethernet, Zigbee, Z-Wave, Matter, Thread, MQTT, ESPHome, HomeKit, and cloud paths fail differently. Follow the matching section below.

If It Happened After Router or Network Work

This is the most common homeowner version of the problem: the modem, router, controller, or access points restarted, and Home Assistant came back with several unavailable devices.

The first suspect is IP address change. Many local integrations remember a device by hostname or IP address. If the router gives that device a different address after a long outage, Home Assistant may keep trying the old address. The WLED integration docs spell out the practical version of this: DHCP address reuse can make Home Assistant connect to the wrong device or fail validation, and the fix is to reconfigure the integration with the correct address, check the router's assignment, and reduce repeats with a DHCP reservation or static IP.

For most homes, prefer DHCP reservations in the router over manually setting static IPs on every small device. Reserve addresses for Home Assistant, local hubs, WLED, Shelly, ESPHome, cameras, NVRs, bridges, and anything mounted in a wall or ceiling. A reservation keeps the router in charge while making the address stable, so the device does not quietly move to a new address after an outage.

The second suspect is mDNS/Bonjour, the local discovery traffic behind many *.local names and auto-discovered devices. Home Assistant's Zeroconf docs describe a browser under Settings > System > Network > Zeroconf Browser. If the device no longer appears there, the problem may be the network path, selected Home Assistant interface, VLAN boundary, meaning a separate network segment, multicast setting, or access point behavior. This matters especially for HomeKit Device, ESPHome discovery, some media devices, and other local integrations.

If Wi-Fi Devices Work in Their App but Not Home Assistant

This is common with ESPHome, a local firmware system for ESP-based devices, WLED LED controllers, Shelly-style local devices, cameras, and other Wi-Fi gear. The device can appear healthy in its vendor app or web page while Home Assistant still marks it unavailable.

For ESPHome, the official Home Assistant integration can auto-discover devices, or you can add one manually with an IP address or hostname. ESPHome's own native API docs say a device may be added by <NODE_NAME>.local or by IP address. If *.local names are unreliable across your router, VLAN, or access point setup, try the actual IP address and then make that address stable with a DHCP reservation.

Also check Wi-Fi quality, not just signal bars. Community ESPHome threads show a recurring pain: the ESP device can still be on Wi-Fi while the Home Assistant API connection is flaky. ESPHome's FAQ says devices may intentionally reboot after configured timeouts when Wi-Fi, API, or MQTT connections are lost. If unavailable events come and go, look at 2.4 GHz coverage, access point roaming, power supply quality, and whether the device is stuck to a weak AP after an outage.

Do not assume that a vendor app working means Home Assistant is wrong. Vendor apps often use a different path, sometimes cloud-backed, while Home Assistant may use local polling, local push, mDNS, or a native API connection inside the house.

If MQTT Devices Are Unavailable After a Restart

MQTT, a local message-bus system used by many DIY and bridge devices, adds another layer: Home Assistant, the MQTT broker that passes messages, and the device must agree on discovery and availability. Home Assistant's MQTT docs say that when MQTT starts up, discovered MQTT devices and entities can be unavailable until a discovery message is received and processed. The docs also say devices using MQTT discovery should subscribe to the Home Assistant birth message and use it to resend discovery.

That matches real GitHub issue patterns. A 2025 Home Assistant Core issue described some MQTT devices remaining unavailable after a restart even though retained discovery and fresh device messages were visible in MQTT Explorer. The exact bug history is less important than the lesson: if MQTT devices are the only thing affected, check the broker, retained discovery topics, birth messages, availability topics, and whether the device publishes its discovery again after Home Assistant restarts.

Practical order:

  • Confirm the broker is running and Home Assistant is connected to it.
  • Use MQTT Explorer or the Home Assistant MQTT listen tool to verify messages are arriving.
  • Check whether the device publishes availability topics like online and offline.
  • Check whether discovery payloads are retained or resent after Home Assistant's birth message.
  • Reload the MQTT integration only after you understand whether messages are missing or Home Assistant is not processing them.

If Only Zigbee, Z-Wave, Matter, or Thread Devices Are Unavailable

Radio networks fail differently from Wi-Fi devices. If only one protocol family is affected, stay inside that family first.

For Zigbee, a local low-power mesh radio used by many sensors and switches, look at the coordinator, meaning the USB or network radio that owns the Zigbee network, USB placement, powered routers, battery levels, and whether the outage happened after moving the hub or changing channels. Home Assistant 2026.7's ZHA overhaul moved Zigbee device management into a fuller page with neighbors, clusters, bindings, and signatures easier to inspect. Use that visibility, but do not rebuild the network because one sleepy sensor missed a check-in.

For Z-Wave, another local smart-home radio common in locks, sensors, and North American installed devices, the Home Assistant Z-Wave JS docs note node status sensors, ping buttons, and statistics that can help troubleshoot dead nodes and RF issues. A dead node is not the same as a Wi-Fi IP change. Start with the Z-Wave JS health and node tools before excluding and including devices again.

For Matter and Thread, Matter is the cross-platform smart-home standard and Thread is the low-power mesh network many Matter devices use. Unavailable devices often come down to IPv6, Thread border routers, fabric/controller state, or the Matter server. Tara has separate guides for Thread border-router errors and Matter network-connectivity stalls because those topics have their own traps. The short version here: if every Matter-over-Thread device is unavailable, check the border router and network path before factory-resetting accessories.

If a Cloud Integration Is Unavailable

Cloud integrations are different because the device can be fine and your local network can be fine, while the vendor login, API, rate limit, or internet path is not. Logs usually make this obvious with authentication, timeout, token, or API errors.

Do not build critical household behavior that assumes every cloud device will always be reachable. Use local-first paths for lights, locks, leak sensors, presence, and essential notifications where possible. If a cloud appliance is useful but not critical, let Home Assistant show the state, but keep fallback controls available in the vendor app or at the physical device.

This matters for safety. A missing cloud state should not cause an alarm to disarm, a lock to unlock, a garage door to open, an HVAC system to run aggressively, or a water valve to toggle without confirmation. For risky devices, unavailable should pause or notify, not improvise.

Make Dashboards and Automations Handle Unavailable Gracefully

After you fix the immediate issue, improve how the system behaves next time. Home Assistant's templating docs recommend handling unknown and unavailable explicitly, and the has_value() helper can keep templates from pretending an unavailable sensor is a valid reading.

In plain English: do not make a dashboard card or notification say the freezer is 0 degrees because a temperature sensor disappeared and your template defaulted to zero. Show "sensor unavailable" or send a maintenance alert. For automations, add safe conditions around important sensors so a missing value does not trigger a risky action.

A useful homeowner alert is a small daily or hourly check that counts unavailable devices you actually care about, not every disabled diagnostic entity in Home Assistant. Label critical devices, ignore chatty extras, and send one calm notification when a meaningful device has been unavailable longer than expected.

What Not to Do First

  • Do not delete integrations first. You can lose stable entity IDs and break automations that were otherwise recoverable.
  • Do not factory reset Matter, Zigbee, or Z-Wave devices first. Radio re-pairing is slow and may create duplicate devices.
  • Do not click Update all as a troubleshooting reflex. Updates can help known bugs, but they also add change while you are trying to isolate a problem.
  • Do not reboot the whole house repeatedly. Restarting Home Assistant, routers, coordinators, and devices at random makes it harder to know what fixed the issue.
  • Do not hide unavailable states with optimistic templates. If the device is missing, the house should say so clearly.

Tara's Take

A reliable smart home is not a home where nothing ever goes unavailable. It is a home where unavailable states are easy to interpret, safe by default, and not catastrophic when the router reboots.

For Tara-style Home Assistant installs, the default is a local hub with stable network reservations, labeled critical devices, restrained cloud dependency, and backup controls for safety-sensitive paths. That makes the first response boring: check the network, check logs, identify the stack, fix the address or integration path, and only then decide whether a device needs deeper repair.

If the unavailable device points to a more specific stack, these guides go deeper.

FAQ

Should I delete and re-add unavailable Home Assistant devices?

Usually no. First prove whether Home Assistant can still reach the device, whether its IP address changed, whether the integration logged an error, and whether the device is waiting for discovery or a radio network to recover. Delete or re-pair only after recovery in place fails.

Why do devices go unavailable after a router reboot?

The common local cause is reachability. The router may have handed out new IP addresses, mDNS discovery may not be crossing the right network, or a Wi-Fi device may have rejoined slowly. DHCP reservations for Home Assistant and fixed-location devices prevent many repeat incidents.

Why are MQTT devices unavailable after a Home Assistant restart?

Home Assistant documents that discovered MQTT devices can stay unavailable until discovery messages are received after MQTT starts. Devices should respond to the Home Assistant birth message, retain discovery where appropriate, or periodically resend discovery with care.

Can an unavailable entity still mean the physical device works?

Yes. A Shelly, ESPHome, WLED, cloud appliance, or radio device may still work in its own app or on its own buttons while Home Assistant cannot reach the integration path. That is why the first check is device reachability outside Home Assistant.

Should automations run when a sensor is unavailable?

For safety-critical actions, no. Use unavailable states as a reason to pause, notify, or fall back safely. Do not make locks, garage doors, alarms, HVAC, or water shutoff routines take risky actions because a device disappeared.