定义
Telemetry（遥测数据）是设备按 Thing Model 定义上报的实时或历史数据，如温度、湿度、电量、振动等。平台将遥测数据写入 Time Series DB，支持实时曲线、历史查询与趋势分析。
应用场景
- 实时监控：Device Monitoring 展示设备实时曲线
- 故障诊断：Fault Diagnosis 对比异常时刻前后曲线
- 预测性维护：Predictive Maintenance 基于时序数据分析
数据存储与查询
遥测数据写入 Time Series DB 时序数据库，按设备、属性、时间戳索引。支持实时订阅（如 Event Stream 事件流）、历史范围查询、聚合统计（最大值、均值、分位数等）。数据保留策略可配置，冷数据可归档至对象存储，平衡查询性能与存储成本。
与规则引擎联动
遥测数据可触发 Rule Engine 规则引擎：如温度连续 N 次超限、振动幅值突变等。规则引擎对遥测进行阈值判断或表达式计算，触发告警、Webhook 或 Downstream Command 下行指令，实现自动化运维与预测性维护。
遥测点是带时间戳的属性样本
一条遥测点至少包含设备标识、物模型属性、采样时刻和值。平台收到的时刻只能作为入库时刻，不能代替采样时刻。补传、离线缓存和批量上报都会使两个时刻分开，曲线若按入库时刻绘制，停机期间的历史会堆在恢复上线的那一秒。值的类型和单位以物模型为准，设备不得在同一属性里一会儿上报数值、一会儿上报字符串说明。
采样可以按周期，也可以在变化超过死区时上报。周期采样便于对齐多个属性；变化采样省流量，但安静期间会留下空白，空白不等于值是零。存储和作图都要保留“这段没有点”的信息。质量标记，例如传感器无效、超出量程、替代值，应随点一起保存。把无效值写成零，规则会把故障当成真实的零点去执行动作。需要可靠送达的点再单独选择服务质量，周期覆盖型的温度则不必全部要求确认。
上报周期要和存储保留策略一起定
周期定得比使用方的判断更密，多余的点只会放大写入和费用；定得比故障持续时间还长，则整次故障可能落在两个点之间，曲线上看不到。确定周期前应写明：告警需要多快发现、报表需要多细的粒度、设备链路能持续发送多少。三者冲突时，在设备侧做死区或短时聚合，平台侧保存能支持最细必要粒度的结果，而不是把原始极限频率无选择地留满整个生命周期。
保留策略是使用条件的另一半。热数据用于近期曲线和规则，温数据用于复盘，更老的数据若只留日聚合，就不能再回答分钟级问题。策略变更前要通知依赖旧粒度的规则和报表。设备时钟漂移超过允许范围时，点仍可入库，但应打上时钟不可信标记，避免和操作审计比先后。需要在影子里展示的最新值，只取每个属性的最近一个有效点，不要把影子当成第二份历史库；历史仍以时序记录为准，影子页面只是当前快照。
把事件和控制回执写进同一条遥测
事件是一次发生，例如门被打开、故障码出现；控制回执是某条指令的结果。它们都不是周期属性。塞进遥测表后，作图会在事件时刻画出一个无法插值的点，聚合均值也被拉偏。事件应走事件通道，回执应挂在指令标识上。遥测里只保留可重复采样的量。若业务确实要把故障码的当前值做成属性，应明确这是“当前代码”而不是“第几次发生”，次数和发生时刻另记。
重复上报同一采样时刻的不同值时，要有替换规则：默认保留先到的点并记录冲突，而不是静默以后到的覆盖，否则补传会改写已经用于告警的历史。属性标识沿用物模型，不要把寄存器地址直接当遥测名。改版时新增属性用新标识，停止使用的属性保留旧点以便读取，不能把新量纲写进旧标识。与设备影子同步时，只推动最新有效值；一次同步失败不应触发把整段历史再报一遍，那会把正常补传放大成流量高峰。
为每个属性记录预期周期和允许的空窗。空窗超过允许值时产生“缺失”而不是沿用上一个值去画平线。平线会被读成过程稳定。补传到达后，若落在已经聚合的窗口里，应重算该窗口或把该窗口标成未完成，不能让先算出的聚合永远代表那段时间。属性停用后停止期待新点，但查询旧时间范围仍能读到停用前的点。新点若又用回停用标识，拒绝入库并告警，防止量纲不同的新量写进旧序列。采样时刻以设备上报为准，平台不得按接收顺序改写；接收顺序只用于观察延迟，不参与曲线的时间轴。