Home › Help guides

Unavailable entities: the five usual causes

Updated 25 September 2026

The symptom

Cards on your dashboard are greyed out and say Unavailable. A room full of lights won't respond. A sensor that has worked for months now reads Unknown. Sometimes it's one device; sometimes it's twenty at once, and sometimes they come back on their own and drop out again.

Unavailable means Home Assistant knows the entity should exist but can't currently talk to whatever provides it. Unknown means it's connected but hasn't got a value yet. Both are symptoms, not causes, and the cause is almost always one of five things.

Here is how our check summarised it on a demonstration instance, and the list it recorded:

6 things aren't responding (20.0% of your system)
These show as unavailable or unknown — for example binary_sensor.connection, conversation.home_assistant, person.test_owner, sensor.backup_last_attempted_automatic_backup. Usually that's a device that's off, out of range, or an integration that failed to load.

binary_sensor.connection: unavailable
conversation.home_assistant: unknown
person.test_owner: unknown
sensor.backup_last_attempted_automatic_backup: unknown
sensor.backup_last_successful_automatic_backup: unknown
sensor.backup_next_scheduled_automatic_backup: unknown

A handful is normal on any install. The check marks it as serious once more than 15% of your entities aren't responding. For a sense of scale, on one real install of about 950 entities the check found 144 not responding.

Why it happens: the five usual causes

1. The device is off, flat or out of range. A battery sensor with a dead battery, a smart plug somebody switched off at the wall, a Zigbee device too far from the nearest router, a Wi-Fi device on the edge of coverage. This is the most common cause by far, and it shows up one device at a time.

2. The integration behind it failed to load. If lots of entities went unavailable at once, and they all belong to the same brand or hub, the integration didn't start. That has its own guide.

3. The device moved on the network. Many local integrations remember a device by its IP address. After a power cut or a router change, the device can come back on a different address and Home Assistant keeps calling the old one.

4. The device was re-paired and came back under a new name. The old entity is left behind, unavailable forever, while the working one is now called ..._2. Anything that uses the old name has stopped working too. See orphaned devices and entities.

5. A configuration change removed it. If entities you defined yourself (template sensors, groups, anything in YAML) all went unavailable after an edit, check for a duplicated top-level key in configuration.yaml. Two template: blocks means Home Assistant keeps only the last one, and every sensor in the first stops existing. The configuration check passes, and nothing in the log says why.

How to fix it yourself

1. Group them first. Go to Settings → Devices & services → Entities, filter to unavailable entities, and sort by integration. If one integration accounts for most of them, you're looking at cause 2 or 3 and fixing one thing will bring them all back.
2. Check the integration's card. On Settings → Devices & services, a red or orange card that says Failed to set up or Retrying setup is cause 2. Follow the failed integration guide.
3. For a single device, check the device. Is it powered? Does its own app see it? For battery devices, check the battery level entity (it often stays at its last value). For Zigbee, Thread and Z-Wave, check the device's signal or link quality, and add a mains-powered device between it and the coordinator if it's weak.
4. For a local device, check its IP address. Look up the device in your router's client list, compare it with what the integration has, and if it changed, reconfigure the integration with the new address. Then reserve that address in the router so it doesn't happen again.
5. **For an old name, look for _2.** Search the entity list for the same name with _2 on the end. If it's there and working, the unavailable one is a leftover: delete the leftover, rename the new one back to the old name, and everything that used the old name comes back.
6. For your own entities, check the YAML. Search configuration.yaml (and any package files) for a top-level key that appears twice, and merge the two blocks into one. Check configuration, then reload or restart.
7. Check what depends on it. An unavailable entity breaks automations silently, and it also arms numeric triggers, so a sensor that drops out and comes back can fire an automation even though nothing changed. Review any automation that uses it once it's back.
8. Leave the ones that are meant to be off. Something you've switched off at the wall, or a device that only exists at certain times of year, is fine as unavailable. If it will never come back, delete it rather than letting it hide the ones that matter.

Unknown isn't always a problem

Some entities read Unknown until something happens: a "last automatic backup" sensor on an install that has never made an automatic backup, a person with no device tracker assigned, or a sensor straight after a restart. Our demonstration instance has exactly those. Check whether the value should exist before chasing it.

Or we'll find the cause for you — from A$29, no subscription. We reload integrations that have failed (Check-up, A$29); we remove leftovers you tick (Repair, A$89); a device that's off, flat or out of range needs someone at the house.