所有数据都发到一个主题，接收端很快就会靠猜字段判断用途。主题规划需要反映业务方向。
本文使用MQTT 3.1.1、HTTP 或 CoAP 的演示设备与消息。设备通信需要同时定义身份、数据语义、时序与失败处理。协议传输确认不自动代表业务动作完成，采样时间也不能简单用服务器收到消息的时刻替代。
1. 从现象推到机制
遥测描述采样事实，命令表达希望设备执行的动作，状态报告设备当前已确认情况。命令号和设备号承担不同身份，响应要关联原命令。主题权限还要限制设备只能发布或订阅属于自身的范围。
图中的四个节点分别表示设备身份、遥测事实、控制命令、状态反馈。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
用虚构 sensor-7 定义三类主题和消息版本。时间字段区分设备采样与网关接收，单位直接放在结构约定中。
1
2
3
4
5
demo/device/sensor-7/telemetry
demo/device/sensor-7/command
demo/device/sensor-7/state
command: command_id, desired_state
state: command_id, reported_state, observed_at
在独立代理与虚构设备标识下实验，保留发布端、代理和消费端记录。命令与遥测使用不同主题及权限；网络断开、重复消息和设备重启都要作为正常分支观察。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 设备收到命令但尚未执行 | 不能直接把目标状态当真实状态 |
| 同设备重复上报采样 | 需要判断是重传还是新样本 |
| 设备订阅另一设备命令 | 应由主题权限阻止 |
对照 1：设备收到命令但尚未执行
不能直接把目标状态当真实状态。观察时记录desired 与 reported 字段。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：同设备重复上报采样
需要判断是重传还是新样本。观察时记录采样身份与序号。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：设备订阅另一设备命令
应由主题权限阻止。观察时记录代理 ACL 与实际设备身份。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
主题名本身不形成认证。代理账号、访问控制与传输保护需要单独配置，消息结构也应有版本演进策略。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“设备订阅另一设备命令”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
