An automation can look like it worked even when the action you wanted to test never ran. The notification might be left over from yesterday. The automation editor's Run actions control might have created it without checking the trigger or conditions. Or a service call might have been accepted even though its data pointed to the wrong place.
A useful test needs to separate those possibilities. Use one fictional MQTT message, a temporary automation you administer, and a persistent notification with a unique identifier. Keep the goal narrow: find out whether one recorded automation run reached one harmless action at one time. This does not test a real device, a broker's long-term reliability, or the identity of anything on a network.
If an unfamiliar client prompted the check, handle that inventory question separately. How to See Every Device on Your Network and Find Its IP Address explains how to compare local observations with router records before putting a name to a device. An automation result cannot establish ownership or presence.
The action as evidence
Before editing the automation, write down a one-sentence claim. For example: “At 14:30, the MQTT message on lab/action-check/2026-11-05/event whose kind is fictional_check caused automation automation.lab_action_check to create notification lab_action_check_2026_11_05.”
There are four parts to check independently: the message topic and content, the automation, the action, and the visible result. Leave any of them vague, and a notification that appears later won't answer the question. Avoid topics used by a NAS, a router, a security alert, or an existing integration. A laboratory topic carrying today's date is less likely to be reused by accident.
For the first check, choose an action with no external consequence. Home Assistant's persistent notification integration works well here: it keeps a message in the interface until you dismiss it, and its create service accepts a notification identifier. A logbook entry or a dedicated helper can do the same job. Don't start with a lock, switch, alarm, restart, message to another person, or network configuration change.
The identifier matters. A fixed, descriptive value such as lab_action_check_2026_11_05 separates this result from a generic notification another test left behind. Keep credentials, real device names, private addresses, and customer data out of it.
An unmistakably fictional fixture
Publish one small JSON message from a test client you control. This example is deliberately fictional:
~~~json { "kind": "fictional_check", "label": "Tutorial sensor", "note": "harmless action verification" } ~~~
Use a topic such as lab/action-check/2026-11-05/event and record the exact publication time. Publish without retain for this event-path test. A retained message can arrive later when a subscriber reconnects. That's useful behavior to test separately, but it doesn't show that a new event just occurred.
Send the fixture once. If you keep sending it until a notification appears, you lose the timing evidence needed to interpret the result. When the first run fails, inspect the recorded trigger, conditions, and action before changing one variable for a later test.
MQTT topics are case-sensitive. Lab/action-check and lab/action-check are different topics, as are /event and /events. The topic in your written claim must match the automation configuration and publisher command character for character.
A temporary automation with a narrow scope
Use an MQTT trigger with the exact test topic. If you filter on a JSON value, the condition or trigger filter should match the fictional kind value and nothing from a real integration.
Give the automation an obvious temporary name, such as “Lab: verify persistent notification action 2026-11-05,” and check that it's enabled before sending the message. Add one persistent_notification.create action. The message can repeat the fixture's harmless label. Its title should identify it as a laboratory result, not an alert about a device. Set notification_id in the service data to the unique notification identifier, and copy that same identifier into the title or message so it is visible in the interface.
There's no need for a second action just to make the test feel thorough. Putting a notification, a log entry, an MQTT republish, and a helper update in one automation gives you four possible failure paths. Verify one action first. Add another only when the evidence for the first is clear.
Before publishing, remove any older notification with the same identifier or choose a fresh dated identifier. Otherwise, a real but stale notification can make a failed new run look successful. Record when you removed the old result. That time belongs in the test record, but it isn't proof that an action ran.
Manual actions and automation triggers
Home Assistant lets you run an automation's actions manually. This is useful for checking whether a notification service call is accepted syntactically and displays what you expect. Run actions skips the trigger and top-level automation conditions; conditions within the action sequence still run. It therefore doesn't verify MQTT delivery or the top-level conditions.
If you use Run actions, record the result as an action-only check. Then dismiss the notification or change the identifier before the full test. Keep the two results in separate sentences. “The action can create a notification” and “the fictional MQTT message reached the action” are separate observations.
A successful call to an MQTT publish service has a similar limit: it means Home Assistant accepted a request to publish. On its own, it doesn't show that the broker delivered the message back to the subscribed automation, that the payload filter matched, or that the action finished. Service acceptance gives you something to investigate. It isn't the final result.
Separate checks of the run and notification
After publishing once, open the automation's trace or other run record. Find a run timestamped after the recorded publication. Check that the trigger data names the isolated test topic and contains the fictional payload, then follow the run through any conditions to the persistent_notification.create action.
The action record should show which service and data it used. Compare the unique identifier visible in the notification's title or message with the same marker in the trace's action data, and compare the notification's creation time with the trace's action timestamp. A matching trace action and a matching new notification support the limited claim you wrote down. They don't prove that a future message will arrive or tell you anything about an actual sensor or network client.
Be cautious when interpreting partial results:
- No run record at the expected time: check whether the automation is enabled, along with broker selection, topic spelling, and publication timing, before editing the action.
- A run stops at a condition: inspect the actual trigger data and condition expression. Don't assume this run created a visible notification.
- The action appears in the run but no new notification is visible: compare the action's identifier and service data with the fields the integration expects, then look for an older notification with the same identifier.
- A notification is visible but there's no matching action in the recorded run: treat it as evidence from another run or a manual action until timestamps and identifiers connect it to this test.
Automation modes can affect the result, too. In single mode, a new trigger can be ignored while an earlier run is still active. Don't change the mode just to make the test look successful. First find out whether the expected run existed and why it did or didn't reach the action.
A repeatable test record
Save a short test record outside Home Assistant: automation name, isolated topic, fictional payload, retain setting, publication time, trace/run time, notification identifier, and observed result. Leave out access tokens, broker passwords, real hostnames, and real device identifiers.
That record is more useful than a broad conclusion such as “MQTT works.” After a Home Assistant update, broker restart, or configuration change, it gives the next person investigating a precise point of comparison. It also shows whether the test covered an MQTT trigger or only a manually started action.
DeviceShelf Server can publish network observations through MQTT discovery to a Home Assistant installation you administer. If you're testing an automation from that output, first verify the harmless fixture path above. Then compare timestamps with the originating service and router records. A persistent notification confirms only the action of one configured path; it doesn't guarantee device identity, availability, delivery, or a security conclusion.
Once you're done, disable or remove the temporary automation and dismiss the test notification. Remove any retained laboratory data you created for a separate test. Cleaning up prevents someone from later mistaking a dated fixture for a live operational alert.