Global – October 30, 2026 -- An MQTT topic convention that works in a pilot can become unmanageable after a second plant, a new equipment vendor or the first external integration, according to new TDengine guidance. Inconsistent paths make subscriptions overbroad, access rules hard to review and equipment identity ambiguous downstream.
Six-level namespace separates stable identity from changing values
The illustrative structure is industrial/{site}/{area}/{line}/{equipment_id}/{message_class}, with classes such as telemetry, event and health. It is an organizational convention, not a protocol-mandated industrial schema. Values such as pressure, mode or batch number belong in the payload. Putting a transient device state into the path, as in plant-a/line-2/filler-07/running/pressure, splits one asset across routes.
Wildcard and case rules drive subscription design
MQTT topic names are case-sensitive, so Line-2 and line-2 are different names. The + wildcard matches one level, while # must be the last character of a filter. Wildcards belong in subscription filters, not in published topic names. Routine application subscriptions should avoid # because its breadth complicates least-privilege access and message-rate control. Hierarchy depth must also stay constant across sites. Otherwise a filter can silently miss or overmatch messages in another plant.
Five naming rules apply before devices publish at scale
- Use a single case convention.
- Use controlled site and equipment identifiers instead of display labels.
- Reserve message-class names and document their payload contracts.
- Define how renamed, retired or moved assets keep their historical identity.
- Version breaking changes explicitly, for example with a v2 level.
Broker ACLs and TDengine IDMP still require separate validation
ACL syntax is broker-specific, so policies must be validated on the deployed broker. A topic pattern alone is not authorization. TDengine's MQTT ingestion Topic Analysis parses topic levels into variables for payload transformations, but it does not create an asset hierarchy or validate equipment identity. Governed equipment context belongs in TDengine IDMP, whose asset trees should be configured from reviewed context.
TDengine recommends testing any namespace with at least two plants and several equipment classes before standardizing it.