本文为 4G 物联网模块实战系列文章第 2 篇，记录 FS800DTU 从 TCP 透传切换到 MQTT 模式的折腾过程。
版权声明：本文为原创技术分享文章，转载请注明出处。

目录

• 前言
• 1 MQTT 是什么
• 2 准备工作
  • 2.1 硬件连接
• 3 配置步骤：FS800DTU 切换到 MQTT 模式
  • 3.1 第一步：打开配置工具，读取模块信息
  • 3.2 第二步：工作模式选择 MQTT Client
  • 3.3 第三步：填写 MQTT Broker 参数
  • 3.4 第四步：设置并保存
• 4 验证：真的连上了吗？
  • 4.1 方法一：看配置工具的状态
  • 4.2 方法二：用 MQTTX 验证收发
• 5 跟 TCP 透传比起来，体验怎么样？
• 6 遇到的坑
  • 6.1 坑 1：Client ID 重复导致连接被踢
  • 6.2 坑 2：Topic 大小写敏感
• 7 总结

前言

承接第一篇，TCP 透传已经跑通了，电脑发什么服务器收什么。但有一个问题一直在我脑子里转：TCP 透传虽然能用，但总感觉少了点什么——比如你要自己维护连接状态、自己处理断线重连、多个设备同时在线时服务器端还得自己区分数据来自谁。

MQTT 这个协议之前听说过很多次，说是“物联网事实标准”，但一直没真正动手试过。这次既然 FS800DTU 支持 MQTT 模式，就想着干脆折腾一下，看看从 TCP 透传切换到 MQTT，到底有什么区别，是不是真的像传说中那么好用。

我的目的其实很简单：看看 MQTT 到底值不值得替代 TCP 透传，答案放到文章最后。

1 MQTT 是什么

不堆概念，只说三点：

1. 发布/订阅模式：不是设备直连设备，而是所有设备都先连接到 MQTT Broker（消息服务器）。可以把 Broker 理解成一个"消息中转站"，设备把数据发布（Publish）到某个 Topic 后，Broker 会把消息转发给订阅（Subscribe）了这个 Topic 的设备。
2. 省流量：MQTT 是一种运行在 TCP 之上的应用层协议，因此并不是替代 TCP，而是在 TCP 连接基础上提供发布/订阅、QoS、主题管理等能力。对于物联网的小数据量通信来说，整体使用体验更加友好。
3. 三种 QoS 等级：0（最多发一次，丢了不管）、1（至少发一次，保证到达）、2（恰好一次，最可靠）。

2 准备工作

硬件：

• FS800DTU × 1
• 物联网卡 × 1
• 4G 天线 × 1
• USB-TTL × 1

软件：

• 模块对应的配置工具
• MQTTX 或其他 MQTT 客户端软件（用来模拟云端，验证收发）

2.1 硬件连接

3 配置步骤：FS800DTU 切换到 MQTT 模式

3.1 第一步：打开配置工具，读取模块信息

跟上一篇一样，打开 配置工具，选对 COM 口，点击“读取基本信息”。确认能读到模块型号和固件版本，说明连接正常。

3.2 第二步：工作模式选择 MQTT

在配置工具的工作模式下拉菜单里，从“TCP”切换到 “MQTT ”。这一步是核心，选错了后面的参数都不会出现。

3.3 第三步：填写 MQTT Broker 参数

我这次测试使用的是 EMQX 提供的公共 MQTT Broker，无需注册账号，也不需要用户名和密码，适合用来做功能验证。

配置如下：

• 服务器IP： broker.emqx.io
• 端口号： 1883
• Client ID： FS800DTU
• 发布主题： 123A
• 订阅主题： 321B
• 用户名： 留空
• 密码： 留空

说明：

• Client ID 设备在 Broker 上的唯一身份标识，同一个 Broker 在同一时刻不能有两个客户端使用相同的 Client ID，否则后连接的客户端会将前一个客户端踢下线。
• 发布主题 模块发送数据时使用的话题。
• 订阅主题 模块接收数据时订阅的话题。

配置完成后如下图所示：

3.4 第四步：设置并保存

点击“设置所有参数”，模块会保存配置并自动尝试连接服务器。

