1. 设备管理
ThinkLink （简称 TKL）支持多种设备类型的接入与统一管理，包括 LoRaWAN 设备、子设备、虚拟设备以及通过第三方协议接入的外部设备。系统提供灵活的设备生命周期管理能力，涵盖设备档案配置、物模型挂载、属性设置及设备间关联关系建立等功能。
- 【注意1】 ThinkLink V2 支持 LoRaWAN 设备、子设备、虚拟设备和外部设备等多种类型。
- 【注意2】 在新增设备时，若选择非 LoRaWAN 类型的第三方设备，其通信接口协议必须符合 TKL V2 的协议标准。
- 【注意3】 对于通过 ThinkLink NS 接入的 LoRaWAN 设备，需先在“LoRaWAN设备档案”中完成设备注册，再将对应的
devEUI添加至平台设备列表中。
1.1. LoRaWAN 设备档案
所有使用 OTAA 或 ABP 模式接入的 LoRaWAN 终端设备，均需在此模块预先创建设备档案。该档案用于网络服务器（NS）对设备的身份认证、密钥管理和通信调度。
1.1.1. 新增单个LoRaWAN 设备档案
| 字段名 | 是否必填 | 说明 |
|---|---|---|
devEui | 必填 | 设备唯一标识符（EUI），全局唯一，不可重复。 |
devAddr | ABP 模式下必填 | 设备地址，确保在网络中不冲突。 |
enable | 必填（默认值：TRUE） | 是否启用该设备。TRUE 表示启用，FALSE 表示禁用。 |
down_enable | 必填（默认值：TRUE） | 是否允许下行通信。TRUE 允许，FALSE 禁止。 |
lw_ver | 必填（建议值：1.0.2） | LoRaWAN 协议版本。推荐填写 1.0.2，兼容大多数 1.0.3 和部分 1.0.4 地区协议。 |
standard | 必填 | 频段标准，可选： • CN470 • EU433 • EU868 • AS923 • AU915 • US902 |
class_mode | 必填（默认值：ClassA） | 设备正常工作模式，可选：ClassA 或 ClassC。 |
join_class_mode | 必填（默认值：ClassA） | 重入网后的工作模式，应与设备实际行为一致。 |
app_key | OTAA 模式下必填 | OTAA 加密密钥（应用主密钥）。 |
apps_key | ABP 模式下必填 | 应用会话密钥。 |
nwks_key | ABP 模式下必填 | 网络会话密钥。 |
rx1dr_offset | 必填（默认值根据频段自动填充） | 下行窗口 RX1 的 DR 偏移量，不同地区标准有差异。 |
rx2dr | 必填（默认值根据频段自动填充） | RX2 窗口的传输速率（Data Rate）。 |
rx_delay | 必填（默认值：1） | 上行数据后，第一个下行接收窗口的延迟时间（单位：秒）。 |
rx_delay_join | 必填（默认值：5） | Join 流程中的下行响应延迟时间（单位：秒）。 |
rx2_freq | 必填（默认值根据频段自动填充） | RX2 接收窗使用的固定频率，依地区标准而定。 |
📌提示：在添加新设备档案时，只需选定正确的
standard（频段）和lw_ver（协议版本），其余参数将自动填充为对应标准的默认值，简化配置流程。
1.1.2. 批量导入 LoRaWAN 设备
对于大规模部署场景，支持通过 Excel 表格批量导入 LoRaWAN 设备档案。
- 下载标准模板文件（参考示例格式：mt_sdev_pf_macs--1756347416255.xlsx）；
- 按照字段要求填写设备信息；
- 校验无误后上传至系统；
- 系统自动校验并导入设备档案。
1.2. 新增设备
1.2.1. 新增单个设备
在完成 LoRaWAN 设备档案配置后，可将其注册为平台管理设备。
| 字段 | 说明 |
|---|---|
| EUI | 设备的唯一编号，在 ThinkLink 系统内必须唯一。 |
| 名称 | 用户自定义的设备名称，便于识别和管理。 |
| 设备类型 | 可以为设备或者资产，资产为变量值重新组合后的虚拟体 |
| 配置模板 | 可选择已预设的配置模板，快速绑定物模型、RPC 等功能配置。 |
✅操作建议：使用配置模板可大幅提高设备上线效率，特别适用于同型号设备批量部署。
1.2.2. 批量增加设备
可以通过 Excel 表格进行设备信息的批量导入。操作方法如下：
- 可先勾选一个已有设备，点击“导出”按钮，下载该设备的档案信息模板；
- 在此基础上填写或修改其他设备的信息，必须填写
EUI字段（EUI 为设备的唯一标识）； - 若部分参数无需导入或修改，可直接删除对应列；
- 完成表格编辑后，执行批量导入操作：
- 若系统中已存在相同 EUI 的设备：系统将更新该设备的对应参数；
- 若系统中不存在该 EUI 的设备：系统将作为新设备进行添加。
⚠️ 请确保每个设备的 EUI 唯一且准确，以保证导入结果符合预期。
1.3. 设备详情
进入任一设备详情页面后，可进行以下高级配置与监控操作。
1.3.1. 新增物模型
- 点击「新增」按钮，可为设备挂载一个物模型。 +一个设备可挂载多个物模型，以解析不同类型的数据报文（如传感器数据、状态上报、事件通知等）。
- 物模型负责将原始二进制 payload 解析为结构化的应用层数据（如温度、湿度、开关状态等）。
1.3.2. 新增 RPC
- 支持为设备挂载多个远程过程调用（RPC）模型。
- 用于实现对设备的反向控制指令下发（如远程重启、参数修改、固件升级等）。
1.3.3. 服务端属性（Server Attributes）
- 属于业务层逻辑参数，独立于设备上报的实际数据。
- 示例：温湿度告警阈值、心跳检测周期、用户备注等。
- 可在物模型脚本或 RPC 中被调用，参与逻辑判断。
🔧 用户可通过界面手动增删服务端属性。
1.3.4. 共享属性（Shared Attributes）
- 存储于设备侧，但可在服务端和设备侧双向更新。
- 典型用途：设备工作模式、采样间隔、OTA 更新标记等。
- 可在物模型解析上行报文时提取并同步至平台。
1.3.5. 遥测数据（Telemetry Data）
- 实时保存设备最新一次上报的遥测信息及其时间戳。
- 包括温度、电压、位置、状态码等动态变化数据。
1.3.6. 设备关联
- 支持为主设备添加从设备，或为从设备指定主设备，构建设备拓扑关系。
- 关联类型支持：
- 从设备 → 主设备
- 主设备 ← 多个从设备
当关联设备的以下数据发生变化时，系统将自动触发通知至主设备：
| 变更类型 | 触发条件 |
|---|---|
| 遥测数据 | 从设备上报新的 telemetry |
| 共享属性 | 平台或设备修改 shared attributes |
| 服务端属性 | 业务系统修改 server attributes |
主设备可通过物模型中的脚本处理这些变更数据，实现聚合计算、联动触发等功能。
1.3.7. 资产类物模型示例：多设备温湿度平均值计算
以下是一个典型的资产级物模型应用案例：主设备代表“空调区域”，下属四个温湿度传感器作为从设备。每当任一从设备上报数据时，主设备自动计算当前区域的平均温湿度。
场景说明：
- 主设备关联了 4 个从设备；
- 各从设备定期上报自身温湿度（t, h）；
- 主设备物模型脚本实时聚合数据并更新 avgT（平均温度）、avgH（平均湿度）。
示例脚本如下：
javascript
let preTelemetry = device.telemetry_data[thingModelId];
let tempetrature;
let humidity;
if (!noticeAttrs.telemetry_data) {
return {
telemetry_data: null,
server_attrs: null,
shared_attrs: null,
}
}
// 遍历所有从设备模型ID，提取最新温湿度
msg.thing_model.forEach((tid) => {
if (msg.telemetry_data[tid].t != null) {
tempetrature = msg.telemetry_data[tid].t;
humidity = msg.telemetry_data[tid].h;
}
});
let avgT = device.telemetry_data[thingModelId]?.avgT || 0;
let avgH = device.telemetry_data[thingModelId]?.avgH || 0;
// 构造服务端属性，记录各从设备最后一次数据
let attrs_server = {
[msg.eui]: {
"tempetrature": tempetrature,
"humidity": humidity
}
};
// 初始值判断
if (avgT === 0) avgT = tempetrature;
if (avgH === 0) avgH = humidity;
// 计算平均值（此处仅为简单累加示例，实际建议使用加权或滑动平均）
avgT = (avgT + tempetrature) / 2;
avgH = (avgH + humidity) / 2;
// 返回更新后的遥测数据
let attrs_telemetry = {
"avgT": avgT,
"avgH": avgH
};
return {
telemetry_data: attrs_telemetry,
server_attrs: attrs_server,
shared_attrs: null,
};此模型广泛应用于楼宇环境监测、冷链仓储、智慧农业等需要“区域级数据聚合”的场景。