去年帮朋友做冷库监测的时候，客户提了个需求：库房在郊区，没有WiFi覆盖，距离办公室一百多米，但要求24小时盯着温湿度，温度一超限就得马上知道。当时我想过拉网线、想过LoRa，最后定下来的方案就是室内4G温湿度传感器——每个库房放一个，通过4G网络直接把数据推上云平台，手机端随时看。这个方案最核心的价值就一句话：不需要现场有任何网络基础设施，只要有4G信号覆盖，设备通电就能用，数据直接进云端，24小时不断线。
这篇文章就把整个项目的设计思路、硬件选型、固件实现、云端对接和现场排查一次性讲透。不管你是想做一个冷库监控、机房温湿度记录、档案室环境监测，还是单纯想把手里的DHT11、SHT30传感器接上4G模块实现远程数据追踪，这套方案都能直接照着抄。基础部分我会讲得比较细，有经验的可以直接跳到通信链路和问题排查章节。
1. 方案选型：为什么是"4G温湿度传感器"而不是WiFi或LoRa
1.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指令，简单说就是你通过串口给模块发文本指令，模块干完活给你回一个结果。比如发AT+CGATT?查询模块是否附着上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才算正常 发送: AT+CPIN? 期望: +CPIN: READY // 查询信号强度，数值越大越好，一般大于15可以正常通信 发送: AT+CSQ 期望: +CSQ: 22,0 // 查询是否注册上4G网络 发送: AT+CGATT? 期望: +CGATT: 1 // 查询当前网络类型，确认是LTE而不是回落到了2G/3G 发送: AT+PSRAT? 期望: +PSRAT: 7 // 7代表LTE // 如果是MQTT方式，直接用模块内置的MQTT指令 发送: AT+MQTTCFG="tcp://你的域名或IP:1883",6000 期望: OK 发送: AT+MQTTOPEN 期望: +MQTTOPEN: OK 发送: AT+MQTTSUB="device/001/status",0 期望: +MQTTSUB: OK // 发布数据 发送: AT+MQTTPUB="device/001/data","{\"temp\":23.5,\"humi\":58.2}",0,0 期望: +MQTTPUB: OK这套流程看着不长，但每一条指令背后都有坑。比如AT+CSQ返回的信号强度是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就行，正确做法是先把模块的协议栈完全关掉，用AT+MQTTCLOSE关闭连接，接着AT+CEREG=0注销网络注册，再重新初始化，让模块重新搜网附着。这个过程要花差不多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天，你还想得起它、信得过它。
