An MQTT client doesn't necessarily come back to an empty inbox when it reconnects. Depending on the connection and subscription settings, the broker can keep session information and deliver messages queued while the client was away. A retained message can arrive when a client subscribes, too. Both behaviors are useful, but neither proves that a device just produced a new event.
This matters when a Home Assistant automation reacts to a message after a restart, network interruption, or broker maintenance. The notification might reflect a fresh measurement. It might also be a replay from an earlier session or retained state arriving at the subscriber. The lab check below helps you tell those cases apart instead of guessing from a dashboard timestamp. It doesn't establish whether a real device, NAS, or service is healthy.
Session state and retained state
MQTT sessions and retained messages are different features. A session can hold information about a client connection, including subscriptions and, depending on quality of service and session settings, messages waiting for delivery. A retained message is stored by the broker for a topic and can be sent to a later subscriber. The MQTT Version 5.0 specification defines the protocol details.
A message arriving after reconnect doesn't tell you why it arrived. The payload can look exactly the same whether it was published moments ago or delivered from state the broker kept. Topic names don't prove anything either. A topic called online, event, or current means only what its publisher and consumers agree it means.
Before testing, write down four facts for one lab path: which client will disconnect, the exact topic, the QoS chosen by the publisher and subscriber, and whether the publisher uses the retain flag. Include the connection's session behavior if you control it. Avoid wildcard subscriptions. Don't use a command topic. Don't include credentials, actual device identifiers, or private addresses in test topic names, payloads, or shared records.
A dedicated lab topic
Use a broker and Home Assistant instance you administer. Create a clearly temporary topic, such as lab/session-replay-2026-10-28/event, with one known test publisher and one known subscriber. The subscriber can be a Home Assistant MQTT trigger or a separate diagnostic client. Choose a path that lets you record the topic, payload, receive time, and retain indicator. Before each independent run, clear any retained lab message by publishing a zero-length payload with the retain flag enabled on that exact test topic. Complete this reset before recording observations. Use test payloads unique to each run; don't reuse the example values below in later runs.
With the subscriber connected, have the publisher send a distinct value, for example run-a. Record what arrives, then disconnect the subscriber. While it's disconnected, publish a second distinct value, run-b, using your chosen QoS and retain setting. Change no more than one setting per run. Receiving run-b after reconnect tells you something, but you still need to classify the delivery.
For the session continuation run, keep the same client ID and record the Session Present flag in CONNACK after reconnect. Repeat the run with a deliberately clean or expired session if your broker and client configuration support it. After starting a new session, resubscribe to the lab topic because the previous subscriptions are no longer present. Record whether the client automatically resubscribes and, for MQTT 5 where applicable, the subscription's Retain Handling setting, since retained delivery depends on subscribing and the subscription options. Then repeat with retain disabled and enabled, changing only that variable. These small comparisons tell you more than restarting several services at once. A restart can erase the event order that would explain the result.
Broker observations and subscriber results
Use the broker's log, or an administrative observation available in your test environment, to record connects, disconnects, subscriptions, and publications. Don't assume the user interface shows every broker-side detail. The MQTT protocol specifies how packets and sessions behave; the broker implementation decides how those details appear in its diagnostics.
Make a small table for each run with the connection time, session choice, publication time, retain flag, subscriber receive time, and received value. Label each row as an observation, not a conclusion. For example, “subscriber received run-b after reconnect” is supportable. “The device sent a new event after reconnect” isn't, unless the publisher's own fresh measurement and timestamp establish that fact.
If the result changes when you toggle only retain, investigate retained delivery as the leading explanation. If it changes only with the session setting, look into session continuation and queued delivery. If neither changes the result, check spelling, case, authentication, ACLs, QoS, and the exact subscription filter before drawing a broader conclusion.
A harmless Home Assistant automation
Home Assistant can react directly to an MQTT message. Its MQTT integration also has its own connection and discovery behavior. The MQTT integration documentation and the automation trigger reference distinguish integration setup from an automation's trigger configuration. A successful connection doesn't tell you whether a particular rule received the intended message.
Create a temporary automation for the lab topic. For the first test, have it add a persistent notification, write a logbook entry, or update a dedicated helper. Don't publish a command, restart a host, switch power, or change a network setting. Send the two lab values through the controlled sequence. Then inspect the automation trace and the harmless result.
The trace answers a limited question: did this configured rule enter its trigger and complete its configured path? It doesn't prove when a real device event happened or where it came from. Home Assistant's automation troubleshooting guidance helps distinguish a trigger that never fired from a condition or action that prevented the expected result.
If the automation fires twice, resist adding a delay or suppression rule straight away. Compare both trace times with the broker observation and the lab table. The cause could be a repeated publisher event, retained delivery, two subscriptions, or a reconnect effect. Hiding the second notification with a workaround can also hide the evidence you need to diagnose the path.
Discovery, availability, and fresh events
MQTT discovery can create or update a Home Assistant entity after configuration is published. That's separate from a state message, and a replayed message is another matter again. Home Assistant's discovery documentation explains the configuration path. Before treating an entity change as evidence in a session test, confirm the entity's unique ID and state topic.
An availability topic is a separate signal as well. It may describe the publisher's declared connection state according to its configuration, but it doesn't test every service that publisher represents. A NAS, for example, can be connected to the broker while a file share is unavailable. Record availability transitions and received events in separate columns.
DeviceShelf Server can provide network observations through MQTT discovery to a Home Assistant installation you administer. You can compare an observation with broker and service records. It doesn't prove what caused a broker replay, establish a device's identity or availability, or show that an automation action succeeded.
Cleanup and a bounded conclusion
After the test, disable or remove the temporary automation. Clear any retained lab message you created, and verify that no test topic can affect a production action. Keep the non-sensitive record of the test settings, message order, broker observation, and trace result. That gives you something to compare with a later incident without treating the lab result as if it covers every client.
Keep the conclusion narrow: under the recorded session and retain settings, the lab subscriber received a specific value after reconnect, and the temporary automation recorded it once or twice. If the origin is still uncertain, check the relevant publisher and broker logs before changing a production alert. The test should give you a concrete next check. One MQTT delivery isn't a health guarantee.