ThinkLink 收不到设备数据？沿网关、NS、AS 到实时数据逐层排查

先选一台能核对结果的设备

第一次接入建议使用协议资料完整、当前参数已知的设备，并选择能够独立验证的量，例如与现场参考仪表对比温度。这样出现问题时，可以区分“链路没有数据”和“数值解释错误”。

开始前记录设备型号、区域与频点计划、入网方式、上报周期、固件版本和使用的物模型。设备密钥应在受控位置核对，不应贴进工单截图或公开文章。给设备一个易识别的测试名称，有助于在多个数据页面中追踪同一次上报。

四层证据，分别说明什么

ThinkLink 将网络报文和业务数据分开呈现。对于直接接入平台原生 LoRaWAN 网络服务的链路，可以按下表依次检查。若数据来自外部网络服务器的 MQTT 桥，应先检查桥的来源消息和 AS 入站，不能要求所有外部数据都出现在本地 NS 页面。

根据最后一个成功环节定位故障

先检查网关是否连接到了预期平台，再确认设备产生上行。对刚复位或正在入网的设备，按文档使用 DevEUI 查找入网报文；已入网后的普通数据帧需要注意 DevAddr 与查询条件。用错误的标识筛选，可能让实际存在的数据看起来“消失”。

NS 有数据但 AS 没有可用报文时，优先核对设备档案、入网状态和密钥一致性。AS 已有负载而实时页面没有值时，再检查物模型绑定、端口分支和解析输出。Base64 编码只是表达字节的方式，不应把 AS 中仍为 Base64 的 payload 误认为尚未完成 LoRaWAN 解密。

用同一次上报关联各层记录

排查时固定一个短时间窗口，记录网关收到报文的时间、设备上报序号以及 AS 中的业务端口。再把该条负载送入模型测试，与实时页面中的时间和字段值比较。若混用昨天的 payload 和今天的新模型，容易得到无法复现的结论。

对于能手动触发上报的设备，可在现场产生一次已知状态变化，并记录实际操作时间。不能手动触发的设备则按其上报周期等待，不要连续重置设备来“催数据”。每次改变参数后保留修改记录，确保能解释结果变化来自哪里。

首台验收通过后，再复制配置

建议把首台设备验收分成连续性、正确性和可维护性三项：连续性看是否按预期上报；正确性看字段、单位与现场状态是否一致；可维护性看离线后如何定位、模型版本如何识别。

只有这三项成立，再将适用的模型和档案配置用于同类设备。相同外观或相近型号不代表协议相同。对不同固件、端口定义或传感器选件，仍应保留新的样本测试。

1. 保存一条正常上报样本及其期望值。
2. 核对实时页面和历史查询结果。
3. 验证一次异常或缺失数据的显示方式。
4. 记录排障路径、模型版本及负责人。