3、通信协议基础：MQTT协议原理、JSON数据格式、Wi-Fi与以太网选型
各位同学，咱们今天聊点实在的。做物联网安防，说白了就是让传感器把话说清楚，并且能及时传到该去的地方。这里头有三个东西绕不开：MQTT协议、JSON数据格式，还有通信方式的选择。我一个个讲，你跟着走就行。
3.1 MQTT协议：物联网的“对讲机”
MQTT，全称是Message Queuing Telemetry Transport。名字挺长，但原理很简单——它就是个轻量级的发布/订阅模型。我习惯把它比作一个微信群：传感器是群成员，服务器是群主。传感器往群里发消息，谁需要谁就去取。
为什么物联网安防偏爱MQTT？
- 极轻量：报文头最小只有2字节。我在一个项目里用4G模块传数据，流量费省了一大截。
- 支持QoS：三种服务质量等级，从“发完不管”到“确保送达”。安防告警我一般用QoS 1，丢了可不行。
- 持久连接：长连接+心跳保活，传感器不用反复握手。这对电池供电的设备太重要了。
- 遗嘱消息：设备突然掉线，服务器能收到“最后遗言”。嗯，这个功能在安防场景里很实用。
核心概念速览
- Broker：消息代理，就是服务器。我常用Mosquitto或EMQX。
- Topic：主题，消息的“标签”。比如
home/livingroom/door/sensor。 - Publish：发布者，传感器往Topic发数据。
- Subscribe：订阅者，告警中心或手机App订阅Topic。
一个简单的MQTT通信示例
假设你有一个门磁传感器，检测到门被打开。它要发一条消息给服务器。伪代码大概是这样的：
// 传感器端（发布者）
client.publish("home/livingroom/door", "{\"status\":\"open\",\"timestamp\":1700000000}", 1);
// 告警中心（订阅者）
client.subscribe("home/+/door", function(topic, payload) {
// 解析JSON，判断是否需要告警
console.log("收到门状态：", payload);
});你看，代码就这么几行。但要注意，Topic里的 + 是通配符，表示匹配任意一级。我刚开始用的时候，经常把 # 和 + 搞混，后来吃了亏才记住——# 匹配多级，+ 只匹配一级。
我的经验：Topic命名最好用层级结构，比如 设备类型/位置/传感器/动作。这样后期扩展方便，也容易做权限控制。
3.2 JSON数据格式：传感器的“普通话”
MQTT只管把消息传过去，但消息里写什么？我建议用JSON。为什么？因为它人类可读，解析简单，而且几乎所有语言都支持。
一个标准的安防传感器JSON报文
{
"device_id": "door_sensor_001",
"type": "door_magnetic",
"status": "open",
"timestamp": 1700000000,
"battery": 85,
"signal_strength": -65
}字段说明：
| 字段 | 类型 | 说明 |
|---|---|---|
| device_id | string | 设备唯一标识，我习惯用MAC地址后6位+随机数 |
| type | string | 传感器类型，方便服务器做不同处理 |
| status | string | 当前状态，open/close, motion/no_motion等 |
| timestamp | int | Unix时间戳，单位秒。注意时区问题 |
| battery | int | 电量百分比，0-100。低于20%就该告警了 |
| signal_strength | int | 信号强度，dBm。这个值我一般用来判断通信质量 |
避坑指南：我曾经在项目里用浮点数表示电量，结果解析时精度丢失，导致告警逻辑出错。后来统一改成整数百分比，再也没出过问题。记住，JSON里能用整数就别用浮点数。
JSON嵌套与数组
有时候一个传感器会同时上报多个数据。比如一个温湿度传感器：
{
"device_id": "temp_hum_002",
"readings": [
{"type": "temperature", "value": 25.3, "unit": "celsius"},
{"type": "humidity", "value": 60, "unit": "%"}
],
"timestamp": 1700000000
}这种结构很灵活。你想想看，如果以后要加个气压传感器，直接在 readings 数组里加一项就行，不用改协议。这就是JSON的好处。
3.3 Wi-Fi与以太网选型：有线还是无线？
这个问题，我几乎在每个项目里都会被问到。我的回答是：看场景，没有绝对的好坏。
Wi-Fi方案
- 优点：部署灵活，不用布线，适合改造项目。ESP8266/ESP32芯片便宜，生态成熟。
- 缺点：功耗高，穿墙能力差，受干扰大。我有个项目在工厂里用Wi-Fi，结果机器一开，信号直接掉到-90dBm。
- 适用场景：家庭安防、办公室、小型商铺。这些地方Wi-Fi覆盖好，设备数量少。
以太网方案
- 优点：稳定，延迟低，不受无线干扰。PoE供电还能省一根电源线。
- 缺点：需要布线，施工成本高。后期改位置很麻烦。
- 适用场景：机房、银行、医院、工厂。这些地方对稳定性要求极高，不能容忍掉线。
我的选型建议
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 家庭门磁/窗磁 | Wi-Fi | 部署方便，成本低 |
| 工厂设备监控 | 以太网 | 抗干扰，稳定可靠 |
| 商场烟感 | Wi-Fi + 有线备份 | 主用Wi-Fi，有线做心跳保底 |
| 银行金库门禁 | 以太网 | 安全第一，不能有无线风险 |
混合方案
说实话，现在很多项目都是混合的。比如一个智能楼宇，核心设备用有线，边缘传感器用Wi-Fi。中间通过一个网关做协议转换。我做过一个项目，网关用树莓派，一边接以太网连云端，一边用Wi-Fi连十几个传感器。效果还不错。
一个小技巧：如果你用Wi-Fi，记得把传感器放在离路由器近的地方，或者用Mesh组网。我曾经在别墅项目里，门磁离路由器太远，经常掉线。后来加了个中继器，问题就解决了。
3.4 三者如何配合？
好了，现在我们把三个东西串起来。一个典型的安防传感器工作流程是这样的：
- 传感器采集数据：比如门磁检测到门开了。
- 封装成JSON：把状态、时间、电量等信息写成JSON字符串。
- 通过MQTT发布：传感器作为客户端，把JSON发布到指定Topic。
- Broker转发：MQTT Broker收到消息，转发给所有订阅者。
- 告警中心处理：订阅者（比如手机App）解析JSON，判断是否触发告警。
你想想看，如果不用MQTT，传感器得自己建立TCP连接，自己处理重连，自己管理会话。那代码量至少翻一倍。而JSON让数据格式统一，不管后端用什么语言解析，都不会出错。至于Wi-Fi还是以太网，就看你的设备是固定安装还是灵活部署了。
最后提醒一句：无论选哪种方案，一定要做断线重连和心跳检测。我见过太多项目，设备上线时好好的，过几天就失联了。原因就是没做重连机制。MQTT有内置的Last Will和心跳，一定要用起来。
好了，这一章就到这里。下一章我们聊聊传感器数据采集与边缘计算，到时候我会分享一些我在实际项目中踩过的坑。