上个月我把园区一个办公楼的室内环境监测项目收了尾核心设备就是标题里这组“以太网温湿度气体多参量传感器”。说得直白点它是一个能同时采集温度、湿度、二氧化碳、TVOC并且直接走网线上报数据的终端节点如果把这栋楼比作一个人楼宇自控平台是大脑网线是神经这些传感器就是分布在各处的神经末梢。这套系统上线之后物业不再靠人工拿手持表去一层层测运维人员打开后台就能看到每一个房间的实时环境曲线。写这篇东西不是要讲一个多么前沿的概念而是把我从选型、画板、调协议、现场装点位上摸出来的一套完整做法整理出来给正在做楼宇环控、实验室监控或者机房环境监测的朋友一个可直接抄的参考。1. 项目缘起一栋楼最不缺的是数据最缺的是靠谱的数据1.1 真实痛点空调开了 24 小时投诉却从没停过这个项目来自一个十二层的园区办公楼痛点非常典型不同朝向的办公室温差能到 4 到 5 摄氏度朝阳面夏天闷热背阴面冬天阴冷会议室下午二氧化碳浓度经常破 1500ppm参会的人昏昏欲睡个别房间偶尔有装修残留的异味但物业查不到源头。原有的楼宇自控系统只采集了新风机组和空调箱的供回水温度至于每个房间到底什么环境完全靠人工巡检。业主的诉求其实很朴素不能只在机房看设备温度必须知道人所在的空间是什么状态。这正是“环境感知神经”要解决的问题。这类需求听起来简单真正落地却卡在设备形态上。如果每个房间装一个温度计、一个湿度计、再单独装一个二氧化碳检测仪线缆、安装、维护三座大山立刻压过来如果只装单一的温湿度传感器业主又抱怨闻不到“味道”。所以“多参量”这个方向几乎是必然选择。一个设备同时测温湿度、二氧化碳和 TVOC用一根网线既通数据又供电省掉了传感器箱、串口服务器、小电源适配器和一堆乱七八糟的线缆。节点数量一旦超过五十个这种省法就是决定项目利润和后期维护量的关键。1.2 方案选型为什么我最终选了以太网而不是 RS485 或无线同行看到我的方案第一反应都是问这种传感器用 RS485 不就行了干嘛非要碰以太网我确实也想过 RS485。从成本看RS485 芯片便宜布线距离长带 Modbus 协议也很成熟。但它有两个硬伤第一楼内跨楼层走线必须总线串联一旦某一段短路后面整串设备全部离线排障能把人逼疯第二RS485 本质上需要一个串口服务器或者采集器去转成 IP 协议增加了一层故障点后期替换设备还要去改地址、改波特率。对于动辄几十上百个点的建筑空间RS485 的“一根总线拖到底”反而成了维护噩梦。无线方案我也测过 LoRa 和 Zigbee安装在灵活性上确实占优但在这类钢筋混凝土结构的楼里无线信号穿墙衰减非常明显金属吊顶、电梯井、强弱电间都会让数据一跳再跳。更关键的是楼宇环境监测的数据最终要交给上层平台做分析和告警主流的楼宇自控系统、能耗平台、数字孪生平台对 IP 网络的接入远比串口友好。以太网方案相当于让每个传感器直接获得一个 IP 地址平台侧用 Modbus TCP 轮询上层用 MQTT 订阅推送中间不需要任何协议转换网关。我把几种方案的成本、可靠性和维护难度拉了个表对比项RS485 总线LoRa/Zigbee 无线以太网本项目采用传输距离1200m 内但受总线拓扑限制空旷距离可观楼内衰减大100m 以内网线直连楼层内可走交换机堆叠部署复杂度需串联布线节点越多风险越大无需布线但网关和电池/供电麻烦星型拓扑单点故障不影响全局响应速度半双工轮询节点多时延迟高上行延迟不稳定全双工 TCP毫秒级响应与平台对接必须加串口服务器需要专用网关直接 TCP/IP天然友好供电方式需额外布供电线或带 RS485 的电源线电池或本地电源PoE 或网线旁路供电维护难度总线故障排查困难电池更换、网关故障常见单点排查网口状态透明这个表的结论很明确以太网方案在建筑侧的综合维护成本其实是最低的。尤其是 PoE 供电的引入让传感器真正做到“一根网线全干完”施工队只需要敷设标准网线不用再考虑现场有没有 220V 插座也不用担心强电干扰传感器信号。后面我会重点讲 PoE 供电的板级设计和现场预算这是很多人容易翻车的地方。2. 硬件方案传感器怎么选、主控怎么搭、PCB 怎么画2.1 温湿度与气体传感器选型先搞懂测量原理再下单多参量传感器的硬件核心不是主控而是传感器探头选型。温湿度这块早期很多项目喜欢用 DHT11、DHT22便宜是便宜但精度、一致性和长期稳定性都一般。DHT22 标称精度 ±0.5°C实际在批量装配中经常差到 1°C 以上而且潮湿环境下容易失效。我这次选的是 SHT30I2C 接口精度可以做到 ±0.3°C 和 ±2%RH 左右贴片封装体积小适合放在探头的末端。再往上还有 SHT40、SHT45但普通楼宇监测用 SHT30 已经完全够用性价比很高。二氧化碳是“气体多参量”里最不能省的一项。市面上二氧化碳传感器主要有两类电化学和红外NDIR。电化学模块便宜但寿命短、容易漂移不适合做建筑长期监测。我选的是 MH-Z19 这类 NDIR 二氧化碳模块原理是让红外光穿过气室根据二氧化碳分子对特定波长的吸收程度计算浓度。它寿命更长能到五年以上量程 0 到 5000ppm精度大约 ±50ppm 再加 5% 读数误差对室内空气质量判断完全够用。模块自带 UART 和 PWM 输出接主控时可以用 UART省事。另一路气体参数我选了 SGP30用来测 TVOC 和 eCO2。SGP30 属于金属氧化物半导体传感器内部有一个加热元件污染气体接触半导体表面后会造成电导率变化通过算法折算成总挥发性有机物浓度。这类传感器有个特点绝对值别太较真更适合看趋势和突发事件。比如有人喷了空气清新剂、装修散味、午餐时间茶水间气味飙升SGP30 都能很快反映出来。用它去“精确测量甲醛浓度”不现实但楼宇场景里我们需要的是“有没有异味、空气质量是否恶化”的指示信号这就够了。如果项目有特殊需求比如医院或实验室要求甲醛也可以在这路接口上替换为电化学甲醛模块代价是定期标定和维护。2.2 主控、PHY 与 PoE 供电一个工程板级的组合方案主控我选了 STM32F407VET6。原因很直接这颗芯片内置以太网 MAC配合一颗外置 PHY 就能跑 TCP/IP不需要外挂复杂的网络协议栈芯片。F407 的主频 168MHz内部 Flash 和 RAM 足够跑 LwIP 协议栈同时还能处理三个传感器的数据采样、滤波和状态管理性能冗余很大。板级网络方案是 STM32 的 RMII 接口接了一颗 LAN8720A 的 PHY再通过内置网络变压器的 RJ45 座比如 HR911105A出线。需要特别注意RJ45 座一定要带网络隔离变压器这不是省成本的地方雷击浪涌、地环路和静电都可能通过网线传导进板子没有变压器隔离烧一片 PHY 不是开玩笑。供电方面如果现场有条件用 PoE 交换机我会在板上预留 PoE PD 模块的位置比如 MP8007 或 TPS23753。PoE 供电后进入板内 DC-DC再生成多路电压给主控、传感器和以太网 PHY。传感器和气体模块的供电纹波要控制好特别是 SGP30 的加热器对电源质量比较敏感我用了一路单独的 LDO 给模拟传感器供电电源纹波控制在 50mV 以内。如果不走 PoE则预留 9 到 36V 宽压 DC 输入这样现场可以用原有的 24V 电源总线也方便后期改造。PoE 模式的典型功率在 3W 左右一个以太网交换机端口带动十个这样的传感器完全没问题。2.3 结构设计别让传感器“自己骗自己”这个部分踩的坑最值钱。气体传感器和温湿度传感器对环境温度非常敏感而以太网 PHY、DC-DC 电源和主控都是发热源。如果 SGP30 紧挨着 LAN8720A板子工作半小时后局部温度能比环境温度高 5°C 以上直接影响 SHT30 的湿度读数也会让 SGP30 的基线产生严重偏移。我第一版 PCB 就是这么翻车的温度读数永远比实际高两度后来热成像一照问题一目了然。我的调整思路是把温湿度传感器放到探头的末端尽量远离 PCB 上的功率器件SGP30 放在板子边缘开散热通风孔让自然对流把热量带走MH-Z19 因为体积大单独做气室四周不要紧贴金属外壳避免外壳导热造成测量腔体温度畸变。结构上还要留校准孔这样工厂标定和现场零点校准时不需要拆壳。防护等级方面普通办公室做到 IP30 足够如果用在厨房或者潮湿环境传感器探头要有防尘罩和防冷凝设计。3. 固件与协议把采集值变成别人能用的数据3.1 网络协议栈与通信模式LwIP 是首选但别裸写 TCPSTM32F407 跑以太网我首选的协议栈是 LwIP。LwIP 的开源生态非常成熟支持 TCP、UDP、DHCP、DNS代码体积也小适合在嵌入式 MCU 上跑。它的接口模式有两类一类是 raw/callback API性能好但代码写起来很绕另一类是 netconn/socket API写起来像普通 socket 编程可读性高。考虑到后续要同时维护 Modbus TCP 和 MQTT 两条链路我用的是 netconn API牺牲一点点性能换维护效率。通信模式上我让设备同时扮演两个角色一是作为 TCP 服务器在 502 端口监听 Modbus TCP 请求方便楼宇自控系统用标准的 Modbus 轮询读取数据二是作为 MQTT 客户端主动连接后台的 MQTT Broker把实时数据推送给上层平台。这两个链路可以并存Modbus TCP 是“被拉”MQTT 是“主动推”。很多项目只做 Modbus TCP结果平台侧全部靠轮询数据刷新不够及时只做 MQTT 又不好接老旧的 BA 系统。双通道设计可以兼容新旧平台实际交付时业主非常认可。3.2 寄存器表与 JSON 数据帧设计数据格式必须一开始就定死协议设计最关键的是数据帧对楼宇这个场景来说字段必须清晰带时间戳还要有数据质量标志。Modbus TCP 部分我把关键数据放在保持寄存器里用的是标准线圈和寄存器语义方便用 Modbus Poll 之类的工具直接调试。寄存器地址表大致是这样的寄存器地址内容数据类型数据说明0x0000设备类型只读 U16固定值 0x0018表示多参量环境传感器0x0001固件版本只读 U16例如 0x0103 表示 V1.0.30x0010温度只读 Int16单位 0.1°C230 表示 23.0°C0x0011相对湿度只读 U16单位 0.1%RH462 表示 46.2%RH0x0012二氧化碳浓度只读 U16单位 ppm0x0013TVOC 浓度只读 U16单位 ppb0x0014状态字只读 U16bit0 温湿度正常bit1 CO2 正常bit2 TVOC 正常bit3 数据失效0x0020采样周期读写 U16单位秒默认 30范围 10 到 600MQTT 的推送报文我用 JSON 格式按行发送便于数字孪生平台直接用 JSON 解析。一个典型的报文长这样{device_id:ACU-03-121,ts:2025-03-18T10:24:3108:00,temp:23.4,rh:46.2,co2:612,tvoc:156,status:1}注意这里status是一个整型状态标志位不是直接把寄存器拆开而是固件内部算好之后打包客户端拿到不需要做位运算。MQTT 的 topic 我按项目编号和楼层组织比如building/floor03/room121/acusensor设备只往自己的 topic 发数据推荐用 QoS 1确保不丢包。如果上层平台需要历史数据就直接订阅 topic 写时序数据库如果需要指令下发比如改采样周期再用一个.../cmd的 topic 回传。3.3 断线重连、看门狗与本地缓存网线掉了也不能丢数据现场最容易出问题的不是传感器而是网络。固件里我做了三重保险。第一重是断线检测TCP 长时间没有收到对端 ACK就主动断开重连MQTT 断线后按指数退避算法重连第一次等 5 秒、第二次 10 秒、第三次 20 秒最大间隔 5 分钟防止所有设备同时上线把 Broker 打爆。第二重是独立看门狗除了 MCU 的 IWDG我还在 App 层维护一个“网络心跳计数器”如果网络任务超过 60 秒没有成功收发任何报文看门狗强制复位系统。这个设计帮我解决过一次 TCP 协议栈卡死的问题不加的话设备可能“假活”好几天。第三重是本地缓存。每 30 秒一条数据如果网络断开数据先写入外部 SPI Flash 的一块环形缓冲区能存 24 小时的量。网络恢复后设备先把缓存的旧数据按时间顺序补传到平台再继续上报实时数据。为了避免 Flash 频繁擦写造成寿命损耗我在固件里加了磨损均衡逻辑并且设置了缓存上传成功后的擦除策略。这个功能在改造项目里非常重要因为甲方网络经常因为割接、重启、弱电间跳闸而不稳定有了缓存至少数据不丢。4. 现场部署与调参完整走一遍项目流程4.1 点位选择和安装高度一错毁所有设备做好了如果点位选错数据再准也没有意义。办公室的温湿度传感器高度我一般装在 1.2 到 1.5 米大概是人坐姿呼吸带的高度。千万不能装在空调出风口正下方、窗边阳光直射处、或者暖气散热片附近否则测出来的温度不是房间温度而是设备周围那一点局部“小气候”。气体传感器的安装位置还要考虑空气流动不能塞在文件柜后面死角和吊顶里尤其是二氧化碳传感器它靠空气扩散进气如果周围被遮挡响应会慢很多。一些特殊区域的点位需要单独加参数地下车库和机房里我会在气体接口上追加一氧化碳传感器车位密度大的地方 CO 数据很有价值实验室和化学品存储区则适合换装可燃气体探测器并把报警阈值单独调低。点位编号必须和设备 ID 严格对应我每台设备出厂时就把设备ID、MAC地址、楼层房间号烧进一个二维码标签贴在外壳上现场施工人员用手机扫一下就能把设备装到指定位置。这个细节在大项目中能省掉大量后期排障时间。4.2 网络规划与 PoE 预算把隐患掐在施工前以太网传感器对网络是“即插即用”但前提是网络规划做在前面。我的做法是单独划一个 IoT VLAN比如10.24.3.0/24只允许传感器和平台之间通信禁止传感器直接跨 VLAN 访问办公网络。平台服务器通过防火墙白名单访问 502 端口和 MQTT 端口。这里一定要和甲方的网络管理员提前对齐特别是 VLAN、DHCP 地址段和端口开放策略。我吃过一次亏设备出厂默认 DHCP现场网络没有配置地址保留结果传感器 IP 频繁漂移平台侧一会儿连不上这个一会儿连不上那个。PoE 预算也要算准。每个传感器的功耗大概 3W但如果后期加了主动式气泵或电化学传感器功耗会到 4.5W 左右。交换机 PoE 端口的总功率要留 25% 余量比如一台 24 口 PoE 交换机预算 400W实际接满 24 台设备按每台 5W 算只要 120W看似够但交换机本身的 PoE 总功率和端口功率是两码事端口功率预算不足会导致设备启动瞬间反复掉电。方案沟通时我给甲方写了一个硬指标传感器供电使用 802.3af 标准 PoE端口最大功率不低于 15W这样即使后期升级带加热除湿的传感器也不需要重换交换机。4.3 标定与零点校准数据准确性的最后一道关出厂时温湿度传感器本身有厂商校准但气体传感器尤其是 SGP30 不能直接“开箱即用”。我建议每一批设备在通电老化 48 小时后在干净的空气环境里做一次零点校准。SGP30 内部有基线算法首次上电的 12 小时数据波动很正常不要让施工人员拿这个时间去试报警阈值。二氧化碳传感器的零点校准也很关键。MH-Z19 支持零点标定功能做法是在户外空气流通的地方短接校准引脚让模块把 400ppm 作为基线。这一步不能省尤其是长期在室内运行的模块基线漂移会导致读数越来越离谱。现场校准还有一个小技巧多参量传感器要放在同一个环境里做对比测试而不是拿着手持仪表去挨个“敲”数值。手持仪表和传感器的响应时间不一样直接对比会让人觉得数据全是错的。我通常是让设备稳定运行 30 分钟再用手持仪表在设备旁边测 5 分钟取平均误差在温湿度 ±0.5°C / ±5%RH、CO2 ±100ppm 以内就认为通过。TVOC 不做绝对精度判断只做趋势一致性判断。5. 常见问题与排查技巧实录5.1 现场故障速查表遇到问题先看现象再动设备设备上线后现场排障不可避免。我习惯把所有常遇到的问题整理成速查表发给现场运维人员这样可以减少大量无效沟通。以下是这个项目里最常碰到的几类问题现象可能原因处理步骤温度读数明显偏高传感器离发热元件太近或被阳光直射检查安装位置改善通风必要时重新装湿度长期显示 99%探头进水或冷凝取出传感器放在干燥环境恢复检查外壳密封CO2 数值偏高且不回零传感器长期未做基线校准户外空气下做零点标定若仍漂移则返厂TVOC 数值乱跳SGP30 预热不足或酒精等干扰老化 48 小时加数据滤波不要追求绝对值设备网口灯亮但 ping 不通IP 冲突或交换机端口 VLAN 不对检查 MAC 与 DHCP 保留核对交换机 access/trunk 配置Modbus TCP 502 端口超时防火墙阻断或平台侧请求地址写错检查白名单用 Modbus Poll 联调设备反复重启PoE 功率不足或电源纹波大更换 802.3af 端口检查 DC-DC 输出数据断续上报网线压接不良或 DHCP 租期太短重新做水晶头检查 DHCP lease time这里我再多说一句现场很多“传感器坏了”的问题最后都出在网线和水晶头上。很多人觉得六类线随便压压就行但 PoE 供电对线对的接触电阻很敏感水晶头接触不良造成供电不稳设备会表现成随机重启。排查这类问题时先换一根成品网线试一下最快。5.2 排查工具Modbus Poll Wireshark tcpdump设备联调的时候我的三件套是 Modbus Poll、Wireshark还有 Linux 服务器上的 tcpdump。Modbus Poll 用来直接读寄存器验证地址映射和字节序。Wireshark 抓包主要是看 TCP 握手是否正常、Modbus 报文的功能码和数据长度对不对。抓包过滤器可以写成tcp.port 502在服务器端如果不想开图形界面tcpdump 更轻量tcpdump -i eth0 port 502 -n -XX还有一次 MQTT 上报延迟的问题就是用 tcpdump 抓出设备重连频率异常高才发现 MQTT Broker 的 keepalive 配置和固件里的心跳间隔不匹配。这种问题看平台日志看不出来抓包一眼就清楚。5.3 我踩过的几个坑第一个坑是 SGP30 离 PoE 电源太近。第一版板子温度读数偏高两度后来把 SGP30 挪到板子边缘温度偏差就消了。所以画板阶段一定要做热仿真或者直接用热成像仪验证别等装到现场再去贴隔热棉。第二个坑是 DHCP 地址保留没做设备 IP 漂移导致平台数据断档后来把每台设备的 IP 和 MAC 绑定才解决。第三个坑是 MQTT 重连没有退避策略现场五十台设备同时掉线重连Broker 直接被连接风暴打挂。第四个坑是部署完没有立刻做二氧化碳零点校准第一周数据整体偏高近 100ppm业主差点以为传感器质量不行。如果你也准备做类似项目我最大的建议是不要先急着做平台界面先把单台设备的网络、数据、标定闭环打通再批量复制。环境监测项目表面上是硬件问题本质上是系统可靠性问题。一块板子能跑通不算本事五十块板子在弱电间里持续稳定跑三个月才叫真本事。后面我打算把 PM2.5、光照度和噪音也做进这套节点里顺便把设备固件升级做成远程 OTA目前这套东西已经在实验室跑通了等我再沉淀一段时间找机会把远程升级和边缘校准的部分单独写一篇。
上个月我把园区一个办公楼的室内环境监测项目收了尾核心设备就是标题里这组“以太网温湿度气体多参量传感器”。说得直白点它是一个能同时采集温度、湿度、二氧化碳、TVOC并且直接走网线上报数据的终端节点如果把这栋楼比作一个人楼宇自控平台是大脑网线是神经这些传感器就是分布在各处的神经末梢。这套系统上线之后物业不再靠人工拿手持表去一层层测运维人员打开后台就能看到每一个房间的实时环境曲线。写这篇东西不是要讲一个多么前沿的概念而是把我从选型、画板、调协议、现场装点位上摸出来的一套完整做法整理出来给正在做楼宇环控、实验室监控或者机房环境监测的朋友一个可直接抄的参考。1. 项目缘起一栋楼最不缺的是数据最缺的是靠谱的数据1.1 真实痛点空调开了 24 小时投诉却从没停过这个项目来自一个十二层的园区办公楼痛点非常典型不同朝向的办公室温差能到 4 到 5 摄氏度朝阳面夏天闷热背阴面冬天阴冷会议室下午二氧化碳浓度经常破 1500ppm参会的人昏昏欲睡个别房间偶尔有装修残留的异味但物业查不到源头。原有的楼宇自控系统只采集了新风机组和空调箱的供回水温度至于每个房间到底什么环境完全靠人工巡检。业主的诉求其实很朴素不能只在机房看设备温度必须知道人所在的空间是什么状态。这正是“环境感知神经”要解决的问题。这类需求听起来简单真正落地却卡在设备形态上。如果每个房间装一个温度计、一个湿度计、再单独装一个二氧化碳检测仪线缆、安装、维护三座大山立刻压过来如果只装单一的温湿度传感器业主又抱怨闻不到“味道”。所以“多参量”这个方向几乎是必然选择。一个设备同时测温湿度、二氧化碳和 TVOC用一根网线既通数据又供电省掉了传感器箱、串口服务器、小电源适配器和一堆乱七八糟的线缆。节点数量一旦超过五十个这种省法就是决定项目利润和后期维护量的关键。1.2 方案选型为什么我最终选了以太网而不是 RS485 或无线同行看到我的方案第一反应都是问这种传感器用 RS485 不就行了干嘛非要碰以太网我确实也想过 RS485。从成本看RS485 芯片便宜布线距离长带 Modbus 协议也很成熟。但它有两个硬伤第一楼内跨楼层走线必须总线串联一旦某一段短路后面整串设备全部离线排障能把人逼疯第二RS485 本质上需要一个串口服务器或者采集器去转成 IP 协议增加了一层故障点后期替换设备还要去改地址、改波特率。对于动辄几十上百个点的建筑空间RS485 的“一根总线拖到底”反而成了维护噩梦。无线方案我也测过 LoRa 和 Zigbee安装在灵活性上确实占优但在这类钢筋混凝土结构的楼里无线信号穿墙衰减非常明显金属吊顶、电梯井、强弱电间都会让数据一跳再跳。更关键的是楼宇环境监测的数据最终要交给上层平台做分析和告警主流的楼宇自控系统、能耗平台、数字孪生平台对 IP 网络的接入远比串口友好。以太网方案相当于让每个传感器直接获得一个 IP 地址平台侧用 Modbus TCP 轮询上层用 MQTT 订阅推送中间不需要任何协议转换网关。我把几种方案的成本、可靠性和维护难度拉了个表对比项RS485 总线LoRa/Zigbee 无线以太网本项目采用传输距离1200m 内但受总线拓扑限制空旷距离可观楼内衰减大100m 以内网线直连楼层内可走交换机堆叠部署复杂度需串联布线节点越多风险越大无需布线但网关和电池/供电麻烦星型拓扑单点故障不影响全局响应速度半双工轮询节点多时延迟高上行延迟不稳定全双工 TCP毫秒级响应与平台对接必须加串口服务器需要专用网关直接 TCP/IP天然友好供电方式需额外布供电线或带 RS485 的电源线电池或本地电源PoE 或网线旁路供电维护难度总线故障排查困难电池更换、网关故障常见单点排查网口状态透明这个表的结论很明确以太网方案在建筑侧的综合维护成本其实是最低的。尤其是 PoE 供电的引入让传感器真正做到“一根网线全干完”施工队只需要敷设标准网线不用再考虑现场有没有 220V 插座也不用担心强电干扰传感器信号。后面我会重点讲 PoE 供电的板级设计和现场预算这是很多人容易翻车的地方。2. 硬件方案传感器怎么选、主控怎么搭、PCB 怎么画2.1 温湿度与气体传感器选型先搞懂测量原理再下单多参量传感器的硬件核心不是主控而是传感器探头选型。温湿度这块早期很多项目喜欢用 DHT11、DHT22便宜是便宜但精度、一致性和长期稳定性都一般。DHT22 标称精度 ±0.5°C实际在批量装配中经常差到 1°C 以上而且潮湿环境下容易失效。我这次选的是 SHT30I2C 接口精度可以做到 ±0.3°C 和 ±2%RH 左右贴片封装体积小适合放在探头的末端。再往上还有 SHT40、SHT45但普通楼宇监测用 SHT30 已经完全够用性价比很高。二氧化碳是“气体多参量”里最不能省的一项。市面上二氧化碳传感器主要有两类电化学和红外NDIR。电化学模块便宜但寿命短、容易漂移不适合做建筑长期监测。我选的是 MH-Z19 这类 NDIR 二氧化碳模块原理是让红外光穿过气室根据二氧化碳分子对特定波长的吸收程度计算浓度。它寿命更长能到五年以上量程 0 到 5000ppm精度大约 ±50ppm 再加 5% 读数误差对室内空气质量判断完全够用。模块自带 UART 和 PWM 输出接主控时可以用 UART省事。另一路气体参数我选了 SGP30用来测 TVOC 和 eCO2。SGP30 属于金属氧化物半导体传感器内部有一个加热元件污染气体接触半导体表面后会造成电导率变化通过算法折算成总挥发性有机物浓度。这类传感器有个特点绝对值别太较真更适合看趋势和突发事件。比如有人喷了空气清新剂、装修散味、午餐时间茶水间气味飙升SGP30 都能很快反映出来。用它去“精确测量甲醛浓度”不现实但楼宇场景里我们需要的是“有没有异味、空气质量是否恶化”的指示信号这就够了。如果项目有特殊需求比如医院或实验室要求甲醛也可以在这路接口上替换为电化学甲醛模块代价是定期标定和维护。2.2 主控、PHY 与 PoE 供电一个工程板级的组合方案主控我选了 STM32F407VET6。原因很直接这颗芯片内置以太网 MAC配合一颗外置 PHY 就能跑 TCP/IP不需要外挂复杂的网络协议栈芯片。F407 的主频 168MHz内部 Flash 和 RAM 足够跑 LwIP 协议栈同时还能处理三个传感器的数据采样、滤波和状态管理性能冗余很大。板级网络方案是 STM32 的 RMII 接口接了一颗 LAN8720A 的 PHY再通过内置网络变压器的 RJ45 座比如 HR911105A出线。需要特别注意RJ45 座一定要带网络隔离变压器这不是省成本的地方雷击浪涌、地环路和静电都可能通过网线传导进板子没有变压器隔离烧一片 PHY 不是开玩笑。供电方面如果现场有条件用 PoE 交换机我会在板上预留 PoE PD 模块的位置比如 MP8007 或 TPS23753。PoE 供电后进入板内 DC-DC再生成多路电压给主控、传感器和以太网 PHY。传感器和气体模块的供电纹波要控制好特别是 SGP30 的加热器对电源质量比较敏感我用了一路单独的 LDO 给模拟传感器供电电源纹波控制在 50mV 以内。如果不走 PoE则预留 9 到 36V 宽压 DC 输入这样现场可以用原有的 24V 电源总线也方便后期改造。PoE 模式的典型功率在 3W 左右一个以太网交换机端口带动十个这样的传感器完全没问题。2.3 结构设计别让传感器“自己骗自己”这个部分踩的坑最值钱。气体传感器和温湿度传感器对环境温度非常敏感而以太网 PHY、DC-DC 电源和主控都是发热源。如果 SGP30 紧挨着 LAN8720A板子工作半小时后局部温度能比环境温度高 5°C 以上直接影响 SHT30 的湿度读数也会让 SGP30 的基线产生严重偏移。我第一版 PCB 就是这么翻车的温度读数永远比实际高两度后来热成像一照问题一目了然。我的调整思路是把温湿度传感器放到探头的末端尽量远离 PCB 上的功率器件SGP30 放在板子边缘开散热通风孔让自然对流把热量带走MH-Z19 因为体积大单独做气室四周不要紧贴金属外壳避免外壳导热造成测量腔体温度畸变。结构上还要留校准孔这样工厂标定和现场零点校准时不需要拆壳。防护等级方面普通办公室做到 IP30 足够如果用在厨房或者潮湿环境传感器探头要有防尘罩和防冷凝设计。3. 固件与协议把采集值变成别人能用的数据3.1 网络协议栈与通信模式LwIP 是首选但别裸写 TCPSTM32F407 跑以太网我首选的协议栈是 LwIP。LwIP 的开源生态非常成熟支持 TCP、UDP、DHCP、DNS代码体积也小适合在嵌入式 MCU 上跑。它的接口模式有两类一类是 raw/callback API性能好但代码写起来很绕另一类是 netconn/socket API写起来像普通 socket 编程可读性高。考虑到后续要同时维护 Modbus TCP 和 MQTT 两条链路我用的是 netconn API牺牲一点点性能换维护效率。通信模式上我让设备同时扮演两个角色一是作为 TCP 服务器在 502 端口监听 Modbus TCP 请求方便楼宇自控系统用标准的 Modbus 轮询读取数据二是作为 MQTT 客户端主动连接后台的 MQTT Broker把实时数据推送给上层平台。这两个链路可以并存Modbus TCP 是“被拉”MQTT 是“主动推”。很多项目只做 Modbus TCP结果平台侧全部靠轮询数据刷新不够及时只做 MQTT 又不好接老旧的 BA 系统。双通道设计可以兼容新旧平台实际交付时业主非常认可。3.2 寄存器表与 JSON 数据帧设计数据格式必须一开始就定死协议设计最关键的是数据帧对楼宇这个场景来说字段必须清晰带时间戳还要有数据质量标志。Modbus TCP 部分我把关键数据放在保持寄存器里用的是标准线圈和寄存器语义方便用 Modbus Poll 之类的工具直接调试。寄存器地址表大致是这样的寄存器地址内容数据类型数据说明0x0000设备类型只读 U16固定值 0x0018表示多参量环境传感器0x0001固件版本只读 U16例如 0x0103 表示 V1.0.30x0010温度只读 Int16单位 0.1°C230 表示 23.0°C0x0011相对湿度只读 U16单位 0.1%RH462 表示 46.2%RH0x0012二氧化碳浓度只读 U16单位 ppm0x0013TVOC 浓度只读 U16单位 ppb0x0014状态字只读 U16bit0 温湿度正常bit1 CO2 正常bit2 TVOC 正常bit3 数据失效0x0020采样周期读写 U16单位秒默认 30范围 10 到 600MQTT 的推送报文我用 JSON 格式按行发送便于数字孪生平台直接用 JSON 解析。一个典型的报文长这样{device_id:ACU-03-121,ts:2025-03-18T10:24:3108:00,temp:23.4,rh:46.2,co2:612,tvoc:156,status:1}注意这里status是一个整型状态标志位不是直接把寄存器拆开而是固件内部算好之后打包客户端拿到不需要做位运算。MQTT 的 topic 我按项目编号和楼层组织比如building/floor03/room121/acusensor设备只往自己的 topic 发数据推荐用 QoS 1确保不丢包。如果上层平台需要历史数据就直接订阅 topic 写时序数据库如果需要指令下发比如改采样周期再用一个.../cmd的 topic 回传。3.3 断线重连、看门狗与本地缓存网线掉了也不能丢数据现场最容易出问题的不是传感器而是网络。固件里我做了三重保险。第一重是断线检测TCP 长时间没有收到对端 ACK就主动断开重连MQTT 断线后按指数退避算法重连第一次等 5 秒、第二次 10 秒、第三次 20 秒最大间隔 5 分钟防止所有设备同时上线把 Broker 打爆。第二重是独立看门狗除了 MCU 的 IWDG我还在 App 层维护一个“网络心跳计数器”如果网络任务超过 60 秒没有成功收发任何报文看门狗强制复位系统。这个设计帮我解决过一次 TCP 协议栈卡死的问题不加的话设备可能“假活”好几天。第三重是本地缓存。每 30 秒一条数据如果网络断开数据先写入外部 SPI Flash 的一块环形缓冲区能存 24 小时的量。网络恢复后设备先把缓存的旧数据按时间顺序补传到平台再继续上报实时数据。为了避免 Flash 频繁擦写造成寿命损耗我在固件里加了磨损均衡逻辑并且设置了缓存上传成功后的擦除策略。这个功能在改造项目里非常重要因为甲方网络经常因为割接、重启、弱电间跳闸而不稳定有了缓存至少数据不丢。4. 现场部署与调参完整走一遍项目流程4.1 点位选择和安装高度一错毁所有设备做好了如果点位选错数据再准也没有意义。办公室的温湿度传感器高度我一般装在 1.2 到 1.5 米大概是人坐姿呼吸带的高度。千万不能装在空调出风口正下方、窗边阳光直射处、或者暖气散热片附近否则测出来的温度不是房间温度而是设备周围那一点局部“小气候”。气体传感器的安装位置还要考虑空气流动不能塞在文件柜后面死角和吊顶里尤其是二氧化碳传感器它靠空气扩散进气如果周围被遮挡响应会慢很多。一些特殊区域的点位需要单独加参数地下车库和机房里我会在气体接口上追加一氧化碳传感器车位密度大的地方 CO 数据很有价值实验室和化学品存储区则适合换装可燃气体探测器并把报警阈值单独调低。点位编号必须和设备 ID 严格对应我每台设备出厂时就把设备ID、MAC地址、楼层房间号烧进一个二维码标签贴在外壳上现场施工人员用手机扫一下就能把设备装到指定位置。这个细节在大项目中能省掉大量后期排障时间。4.2 网络规划与 PoE 预算把隐患掐在施工前以太网传感器对网络是“即插即用”但前提是网络规划做在前面。我的做法是单独划一个 IoT VLAN比如10.24.3.0/24只允许传感器和平台之间通信禁止传感器直接跨 VLAN 访问办公网络。平台服务器通过防火墙白名单访问 502 端口和 MQTT 端口。这里一定要和甲方的网络管理员提前对齐特别是 VLAN、DHCP 地址段和端口开放策略。我吃过一次亏设备出厂默认 DHCP现场网络没有配置地址保留结果传感器 IP 频繁漂移平台侧一会儿连不上这个一会儿连不上那个。PoE 预算也要算准。每个传感器的功耗大概 3W但如果后期加了主动式气泵或电化学传感器功耗会到 4.5W 左右。交换机 PoE 端口的总功率要留 25% 余量比如一台 24 口 PoE 交换机预算 400W实际接满 24 台设备按每台 5W 算只要 120W看似够但交换机本身的 PoE 总功率和端口功率是两码事端口功率预算不足会导致设备启动瞬间反复掉电。方案沟通时我给甲方写了一个硬指标传感器供电使用 802.3af 标准 PoE端口最大功率不低于 15W这样即使后期升级带加热除湿的传感器也不需要重换交换机。4.3 标定与零点校准数据准确性的最后一道关出厂时温湿度传感器本身有厂商校准但气体传感器尤其是 SGP30 不能直接“开箱即用”。我建议每一批设备在通电老化 48 小时后在干净的空气环境里做一次零点校准。SGP30 内部有基线算法首次上电的 12 小时数据波动很正常不要让施工人员拿这个时间去试报警阈值。二氧化碳传感器的零点校准也很关键。MH-Z19 支持零点标定功能做法是在户外空气流通的地方短接校准引脚让模块把 400ppm 作为基线。这一步不能省尤其是长期在室内运行的模块基线漂移会导致读数越来越离谱。现场校准还有一个小技巧多参量传感器要放在同一个环境里做对比测试而不是拿着手持仪表去挨个“敲”数值。手持仪表和传感器的响应时间不一样直接对比会让人觉得数据全是错的。我通常是让设备稳定运行 30 分钟再用手持仪表在设备旁边测 5 分钟取平均误差在温湿度 ±0.5°C / ±5%RH、CO2 ±100ppm 以内就认为通过。TVOC 不做绝对精度判断只做趋势一致性判断。5. 常见问题与排查技巧实录5.1 现场故障速查表遇到问题先看现象再动设备设备上线后现场排障不可避免。我习惯把所有常遇到的问题整理成速查表发给现场运维人员这样可以减少大量无效沟通。以下是这个项目里最常碰到的几类问题现象可能原因处理步骤温度读数明显偏高传感器离发热元件太近或被阳光直射检查安装位置改善通风必要时重新装湿度长期显示 99%探头进水或冷凝取出传感器放在干燥环境恢复检查外壳密封CO2 数值偏高且不回零传感器长期未做基线校准户外空气下做零点标定若仍漂移则返厂TVOC 数值乱跳SGP30 预热不足或酒精等干扰老化 48 小时加数据滤波不要追求绝对值设备网口灯亮但 ping 不通IP 冲突或交换机端口 VLAN 不对检查 MAC 与 DHCP 保留核对交换机 access/trunk 配置Modbus TCP 502 端口超时防火墙阻断或平台侧请求地址写错检查白名单用 Modbus Poll 联调设备反复重启PoE 功率不足或电源纹波大更换 802.3af 端口检查 DC-DC 输出数据断续上报网线压接不良或 DHCP 租期太短重新做水晶头检查 DHCP lease time这里我再多说一句现场很多“传感器坏了”的问题最后都出在网线和水晶头上。很多人觉得六类线随便压压就行但 PoE 供电对线对的接触电阻很敏感水晶头接触不良造成供电不稳设备会表现成随机重启。排查这类问题时先换一根成品网线试一下最快。5.2 排查工具Modbus Poll Wireshark tcpdump设备联调的时候我的三件套是 Modbus Poll、Wireshark还有 Linux 服务器上的 tcpdump。Modbus Poll 用来直接读寄存器验证地址映射和字节序。Wireshark 抓包主要是看 TCP 握手是否正常、Modbus 报文的功能码和数据长度对不对。抓包过滤器可以写成tcp.port 502在服务器端如果不想开图形界面tcpdump 更轻量tcpdump -i eth0 port 502 -n -XX还有一次 MQTT 上报延迟的问题就是用 tcpdump 抓出设备重连频率异常高才发现 MQTT Broker 的 keepalive 配置和固件里的心跳间隔不匹配。这种问题看平台日志看不出来抓包一眼就清楚。5.3 我踩过的几个坑第一个坑是 SGP30 离 PoE 电源太近。第一版板子温度读数偏高两度后来把 SGP30 挪到板子边缘温度偏差就消了。所以画板阶段一定要做热仿真或者直接用热成像仪验证别等装到现场再去贴隔热棉。第二个坑是 DHCP 地址保留没做设备 IP 漂移导致平台数据断档后来把每台设备的 IP 和 MAC 绑定才解决。第三个坑是 MQTT 重连没有退避策略现场五十台设备同时掉线重连Broker 直接被连接风暴打挂。第四个坑是部署完没有立刻做二氧化碳零点校准第一周数据整体偏高近 100ppm业主差点以为传感器质量不行。如果你也准备做类似项目我最大的建议是不要先急着做平台界面先把单台设备的网络、数据、标定闭环打通再批量复制。环境监测项目表面上是硬件问题本质上是系统可靠性问题。一块板子能跑通不算本事五十块板子在弱电间里持续稳定跑三个月才叫真本事。后面我打算把 PM2.5、光照度和噪音也做进这套节点里顺便把设备固件升级做成远程 OTA目前这套东西已经在实验室跑通了等我再沉淀一段时间找机会把远程升级和边缘校准的部分单独写一篇。