4 验证：真的连上了吗？

4.1 方法一：看配置工具的状态

配置工具上会显示连接状态。如果显示“已连接”，说明 FS800DTU 已经成功连上了 MQTT Broker。

4.2 方法二：用 MQTTX 验证收发

1. 电脑上打开 MQTTX，连上同一个 Broker（broker.emqx.io）。
2. 测试发布：在 MQTTX 中向模块订阅的话题 321B 发布一条消息。因为模块订阅了 321B，它的串口应当能原样收到。
3. 测试订阅：通过串口往模块发布的话题 123A 发一条消息。在 MQTTX 中订阅 123A，应当能收到这条消息。
   
   如图所示双向都能通，说明 MQTT 模式已经跑通了。

5 跟 TCP 透传比起来，体验怎么样？

完成配置和收发测试之后，再结合这次实际使用体验，与 TCP 透传模式做一个简单对比。

配置复杂度
TCP 透传就填 IP 和端口，两行搞定。MQTT 多出来 Client ID、订阅 Topic、发布 Topic 这几个参数，第一次配置的时候我愣了一会儿才填完。尤其是一开始没搞清楚 Client ID 和 Topic 的作用，后来真正收发一次数据以后就理解了。不过熟悉之后也就那样，多填几个空的事。

连接稳定性
TCP 透传模式下，心跳包得自己操心——配长了怕被基站踢掉，配短了又费流量。MQTT 模式就不用管这个了，Broker 那边会维持连接，模块异常断开之后也能自己重连回来。省心不少。

多设备场景
TCP 透传如果多个设备同时在线，服务器端收到数据之后还要自己判断“这条数据是从哪个设备发来的”。MQTT 模式每个设备有独立的 Client ID，天然就分清楚了。如果你只折腾一个设备，这个优势感受不到；但设备一多，差异就出来了。

流量消耗
TCP 每次发包都有固定的头部开销，MQTT 的头部更精简，流量费能省一点。不过对于小数据量的场景，这个差距其实不明显，更多是心理上的安慰。

调试难度
TCP 透传调试很简单，电脑上开个 TCP服务器 就能收数据。MQTT 多了一个 Broker 的环节，需要额外装个 MQTTX 或者类似工具才能验证收发。多了一个工具，就多了一道学习成本。

---

几点感受：

1. 配置确实多了几步，但不复杂，填几个参数的事。
2. 不用自己操心心跳了——TCP 透传时还要想着配心跳包防止被基站踢掉，MQTT 模式下 Broker 会帮你维持连接，省心不少。
3. 数据到了云端之后，分发更灵活——TCP 透传是点对点的，MQTT 是一对多的，一个设备发数据，多个订阅者都能收到。如果只是单个设备连单个服务器，这个优势体现不出来；但如果未来有多个设备或者多个接收端，MQTT 的优势就出来了。

6 遇到的坑

6.1 坑 1：Client ID 重复导致连接被踢

第一次配置时，我随手填了个 freestrong，结果连上之后几秒钟就断了。查了半天才发现——MQTTX 上同时有很多人在测试，Client ID 重复会导致互相踢下线。改成一个不容易重复的 ID（比如 FS800DTU_<随机数>）之后就稳定了。

6.2 坑 2：Topic 大小写敏感

123A 和 123a 是两个完全不同的 Topic。我一开始没注意大小写，模块发数据到 123A ，但 MQTTX 订阅的却是 123a ，结果怎么都收不到。

7 总结

这次折腾下来，FS800DTU 的 MQTT 模式已经成功跑通，包括 参数配置、Topic 设置、MQTTX 收发验证 等整个流程，也终于搞清楚了 MQTT 在实际通信中的工作方式。

相比 TCP 透传，MQTT 并不是替代方案，而是更适合物联网场景的一种通信方式。如果只是设备与服务器之间进行简单的数据传输，TCP 透传依然足够直接；而当设备数量增加，或者需要接入云平台、多终端订阅数据时，MQTT 的优势就会逐渐体现出来。

下一篇准备继续折腾 OneNET 平台接入，看看 FS800DTU 如何接入官方支持的物联网平台，实现设备数据上云。