MQTT discovery can make a Home Assistant entity appear quickly. That's useful, but seeing an entity card is just the first check. On its own, it doesn't prove that the publisher is still connected, that the value is fresh, or that an automation should act on it.
This guide covers a narrow test on an MQTT broker and Home Assistant installation you administer. The goal is simple: confirm that a known test message creates or updates the intended entity and that a harmless automation can observe the update. The test doesn't certify a device, establish its availability, or prove that a real-world action completed.
Discovery and current state
Home Assistant's MQTT discovery mechanism lets a publisher describe entities through MQTT configuration topics. Home Assistant: MQTT discovery The configuration can include a state topic, an availability topic, and identifiers that group entities into a device. Those fields describe parts of the integration. They don't check the source's health.
An entity might exist because Home Assistant received a retained discovery configuration earlier. The displayed value could be an old retained state. Or the entity could be unavailable because its publisher disconnected. Check each part separately: did discovery create the expected entity, did a state message update it, and did an automation receive the intended state transition?
Write down the exact discovery topic, state topic, entity ID, expected test value, and test time. Exact names matter here. A broker doesn't interpret MQTT topics by intent; the protocol defines how strings and filters match. OASIS MQTT Version 5.0 A discovery topic for one test device and a state topic for another may both look right while referring to different paths.
A dedicated lab entity
Don't start by changing a discovered entity that controls power, networking, backups, or access. Create or choose a clearly labeled lab entity on a broker you control. Give its topic a purpose and a date, such as lab/discovery-check-2026-10-24/state. Keep credentials, addresses, and realistic commands out of the payload.
If you publish the discovery configuration yourself, use a supported component such as sensor and an unused discovery topic/object ID so it can't replace a real entity. If you supply a unique_id in the payload, it must also be distinct from those of existing entities. Record whether the configuration is retained. Retention can make sense for discovery data, but it's also why an entity can stay visible after the publisher stops. Stopping a test client doesn't remove a retained configuration. Plan that cleanup before you test.
For the lab sensor to appear under a device, supply a distinct unique_id and valid device information containing identifiers or connections. You can inspect the device and entity views, but the UI doesn't verify the publisher's descriptive fields. Home Assistant: MQTT discovery Use factual names for the lab check. “MQTT discovery lab entity” tells you more than a name suggesting that a particular NAS, sensor, or service has been confirmed.
Entity verification with a known state change
Let Home Assistant receive the discovery configuration, then find the entity in its MQTT integration or developer tools. Note its entity ID. Don't assume the friendly name determines it. Publish one harmless, unambiguous state value through the declared state topic, such as check-1 if the entity configuration accepts text.
Watch the entity state and record the time. If it updates correctly, you've shown that this message matched this configured path in this installation. That doesn't demonstrate delivery during a future broker restart, packet loss, or a different subscriber session. If nothing changes, compare the configured state topic with the published topic character by character before changing broader broker settings.
Repeat the check with a deliberately different value, such as check-2. Two distinct values tell you more than sending the same value repeatedly because they help distinguish a current update from an already retained display. If the entity uses a numeric or JSON value template, send a payload that's valid for that template. Don't weaken the configuration just to pass the test.
An automation for observation
Once you've seen the state change, create a temporary automation that watches only the lab entity. A Home Assistant state trigger can match a specific state transition. The documentation also explains how an entity state differs from an attribute. Home Assistant: state trigger Use the entity's actual state, not a guessed attribute.
Keep the first action reversible. Write a logbook entry, create a persistent notification, or set a dedicated test helper. Don't start a service, reboot a host, or publish to a command topic for this initial test. Trigger the test value once, then inspect the automation trace and its harmless result. If the entity updates but there's no trace, look at the automation configuration. If there's a trace but the expected action is missing, look at the conditions or action sequence.
A short test sequence is enough:
- Record the discovery topic, state topic, entity ID, and expected test value.
- Publish or confirm the lab discovery configuration, then find the resulting entity.
- Send
check-1on the exact state topic and record the entity state and time. - Send
check-2, then confirm that the state changed again. - Create and enable a temporary automation with a state trigger for the lab entity's transition from
check-1tocheck-2and a notification or log entry as its only action. Publishcheck-1followed bycheck-2again on the exact state topic, then verify that the resulting automation trace identifies the expected state trigger and that the notification or log entry exists. - Disable or remove the automation and clean up the lab discovery configuration when the check is complete.
A separate availability check
An entity update doesn't tell you the same thing as availability. MQTT discovery supports availability configuration, but receiving a state once doesn't prove the publisher is still online. An unavailable state doesn't tell you the cause, either. The problem could be a broker connection, an availability topic, a configuration mismatch, or the publisher itself.
If an automation depends on availability, make sure it behaves safely when availability is absent. For a workflow with real consequences, start with a notification containing the observed entity state and time. Review that record before adding a real action. Keep “Home Assistant received a test state” separate from “the device is ready for an operation.”
DeviceShelf Server can export network observations through MQTT discovery for a Home Assistant setup you administer. It can provide entities and events to inspect alongside broker records. But that doesn't prove a discovered entity is current, a device identity is certain, or an automation completed. Check each of those on the specific path you use.
The result is intentionally limited: one controlled publisher produced two distinguishable test states, Home Assistant displayed them on the intended entity, and a temporary automation recorded one reversible observation. That's enough evidence to continue carefully. It isn't a reason to widen subscriptions or trust an untested action.