ThinkLink 多传感器怎样汇总成一个房间：虚拟资产与缺失数据

先写清房间需要什么结果

一个房间可以有多个温湿度传感器，但平均温度、最高温度和最新一次读数回答的是不同问题。先说明指标用途，再确定成员列表、单位和计算方式。以两台传感器为例，如果一台在送风口、一台在人员活动区，简单平均未必代表舒适度；本文提供聚合设计方法，不为具体建筑指定控制阈值。房间范围应来自经过确认的设备关系或业务清单，不能仅因设备名称包含同一个房号就自动纳入。上线前记录谁有权增加或移除成员，避免后续安装变化悄悄改变统计口径。

把源设备连接到资产对象

ThinkLink 使用 VIRTUAL 资产承接多设备通知，源设备通过 from_eui 指向目标 to_eui，并选择需要通知的属性类型。核对关系方向、目标类型和模型绑定，不要把连线接到普通设备后期待它自动拥有聚合能力。分别让每个成员产生一条有效数据，观察资产模型是否收到正确来源。关系的通知范围决定何时运行；不要为了“保险”订阅所有字段，使无关配置更新也触发业务计算。源设备身份应使用 EUI，显示名称用于阅读而不作为唯一识别键。

保存每个成员的值与有效性

聚合脚本需要区分新来的那台设备和其他成员的已有状态。可按官方过程数据机制保存各成员读数及必要时间信息，但有效时间必须说明来自采样还是接收，协议缺失时不能凭空补出。新脚本优先使用 process_data 保存中间状态，最终指标返回遥测。不要把“从未收到”“超出有效期”和“测量为零”合并处理。若需要处理过期成员，应明确何时重新计算；事件驱动关系没有新事件时不会自动重算，不能仅写一个时间比较就宣称具备独立的超时调度。

用缺失与重复样本验证计算

建议先用少量成员，手工算出预期结果再核对资产输出。测试正常两台、只到一台、重复同一条、乱序到达、无效单位和移除成员等情况。重复消息不应让成员数量增加，旧样本不应无条件覆盖较新的有效值；具体判断由项目脚本实现和测试。输出除聚合值外，可加入有效成员数和缺失说明，帮助看板解释结果。累计能耗与平均温度不能套同一算法；涉及累计量还要处理清零和换表，不能把每次收到的累计读数直接相加。

1. 确认成员与指标含义。
2. 逐个验证源设备到资产的通知。
3. 测试缺失、重复、乱序与成员移除。
4. 先展示观察结果，再独立验收控制。

先验收数据再启用联动

资产输出正确后，先让看板展示一段观察数据，确认成员数量、更新时间和缺失提示与现场一致，再考虑接入控制或通知。控制目标的身份、权限和动作回读仍要单独验证，聚合正确不等于下行可靠。交付应包含成员清单、指标公式、单位、有效期规则、重新计算时机和测试样本。若后续更换传感器或改变空间范围，应重新核对关系并处理旧成员缓存。这样的维护步骤能避免设备已移走但旧读数长期参与计算，使一个看似平滑的数字持续误导现场判断。