Should an MQTT topic contain a device name or an ID?

Use a stable ID. A display name can change, and renaming should not break subscriptions or access rules.

When should I use retained messages in MQTT?

Use them for state that a new subscriber should see immediately, such as device status or the last known configuration. Avoid them for high-frequency telemetry.

Which MQTT QoS level should IoT devices use?

QoS 0 for frequent telemetry, QoS 1 for commands and important events. QoS 2 is rarely worth its extra round trips.

MQTT Topic Design for IoT Fleets: Naming Scheme

Short answer. Use lowercase, hierarchical topics that identify the tenant, site and device first, then the kind of message (telemetry, status, command). Publish device state as a retained message with a last-will message for offline detection, use QoS 0 for frequent telemetry and QoS 1 for commands, and restrict every device to its own branch of the topic tree.

A topic structure that scales

Topics are read left to right, so put the broadest scope first. A structure that works for fleets spread over several sites and customers is:

{tenant}/{site}/{device}/{kind}/{name}

For example:

acme/farm-01/node-0042/telemetry/temperature
acme/farm-01/node-0042/telemetry/battery
acme/farm-01/node-0042/status
acme/farm-01/node-0042/cmd/set-interval
acme/farm-01/node-0042/cmd-ack

This is an example scheme to adapt, not a standard. Its value is that a dashboard can subscribe to one site with acme/farm-01/+/telemetry/# and an access rule can match a whole tenant with a single prefix.

Naming rules

No leading slash. A leading slash creates an empty first level that wastes a segment and confuses wildcards.
Do not start with $. Topics beginning with $ are reserved for the broker, for example $SYS.
Use stable IDs, not display names. Renaming a device in a dashboard should not break subscriptions.
Lowercase ASCII, with hyphens. Topics are case-sensitive, and spaces or non-ASCII characters cause trouble in tools.
Never use + or # in published topic names. Wildcards are for subscriptions only.
Keep data out of the topic. Timestamps and values belong in the payload.
Keep it short. The topic is sent with every message, which matters on constrained links.

Status: retained messages and last will

Each device should publish a retained status message, such as online, right after connecting. It should also register a last-will message, such as offline, when it connects. If the connection drops without a clean disconnect, the broker publishes the last will for the device. Because the status is retained, any dashboard that subscribes later immediately receives the last known state.

Use retained messages for state, not for high-frequency telemetry.

QoS and payloads

QoS 0 for frequent telemetry, where the next reading replaces a lost one.
QoS 1 for commands, acknowledgements and important events, where the message must arrive at least once. Make handlers idempotent, because QoS 1 can deliver duplicates.
QoS 2 is rarely needed and costs extra round trips.
Payloads: use compact JSON with a timestamp, a value and a unit, for example {"ts":1767225600,"v":21.4,"u":"C"}. Choose a binary format only if bandwidth or battery truly demands it.

Access control

Give every device its own credentials and allow it to publish and subscribe only inside its own branch, for example acme/farm-01/node-0042/#. Give dashboards and users read access at the site or tenant level. Use encrypted connections (TLS) between devices and the broker. With this model one compromised device can be revoked without affecting the rest of the fleet, and customers sharing a broker cannot see each other's data.

Where to go next

If you are connecting a mixed set of devices to one platform, see our IoT Integration service, and e.FM Cloud for MQTT-based dashboards with multi-tenant accounts.

MQTT Topic Design for IoT Fleets: A Practical Naming Scheme