温度值都是二十多，不代表每台设备使用相同单位、量程和校准关系。
本文使用MQTT 3.1.1、HTTP 或 CoAP 的演示设备与消息。设备通信需要同时定义身份、数据语义、时序与失败处理。协议传输确认不自动代表业务动作完成，采样时间也不能简单用服务器收到消息的时刻替代。
1. 从现象推到机制
原始寄存器值、工程量和业务判定应分层。设备模型需要字段类型、单位、有效范围、质量与采样时间。异常时不能把缺失值自动替换为零，否则会制造看似正常的低温或停机状态。
图中的四个节点分别表示原始输入、工程换算、质量标记、业务使用。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
用合成温度与电压数据建立消息结构，保留原始值和换算版本。只有手册或标定证据支持的公式才进入正式转换。
1
2
{"device":"sensor-7","sample_seq":8,"value":23.5,
"unit":"degC","quality":"good","schema_version":1}
在独立代理与虚构设备标识下实验，保留发布端、代理和消费端记录。命令与遥测使用不同主题及权限；网络断开、重复消息和设备重启都要作为正常分支观察。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 设备离线没有新数据 | 应显示过期或缺失而非零 |
| 两型号比例因子不同 | 不能共用未经验证的换算 |
| 值超出有效范围 | 应保留异常而非直接截成边界 |
对照 1：设备离线没有新数据
应显示过期或缺失而非零。观察时记录最近采样时刻和质量标记。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：两型号比例因子不同
不能共用未经验证的换算。观察时记录型号手册与标定版本。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：值超出有效范围
应保留异常而非直接截成边界。观察时记录原始值与数据质量。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
数据契约不是一次性表格。固件或传感器换型后，应重新确认字段含义和转换，避免新旧值混入同一趋势。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“值超出有效范围”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
