设备管理基础：创建设备、设备凭证与设备配置

好，咱们今天聊聊设备管理。说白了，ThingsBoard 里的一切数据流转，都离不开「设备」这个基本单元。你想想看，没有设备，传感器数据往哪儿送？指令又发给谁？所以，把设备管理搞明白，是后续所有操作的地基。

我个人习惯，在开始接入任何真实硬件之前，都会先在平台里把设备「虚拟」地创建好。这一步看似简单，但里面的门道不少。尤其是设备凭证，我见过太多新手在这里栽跟头了。

一、创建设备：从零开始的第一步

在 ThingsBoard 里创建设备，其实就两步。但这两步里，藏着一些容易被忽略的细节。

首先，你得登录到你的 ThingsBoard 实例。不管是社区版还是专业版，入口都在左侧菜单栏的「实体」->「设备」里。点进去，你会看到一个设备列表。右上角那个大大的「+」号，就是我们的起点。

点击「+」号，选择「添加新设备」。这时候会弹出一个对话框，你需要填两个核心信息：

  • 设备名称：这个你自己定，但建议用有意义的命名规则。比如 temperature_sensor_001，而不是 device_1。我在项目里吃过亏，设备一多，名字乱成一锅粥，查问题的时候想死的心都有。
  • 设备类型：这个也很关键。你可以把它理解成设备的「标签」。比如所有温度传感器都归为 temperature_sensor，所有电表都归为 energy_meter。后续做规则链或者仪表盘过滤时，这个字段能帮你省大事。

填完这两项，点「添加」就完成了。嗯，就是这么简单。但别急，真正的重头戏在设备凭证上。

二、设备凭证：设备与平台的「握手协议」

设备创建好了，它怎么证明自己是自己？这就是设备凭证干的事。ThingsBoard 支持三种主流凭证方式，我一个个说。

1. Access Token（访问令牌）

这是最简单、最直接的方式。说白了，就是一个字符串。设备每次上报数据时，把这个字符串带在请求里，平台一看，嗯，对上了，放行。

怎么获取？创建设备后，点进设备详情页，找到「凭证」选项卡。默认情况下，系统会自动生成一个 Access Token。你可以直接复制使用，也可以点击右侧的铅笔图标修改它。

我个人建议：在开发测试阶段，用 Access Token 最省事。但生产环境里，我强烈建议你换用更安全的方式。为什么？因为 Token 是明文传输的，一旦被截获，别人就能冒充你的设备。

代码示例，用 MQTT 客户端通过 Access Token 上报数据：

mosquitto_pub -d -h your.thingsboard.server -p 1883 \
-t "v1/devices/me/telemetry" \
-u "YOUR_ACCESS_TOKEN" \
-m '{"temperature": 25.5, "humidity": 60}'

看到没？-u 参数后面跟的就是你的 Access Token。简单粗暴。

2. X.509 证书

这个就高级多了。X.509 证书是公钥基础设施（PKI）的一部分。每个设备都有一个独一无二的证书，平台也有自己的证书。通信时，双方互相验证，安全性拉满。

我在一个工业项目里用过这个方案。客户要求数据必须加密传输，而且设备身份不能被伪造。Access Token 肯定不行，MQTT Basic 也差点意思。最后上了 X.509 证书，虽然配置起来麻烦点，但心里踏实。

配置步骤大致如下：

  1. 在 ThingsBoard 里，进入「安全」->「证书」菜单，上传你的 CA 证书（根证书）。
  2. 为每个设备生成一个客户端证书，并用 CA 证书签名。
  3. 在设备详情页的「凭证」选项卡里，选择「X.509 证书」，然后上传客户端证书。
  4. 设备连接时，MQTT 客户端需要配置证书路径和私钥路径。

注意：证书是有有效期的！我曾经因为忘记更新证书，导致一批设备在凌晨三点集体离线。那叫一个酸爽。所以，建议你提前规划好证书的轮换策略。

连接示例（使用 OpenSSL 生成的自签名证书）：

mosquitto_pub -d -h your.thingsboard.server -p 8883 \
--cafile ca-cert.pem \
--cert client-cert.pem \
--key client-key.pem \
-t "v1/devices/me/telemetry" \
-m '{"temperature": 25.5}'

3. MQTT Basic（用户名密码）

这个大家应该很熟悉了。就是传统的用户名加密码认证。在 ThingsBoard 里，用户名就是设备的 Access Token，密码可以自定义，也可以留空。

说实话，这个方式我用得不多。因为它本质上和 Access Token 一样，都是明文传输。唯一的区别是，它符合 MQTT 协议的标准认证流程，有些 MQTT 客户端库只支持这种认证方式。

配置方法：在设备凭证里选择「MQTT Basic」，然后设置用户名和密码。用户名必须填 Access Token，密码可以随便填，但建议也设一个复杂的。

小技巧：如果你的设备用的是 ESP32 或者 Arduino，它们自带的 MQTT 库通常只支持用户名密码认证。这时候用 MQTT Basic 就对了。

三、设备配置：给设备加点「料」

设备创建好了，凭证也配好了，但设备本身还是「空」的。我们需要给它加点配置信息。比如，这个设备安装在哪个位置？它的采集频率是多少？它的固件版本是什么？

ThingsBoard 提供了两种方式来管理设备配置：

  • 服务器端属性：这些属性存储在平台上，设备可以通过 API 读取。适合存放不经常变化的配置，比如设备位置、安装日期等。
  • 客户端属性：这些属性由设备主动上报。适合存放设备自身的状态信息，比如当前固件版本、运行时长等。

怎么添加？在设备详情页，找到「属性」选项卡。你可以手动添加键值对，也可以通过规则链自动处理。

举个例子，我想给设备添加一个位置信息：

// 服务器端属性
{
  "location": "工厂A区-3号生产线",
  "installDate": "2024-01-15",
  "maintenanceInterval": 30
}

设备端怎么读取？通过 MQTT 订阅主题 v1/devices/me/attributes，或者发送 GET 请求到 /api/v1/{ACCESS_TOKEN}/attributes。

我的经验：设备配置这块，最容易犯的错误是把所有东西都塞到属性里。记住，属性是给「人」看的，不是给「机器」跑的。真正控制设备行为的参数，应该放在设备配置里，或者通过规则链下发。

四、避坑指南：我踩过的那些坑

最后，分享几个我实际项目中遇到的坑，希望能帮你少走弯路。

  • Access Token 泄露：有一次我把 Token 写死在代码里，结果代码被上传到了公开的 GitHub 仓库。不到一小时，就有「热心网友」帮我测试设备了。从那以后，我所有 Token 都通过环境变量或者配置文件注入。
  • 证书链不完整：配置 X.509 证书时，如果服务器证书没有包含完整的证书链，设备会一直报错。我当时排查了整整一天，最后发现是少了中间证书。
  • 设备类型命名混乱：团队里有人用中文命名设备类型，有人用英文，还有人用拼音。结果做数据统计时，一个类型出现了三个不同的名字。后来我们统一了命名规范，才解决了这个问题。

好了，设备管理的基础就这些。记住，设备是 ThingsBoard 的基石，把这一步走稳了，后面的数据采集、规则链、仪表盘才能玩得转。下一章，咱们聊聊怎么让设备真正「开口说话」——数据上云。

← 上一章 📖 返回目录 下一章 →