Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
If a Home Assistant sensor shows Unavailable, Home Assistant cannot currently obtain usable data from the device or service, or the integration has decided that the source cannot be reached. It is not the same as Unknown: unavailable means the entity is currently unreachable or its availability rules have marked it offline, while unknown means Home Assistant does not yet know the state.
Start with the entity’s integration, logs, and diagnostics. Then verify the source is powered and reachable, check local network or cloud-service health, and apply the integration-specific checks. MQTT sensors additionally depend on retained messages, update expiry, and availability topics; Z-Wave sensors require a compatible adapter, suitable firmware, and a clean radio connection. There is no universal reset that fixes every unavailable sensor.
What “unavailable” means in Home Assistant
Every entity has a state, and Home Assistant uses state labels to describe what it knows about that entity. An unavailable sensor is one for which the integration cannot currently provide data, or for which its availability logic says the source cannot be reached. A disconnected device, failed API request, broken dependency, invalid configuration, or explicit offline message can all lead to this state.
Recommended Free Tools
Unknown has a different meaning. It indicates that the state is not yet known. Home Assistant’s developer guidance distinguishes the two cases: “If we can’t fetch data from a device or service, we should mark it as unavailable.” If a fetch succeeds but a particular value is temporarily missing, the integration should use unknown instead. This distinction matters because an unavailable entity usually calls for connection or integration troubleshooting, whereas an unknown value may simply need an initial update or a valid reading.
#1 Best Overall
- Z-Wave 800 Series Powered by the EFR32ZG23 chip, supports S2 Security, offers strong anti-interference capability, and delivers secure and stable control of your Z-Wave devices.
- Long-Range Control Supports Z-Wave Long Range (ZWLR) for direct point-to-point communication with distant devices, enabling wider and more reliable coverage.
- External Antenna Equipped with a 2dBi external antenna with adjustable angles to enhance Z-Wave signal stability.
- Plug & Play Setup Simply plug into a USB port to get started. Works with popular open-source platforms like Home Assistant and openHAB, compatible with most Z-Wave frequencies worldwide.
- USB Extension Included Allows flexible placement on different USB ports for easy deployment, keeping the device away from electromagnetic interference.
| State | What it tells you | First question to ask |
|---|---|---|
| Unavailable | The integration cannot currently fetch data, or its availability rules report that the source is offline. | Can Home Assistant reach the device or service, and is the integration reporting an error? |
| Unknown | The state is not known yet, even though the integration may have completed a fetch. | Has the source sent a first valid value, and is the value temporarily missing? |
Do not treat an unavailable state as proof that the sensor itself has failed. The cause may be the device, its power, a network path, a cloud provider, a protocol adapter, configuration, or a timeout policy. The affected integration, device model, Home Assistant version, installation method, and the time the failure began determine which branch applies.
Fast triage: identify the failing link before changing settings
Use this order so that a temporary network or power problem is not mistaken for a configuration defect.
- Confirm the exact state. Open the entity and verify that it says unavailable rather than unknown. Note the entity name, device name, last meaningful value, and when the state changed.
- Identify the owning integration. The integration determines where data comes from and which diagnostics are relevant. A sensor supplied by MQTT has different failure modes from one supplied by Z-Wave or a cloud service.
- Read the logs around the failure time. Look for warnings or errors from the affected integration. Configuration errors, missing required settings, dependency failures, authentication problems, and connection errors are often recorded there.
- Download integration diagnostics when available. Diagnostics can expose the integration’s view of the device, connection, or configuration without requiring you to guess which setting is wrong. Treat sensitive values in diagnostic output as confidential.
- Check power and physical status. Confirm that the device has power, batteries are not depleted, and any hub, bridge, or USB adapter is connected. A powered-off source cannot provide a valid state regardless of dashboard settings.
- Check reachability. Verify that the device, hub, or service can be reached from the system running Home Assistant. For network devices, check the local network, router, DNS, and DHCP behavior. For cloud integrations, check whether the provider is experiencing an outage.
- Use the integration’s own troubleshooting guidance. An error that names a particular integration is more useful than a generic restart. Follow that integration’s documented recovery sequence before changing unrelated entities.
After each change, observe the same entity and the logs. If it returns to a normal value, record which change fixed it; otherwise, undo changes that add uncertainty and continue down the appropriate branch.
Step 1: read the logs and diagnostics correctly
Look for the first actionable error
Logs may contain repeated follow-up errors after one original failure. Focus on the earliest message that explains why data could not be fetched: a timeout, refused connection, authentication failure, missing dependency, malformed payload, or configuration validation error. Repeated “unavailable” messages alone describe the symptom, not the cause.
Separate configuration errors from reachability errors
A missing required setting or invalid configuration points to the integration setup. A timeout, refused connection, or name-resolution failure points toward the device, service, or network path. Do not replace hardware or rewrite automations while the log is reporting a missing configuration value, and do not keep editing YAML when the source is simply powered off.
Rank #2
- Dual Radio Z-Wave Plus Long Range & Zigbee 3.0 USB universal gateway - Works with HomeAssistant, Zigbee2MQTT, Z-Wave JS, Open Z-Wave and more Smart Home platforms
- Latest Z-Wave 800 series chip (EFR32ZG23) with enabled Long Range support for up to 1 mile radio range
- State of the art Zigbee 3.0 chip (EFR32MG21) to support Zigbee stack and high range
- Compatible with more than 8000 devices out of the biggest Smart Home ecosystems
- Slim and compact design - Z-Stick 10 Pro does not block any of the nearby USB ports
Use diagnostics as a snapshot, not a guarantee
Diagnostics describe what the integration could see when the report was generated. A later report may differ if the device reconnects, a cloud service recovers, or an MQTT message arrives. Compare the diagnostic output with the time of the failure and avoid exposing credentials or other private connection data when sharing it.
Step 2: verify the source and every connection between it and Home Assistant
Device and hub checks
- Confirm the sensor, bridge, hub, or adapter is powered.
- Check physical connections and indicators relevant to that device.
- For battery-powered devices, consider whether a depleted battery or a device that has gone to sleep explains the missing updates.
- If a hub supplies several entities, check whether all of them became unavailable at the same time. A group failure points more strongly to the hub, adapter, or network path than to one sensor.
Local network checks
For a network-connected source, verify that Home Assistant can still reach the device and that the device has not received a changed address or lost DNS resolution. Check the router and DHCP behavior, then check whether the relevant host or service is reachable from the Home Assistant installation. A connection error generally means that something on the device, service, or network side cannot be reached; it does not by itself identify which layer failed.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchCloud-service checks
Cloud-backed integrations can become unavailable even when the local sensor has power. Check the provider’s service status when the log indicates a remote request or authentication problem. If the provider is down, local configuration changes will not restore the entity; wait for the service or use a local data path if the integration supports one.
MQTT sensors: retained state, expiry, and availability topics
MQTT has two separate concepts that are easy to confuse: the sensor’s state topic and its availability topic. A device can publish a perfectly valid state while its availability topic says it is offline, or it can publish an online availability message without having sent a new state yet.
Check the retained state message
A retained MQTT state message is delivered immediately after Home Assistant subscribes, so the sensor can show its last known value after a restart or resubscription. Without a retained message, the initial state is undefined until the device publishes again. If the sensor becomes unknown or unavailable after Home Assistant restarts and only recovers when the device sends a fresh reading, inspect whether the state message is retained.
Rank #3
- ⚠️ READ FIRST: This USB stick is not a stand-alone hub. It must be used with smart home software running on a computer or on a Z-Wave compatible smart home hub such as HomeSeer HomeTroller or Home Assistant Green.
- 💡 WORKS WITH ALL Z-WAVE DEVICES: SmartStick G8 can control both standard Z-Wave devices (mesh network) and Long Range (LR) devices at the same time. You can mix and manage both types of devices in your home as long as you're using compatible software like HomeSeer or Home Assistant.
- 📏 INCREDIBLE LONG RANGE CAPABILITY: SmartStick G8 supports the latest 800 Series Z-Wave Long Range technology, offering wireless coverage of up to 1 mile. To use this feature, you'll need LR-compatible software and hubs, like Z-Wave JS UI v9.10.0 (or later) paired with HomeSeer or Home Assistant. Note: Your devices also need to support Z-Wave LR and be added as LR devices.
- 👆 EASY UPGRADE FROM OLDER CONTROLLERS: If you're upgrading from a previous Z-Wave controller (500, 700, or 800 series), SmartStick G8 makes it easy to migrate your Z-Wave network. Just use Z-Wave JS UI v9.9.0 (or later) for the migration. This feature works with HomeSeer and Home Assistant. Important: Don't use other methods (like PC Controller) for migration—they could make the stick unusable.
- 🌎 GLOBAL COMPATIBILITY: Works with all Z-Wave frequencies used in most coutries around the world (frequency is set using HomeSeer or Home Assistant software or hub).
Check expire_after
The MQTT sensor option expire_after marks the sensor unavailable when no update arrives for the configured number of seconds. Its default is no expiry. A value that is too short can make a normally intermittent sensor appear offline; a value that is too long can hide a stopped publisher. Compare the configured interval with the device’s real publishing schedule and with any sleep or batching behavior.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Check availability topics and payloads
Verify that the configured availability topic is the one the device actually publishes. Confirm the expected online and offline payloads, including spelling and capitalization. If several availability topics are configured, check availability_mode:
| Mode | Effect | When it fits |
|---|---|---|
all |
Every configured availability source must indicate availability. | Use when every component is required before the sensor is usable. |
any |
At least one configured availability source must indicate availability. | Use when any one of several sources is sufficient. |
latest |
The most recently received availability message determines the state. | Use only when message order and publisher behavior make the latest report authoritative. |
Match the mode to what the device actually publishes. An incorrect mode or payload can force an entity to unavailable even though state messages continue to arrive.
Distinguish broker problems from sensor publishing problems
If many MQTT entities change state together, investigate broker reachability, credentials, and the connection between Home Assistant and the broker. If one entity alone stops updating, inspect that device’s publishing schedule, topic, retained message, and expiry setting first. The timing of the last state and availability messages is more useful than repeatedly reloading the dashboard.
Z-Wave sensors: adapter, firmware, and radio conditions
Z-Wave failures require a protocol-specific check. Home Assistant’s Z-Wave documentation recommends using a compatible adapter and recommends an 800-series adapter with firmware at least 7.23.2. That is a compatibility and reliability requirement for the Z-Wave branch, not a general remedy for MQTT, Wi-Fi, cloud, or unrelated integrations.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #4
- Brand New, High Quality Replacement AC Wall Power Charger Adapter
- Input: AC 100-240V 50/61Hz Auto (Worldwide AC Input)
- Over Voltage Protection, Over Heat Protection
- Tested Units. In Great Working Condition.
Confirm adapter compatibility and connection
- Check that the adapter model is on Home Assistant’s compatible list.
- Confirm that the adapter is connected to the host running Home Assistant and is available to the Z-Wave integration.
- Verify the adapter firmware meets the documented recommendation of 7.23.2 or newer for an 800-series adapter.
- Check whether several Z-Wave entities failed together; a shared adapter or radio problem is more likely than simultaneous sensor failures.
Test for USB-related radio interference
The Z-Wave troubleshooting guidance identifies possible RF interference from a computer’s USB ports and recommends trying a USB extension cable. Use the cable as a limited diagnostic step that moves the adapter away from the host and other electronics. It will not fix an invalid configuration, a missing MQTT message, a cloud outage, or a device with no power.
Interpret the result
If moving the adapter changes connectivity, investigate radio placement and interference. If it changes nothing, return to adapter compatibility, firmware, power, network or host stability, and the Z-Wave integration’s own logs. Do not buy replacement hardware until the entity’s integration and the logs point to the Z-Wave path.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.When configuration or dependencies cause unavailability
An integration may be unable to start or refresh entities when a required setting is missing, a credential is invalid, or a dependency has failed. Logs normally identify these conditions more directly than the entity card does.
Configuration errors
Check the integration’s required settings and correct the specific field named in the error. Avoid changing multiple unrelated options at once; doing so makes it difficult to tell whether the entity recovered because of a valid correction or a temporary reconnection.
Dependency failures
Some entities depend on a bridge, broker, hub, library, or remote API. If the dependency is unavailable, every child entity may become unavailable. Diagnose the dependency first, then verify whether the child entities recover without additional edits.
Best Value
- Pre-flashed with Zigbee coordinator firmware based on EZNet 6.10.3 out of box
- Support smart home platforms like Home Assistant, openHAB, Zigbee2MQTT and so on
- Based on EFR32MG21
- +20dBm output gain
- Aluminum housing effectively reduces signal interference from peripherals
Authentication and permissions
A service can remain powered and reachable while rejecting Home Assistant’s requests. An authentication or authorization error calls for checking the integration’s credentials, token, account status, and permissions rather than replacing the sensor or changing dashboard cards.
If an automation is also failing
Diagnose the entity before debugging the automation. Home Assistant’s automation troubleshooting guidance directs users to the logs and the entity state and recommends checking the device’s power and connection when its entity is unavailable.
- Open the affected entity and confirm whether its state is unavailable or unknown.
- Check the integration logs for the time the automation should have triggered.
- Restore the device or service connection first.
- Only after the entity reports a valid state, inspect the automation’s trigger, conditions, and actions.
An automation that depends on a missing state cannot reliably evaluate that trigger or condition. Rewriting the automation while the source entity is unavailable can conceal the real failure and create a second problem.
Decision table: match the symptom to the next check
| Observed pattern | Most useful next check |
|---|---|
| One sensor became unavailable after a configuration change. | Read the integration log for missing settings, invalid values, or dependency errors. |
| Several entities from one hub failed together. | Check hub power, adapter connection, host visibility, and the integration’s connection errors. |
| Network-based entities failed together. | Check router, DNS, DHCP, local reachability, and the service or device status. |
| Cloud entities failed together while local devices still work. | Check the provider’s status and authentication errors. |
| An MQTT sensor recovers only when it publishes again. | Check retained state, publishing interval, expire_after, and availability payloads. |
| Multiple Z-Wave entities are unreliable. | Check adapter compatibility, firmware, host connection, and possible USB radio interference. |
| An automation stopped when its sensor became unavailable. | Restore the entity first, then review the automation trace and conditions. |
Common mistakes that prolong the outage
- Confusing unavailable with unknown: the two states imply different causes and different first checks.
- Restarting without reading logs: a restart may briefly reconnect an integration while leaving the original configuration or network fault untouched.
- Changing dashboard cards: presentation changes do not restore a device, broker, adapter, or cloud service.
- Using an MQTT expiry that is shorter than the device’s normal interval: intermittent or sleeping sensors then appear offline by design.
- Assuming retained state proves the device is online: a retained value is only the last published value; availability and freshness still need checking.
- Buying Z-Wave hardware for a non-Z-Wave problem: adapter and USB-interference checks apply only after the entity is identified as Z-Wave.
- Changing several variables at once: make one controlled change, observe the entity and logs, and document the result.
What to record before asking for help
A precise report shortens diagnosis. Record the Home Assistant version and installation method, the affected integration and device model, the entity’s exact state, when it changed, whether other entities failed at the same time, and the relevant log lines. For MQTT, include the state topic behavior, retained-message status, expiry value, availability topics, payloads, and mode. For Z-Wave, include the adapter series, firmware version, host connection, and whether moving it with a USB extension changed the result. Remove credentials and private identifiers before sharing diagnostics.
How to tell whether the fix is complete
A sensor is not fully repaired merely because its card displays a value once. Confirm that it remains available through the source’s normal update interval, that logs no longer report the same connection error, and that dependent automations receive the expected state. For MQTT, verify both state freshness and availability behavior. For Z-Wave, verify that the adapter remains connected and that related entities are stable rather than recovering only temporarily.
The correct resolution depends on the failing layer. Use the state distinction to choose the right starting point, logs and diagnostics to identify the layer, and the integration-specific branch to make a targeted correction. This avoids treating every unavailable sensor as the same problem.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
