An MQTT dashboard can show a device as online as soon as Home Assistant, a broker, or an integration starts. That's useful when you want a value on the dashboard without waiting for the next update. But it can be misleading. The value may come from a retained message published before a laptop went to sleep, a NAS rebooted, or a Wi-Fi client left the network.
MQTT isn't at fault here. Retention has a specific purpose and a specific delivery rule. The mistake is treating a saved message as proof that a device is reachable right now. This guide covers how to identify retained state, test a small setup you administer, and choose an automation that won't turn old information into an urgent alert.
Message delivery and current reachability
MQTT publishes messages to named topics. When a publisher marks a message as retained, the broker stores the last retained message for that topic and sends it when a matching client later subscribes. The MQTT specification calls this a retained message. It makes no promise that the device that originally supplied the value is still connected or healthy. MQTT Version 5.0 describes the retain flag and the broker's retained-message behavior.
Take a state topic such as home/lab-nas/status, with online as its last payload. If the publisher sent that value yesterday, then lost power before it could publish offline, a new subscriber may receive online today. That tells you the broker stored the value. It doesn't independently tell you anything about the NAS's power, network path, file service, or current operating-system uptime.
Write down what the topic claims to represent first. A status message might mean a service passed a self-check. It might mean a network monitor saw a reply, or just that a client connected to a broker. Those are different observations. A display label such as “available” shouldn't imply details that the payload and publisher don't provide.
Retained-message identification
Only inspect a topic on a broker and network you own or are authorized to administer. Home Assistant's MQTT integration has tools for listening to a topic while you test a setup. Its documentation also distinguishes the broker connection from the entities and automations that consume messages. See Home Assistant MQTT for supported configuration and testing paths.
For a controlled command-line check, Mosquitto documents mosquitto_sub and the message fields it can display. Use %r in Mosquitto's -F output format to check the RETAIN flag and identify a retained message. You can't tell from the payload alone: the string online says nothing about when it was published. The Mosquitto subscriber manual documents the relevant client options.
If you can change the publisher, add a timestamp or monotonic sequence that it generates to the payload. Describe which clock and time zone it uses. You'll still need to interpret a timestamp. A wrong clock, delayed publication, or old retained value can make it unsuitable as proof. But it does let an operator compare the received state with the intended update interval, instead of going by the dashboard's color alone.
A small, harmless retention test
Use a disposable test topic, not a device-control topic or a wildcard subscription. Publish a clearly labeled test value with retention enabled. Establish a fresh subscription to the test topic; for MQTT 5, set Retain Handling to 0. Reconnecting alone is insufficient: resuming a persistent session does not itself trigger retained-message replay. Check whether the subscriber receives that value before a new publication. Then clear the retained message by publishing an empty retained payload to the same test topic, as MQTT specifies. At each step, record the topic, payload, retain indicator, and local time.
This establishes how the broker handles retained messages for that topic. It doesn't test a NAS, prove delivery to every subscriber, or confirm that a Home Assistant automation took an action. Those need separate checks. If the test doesn't behave as expected, stop before changing production topics. Verify the exact broker, credentials, topic spelling, and client documentation.
Keep passwords, whole inventories, private addresses, and personally identifying device names out of test payloads. A retained message can outlive the test client. Another authorized subscriber may see it later. Clearing the value when you're done is good housekeeping, but you still need to review who is allowed to subscribe or publish.
A separate model for current availability
A claim about current availability needs a mechanism based on a recent observation and a defined timeout. MQTT's Last Will and Testament facility can publish a message if a client connection ends in specified circumstances. That's still a signal about the broker connection, though, not a complete health check for every service on the client. The MQTT standard specifies will messages and session behavior. Follow the documented publisher and broker configuration, and don't read more into the result than it tells you.
Home Assistant also documents MQTT availability topics for entities. An availability topic can make an entity unavailable when the expected availability state changes; its state topic remains a separate value. Read the integration's availability guidance before choosing retained messages, expiry, or an automation trigger. What the publisher actually observes determines the right choice.
A NAS status page, a file share, and the NAS's MQTT client can disagree, for example. A working broker session doesn't prove that the file share is accepting requests. And a temporarily unavailable MQTT publisher doesn't establish that the NAS has rebooted. Give each measured signal one stated purpose. Then compare it with the service or log that answers the next question.
Automation checks for old state
An MQTT automation trigger can receive a message after Home Assistant starts or resubscribes. Before the automation sends a notification, writes a record, or changes another system, have its condition check information appropriate to that action. If the action requires current state, require a trustworthy observation timestamp within a documented freshness interval or obtain a fresh observation. Sequence numbers help check for duplicates and message order; an unseen sequence number can still belong to an old message. A separate availability state from the same managed publisher can be an additional condition, but it does not prove that the state message is fresh.
Start with a low-risk action, such as a logbook entry or a persistent notification triggered by a message on the test topic. Establish a fresh subscription to the test topic, with Retain Handling set to 0 for MQTT 5, to check whether the retained message would invoke the rule. Then repeat the test with a deliberately old timestamp and verify that the condition rejects it. A successful test shows that one publisher, topic, condition, and action worked in that scenario. It doesn't establish general device monitoring coverage.
Don't disable retention across unrelated topics to work around a confusing result. Retention is useful for configuration and last-known state when it's documented. Limit the change to the topic and consumer that need different semantics. Keep a short test record, and review the effect after a normal reconnect.
A troubleshooting record
When a device appears online unexpectedly, record four facts: the exact topic, the payload and its time fields, whether the received message was retained, and the independent check you performed. For a managed NAS, you might check its authorized administration interface or a documented service it normally provides. For a network-monitoring publisher, you might check the time and method of its last observation.
DeviceShelf Server can be one publisher of network observations to a Home Assistant installation you administer. Inspect any MQTT state or event alongside its observed time and the device's own records. It isn't a guarantee of availability, identity, or security. Its server documentation describes the supported integration path.
Often, the useful conclusion is modest: “This subscriber received a retained value that was published at this time,” if a trustworthy publication timestamp is available. Otherwise, record the reception time and explicitly state that publication time is unknown. That's enough to decide whether to wait for a fresh update, inspect an availability signal, or check a service directly. It's more accurate, and safer, than claiming a saved status message proves the device is online now.