An MQTT message can look like JSON and still be unsafe input for an automation. It might be malformed, arrive on the wrong topic, or be retained from an earlier test. Even valid JSON can contain a field whose meaning has changed. A rule may react to any of these messages without receiving the event it was supposed to handle.
Start with a smaller question than “does MQTT work?”: can a Home Assistant rule receive one controlled JSON message, extract the intended value, and make one harmless change you can observe? This guide walks through that check on a broker and Home Assistant installation you administer. The test won't establish whether a real device is online, a sensor reading is accurate, or a production action should run.
A single purpose for the test
Decide what the automation needs from the payload before you create a trigger. A small lab message such as {"event":"check","sequence":1} lets you check whether the message parses as JSON and whether the expected event field contains the expected value. That's all it proves. It cannot show that a device produced a fresh measurement. Keep credentials, full network inventories, MAC addresses, private IP addresses, and personal names out of the test payload.
Pick a temporary topic that no existing publisher or rule uses, for example lab/json-payload-check-2026-10-29/event. Avoid wildcards and command topics. Write down the broker, exact topic, expected JSON shape, configured QoS, retain choice, and the entity or automation that will observe it. With that record, you can tell a topic error from a template error without changing several settings at once.
The MQTT specification defines a message payload as application data. The publisher and consumer choose to use JSON; the broker doesn't add that property. The MQTT Version 5.0 specification provides background on topics and message delivery, but it doesn't define what a field named event or status means.
Topic checks before template checks
First, confirm the exact topic path using a controlled publisher and a diagnostic subscriber in the test environment. Publish one clearly marked, fictional message. If it doesn't arrive, check the topic spelling, connection, authentication, and ACLs before adding a JSON template. Even a correct template won't help if the subscriber is listening on a different path.
Next, publish one message with the intended shape and another with a deliberately different but still valid value, such as {"event":"check","sequence":2}. Compare sequence in the diagnostic subscriber’s raw payload to distinguish the two messages; a sensor extracting only event will show check for both. Keep the retain flag the same for both messages. Test retain behavior in a separate run if needed, and record it as a separate variable.
Home Assistant documents MQTT connection and setup separately from MQTT sensors and automations. A connected integration tells you that Home Assistant can talk to the broker. It doesn't show that a particular configured topic, entity, or automation receives the intended data. The Home Assistant MQTT integration documentation covers the integration-level configuration.
A focused MQTT sensor or trigger
An MQTT sensor can expose a state topic and apply a value template when you want a state to inspect. If an event should start a rule, an MQTT trigger can listen to a topic and filter or template the received payload. Choose one of these paths for the lab run. Building a sensor, discovery configuration, and production automation at the same time makes it hard to tell which layer accepted the message.
Extract only the JSON property you need for the check. If the rule should continue only when event equals check, compare that exact value. Parsing successfully isn't enough to accept a payload, and loosening the comparison just to make the test fire defeats the check. Case matters. So can whitespace inside a string, a missing field, or a changed type.
The MQTT sensor documentation covers state and value-template configuration. Follow the documented syntax for the Home Assistant version running in your test instance instead of copying a fragment from an unrelated integration. If a template renders an empty or unexpected value, investigate it. Publishing increasingly broad test data won't explain that observation.
Three controlled lab messages
Use only a broker and topics you administer. This sequence keeps the results easy to follow:
- Publish a valid, clearly fictional message with the expected field and value, such as
{"event":"check","sequence":1}. - Publish a valid JSON message with a deliberately different
eventvalue, such as{"event":"ignore","sequence":2}. - Publish a malformed test string only if the diagnostic path can safely display it. Otherwise, stop after the first two messages and record that invalid-input handling was not tested.
After each message, record its publish time, topic, retain choice, what the subscriber received, the extracted value, and whether the rule triggered. Pay attention to the second message. If the rule runs for both values, it isn't yet testing the intended event. The malformed case is optional because its effect depends on the Home Assistant configuration you've chosen. Never test a malformed payload against an automation that controls power, network configuration, locks, alarms, or another real-world action.
A retained message isn't fresh just because its state becomes visible after subscription. When the run is complete, clear the retained lab value and confirm that the temporary topic cannot feed a permanent rule.
A reversible first action
For the first successful match, make the automation action a persistent notification, a logbook entry, or a dedicated helper. Don't restart a NAS, publish a command, change a network setting, or notify a third party. Home Assistant's automation trigger reference explains MQTT triggers. Its automation troubleshooting guidance helps you tell whether a trigger failed to run or a condition or action prevented the expected result.
Inspect the automation trace after each test message. A trace for the expected message tells you something specific: this configuration entered its configured path for that lab input. It doesn't prove that a production publisher sends comparable data or that a device is healthy. Nor does it prove that a later notification reaches a person.
No trace? Go back to the recorded topic and payload before editing the action. If there's a trace but no visible, harmless result, inspect the conditions and the selected action. Change one element and repeat one fictional input, keeping the result in the lab. That preserves evidence you would lose by changing several things and trying again.
JSON and other network evidence
JSON can carry an identifier or an address. Neither proves a device's identity. Hostnames can change, private Wi-Fi addresses can rotate, and publishers can report old state. When an MQTT message concerns a network device, compare it with suitable independent records: the broker log, the publisher log, the router's active-client view, or a controlled local observation. Start with See All Devices on Your Network and Their IP Addresses if you need to distinguish a current network observation from a label in a message.
DeviceShelf Server can provide network observations through MQTT discovery to a Home Assistant installation you administer. You can use it as one source to compare against the message path. It doesn't validate arbitrary JSON, prove a device's identity or availability, or prove that an automation completed successfully.
Test cleanup and a limited conclusion
After the run, disable or remove the temporary automation and clear any retained lab data you used. Keep only a non-sensitive record of the topic, sample shape, observation times, and trace result. Be specific about what worked: on the recorded test topic, the expected fictional JSON value was extracted and a harmless rule ran once; the different value did not pass the intended filter. If that didn't happen, find the first layer that behaved differently from what you expected before considering a more powerful action.
This gives you a basis for assessing a later production change. It doesn't make an MQTT payload a health guarantee, a security finding, or evidence that every network device is correctly represented.