MQTT Topic design confusion leads to frequent project rework. Real cases show that unstandardized naming causes problems such as case mismatch, wildcard abuse, and device migration failure. The core problem is that Topic does not form a unified semantic skeleton, and identity and business data are mixed. Follow the “Catch 12”:
Story 1: A hospital equipment maintenance project was renamed and reworked for three weeks.
The year before last, we took over a hospital equipment maintenance project and reconstructed the equipment access layer. Opening the original Topic list, I was confused:
/device/001/temperature
Device/002/Temperature
sensor/room1/data
/buildingA/floor3/room305/sensor1/data
dev_003/CMD
Five styles, three uppercase and lowercase, two starting with /. What’s even more outrageous is that some Topics use camel case, some use underscores, and some directly incorporate the location information of the device.
What’s the result?
There were three failures in the first week: In the first fault, the device reported Device/002/Temperature, but the backend subscribed to device/002/temperature. The case did not match and all messages were lost. It took three hours of troubleshooting to discover the problem; for the second fault, the operation and maintenance used # to subscribe to all topics for monitoring. As a result, it was flooded with messages and the Broker memory soared to 90%; the third fault was the most hidden – the topic on the device side was embedded with the location of the computer room /buildingA/floor3/room305/sensor1/data. Later, the campus was adjusted and the equipment was moved from the 3rd floor to the 5th floor. All topics were invalid, and all devices needed to re-burn the firmware.
The root cause of these three failures is the same:There is no standard for topic design.
Story 2: A smart meter company was discussing “whether to migrate to Kafka” 4 months after it went online.
Last year I helped do an architecture review for a company that makes smart meters. The project has been online for 4 months, and the development team is already discussing “whether to migrate to Kafka as a whole.”
I opened their EMQX management backend, took a look at the Topic list, and knew immediately what the problem was:
/device/123/report
device/456/data
/report/device/789
data/temp/111
temp/222
meter/333/readings
/334/energy
Topics for 8 devices and 8 naming styles.
Looking further down the subscription relationship – the back-end service is subscribed to # (full wildcard), the front-end is also subscribed to #, and the alarm service is still #. Three consumers receive exactly the same message flow, and each performs string matching at the business layer to filter “Is this the message I care about?”
Broker’s publish/subscribe mechanism is useless, and MQTT is used as a TCP private protocol.
This is not an isolated case. In the MQTT projects I have seen,At least 90% of Topic designs are buried in the pit of rework in the first month.. Once a Topic is burned into the firmware on the device and hard-coded into the code by multiple microservices, changing it is a “protocol version migration”—more painful than changing protocols.
Topic is the routing identifier of MQTT messages. It plays four roles at the same time:
-
Routing addressing: Broker relies on it to decide who to send the news to
-
Permission boundaries: ACL relies on it to control “who can subscribe to which segment” and is the first gate of security.
-
Business modeling: Equipment layering, tenant layering, and business layering are all mapped on it.
-
Data pipeline: The rule engine relies on it for filtering, forwarding, and landing timing library
If you do any of these four things wrong, you will have to rework it later. And theyAll depends on the original naming decision。
The following 12 catch-all rules are a complete summary after I spent three months to bring the topic system of all the company’s projects from chaos to standardization. They are divided into five groups: first establish the skeleton, then observe the boundaries, then establish the rules, then prevent misuse, and finally implement them. Follow these steps and your MQTT architecture can support 100,000 devices without getting confused.
1. Topic is case sensitive: device/001/data and Device/001/Data are two completely different topics.
2./ is the level separator; + represents single-level wildcarding, # represents multi-level wildcarding, and wildcards can only be used for subscription and not for publishing.
3. The published message must not carry + or #, the Broker will treat it as a normal character, and the downstream will never be able to match it.
Rule 1: Topic is a hierarchical tree, not a string, and the level is from general to specific
Topic is a hierarchical tree separated by /, which is essentially the key of a routing table. Each layer answers a routing dimension. The first thing to do when designing is to give it a stable semantic skeleton, from left to right, from thick to thin.
Pitfalls stepped on:
When I took over a hospital equipment maintenance project, the topics I saw were flat strings like /device/001/temperature, Device/002/Temperature, sensor/room1/data, and dev_003/CMD, with no hierarchy. The subscriber can only rely on like fuzzy matching, and permissions cannot be issued based on prefixes. Later, when doing multi-tenancy, all device IDs crashed and the entire messaging system could not be changed.
Recommended paradigm:
v1/
if(string.IsNullOrWhiteSpace(topic))
throw new ArgumentException("Topic不能为空");
if(topic.StartsWith("/") / topic.Contains('#'))
throw new ArgumentException("发布Topic不允许包含通配符 + #");
if(topic.Any(char.IsUpper))
throw new ArgumentException("Topic必须全部小写");
///{type}
Correct example:
v1/t01/sensor_th/vdev_0001/up/telemetry
v1/t01/sensor_th/vdev_0001/up/event
v1/t01/sensor_th/vdev_0001/down/cmd
Counterexample:
temp
plc_temperature_alarm_2024
dev1_data
data1
The “flat string” in the counterexample has no hierarchy. The subscriber can only rely on fuzzy matching, and permissions cannot be issued based on prefixes.
reason: A qualified Topic must be self-explanatory. The Topic level should answer three questions: “What is this message, where does it come from, and where does it go?” Each layer only expresses one semantic meaning. Do not stuff two meanings into one layer (such as meter-tenantA).
Catch 2: Control the level between 3 and 7, and lock it as a protocol
-
Too shallow (1~2 layers): The amount of information is not enough to subscribe and authenticate by dimension.
-
Too deep (8 floors up): Broker wildcard matching overhead increases sharply, readability collapses, and ACL rules cannot be written completely.
Lock layers 3 to 7 as protocols and write them into the team lint: if they are exceeded, they will be directly refused to be released. The topic level is controlled between 3 and 7 levels, and 5 to 6 levels are recommended. If it exceeds the level, the design must be re-examined.
Pitfalls stepped on:
There is a project Topic designed as company/bld1518/floor3/room305/hvac/type-a/hvac719/temperature/status/realtime – 10th floor. Every time I troubleshoot a problem, it takes me half a day just to look at the topics. When Broker processes Topic matching, the deeper the level, the greater the overhead. AWS IoT Core even stipulates that there can be a maximum of 7 forward slashes in a Topic.
Recommended 6-layer standard structure:
{版本}/{租户}/{产品}/{设备}/{方向}/{类型}
Correct example:
v1/tenant_a/meter/DEV0001/up/telemetry
Counterexample:
v1/cn/shanghai/factory02/workshopA/production_line03/sensor/vdev001/up/telemetry ← 10层
reason: If it is too shallow, the amount of information cannot be subscribed by dimension; if it is too deep, the matching overhead increases sharply, the readability collapses, and ACL rules cannot be written completely. Lock layers 3 to 7 as protocols and write them into team lint. Too deep a hierarchy will make the Topic difficult to read and maintain, increase the Broker’s matching overhead, and easily introduce unnecessary detailed information into a certain layer.
Catch 3: Uplink/downlink separation, data topic and instruction topic are physically isolated
Data and instructions must be distinguished with different prefixes, and upstream and downstream traffic must be separated.
Pitfalls stepped on:
In one project, the device used the same topic to both report data and receive instructions. As a result, the messages from the backend and the device interfered with each other, the messages were pushed in a loop, and the Broker was directly hung up.
Recommended structure:
v1/{tenant}/{product}/{deviceId}/up/telemetry // 设备上报
v1/{tenant}/{product}/{deviceId}/up/event // 告警事件
v1/{tenant}/{product}/{deviceId}/up/ack // 指令应答
v1/{tenant}/{product}/{deviceId}/down/cmd // 平台下发指令
v1/{tenant}/{product}/{deviceId}/down/config // 平台下发配置
Correct example:
v1/t01/sensor_th/vdev_0001/up/telemetry
v1/t01/sensor_th/vdev_0001/down/cmd
Counterexample:
meter/123/data // 既上报又下发，方向混杂
reason:Data Topic and Instruction Topic Lifecycle is completely different from security policy——Data is published by the device, and instructions are subscribed by the device. Mixed together, ACL permission control cannot be done, and message loops cannot be prevented. Once the direction is clear, the consumer can subscribe accurately and the Broker can route accurately.
The core principles of this group: Stable identities go into Topic, and all volatile data goes into Payload.
The following Catch-4 is the general principle, and Catch-5, 6, and 7 are the specific applications of this principle to different data types.
Catch 4: Identity goes into Topic, business data goes into Payload (core principle)
The device ID should neither be at the front nor at the end:
Put the changing (device ID) on the fixed layer, and the unchanging dimensions (environment, type) as the anchor layer, wildcards and ACL can be targeted.
Identity identifiers (tenant, product, device ID) must be placed in the Topic path; business data (temperature, humidity, status values, etc.) must be placed in the Payload.
Pitfalls stepped on:
In order to keep the topic simple, many projects stuff all device IDs into the JSON message body, and the topic is unified into device/data. As a result, the Broker’s ACL authentication is based on the Topic path and cannot parse JSON internal fields, resulting in the inability to perform permission isolation. Once the business code is vulnerable, cross-device unauthorized access will occur.
Recommended practices:
The device ID should be placed at a fixed layer (such as layer 4), not at the front or at the end.
Correct example:
v1/t01/sensor_th/vdev_0001/up/telemetry
Counterexample:
device/data // 所有设备共用一个Topic，ID藏在json内
reason: Payload is the business data carrier; Topic is responsible for routing and authentication. Broker’s ACL is based on the Topic path and cannot parse Payload. Only when the identity enters the topic can the permissions be accurate to the device level. The responsibilities of the two should be strictly separated.
Military Rule 5: Timestamps, values, batch numbers, and location information must never be entered into Topic (volatile data applications)
Topics only carry stable, enumerable routing identities and message types, and variable high-cardinality data such as timestamps, values, batch numbers, and locations are all put into the payload.
Pitfalls stepped on:
Some projects have written the temperature value and timestamp into the topic: device/v001/up/temperature/24.3, device/v001/up/report/1756888888. As a result, the topic name changed every time it was reported, the subscription was completely invalid, and the Broker routing table was exploded. There were also devices that programmed the location floor3 into the Topic. Later, when the device was moved from the 3rd floor to the 5th floor, all Topics became invalid and all devices had to re-burn the firmware.
specification:
The following four types of dataNever enter Topicalways enter Payload:
Recommended practices:
Topic only represents routing identity and message type, and all dynamic values are put into JSON Payload.
Correct example:
Topic: v1/t01/sensor/vdev001/up/telemetry
Payload: {"ts":"2024-06-01T08:00","value":36.5,"location":"floor5"}
Counterexample:
device/v001/up/temperature/24.3 ← 温度值进Topic
device/v001/up/report/1756888888 ← 时间戳进Topic
factory/bld1518/floor3/room305/hvac/telemetry ← 位置进Topic
reason: Any enumeration value (time, value, batch, location) that will be continuously added belongs to data and does not belong to Topic. Data can be released, but Topics must be converged and enumerable. Adding dynamic values to topics will cause the number of topics to expand infinitely, the subscriber cannot wildcard, and offline messages cannot be replayed. Once the position and other high-cardinality dynamic segments change, all related topics will become invalid and the firmware needs to be re-burned or reconfigured. If the location belongs to a stable asset topology rather than a volatile attribute, it can be reserved with caution; but as long as it can be moved or changed, the payload should be placed.
Rule 6: Don’t split topics according to indicators, aggregate and report
Topic should align with the stable routing dimension of “device/entity” and aggregate and report multiple measurement points as the Payload field.
Pitfalls stepped on:
Dozens of measurement points on a device generate dozens of topics, and tens of thousands of devices generate hundreds of thousands of topics. The pressure on Broker memory and subscription matching skyrockets.
specification:
Common measurement points are aggregated into a telemetry topic, and multiple measurement points are all put into the JSON Payload; individual key alarm events are separated into separate event topics.
Recommended practices:
Topic: v1/t01/sensor/vdev001/up/telemetry
Payload: {"temperature":24.5,"humidity":48,"voltage":3.31}
Counterexample:
Topic: device/v001/temperature
Payload: {"temperature":24.5}
Topic: device/v001/humidity
Payload: {"humidity":48}
Topic: device/v001/voltage
Payload: {"voltage":3.31}
reason: Splitting Topics based on indicators will enlarge the number of Topics to “number of devices × number of measurement points”, which will cause the Broker’s subscription matching, memory and permission management pressure to skyrocket, which will bring down the Broker. Aggregation reporting is a standard practice for IoT platforms.
Catch 7: PII is strictly prohibited from entering the topic (security boundary)
Topic is routing metadata, and PII must be excluded from Topic at the design stage; user identities must be replaced with unrecognizable identifiers such as UUIDs, sensitive data must only be placed in payloads, and leakage surfaces must be controlled through permissions, encryption, and desensitization.
Pitfalls stepped on:
Some projects write the mobile phone number directly into the topic: user/13800138000/device/001/data. Later, when the data was exported to a third party for analysis, the mobile phone number was directly exposed in the Topic log. What’s more serious is that the Broker’s monitoring panel, log system, and link tracking all record the Topic name, and PII is leaked to every corner.
specification:
Any PII (mobile phone number, ID number, email address, name, etc.) is prohibited in the Topic and should be replaced by UUID.
Recommended practices:
user/uuid-a1b2c3/device/001/data
Correct example:
user/uuid-a1b2c3/device/001/data
Counterexample:
user/13800138000/device/001/data
user/zhangsan/device/001/data
reason: Topics will leave traces in various aspects such as Broker logs, monitoring panels, link tracking, message queues, etc. Once PII enters the Topic, it will be leaked in a wide range of areas. This rule is not only the application of “what enters the topic”, but also the safety bottom line.
Catch 8: Only use lowercase letters, numbers, and hyphens. Mixing of uppercase and lowercase letters and special symbols is prohibited.
The character set of each layer of Topic must be unified for the entire project as “lowercase letters + numbers + hyphens”, and uppercase/camel case, underscores, spaces, Chinese, special symbols, and leading/trailing slashes are prohibited.
Pitfalls stepped on:
The device sent Device/001/temperature, and the backend subscribed to device/001/temperature. Because of the case sensitivity, all the messages were lost, and it took a whole afternoon to troubleshoot. There are also projects that use spaces and Chinese, and parse exceptions on different SDKs.
specification:
- Each Topic level only usesLowercase letters (az), numbers (0-9), and hyphens (-)。
- Do not use capital letters, do not use camel case (such as deviceTemp), and do not use underscores (such as device_temp).
- Do not use spaces, Chinese characters, or special symbols
- Do not start or end with a slash
Recommended practices:
warehouse/sensor/temp-001/telemetry
Counterexample:
Device/001/temperatureData ← 驼峰
device/001/temperature_data ← 下划线
设备/温湿度01/上报 ← 中文
/device/001/data ← 前导斜杠
reason: Case sensitivity means that Device and device are two different topics; spaces, Chinese characters, and special symbols will be encoded incorrectly in different clients, embedded SDKs, logs, and monitoring links. Leading/trailing slashes introduce empty string levels, interfering with wildcard matching and ACL prefix authorization. Underscores conflict with wildcard escaping in some Broker ACL rules, and some embedded SDKs also handle them inconsistently, so it is safest to use hyphens uniformly.
Catch 9: Keep system messages in reserved segments and physically isolate them from the business
Starting with $ is a namespace reserved by the MQTT server (such as $SYS), which must not be occupied by client business messages; the platform’s own system messages such as device registration, online and offline, and OTA notifications should be layered separately using unified prefixes that do not conflict with the business, and physically isolated from the business topic to avoid confusion with the Broker’s internal topic to facilitate monitoring, ACL authorization, and operation and maintenance troubleshooting.
Pitfalls stepped on:
Many teams have created their own “system topics” and mixed them with the Broker’s internal topics. During operation and maintenance troubleshooting, it is difficult to distinguish which ones are systems and which ones are business.
specification:
Use a unified prefix to physically isolate “system messages” and “business messages”. Business messages are prohibited from starting with $; system messages use fixed prefixes, such as sys/, meta/, and do not occupy $SYS.
Recommended practices:
$SYS/broker/... # Broker自身监控指标（协议保留，业务别用$开头）
_meta/device/register # 设备注册、上下线等平台元数据
sys/ota/notify # 系统级：固件升级通知
meter/123/temp/report # 业务级：电表温度上报
Correct example:
sys/ota/notify
_meta/device/register
Counterexample:
/system/device/123/online ← 和Broker内部Topic容易混淆
reason: System messages are physically isolated from the business, so the monitoring and alarm logic is clear. It is also recommended to have a separate layer for life cycle events such as wills (LWT) and online notifications. $SYS is reserved by the Broker. Brokers such as EMQX have provided monitoring data such as the number of connections and message throughput through $SYS. The business system Topic should be completely isolated from $SYS. At the same time, pay attention to the character set constraints of Military Regulation 8. _meta should be uniformly changed to meta to avoid underscores.
Catch 10: Wildcards only belong to the subscriber, and global subscriptions are prohibited in the production environment.
Wildcards (literal publishing) are prohibited on the publishing side, and the use of +/# is strictly restricted on the subscribing side. Broad subscriptions are strictly prohibited for production and consumers # to prevent overload and data leakage, and # can only be used in controlled scenarios such as management debugging and equipped with ACL and current limiting.
Pitfalls stepped on:
In order to do full monitoring, operation and maintenance colleagues use # to subscribe to all messages on the Broker. After the number of devices increased to 50,000, the Broker CPU soared to 95%, and the message delay changed from milliseconds to seconds; # Covering all topics, even system topics and multi-tenant messages may be consumed together, causing serious data security risks. There are also publishers who write + or # into the Publish Topic, and the Broker treats them as ordinary characters. The downstream subscriptions will never match them, and the errors are extremely subtle.
specification:
-
Publish(PUBLISH): Absolute literal, zero wildcards. + or # must not appear in the publishing Topic.
-
Subscription (SUBSCRIBE): Only + and # are allowed. + Only matches a single layer and should be limited to necessary levels; # Matches multiple layers and must be placed on the last layer.
-
Production backend consumers are prohibited from subscribing to global #, also prohibits over-wide multi-layer wildcard subscriptions such as v1/#.
-
+/# can be used in the ACL according to the subscription filter semantics, but the authorization scope must be tightened and the full subscription cannot be released in disguise.
Recommended practices:
// 合法：用 + 限定层级
v1/t01/sensor/+/up/telemetry
meter/+/temp/report
Counterexample:
# ← 生产消费者禁止
v1/# ← 可能打挂消费服务
reason: The performance of wildcard subscription is weaker than that of ordinary topic subscription, and it will consume more Broker and consumer resources. Global# will cover the entire business level. Under high cardinality, consumers will be overwhelmed by massive messages, Broker CPU and latency will deteriorate, and it will bring the risk of full multi-tenant data leakage. +/# on the publishing side will not be routed according to wildcard characters, but will be treated as ordinary characters, causing downstream subscriptions to never match and making troubleshooting difficult. Therefore, publications must have zero wildcards, subscriptions must use + with caution, and global # is disabled in the production environment.
Catch 11: ACL must be matched with Topic, deny by default, allow explicitly
Topic design must be implemented simultaneously with the ACL policy of “deny by default, allow explicitly”, and strictly limit the device to only publish its own up prefix and subscribe to its own down prefix to prevent compromised devices from stealing data or pretending to issue instructions, causing production accidents.
Pitfalls stepped on:
We have a project where the topic design is very standardized, but the ACL policy has not kept up. As a result, a compromised device used factory/+/+/+/telemetry to subscribe to the data of all devices in the entire factory. What’s even more dangerous is that if the device can publish topics starting with down, the malicious device can disguise itself as a platform and issue control instructions to other devices.
specification:
The ACL should deny by default and allow explicitly, and the permission granularity should be accurate to the topic level. The core principle is the minimum permissions for uplink and downlink: the device is only allowed to publish the up prefix, and is only allowed to subscribe to the down prefix, and the device is refused to publish any topic starting with down.
Recommended ACL policy:
Correct example:
{allow, {user, "device-001"}, publish, ["v1/t01/sensor_th/device-001/up/#"]}.
{allow, {user, "device-001"}, subscribe, ["v1/t01/sensor_th/device-001/down/#"]}.
{deny, all}.
Counterexample:
无ACL，任意订阅
设备可发布 down/#，可伪装平台下发指令
设备可订阅 factory/+/+/+/telemetry，越权读取全厂数据
reason: ACL is the last line of defense for Topic security. Without minimum permissions, malicious devices can disguise themselves as platforms and issue commands to other devices, causing security incidents; wide wildcard subscriptions can allow a compromised device to read the data of the entire tenant/factory. ACL must be denied by default, allowed explicitly, authorized hierarchically, and designed, reviewed, and launched simultaneously with the topic naming skeleton.
Catch 12: Specifications must be coded + version prefixed, don’t just write them in documents
Topic specifications must be upgraded from document conventions to compile-time constraints and run-time verification. If they are not compliant, an exception will be thrown.
Pitfalls stepped on:
The specifications were only written in the Wiki, and three months later new colleagues were still writing them randomly. During business iteration, the old topic is directly modified, causing all equipment to be paralyzed at once.
specification:
We are using enumeration + Builder to lock the naming rules so that developers cannot make mistakes even if they want to. Before publishing, verify the layer number, character set, and whether it contains wildcards. If it is not compliant, an exception will be thrown directly. Add the version prefix v1/v2 to the outermost layer.
Recommended code:
///
/// MQTT Topic统一构建器，强制命名规范，避免手写字符串出错
///
public static class MqttTopicBuilder
{
/// 设备上报遥测数据
public static string Telemetry(string version, string tenant, string product, string deviceId)
{
var topic = $"{version}/{tenant}/{product}/{deviceId}/up/telemetry".ToLowerInvariant();
ValidateTopic(topic);
return topic;
}
/// 平台下发控制指令
public static string Command(string version, string tenant, string product, string deviceId)
{
var topic = $"{version}/{tenant}/{product}/{deviceId}/down/cmd".ToLowerInvariant();
ValidateTopic(topic);
return topic;
}
/// Topic合法性校验
public static void ValidateTopic(string topic)
{
if(string.IsNullOrWhiteSpace(topic))
throw new ArgumentException("Topic不能为空");
if(topic.StartsWith("/") || topic.EndsWith("/"))
throw new ArgumentException("Topic禁止以斜杠开头或者结尾");
if(topic.Contains('+') || topic.Contains('#'))
throw new ArgumentException("发布Topic不允许包含通配符 + #");
if(topic.Any(char.IsUpper))
throw new ArgumentException("Topic必须全部小写");
}
}
Correct example:
v1/meter/123/temp/report
v2/meter/123/temp/report
Counterexample:
硬编码字符串拼接
硬改老Topic的Payload格式
reason: Documentation is soft, code is hard. Only when specifications become lint, type and pre-release verification can they really survive. Enumeration + Builder narrows the legal levels and character sets into the type system, blocking uppercase, special symbols, illegal levels and wildcards at compile time; runtime verification covers dynamic splicing and external input. The version prefix supports grayscale and smooth migration, preventing all devices from being paralyzed at once. It also allows new and old protocols to coexist in parallel and upgrade firmware in batches.
Standard IoT platform (6 layers):
v1/{tenant}/{product}/{deviceId}/up|down/{type}
Multi-tenant SaaS platform (7 layers):
{租户}/{环境}/{站点}/{设备类型}/{设备ID}/{数据流}/{指标名}
Industrial Internet of Things (ISA-95, Layer 7):
{企业}/{工厂}/{车间}/{产线}/{设备类型}/{设备ID}/{数据流}
Smart home (simplified version, 5 layers):
{家庭ID}/{房间}/{设备类型}/{设备ID}/status|control|telemetry
// ===== 设备上行（设备 → Broker → 后端）=====
v1/{tenant}/{product}/{deviceId}/up/telemetry // 遥测（多测点聚合）
v1/{tenant}/{product}/{deviceId}/up/event // 告警/故障/事件
v1/{tenant}/{product}/{deviceId}/up/status // 在线状态上报
v1/{tenant}/{product}/{deviceId}/up/ack // 指令执行应答
// ===== 平台下行（后端 → Broker → 设备）=====
v1/{tenant}/{product}/{deviceId}/down/cmd // 控制指令：开关、重启
v1/{tenant}/{product}/{deviceId}/down/config // 参数配置下发
The protocol is the skeleton of MQTT, and the topic is its blood vessel. No matter how standard the message format is, if the blood vessels are connected randomly, the entire system will still suffer from blood clots.
Topic is not just a string written casually, it is part of the access layer architecture – it takes one more day to design in the early stage and saves countless nights of troubleshooting in the later stage. It is much more cost-effective to write these 10 items into team standards and stick to them on the first day they go online than to spend four months doing information management afterwards.
I compiled a “Topic Naming Standard Template”, including:
-
12 Topic design military rules (divided into 5 groups: determine the skeleton → observe boundaries → establish rules → prevent misuse → implementable, each article contains counterexamples and correct writing methods)
-
4 sets of naming templates that can be directly applied (standard IoT platform/multi-tenant SaaS/industrial ISA-95/smart home)
-
Wildcard usage boundary + ACL least privilege policy table + 12-item pre-go-live checklist
-
Summary of 8 common counterexamples + complete topic collection out of the box
-
Real pitfalls I have encountered (messages lost due to case mismatch, wildcard subscription blocking the Broker, location information embedded in Topic causing relocation failure)
Send a private message to “Topic Naming Standard Template” to get it directly, no tricks.
Friends who are doing MQTT for the Internet of Things can communicate together. I will continue to update this series in this account later, and will also intersperse some records of software exam architect preparation, technology management transformation, and embedded learning.
I am an[IT planner]. I have been working on .NET IoT backend for 8 years. I am moving from pure backend to software and hardware integration architect. The road isn’t easy, but it’s worth it.
Note: The test method code and sample source code have been uploaded to the code library. Those who are interested can take a look.
