第4章数据采集与通信协议

第4章数据采集与通信协议：MQTT协议详解

好，咱们进入整个平台最核心的一环——数据采集。说白了，楼宇里那些传感器、控制器、执行器，它们怎么把数据传上来？靠什么协议？我这些年做过的项目里，十有八九都离不开MQTT。为什么？因为它轻量、灵活、还省带宽。今天我就把MQTT这块掰开揉碎了讲清楚。

4.1 MQTT协议到底是什么？

MQTT，全称Message Queuing Telemetry Transport，消息队列遥测传输。名字挺长，但核心就一句话：它是一种发布/订阅模式的轻量级通信协议。

你想想看，传统楼宇里，BACnet、Modbus这些协议，大多是点对点的。一个控制器要跟另一个控制器说话，得先建立连接，再发指令。MQTT不一样，它有个中间人——Broker（代理服务器）。所有设备都只跟Broker通信，设备之间不直接对话。

举个例子：温度传感器只管往Broker发数据，它不需要知道谁在收。空调控制器只管从Broker订阅温度数据，它不需要知道谁在发。这种解耦，在大型楼宇里太重要了。我记得有一次做一栋20万平米的商业综合体，光传感器就3000多个，如果用传统点对点方式，网络拓扑图能画到崩溃。

MQTT的核心角色：

Publisher（发布者）：发送消息的设备，比如温度传感器、电表
Subscriber（订阅者）：接收消息的设备，比如空调控制器、照明系统
Broker（代理服务器）：消息中转站，负责接收、过滤、转发
Topic（主题）：消息的标签，类似快递单上的地址

4.2 数据上报格式设计——别小看这个

很多新手上来就写代码，数据格式随便定。结果项目一上线，各种解析问题。我建议，数据上报格式一定要提前设计好，而且要统一。

我个人习惯用JSON格式。为什么？因为可读性强，扩展性好，而且几乎所有语言都支持。你想想看，一个温度传感器上报的数据，用JSON写出来是这样的：

{
  "deviceId": "temp_sensor_01",
  "timestamp": "2025-03-15T14:30:00Z",
  "type": "temperature",
  "value": 25.6,
  "unit": "celsius",
  "location": "floor_3_room_301"
}

这里有几个关键字段：

deviceId：设备唯一标识，别用中文，用英文+数字组合
timestamp：时间戳，统一用ISO 8601格式，别搞什么"2025/3/15 14:30"这种
type：数据类型，比如temperature、humidity、power
value：数值，统一用浮点数
unit：单位，这个容易被忽略，但很重要
location：位置信息，方便后续做空间分析

我的经验： 数据上报频率不要太高。温度传感器每30秒上报一次就够了，电表可以每5分钟。频率太高，Broker扛不住，网络也浪费。我曾经见过一个项目，把温度传感器设成每秒上报一次，结果Broker直接挂了。

4.3 JSON Schema定义——给数据上个"紧箍咒"

光有JSON格式还不够。你想想看，如果每个设备上报的JSON结构都不一样，解析端得多痛苦？所以我们需要JSON Schema，说白了就是给数据定义一个模板，所有设备必须按这个模板来。

下面是我常用的一个JSON Schema示例：

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "Building Sensor Data",
  "type": "object",
  "required": ["deviceId", "timestamp", "type", "value"],
  "properties": {
    "deviceId": {
      "type": "string",
      "pattern": "^[a-zA-Z0-9_]+$",
      "description": "设备唯一标识"
    },
    "timestamp": {
      "type": "string",
      "format": "date-time",
      "description": "ISO 8601格式时间戳"
    },
    "type": {
      "type": "string",
      "enum": ["temperature", "humidity", "power", "pressure", "flow"],
      "description": "数据类型"
    },
    "value": {
      "type": "number",
      "description": "测量值"
    },
    "unit": {
      "type": "string",
      "description": "单位"
    },
    "location": {
      "type": "string",
      "description": "位置信息"
    }
  }
}

这个Schema做了几件事：

规定了哪些字段是必填的（required）
限制了字段类型（type）
对type字段做了枚举限制，只能填那几种
deviceId只能用字母数字和下划线

注意： 别把Schema搞得太死板。楼宇里设备种类多，未来可能新增传感器类型。我建议保留一个"extras"字段，放一些自定义数据，这样扩展性更好。

4.4 QoS等级选择——别盲目用最高级

MQTT有三个QoS（服务质量）等级。很多新手觉得QoS越高越好，其实不是。我踩过这个坑，跟大家说说。

QoS等级	含义	适用场景	网络开销
QoS 0	最多发一次，不确认	温度、湿度等非关键数据	最低
QoS 1	至少发一次，有确认	电表读数、设备状态	中等
QoS 2	恰好发一次，严格确认	报警信号、控制指令	最高

我个人建议：

温度、湿度、光照这类数据，用QoS 0就够了。丢一两条没关系，下一轮数据马上来。
电表读数、设备运行状态，用QoS 1。不能丢，但偶尔重复也能接受。
火灾报警、设备故障，用QoS 2。这种数据必须准确到达，不能丢也不能重复。

我曾经在一个项目中，把所有数据都设成QoS 2。结果呢？Broker负载飙升，网络延迟从50ms涨到500ms。后来改成温度用QoS 0，电表用QoS 1，报警用QoS 2，系统一下子就稳了。

4.5 避坑指南——我踩过的那些坑

我曾经... 在项目里遇到过一个诡异问题：温度数据偶尔会跳变，从25度突然跳到100度。排查了半天，发现是传感器上报时，JSON里value字段写成了字符串"25.6"，而解析端期望的是数字。JSON Schema里没做类型校验，结果字符串被隐式转换，出了bug。从那以后，我每个项目都强制用JSON Schema做校验。

另一个坑： Topic命名混乱。有人用"temp/floor1/room101"，有人用"floor1/room101/temp"。解析端要写两套逻辑。我建议统一用"building/floor/room/type"这种层级结构，比如"bldg_a/floor_3/room_301/temperature"。

4.6 实战建议——从零搭建MQTT数据流

如果你现在要开始做，我建议按这个步骤来：

选Broker：小项目用Mosquitto，大项目用EMQX或VerneMQ
定Topic结构：统一层级，比如"site/building/floor/room/device_type"
设计JSON Schema：先定义好，再让设备端按这个格式上报
选QoS等级：按数据类型分，别一刀切
加心跳机制：设备每隔30秒发一个心跳包，Broker知道设备在线
做数据校验：Broker端或后端做JSON Schema校验，不合规的数据直接丢弃

嗯，MQTT这块就讲这么多。下一章咱们聊聊数据存储——数据到了Broker之后，怎么存到数据库里？用什么数据库？怎么设计表结构？到时候见。

📚 课程目录