3. 硬件设备选型与通信协议
数字工地现场看板的数据源头来自部署在工地各区域的传感器与采集终端。本章将系统讲解常用工地传感器的选型要点、设备数据采集原理、MQTT 通信协议的核心机制,以及 JSON 数据格式的定义规范,为后续的数据接入与可视化看板开发奠定基础。
3.1 常用工地传感器选型
工地环境监测通常关注温湿度、颗粒物浓度、噪声和定位信息。下表列出四类核心传感器的典型参数与选型建议:
| 传感器类型 | 测量范围 | 精度 | 输出接口 | 典型型号 | 适用场景 |
|---|---|---|---|---|---|
| 温湿度 | -20~60°C / 0~100%RH | ±0.3°C / ±2%RH | I²C / 数字单总线 | SHT30 / DHT22 | 材料仓库、混凝土养护区 |
| PM2.5 | 0~1000 µg/m³ | ±10% @ 100µg/m³ | UART / PWM | PMS5003 / SDS011 | 土方作业区、道路扬尘监测 |
| 噪声 | 30~130 dB | ±1.5 dB | 模拟量 / I²S | ICS-43434 / MAX9814 | 打桩区、混凝土搅拌站 |
| GPS | 定位精度 2.5m CEP | 冷启动 < 35s | UART (NMEA 0183) | NEO-6M / L76K | 移动设备定位、车辆轨迹 |
选型避坑: 工地环境粉尘大、温湿度变化剧烈,传感器防护等级至少需 IP65。PM2.5 传感器需定期清理风扇进气口,否则数据漂移严重。GPS 天线应避开塔吊金属遮挡,优先选用陶瓷有源天线。
3.2 设备数据采集原理
数据采集链路通常分为三个层级:感知层(传感器原始信号)→ 边缘层(MCU 或 DTU 进行模数转换与初步处理)→ 传输层(通过通信协议上发至平台)。
以温湿度采集为例,典型流程如下:
- 传感器上电初始化:MCU 通过 I²C 或单总线发送配置指令,设置采样率与分辨率。
- 触发测量:MCU 发送测量命令,传感器进入转换状态(典型耗时 10~100ms)。
- 读取原始数据:MCU 读取传感器寄存器中的原始二进制值(如 16 位整数)。
- 工程值换算:根据传感器数据手册的公式将原始值转换为物理量。例如 SHT30 温度换算公式:
T = -45 + 175 × (raw_value / 65535)。 - 数据打包:将工程值、设备 ID、时间戳按 JSON 格式组装,准备发送。
采集周期建议: 温湿度每 30~60 秒采集一次;PM2.5 和噪声建议 10~15 秒;GPS 定位按需触发,移动设备每 5 秒上报一次,固定设备可延长至 60 秒。过高的采集频率会加速传感器老化并增加功耗。
3.3 MQTT 协议详解
MQTT(Message Queuing Telemetry Transport)是物联网领域最主流的轻量级发布/订阅协议,专为低带宽、高延迟、不可靠网络环境设计。其核心机制如下:
- 发布/订阅模型:设备(Publisher)将消息发送到 Broker,订阅者(Subscriber)从 Broker 接收感兴趣的主题消息,实现解耦。
- 主题(Topic):采用层级结构,例如
site/001/sensor/temperature,支持通配符+(单层)和#(多层)。 - 服务质量(QoS):三个等级——QoS 0(最多一次)、QoS 1(至少一次)、QoS 2(恰好一次)。工地场景推荐 QoS 1,兼顾可靠性与网络开销。
- 遗嘱消息(Will Message):设备异常离线时,Broker 自动发布预设遗嘱,便于平台感知设备掉线。
- 保留消息(Retained Message):新订阅者上线后立即收到 Broker 保留的最新消息,适合获取设备最新状态。
以下是一个 ESP32 设备通过 MQTT 上报温湿度数据的 Python 示例(使用 MicroPython 的 umqtt 库):
from umqtt.simple import MQTTClient
import network
import time
# 连接 Wi-Fi
wlan = network.WLAN(network.STA_IF)
wlan.active(True)
wlan.connect('工地WiFi', 'password')
while not wlan.isconnected():
time.sleep(0.5)
# MQTT 连接配置
BROKER = '192.168.1.100'
CLIENT_ID = 'sensor_temp_001'
TOPIC = 'site/001/sensor/temperature'
client = MQTTClient(CLIENT_ID, BROKER)
client.connect()
# 模拟采集并发布
while True:
temp = read_temperature() # 假设已实现传感器读取函数
payload = '{"device":"temp_001","value":%.1f,"unit":"°C"}' % temp
client.publish(TOPIC, payload, qos=1)
time.sleep(30)
安全提醒: 工地 MQTT Broker 必须启用用户名/密码认证,并建议使用 TLS/SSL 加密传输。避免在代码中硬编码凭证,推荐使用安全元件或环境变量管理密钥。
3.4 JSON 数据格式定义
JSON(JavaScript Object Notation)是设备与平台之间最通用的数据交换格式。工地传感器数据需遵循统一的 JSON Schema,确保平台解析一致。以下为推荐的通用数据模型:
{
"deviceId": "sensor_pm_003",
"type": "PM2.5",
"timestamp": "2025-03-15T14:30:00+08:00",
"value": 85.2,
"unit": "µg/m³",
"quality": "normal",
"location": {
"lat": 31.2304,
"lng": 121.4737
},
"metadata": {
"firmware": "v2.1.0",
"battery": 78
}
}
字段定义说明:
| 字段 | 类型 | 必填 | 说明 |
|---|---|---|---|
| deviceId | string | 是 | 设备唯一标识,建议使用 MAC 地址或 UUID |
| type | string | 是 | 传感器类型:temperature / humidity / PM2.5 / noise / GPS |
| timestamp | string (ISO 8601) | 是 | 采集时间,含时区偏移 |
| value | number | 是 | 测量数值,GPS 类型时可为 null |
| unit | string | 是 | 物理单位:°C / %RH / µg/m³ / dB |
| quality | string | 否 | 数据质量标记:normal / warning / error |
| location | object | 否 | GPS 坐标,固定设备可省略 |
| metadata | object | 否 | 设备状态扩展信息 |
数据压缩建议: 对于大批量上报场景,可将字段名缩写为单字母(如
d 代替 deviceId),减少传输字节。平台端再做字段映射还原。例如:{"d":"s1","t":"temp","v":25.3,"u":"°C"}。
3.5 整体架构与数据流
下图展示了从工地传感器到看板平台的完整数据链路,涵盖设备选型、采集、传输与格式转换:
3.6 通信协议选型对比
除 MQTT 外,工地场景还可能涉及其他协议。下表对比了三种常见协议的适用场景:
| 协议 | 传输模型 | 带宽消耗 | 实时性 | 适用场景 |
|---|---|---|---|---|
| MQTT | 发布/订阅 | 低(最小 2 字节头部) | 高(秒级) | 传感器数据上报、远程控制指令 |
| CoAP | 请求/响应(类 HTTP) | 极低(基于 UDP) | 中(需重传机制) | 资源受限设备、低功耗场景 |
| HTTP/HTTPS | 请求/响应 | 高(头部开销大) | 中(轮询延迟) | 配置下发、固件升级、非实时数据查询 |
推荐组合: 实时传感器数据采用 MQTT + QoS 1;设备配置下发与固件升级使用 HTTPS;低功耗电池供电设备可考虑 CoAP 以延长续航。三种协议可在同一网关内共存,通过协议转换模块统一接入平台。