去年帮朋友做冷库监测的时候客户提了个需求库房在郊区没有WiFi覆盖距离办公室一百多米但要求24小时盯着温湿度温度一超限就得马上知道。当时我想过拉网线、想过LoRa最后定下来的方案就是室内4G温湿度传感器——每个库房放一个通过4G网络直接把数据推上云平台手机端随时看。这个方案最核心的价值就一句话不需要现场有任何网络基础设施只要有4G信号覆盖设备通电就能用数据直接进云端24小时不断线。这篇文章就把整个项目的设计思路、硬件选型、固件实现、云端对接和现场排查一次性讲透。不管你是想做一个冷库监控、机房温湿度记录、档案室环境监测还是单纯想把手里的DHT11、SHT30传感器接上4G模块实现远程数据追踪这套方案都能直接照着抄。基础部分我会讲得比较细有经验的可以直接跳到通信链路和问题排查章节。1. 方案选型为什么是4G温湿度传感器而不是WiFi或LoRa1.1 项目需求拆解与场景画像做项目之前先别急着买器件把需求掰开揉碎看一遍。这个标题里藏着几个关键约束条件拆开之后你会发现很多选择都是被需求推着走的。第一是室内两个字。室内意味着设备不需要做严格的户外防水防尘处理外壳可以用普通的ABS塑料盒天线也不用特别考虑雷击浪涌这大大降低了结构设计的门槛。但室内也带来了一个麻烦——信号穿透问题。尤其是冷库、地下室、档案库这种地方墙体厚、金属货架多、空间封闭普通的NB-IoT在某些区域信号不太稳而4G的覆盖广度和穿透能力明显更好这也是为什么最终选择4G而不是NB-IoT的核心原因之一。第二是24小时实时数据追踪。这句话背后意味着设备要长时间在线数据要周期性上报掉线要能自动恢复数据丢了几分钟还能补传。它不是那种每天采几次、存本地、隔几天人工下载一次的离线记录仪而是一个真正意义上的在线监测终端。第三是使用者的真实痛点。我接触过的这类项目用户真正关心的不是技术架构多先进而是三个朴素的问题能不能在手机上随时看到数据温湿度超限了能不能第一时间收到告警设备坏了或者断网了能不能及时发现所有技术选型都要围绕这三个问题展开。1.2 三种通信方案横向对比做远程温湿度监测主流的通信方案无非三种WiFi、LoRa/WiFi网关、4G蜂窝网络。我分别说下实际对比之后的选择结果。WiFi方案的优点是硬件成本低ESP8266加一个DHT11加起来不到20块钱固件里用HTTP POST或者MQTT就能把数据推上云。但它的致命伤是严重依赖现场WiFi网络的稳定性和配置。工业现场、仓库、冷库这些场景现场往往没有WiFi就算有SSID和密码变更一次你就要跑一趟现场重新配置设备换个位置可能信号就不行了。LoRa方案适合多点组网、数据量小、节点密集的场景。几十个节点通过LoRa汇聚到一个网关网关再用4G或以太网上行这套方案在节点数量多的项目里确实划算。但如果只有三五个点位网关成本摊不下来而且LoRa节点本身不能直接上网必须依赖网关在线网关挂了整条链路就断了。4G方案的优缺点都非常明显。优点是独立入网不需要现场配网插上SIM卡通电就能用数据直连云平台适合点位分散、数量少、现场无网的环境。缺点是模块单价高还需要持续的SIM卡流量费用。但从项目落地角度看这套方案省掉的施工调试时间远远值回硬件差价。我把三种方案的关键参数整理成了一个对比表对比项WiFi方案LoRa网关方案4G方案单点硬件成本低约20元中节点分摊网关中高约80-150元是否需要现场网络需要WiFi需要网关上行联网不需要独立入网覆盖距离30-50米节点到网关可达数公里依赖运营商基站配置复杂度低配WiFi高组网网关配置低插卡即用断网自恢复能力一般一般较强适合场景室内WiFi稳定多点位大范围点位少、现场无网这个项目最终选了4G方案就是因为现场没有WiFi、点位只有几个、分布在不同房间4G是成本和时间双重约束下的最优解。1.3 传感器选型DHT11能用但别指望精度热词里有DHT11说明很多新手对这颗传感器非常熟悉。简单说下我的看法DHT11适合拿来学习原理、做原型验证但真正放到商业项目里做温湿度记录我会直接换掉它。DHT11的主要问题是精度和分辨率都不够。温度精度只有正负2摄氏度湿度精度正负5%RH分辨率只有1位小数。做环境监测的时候这种误差会导致两个问题一是数据本身不可信客户拿标准温度计一比对差了3度你很难解释二是告警阈值很难设你想设一个温度超过25度告警但传感器本身就有正负2度的误差实际23度就可能触发告警或者27度才告警边界情况根本说不清。所以我建议只要预算不是极端紧张传感器直接上SHT30或者SHT31。SHT30的温度精度是正负0.3摄氏度湿度精度正负2%RH价格也就几块钱到十几块钱比DHT11贵不了多少但数据质量完全不是一个级别。项目里如果对精度有更变态的要求比如生物制药库房需要正负0.1度那就要上PT100加高精度采集电路这不是这个量级的产品能覆盖的了。另外还有一个容易忽略的点传感器的响应时间和安装位置。DHT11这类传感器如果直接裸露在空气中受通风和辐射影响很大测出来的温度往往偏高。更合理的做法是把传感器放在有通风孔的外壳里避开阳光直射和发热源让传感器和被测环境充分热交换。这个细节后面在部署环节会专门说。2. 硬件核心细节从主控到4G模块的搭配思路2.1 主控选型与最小系统设计主控在这套方案里干的事不复杂定时读取传感器数据解析4G模块的AT指令响应拼接JSON数据包然后通过串口发给4G模块。计算量不大但稳定性要求比较高因为设备一旦部署出去可能几个月没人碰它。我用的主控是STM32F407。选它的原因有几个一是主频高资源足后续想升级功能比如OTA远程升级热词里也有stm32f407 4g ota不用换芯片二是串口数量多一个串口接4G模块一个串口留作调试互不干扰三是F407内部Flash有1MB可以跑Bootloader加App的双分区OTA方案。如果你不想用STM32也可以用ESP32或者国产的Air32系列逻辑上完全没问题。但有一个硬性要求主控必须至少有2个UART一个用于和4G模块通信一个用于日志调试。如果只有一个串口调试的时候就得频繁拔线效率极低。最小系统设计上有几点经验值得分享给4G模块和传感器分别供电不要在同一个LDO上并太多负载。4G模块在发射瞬间电流能冲到2A如果和传感器共用一颗低压差线性稳压器电压跌落会导致传感器读数波动甚至主控复位。主控和4G模块之间要留电平转换或者直接选择3.3V供电的模块。有些4G模块是5V逻辑电平和3.3V的MCU直连会烧IO口这个坑我踩过。预留SIM卡的ESD防护和TVS管静电打坏SIM卡座是现场故障里非常常见的一种。2.2 4G模块选型与关键参数解读4G模块是整个方案里最核心的器件也是成本大头。市面上的模块主要分两个流派一个是移远的EC200S系列市场占有率最高文档齐全AT指令生态成熟另一个是合宙的Air724UG主打低成本和二次开发甚至可以直接用Lua脚本写业务逻辑不需要外挂MCU。我这次用的是移远EC200S的Cat.1版本。为什么用Cat.1而不是普通的4G因为温湿度传感器这种应用上行下行带宽需求都极小一次上报的数据量也就一两百字节Cat.1的速率完全够用而且Cat.1模块比高速4G模块功耗更低、价格更便宜在物联网领域已经成为主流选择。挑选4G模块的时候有几个参数一定要看清楚支持的网络制式必须确认支持中国移动、中国联通、中国电信的LTE网络最好是全网通版本否则换运营商就得换模块。工作温度范围工业级模块一般是零下35度到正75度如果是商业级在冷库等低温场景下会直接罢工。串口电平分清是1.8V还是3.3V和主控I/O电平不匹配需要加转换芯片。SIM卡接口支持eSIM还是插拔式SIM卡项目里建议用插拔式nano SIM方便更换运营商。模块和主控之间的通信走的就是AT指令简单说就是你通过串口给模块发文本指令模块干完活给你回一个结果。比如发ATCGATT?查询模块是否附着上4G网络模块回复CGATT: 1就表示附着成功。理解了这套交互逻辑后面固件开发就好办了。2.3 供电与功耗设计供电方案决定了这个设备能部署在什么环境。我做的时候同时考虑了两种场景一种是室内有插座直接用220V转5V的电源适配器另一种是临时监测需要用电池或者充电宝供电。先说220V供电。这里有个新手容易忽略的问题4G模块在注册网络和发送数据的时候电流峰值很高瞬间可能到1.5A到2A如果电源适配器质量差、纹波大模块就很容易掉线。我经过几次试验后选的是标称2A以上的适配器然后在板子上加了大电容做储能实测下来掉线率明显下降。再说电池供电。温湿度监测不可能频繁换电池所以功耗设计要从两个角度压一是降低采样频率正常情况下我设置为每60秒采集一次、每15分钟上报一次数据在本地缓存而不是每次采集都走网络二是让4G模块在没有数据需要发送的时候进入PSM低功耗模式这个模式下模块的待机电流能降到微安级别。有人可能会问为什么不上报得那么频繁理论上每秒都能上报但实际有两个约束一是流量成本发得越频繁流量消耗越大一个月下来流量费可能比设备本身还贵二是对运营商的网络资源不友好物联网卡虽然便宜但频率过高也可能被运营商限制。每15分钟一次的频率24小时一天96条数据画成曲线已经足够平滑用来做环境趋势分析绰绰有余。3. 固件采集与4G通信实现3.1 温湿度数据采集与精度处理传感器用的是SHT30走I2C接口主控每隔60秒读一次温湿度数据。这里有一个很重要的处理逻辑不要拿单次读数直接上报要做滤波和缓存。我习惯用滑动平均滤波就是把最近5次采样的温度值取算术平均作为当前有效值。这样做的好处是能大幅减少由于空气流动、开关门等原因造成的瞬时抖动。比如冷库开门那一下冷气外泄温度可能会瞬间跳变1到2度如果不滤波云端就会记录一个假告警客户半夜被电话吵醒结果到现场一看一切正常这种体验非常差。滤波之后的数据存到本地的Flash环形队列里每15分钟把队列里的最新一组数据打包上报。如果网络异常导致上报失败数据不会丢而是继续缓存在Flash里等网络恢复后按时间戳顺序补传。这个缓存机制的实现要注意Flash的磨损均衡不能每次都往同一片地址写否则Flash寿命会很快耗尽。SHT30的读取时序很简单但有一个细节必须提醒I2C总线上的上拉电阻不能省。有些开发板的传感器模块自带I2C上拉电阻但如果你自己画板子记得在SCL和SDA上分别接一个4.7K上拉到VCC否则总线通信会随机失败。这个毛病非常隐蔽因为它不是每次都失败而是时好时坏排查起来很痛苦。3.2 AT指令与网络接入流程4G模块上电之后固件要做的事情可以拆成一条清晰的流水线开机、搜网、附着、激活PDP上下文、建立TCP连接或MQTT连接、发送数据、休眠。每一步都对应一组AT指令我把核心流程和指令贴出来供参考。// 模块开机后先发AT测试模块是否响应 发送: AT 期望: OK // 查询SIM卡状态只有返回CPIN: READY才算正常 发送: ATCPIN? 期望: CPIN: READY // 查询信号强度数值越大越好一般大于15可以正常通信 发送: ATCSQ 期望: CSQ: 22,0 // 查询是否注册上4G网络 发送: ATCGATT? 期望: CGATT: 1 // 查询当前网络类型确认是LTE而不是回落到了2G/3G 发送: ATPSRAT? 期望: PSRAT: 7 // 7代表LTE // 如果是MQTT方式直接用模块内置的MQTT指令 发送: ATMQTTCFGtcp://你的域名或IP:1883,6000 期望: OK 发送: ATMQTTOPEN 期望: MQTTOPEN: OK 发送: ATMQTTSUBdevice/001/status,0 期望: MQTTSUB: OK // 发布数据 发送: ATMQTTPUBdevice/001/data,{\temp\:23.5,\humi\:58.2},0,0 期望: MQTTPUB: OK这套流程看着不长但每一条指令背后都有坑。比如ATCSQ返回的信号强度是0到31之间的数值对应接收信号强度大约从-113dBm到-51dBm。别看到返回值不是0就觉得信号没问题信号值在10以下基本不建议部署因为稍微遇到天气变化或者干扰就会掉线。另外模块启动之后不能立刻发AT指令需要等几秒钟让模块完成内部初始化。我一般在模块供电后延时3秒再开始发送第一条AT指令然后通过轮询方式等待模块回复。如果发了几次都没收到OK就强制拉低PWRKEY引脚让模块复位重来。3.3 心跳机制与掉线重连长期在线的设备最怕的就是假在线——表面上TCP或者MQTT连接还在但实际上运营商已经把这个连接的资源回收了数据发不出去设备也不自知。解决这个问题靠的就是心跳机制。我采用的双层心跳策略第一层是MQTT协议层的keepalive我设置的周期是60秒也就是说每60秒模块和服务器之间至少要有一包心跳报文服务器超过180秒没收到心跳就判定设备掉线第二层是业务层的心跳虽然MQTT有keepalive但它有可能会被运营商侧的NAT超时打断所以我还在上报的空闲期内加了每5分钟一次的探活包格式是一个极小的JSON比如{id:dev001,type:ping}服务器收到之后回一个pong。如果连续3次探活都没有收到回复固件就判断网络链路已经断了做一次完整重连。重连流程不是简单重新打开Socket就行正确做法是先把模块的协议栈完全关掉用ATMQTTCLOSE关闭连接接着ATCEREG0注销网络注册再重新初始化让模块重新搜网附着。这个过程要花差不多20秒但换来的是干净的链路状态成功率远高于假装不断开直接重连。还有一个容易踩的坑不要在主循环里阻塞等待AT指令回复。正确做法是用串口中断加状态机把收AT指令回复当成异步事件处理。我见过很多新手写的是发一条AT指令就死循环等待串口数据一张卡住整个设备就卡死了连看门狗都救不回来。4. 云端平台与24小时数据追踪4.1 平台选型自建还是用物联网平台数据从设备端发出来总得有个地方接收、存储、展示、告警。平台选型上我这次直接用了现成的物联网平台没有自己搭服务器。原因很简单这种项目需要的不是定制化能力而是稳定性和开箱即用的配套功能——可视化图表、告警规则引擎、小程序/App端接入自己从头搭这一套至少要多花两周时间。目前主流的物联网平台像阿里云物联网平台、中国移动OneNET、EMQ的云版本都能直接对接MQTT协议设备。我这次用的是阿里云物联网平台注册产品、添加设备、拿三元组ProductKey、DeviceName、DeviceSecret就可以完成设备接入。平台自动生成设备的Topic比如/sys/{ProductKey}/{DeviceName}/thing/event/property/post设备端往这个Topic发一条JSON格式的属性上报消息平台解析后就会生成一条设备属性记录。不过要注意一点阿里云物联网平台的设备认证用的是三元组加签名算法设备和平台通信时不是简单的MQTT用户名密码而是用HmacSHA256对一堆参数做签名。这个签名算法在设备端实现起来不难网上有现成代码但如果用移远EC200S这类模块因为模块内部MQTT功能不支持自定义认证逻辑就要在主控固件里完成签名生成然后把签名结果填到MQTT连接参数里再发给模块。考虑到很多人的项目不想依赖某个特定云厂商也可以自己搭一个轻量服务器跑EMQX Broker加TDengine时序数据库再加一个Grafana做可视化。这套全开源组合的优点是可控性强、没有厂商锁定但缺点是要自己维护服务器和数据库对运维能力有要求。4.2 MQTT上云与数据格式设计设备端与云平台之间的通信协议我选的MQTT而不是HTTP。为什么不用HTTP因为HTTP是短连接每次传数据都要重新建立TCP连接握手开销大对于低功耗设备来说非常不划算而且HTTP是单向请求-响应模式服务器要想主动给设备下发指令比如远程修改上报周期实现起来就很别扭。MQTT虽然主题发布/订阅模式刚上手有点绕但一旦理解了它的逻辑后面做远程控制和状态下发都会非常顺手。数据格式我统一用JSON上报的报文长这样{ id: dev001, type: sensor_data, ts: 1692345600, temp: 23.5, humi: 58.2, bat: 3.85, signal: 22 }字段含义分别是设备ID、消息类型、Unix秒级时间戳、温度摄氏度、湿度百分比、电池电压伏、信号强度CSQ值。把信号强度和电池电压也上报上去不是为了给用户看而是为了运维排查——设备掉线或者数据异常的时候先查这两个字段能快速判断是没电了还是信号太差。Topic设计上我把数据流分成了三路data主题用来上报业务数据event主题用来上报设备上下线事件和异常事件cmd主题用来接收平台下发的控制指令比如临时修改上报周期。这套结构看起来有点冗余但对于日后的功能扩展很有帮助。4.3 告警规则与历史数据可视化24小时数据追踪最核心的价值体现在两个方面实时告警和历史曲线。告警规则我在平台规则引擎里配了两层。第一层是阈值告警比如温度超过30度、低于5度湿度超过80%就触发告警通知。通知方式建议先配电话和短信重要告警用电话语音一般告警用短信App内的消息推送作为补充。我实测下来电话语音的可靠性最高但容易打扰人所以只在温度越限时触发短信可以承担湿度、设备掉线这类次级告警。第二层是离线告警即设备连续N分钟没有上报数据就判定设备离线立即通知运维人员。这一层很容易被忽略但恰恰是最重要的。你想如果设备本身出了问题没数据上来阈值告警永远不会触发等所有人都意识到设备挂了的时候可能已经过了好几天中间的数据全丢了。所以离线告警的优先级比阈值告警还要高。历史数据可视化方面平台的网页端图表功能基本够用能直接画出温度湿度曲线支持按天、按周、按月聚合。如果客户要求做数据大屏展示可以再用平台的API接口把数据拉出来喂给大屏可视化工具。冷库项目里我就给客户配了一个简单的仓库温湿度面板一屏看到所有冷库的当前温度和最低/最高温度效果客户很满意。5. 现场部署与常见问题排查5.1 典型部署场景与安装要点项目真正落地的时候考验的不是代码能力而是对现场环境的理解和应对。我挑三个典型场景说一下安装要点。第一个是冷库。冷库内温度常年零下18度左右湿度高环境恶劣。这种场景下设备外壳必须密封防水否则内部会结露电路板时间久了就全是水珠。我建议使用IP65以上的防水盒接线口用防水接头传感器探头引到盒子外部用食品级不锈钢套管保护。另外冷库墙体带保温层如果设备内部天线位置不当信号会非常差我通常把天线延长出来贴在冷库外墙上实测信号强度能提升10个dB以上。第二个是档案库房。这类场景温度湿度都有严格要求温度14到24度湿度45%到60%但环境相对友好。安装时主要注意避开空调出风口、门窗缝隙和阳光直射点因为这些位置测出来的数据没有代表性。正确位置应该是在库房中间区域、离地1.2到1.5米高的墙面上这个高度基本能代表人员在库房内感受到的环境。第三个是机房。机房环境噪声大、设备发热高传感器别直接装在机柜顶部测出来温度会比实际环境高很多。建议装在机柜侧面或机房立柱上注意别被空调冷风直吹否则测出来又偏低。5.2 常见问题速查表项目从开发到部署我积累了不少坑。整理成一张速查表方便大家排查时对照问题现象可能原因排查思路设备不联网AT指令无响应模块供电不足或串口接线错误测量模块VCC电压是否在3.8V-4.2V确认串口TX/RX是否交叉连接能搜到网但注册失败SIM卡松动、欠费、卡未激活检查SIM卡是否插到位把卡放到手机里测试是否可用信号值很低CSQ小于10天线位置不佳、屏蔽严重延长天线位置靠近窗口或用外置吸盘天线数据上报延迟严重网络拥塞、上报频率过高检查上报周期适当降低频率确认不是短时间内大量数据排队MQTT频繁掉线心跳间隔太长或网络NAT超时把保活周期调到60秒以内业务探活周期调到5分钟温度数据漂移传感器被发热源影响检查传感器是否靠近4G模块4G发射时局部发热会导致读数偏高电池供电几天就没电PSM省电模式没生效确认无数据传输时模块进入PSM模式测量待机电流确认电流值5.3 实测校准与部署后的数据验证设备部署完不能直接撒手不管必须做一个校准验证环节。我的做法是拿一个经过计量校准的温湿度计和传感器放在同一个位置连续记录24小时然后把两边数据做对比。如果传感器读数和标准参考值的偏差在允许范围内就说明安装位置和传感器本身都没有问题。校准环节还有一个容易被忽视的问题传感器在通电初期会有一个自热现象尤其是4G模块发射数据时热量传导到传感器会导致温度读数短暂偏高。我的处理方式是通过软件补偿——在固件里实现一个简单的线性校正函数把4G发射前后的温度差值估算出来并扣除。我分享一下实测中的一组数据在14平米的档案库里SHT30传感器放在离地1.2米墙面4G天线磁吸在窗边实际记录的24小时温度曲线非常平稳波动幅度在0.5度以内湿度记录则与天气变化同步晚间与白天有大约4%RH的自然波动。信号强度在最差时段也能保持在CSQ 19以上全天数据上报成功率在99.7%以上其中丢失的零星数据也都通过本地缓存补传机制成功补上。这套方案做完之后客户说了一句让我印象很深的话以前靠人每天拿温度计去各库房转一圈现在手机打开就能看所有库房的数据曲线报表还能直接用作台账存档。我想这就是做这类物联网小项目最有成就感的时候——技术本身不复杂但解决了真实场景里一个实实在在的问题。如果你准备自己动手做一套我真心建议别在传感器上省那几块钱也别在4G模块供电上偷懒。把硬件底盘打稳后面的软件调试会省掉你大量时间。数据追踪这种东西最重要的永远不是指标多漂亮而是设备挂在墙上180天你还想得起它、信得过它。
