An MQTT entity in Home Assistant can show unavailable just when an automation matters. That's a useful warning, but it doesn't tell you what went wrong. A sensor might have lost power, a publisher might have disconnected, the broker might have rejected a connection, or a topic might be configured incorrectly.
This guide covers a small check on a broker and Home Assistant installation you administer. The aim is narrow: check how one known publisher moves one test entity between available and unavailable, then have a harmless automation observe the change. The test doesn't prove a device's identity or future uptime. It also doesn't prove that a real-world action happened.
The meaning of an availability topic
MQTT discovery and MQTT entities can be configured with availability information. In a typical setup, a publisher sends a payload such as online or offline to an availability topic. The entity maps those values to its availability. Home Assistant documents the MQTT availability options, including an optional availability topic and payload values. Home Assistant: MQTT integration
The key word is configured. When an entity shows as unavailable, Home Assistant has applied its configuration and observed a matching condition in this installation. That doesn't explain the cause. A retained offline message can linger after an earlier disconnect, while a live offline message may be a deliberate maintenance signal. A missing message could mean a topic mismatch or an actual outage.
These are separate questions. Did Home Assistant create the intended entity? Did a known publisher send the exact availability payload? Did the entity change? Did an automation see it? You need different evidence for each answer. MQTT topics are strings that clients match using the protocol's defined topic and filter rules. A name that looks right isn't enough. OASIS MQTT Version 5.0
A contained lab setup
Don't start with the availability topic for a NAS, router, backup service, or power controller. Use a broker and namespace you control, with a clearly temporary name such as lab/availability-check-2026-10-26/status. Keep credentials and private addresses out of test payloads and shared records, and don’t send command payloads.
Create a simple lab MQTT entity or a discovery configuration with a unique object ID. Before publishing anything, record:
- The exact availability topic and the payloads mapped to available and unavailable.
- Whether the availability message is retained.
- The entity ID that Home Assistant actually assigned.
- The time and client used for each test message.
Pay attention to retention. The broker delivers retained messages to later subscribers as stored state, which can be useful for a status topic. But stopping a publisher doesn't remove its last retained state. Have a cleanup plan before changing a retained test message. After the check, clear the retained test value if that's appropriate for the broker you control.
Checks in both directions
Send the configured available payload from the known lab publisher. Find the entity in Home Assistant and record its state and the time. Then send the configured unavailable payload. Only use a different, explicit test value if the entity configuration maps it. Otherwise, you may be testing a parsing error rather than availability.
Check that the state changes in the intended order. If it doesn't, compare the topic, payload spelling, case, and retain setting before changing connection settings or restarting services. Change one variable at a time so the test tells you something useful. For example, sending online, then offline, then online makes it easier to tell whether the entity reflects current messages or still displays an earlier retained value.
An MQTT sensor's state topic and availability topic are separate paths, too. Home Assistant's MQTT sensor documentation describes state and availability separately. Home Assistant: MQTT sensor A current state value can coexist with unavailable status. Don't assume an old state is fresh just because it's still visible.
Observation before action
Once the lab entity changes as expected, create a temporary automation that only records an observation. An MQTT trigger can react to a topic and optional payload. A state-based automation can observe the resulting entity state. Choose whichever matches the fact you're testing. Home Assistant: MQTT trigger
For this first pass, make the action a persistent notification, a logbook entry, or a dedicated helper. Don't reboot a host, switch power, alter network access, or publish to a command topic. With the temporary automation enabled, send the configured available payload and confirm that the entity leaves unavailable. Then send the configured unavailable payload once and inspect the automation trace and the harmless result. Home Assistant's troubleshooting guidance explains how traces help distinguish a trigger that didn't fire from a condition or action that didn't behave as expected. Home Assistant: automation troubleshooting
If the entity changes but there's no trace, review the automation target and trigger type. If there's a trace but the expected notification or helper update is missing, inspect the conditions and action path. Neither result establishes whether a production device is available. It narrows down one configuration problem in one controlled test.
An offline event as a starting signal
In a production workflow, a safe first response to an unavailable state is usually to record the entity ID, observed value, and time. Then compare the broker log, the publisher's own log, and any relevant service status separately. Don't make an availability message the only condition for a consequential action.
This matters especially after broker restarts and maintenance. Home Assistant may restart before a publisher reconnects and publishes an available value. A retained value may also arrive before the publisher finishes its own checks. Use a delay or a second independent observation only if you can explain what it protects against. A longer timeout doesn't tell you what caused the failure.
DeviceShelf Server can export network observations through MQTT discovery to a Home Assistant installation you administer. That gives you another observation to compare with broker records. An unavailable entity still doesn't prove a device is gone, identify a network fault, or confirm a recovery action. Keep its availability information and any automation outcome as separate observations.
Test cleanup
Disable or remove the temporary automation, entity, and retained lab configuration according to the setup you created. Check that the test topic can no longer change a real automation. Keep a short record of the topic names, payloads, entity ID, and trace result, leaving out secrets and real network details.
Success here is deliberately limited: a known lab publisher changed one configured entity between two availability states, and Home Assistant recorded one reversible reaction. That's enough evidence to decide whether the configuration needs more work before you attach it to a meaningful action.