When publishing a command from the cloud, set the Message Expiry Interval property (in seconds) so stale commands are discarded if a device is offline longer than the validity window.
Include a Response Topic property in the PUBLISH packet pointing to a per-request reply channel (e.g., commands/responses/REQUEST_UUID); also set a Correlation Data property with the request UUID bytes.
Subscribe the command sender to the Response Topic before publishing the command; the device reads both properties from the incoming PUBLISH and uses them to route its reply.
The device processes the command and publishes the result to the Response Topic, copying the Correlation Data into the response PUBLISH so the sender can match it to the original request.
Set Message Expiry Interval on the response publish too, to avoid stale responses accumulating if the sender has moved on.
Use User Properties (arbitrary key-value pairs in the PUBLISH header) for metadata like firmware version or error codes without modifying the payload schema.
Known gotchas
If the retained message flag is set on a command with Message Expiry Interval, the broker updates the retained message's expiry on each publish; once expired, the retained message is deleted, not re-delivered.
Correlation Data is opaque binary; ensure the sender and device agree on encoding (e.g., raw UUID bytes vs. ASCII string) or correlation matching fails silently.
MQTT 5 Response Topic and Correlation Data are ignored by MQTT 3.1.1 clients on the same broker; if the fleet is mixed-version, the response routing must fall back to a convention-based topic scheme.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp