最近帮几个朋友捣鼓库房、花棚和冷链箱的温湿度监测项目发现一个很反直觉的事DHT11 这种传感器选型反而简单真正折磨人的是数据怎么传回来。同样一个温湿度传感器放到机房里、放到农业大棚里、放到运输途中、放到山区监测点联网方案会完全不同——有线、WiFi、蜂窝、LoRa 这四条路我都实际部署过各有各的优势也各有各的坑。这篇文章我就把这四种方案从原理、硬件选型、功耗、成本、实测体会到选型决策完完整整地对比一遍。不管你是在做单片机小项目、温室大棚监控还是想给仓库做温湿度记录只要还在纠结用哪种方式联网这篇应该能帮你省下不少试错时间。1. 先别急着买模块把需求场景拆透很多人犯的第一个错误是上来就问哪个方案最好。实际上没有最好的方案只有最合适的方案。在做任何技术选型之前先把三个问题想清楚至少能帮你排除掉一半的错误选项。1.1 你连的是一台设备还是一片区域这是最基础的问题。如果一个项目里只有三五台设备而且都在同一个房间那有线或者 WiFi 都很合适但如果你要监控的是分布在一个园区里的几十个点位每个点位之间隔了几百米那 WiFi 就需要多个 AP 覆盖布线和交换机成本也会上来这时候 LoRa 或蜂窝反而更有竞争力。我有个朋友做粮仓监测一开始他想当然地选了 WiFi结果每个仓房要单独配一个路由器还要保证穿墙信号。后来换成了 RS485 有线总线一条双绞线串起十几个仓房省了一大堆网络设备。这就是典型的集中区域和分散区域的区别。1.2 供电条件是第一道分水岭这个问题经常被新手忽略但它几乎直接决定了联网方案的选择。如果你的传感器旁边就有 220V 插座那有线、WiFi、蜂窝随便选功耗不是核心矛盾。如果只能用电池供电而且要求设备跑一年以上那 WiFi 基本可以直接出局LoRa 或者 NB-IoT 才是正路。我做过一个冷库温度记录仪项目用两节 18650 电池供电每个小时上报一次温度。最初用 ESP8266 模块结果电池一个月就耗光了。后来换成了 LoRa 模块同样的电池跑了大半年还有电。这不是什么高深技术纯粹是功耗层面的物理差异。1.3 你要的到底是实时还是够用还有一个关键维度是数据时效性。冷链运输的温度报警要求延误不能超过几分钟否则食品就可能变质但粮仓里的温湿度半小时上报一次完全够用。这个需求差异会直接影响方案选择数据频率推荐方案秒级实时报警有线 / WiFi / 蜂窝分钟级定期上报WiFi / LoRa / NB-IoT小时级低频采集LoRa / NB-IoT远程跨地域移动蜂窝另外温湿度数据本身就是几十字节的小包完全用不到高带宽。很多人担心 LoRa 速率太低其实对温湿度传感器来说LoRa 的速率绰绰有余。2. 有线方案最老、最稳、但部署成本容易被低估很多人一想到温湿度传感器就默认是无线方案反而把有线这个最可靠的方案给忽略了。实际上在工厂、机房、仓库这些固定场所有线方案依然是最推荐的选择。2.1 RS485 总线 Modbus一条双绞线串起几十个节点RS485 是工业现场最经典的通信总线它使用差分信号传输A、B 两根线抗干扰能力远超普通串口。为什么要用 RS485 而不是直接用 TTL 串口因为 TTL 电平的传输距离通常只有几米而 RS485 在 9600 波特率下能轻松跑到 1200 米而且支持多点拓扑一条总线上可以挂几十个设备。具体的硬件组合我推荐这样主控STM32F103 或者任何带 UART 的单片机收发器MAX485 或 SP3485 芯片传感器端直接购买带 RS485 输出的温湿度探头内部已经集成了传感器和收发电路通信协议Modbus RTU主站轮询各从站地址接线时有几个常年踩坑的点我单独列出来A/B 线千万不要接反接反了通信大概率不通总线两端要加 120Ω 终端电阻特别是距离长、节点多的时候屏蔽层单端接地不要两端都接地否则容易形成地环路。波特率我建议选 9600 或 19200稳定可靠没必要追求高速。传感器端的选择如果预算实在紧张可以用 DHT11 自己改造但我实际用下来DHT11 的精度只有 ±2℃ 和 ±5%RH响应也很慢做工业记录不太合适。我更多使用 SHT30 或 BME280 这类数字传感器再通过一个 RS485 转 TTL 模块接到总线上整体成本也就几十块钱。2.2 以太网方案机房场景的稳妥选择如果你的现场本来就铺设了网线那直接用 RJ45 以太网是最省事的。一个温湿度探头带网口插上交换机内网随便访问甚至还能分配一个固定 IP 做 Web 页面显示数据。以太网方案的优点非常明显带宽极大哪怕同时传几十个传感器的数据都毫无压力稳定性好只要网线、交换机不坏链路就不会断可以实现 PoE 供电一根网线同时解决数据和电源但缺点也同样明显如果现场没有现成的网线重新布线的成本会非常高。我之前给一个旧厂房做监测现场根本没有网络布线从交换机拉网线到各个点位穿管、开槽、恢复墙面成本比传感器本身贵了好几倍。所以我的建议是己有网络基础设施的选以太网什么都没有的选 RS485 或者无线。2.3 有线方案实测体会与避坑在有线方案上我踩过的坑主要集中在这几点干扰问题。工厂环境里变频器、电机、大功率设备启动时会对 RS485 通信产生明显干扰。解决方法是使用屏蔽双绞线并且屏蔽层单端接地。我遇到过一次严重丢包的情况排查了好几天最后发现是双绞线走线时和动力电缆平行了太长距离重新分开走线后问题消失。距离与节点数。虽然理论上 1200 米没问题但实际中如果节点超过 32 个接收器负载会增大建议加中继器或者分总线。另外总线分支不要太长最好采用手拉手菊花链结构而不是星形结构。防雷与浪涌。如果室外走线比较长到雷雨季节很容易感应浪涌电压损坏收发器。建议选用带 TVS 管的 RS485 收发器或者在总线上加防雷器成本不高但能省很多维修麻烦。3. WiFi 方案上手最快但功耗和稳定性是两道坎WiFi 应该是做 DIY 项目时最常用的方案没有之一。ESP8266 模块几块钱一个写代码的生态也非常完善。但作为温湿度传感器的联网方案WiFi 有两个绕不开的问题。3.1 主流硬件组合与传感器选择WiFi 方案的硬件组合非常成熟主流是主控 WiFiESP8266 或 ESP32传感器DHT11 / DHT22 / SHT30 / BME280传输协议MQTT / HTTPESP8266 的优势是便宜、生态好Arduino、MicroPython、ESPHome 都支持写起来非常顺手。ESP32 比 ESP8266 贵一点但性能更强自带蓝牙ADC 也更准确适合后续要扩展的项目。传感器方面网上最多的教程是用 DHT11因为它便宜接线也只要一根数据线。但我要说实话DHT11 的测量精度和长期稳定性都不太行尤其是湿度时间长了容易漂移。如果你做的是需要记录数据、做分析的项目我建议至少用 DHT22AM2302或者 SHT30。BME280 更好但注意它测的是气压而不只是温湿度代码里要忽略气压字段。3.2 功耗问题为什么 WiFi 不适合电池供电WiFi 模块的工作电流一般在 70-100mA 左右连接路由器时还会有瞬时尖峰。即便你让它大部分时间休眠只要它一醒来去连接 WiFi那几秒钟的高电流就会消耗大量电量。我们来算一笔账假设你用 2000mAh 锂电池供电ESP8266 每 10 分钟唤醒一次每次花 3 秒完成连接和上报平均电流大约是 0.4mA 左右。听起来不大对不对但实际上 WiFi 连接时间往往不止 3 秒如果路由器信号不好、DHCP 获取 IP 慢、或者 MQTT 服务器响应慢一次唤醒可能要 5-10 秒。再加上锂电自放电2000mAh 实际能撑半年就不错了。如果一定要用 WiFi 做电池供电可以采取这些策略每次上报后立即进入 deep sleep关闭 WiFi 后通过定时器唤醒而不是保持连接尽量靠近路由器缩短连接时间用 ESP32 的 ULP 协处理器实现更细粒度的功耗控制但我个人强烈建议WiFi 方案只用插座供电别跟电池较劲。同一个项目想用电池供电直接去看 LoRa 或者 NB-IoT省得后期因为耗电问题推翻重来。3.3 稳定性掉线、重连、看门狗一个都不能少WiFi 方案最大的痛点是稳定性。我做过一个办公室温湿度监测项目10 个 ESP8266 节点刚开始跑得很开心但后来发现几个节点会时不时掉线有的甚至一周掉好几次。排查一圈后问题集中在几个地方路由器连接数限制。很多家用路由器能同时连接的设备数量有限设备一多就会踢掉老设备。解决办法是换企业级 AP或者减少节点数量。DHCP 租期问题。节点长期离线再上线可能获取不到 IP。我在代码里直接给每个节点配置静态 IP避免依赖 DHCP。信号弱导致的重连失败。ESP8266 在信号弱的情况下会反复尝试连接每次尝试耗电又耗时。我在固件里加了信号强度判断低于某个阈值就延长重试间隔避免陷入死循环。还有一个必须做的保障硬件看门狗或软件看门狗。WiFi 模块跑久了难免出现死机。用软件定时器喂狗一旦程序卡死就自动重启能避免悄悄死掉的情况。传输层我建议用 MQTT配合一个本地或者云端的 Broker。为什么不用 HTTP因为 MQTT 是长连接服务器能随时知道节点是否在线节点上报数据也快。HTTP 每次都要重建连接开销更好功耗更高。温湿度传感器这种小数据量应用MQTT 是更合适的选择。3.4 WiFi 安全与日常使用注意WiFi 方案连接的是你家或公司的无线网络安全问题也不能忽略。几个基本建议不要使用弱密码、尽量用 WPA2/WPA3 加密、不要随意开放网络。至于隐藏 SSID 和 MAC 白名单能提高一些安全性但会给初次配置带来麻烦对大多数项目来说没必要。设置一个好记又安全的密码足够解决问题。4. 蜂窝方案无死角覆盖但钱和电都要花当你需要在没有有线、也没有 WiFi 覆盖的地方采集温湿度比如野外环境监测点冷链运输车偏远库房临时工地蜂窝方案就是最简单粗暴的选择——只要能打得通电话数据就能传回来。但蜂窝方案的两个代价流量费和功耗必须认真对待。4.1 4G Cat.1、NB-IoT 与 Cat-M到底选哪个很多人以为蜂窝就是 4G 手机模块其实在物联网领域蜂窝方案也是分派的。我实际用过下面几种4G Cat.1。全称是 LTE Cat.1速率理论值能到 5-10Mbps 下行2-5Mbps 上行时延较低。它的优势是兼容性好全国几乎都有 4G 覆盖而且因为速率不算太高功耗比普通手机 4G 模块低一些。常见模块有 EC200S、Air724UG 等。适合需要实时数据、可能偶尔传张图表的应用。NB-IoT。窄带物联网专门为低功耗、低频次、小数据量的设备设计。速率只有几十 kbps但穿透能力很强地下车库、地下室也能收到信号。它的功耗非常低支持 PSM省电模式和 eDRX可以做到几年不换电池。常见模块有 BC26、BC35-G。Cat-M。介于 Cat.1 和 NB-IoT 之间但国内实际部署不多一般主要是海外运营商在推。做国内项目基本不用考虑。我的选型经验是需求选择实时性要求高、可能传图片Cat.1低频小数据、电池供电、需要深度覆盖NB-IoT移动场景、高速设备Cat.1温湿度传感器这种场景大部分情况下 NB-IoT 更合适前提是你的项目地区 NB-IoT 网络覆盖到位。如果覆盖不行就老老实实上 Cat.1。4.2 数据量、资费与信号覆盖很多人担心蜂窝方案流量费很贵我实际算了一下温湿度上报的流量小到你完全不用担心假设每 10 分钟上报一次一次数据包按 100 字节算包含协议头部、时间戳、温湿度一天 144 次一个月大约 432KB不到 1MB。哪怕加上 MQTT 保活的心跳包一个月也就在 2MB 以内。运营商的物联网卡套餐一年几块钱到几十块钱基本都能覆盖这个量级。不过物联网卡本身需要注意几点开通和管理通常比普通手机卡繁琐一些需要预留开通时间要注意续费周期欠费停机后重新激活比较麻烦对设备量大的项目建议做一张台账记录每张卡的号码、到期时间、对应设备信号覆盖方面我一直坚持以实测为准。NB-IoT 理论覆盖深度好但这几年建网情况各地区差异很大。我之前在沿海某市做过测试市区 NB-IoT 信号满格但偏一点的老厂房地下室里完全没信号。所以不要只看标称最好先拿开发板到实际点位跑一圈再说。4.3 蜂窝方案的功耗策略蜂窝模块的功耗大头在射频发射。Cat.1 模块在发射信号时瞬间电流可能冲到 300-500mA虽然持续时间短但对电池的压力很大。NB-IoT 在弱网环境下会反复重传功耗也会飙升。几个降低功耗的常用手段尽量保持模块已经附着网络不要频繁开关机。频繁重新附着网络比保持在线更耗电用 PSM 或 eDRX 模式让模块在不发送数据时进入省电状态上报频率能低就低比如一小时一次而不是一分钟一次电源设计上用大容量电池 DCDC 稳压避免射频瞬间拉低电压导致重启蜂窝方案还有一个容易被忽略的问题如果要放到偏远地区一定要测试不同运营商的实际信号。我之前在某山区遇到过移动信号满格、电信完全没有的情况选错运营商会让设备直接变砖。同型号模块三家运营商的物联网卡都测一遍再决定用哪家。5. LoRa 方案低功耗远距离的王牌但组网是真正的门槛LoRa 是最近几年物联网圈最常被提起的技术之一。但很多人的理解是LoRa传得远这个理解只对了一半。LoRa 真正的优势是极远的传输距离 极低的功耗 免费的频段。但它也有明显的边界条件。5.1 LoRa 到底是怎么实现传得远的LoRa 本质上是一种调制技术全称是 Long Range它使用了一种叫做线性调频扩频的方式把信号在很宽的频带上展开接收端通过相关运算把它解调出来。通俗讲它不是靠喊得更大声来传得远而是靠在大噪音里分辨出一个微弱但特征明显的信号来传得远。这就解释了为什么 LoRa 能在发送功率只有 17dBm 左右的时候实现几公里的传输距离。LoRa 的接收灵敏度可以做到 -137dBm 甚至更高这个数值比 WiFi 要低得多意味着它能听到更微弱的声音。实际中我们会调节几个参数扩频因子SFSF7 到 SF12数值越大灵敏度越高、传输越远但速率越低带宽BW125kHz 到 500kHz带宽越宽速率越高但灵敏度会下降编码率CR冗余越高抗干扰越强有效速率越低我常用的组合是 SF12、125kHz 带宽这样能把距离拉到最远代价是速率只有几百 bps。对温湿度传感器这种几十字节的数据包这个速率完全够用。5.2 实测距离别被几十公里的宣传骗了LoRa 的宣传资料里经常写最远几十公里但那是在海面、沙漠等完全开阔且没有遮挡的环境下测出来的。我实际测试的城市和郊区结果如下环境发射端接收端实测距离郊外开阔田地1W 模块网关4.2km城区街道1W 模块楼顶网关1.3km室内跨楼层17dBm 模块楼上网关3 层楼稳定地下车库17dBm 模块地面网关约 200m这些数据仅供参考因为天线高度对 LoRa 的影响非常巨大。把天线从 1 米升到 10 米传输距离可能直接翻好几倍。如果你的网关在楼顶节点在楼下那效果会比两个天线都放在地面上好得多。几个实际经验天线位置比发射功率更重要。天线架高、避开金属遮挡比调大功率有效得多天线馈线越短越好。馈线本身有损耗长了等于白烧功率别把 LoRa 模块贴在金属表面上天线会被严重失配造成驻波比过高距离骤降5.3 自组网还是用 LoRaWAN 网关LoRa 的一个坑在于搞定了点对点通信之后你还需要考虑多节点怎么组网。这个环节有两种路线路线一自组网点对点 / 星型买一对 LoRa 模块比如 SX1278、SX1262 为核心的模块一个做发送端一个做接收端通过 UART 透传。如果只有一个或几个节点主站轮询或者节点定时上报这就够了。代码层面很简单很多模块直接发 AT 指令就行。但自组网的问题也很明显没有链路层协议节点多了之后碰撞、重传、补报都要自己处理。我的经验是如果节点数量在十几二十个以内且上报频率不高自组网完全可行但如果你搞不清楚 ARP 和冲突处理或者节点数量多还是走正规协议更省心。路线二LoRaWANLoRaWAN 是一个完整的 MAC 层协议定义了节点、网关、网络服务器之间的关系。节点只发送给网关网关通过网络回传数据给服务器服务器做认证和数据处理。LoRaWAN 的好处是支持大量的节点网络容量大自带的加密、入网激活流程支持 ADR自适应数据速率自动调节节点的速率和功率达到省电和远距离的平衡代价是你要部署网关。商业网关价格从几百到几千不等比如 RAK 系列、八信道的 SX1302 网关。你也可以用树莓派 LoRaWAN 网卡自己搭一个但稳定性要自己维护。我的建议是如果只是玩一玩、传感器不超过十个自组网透传就行如果要做正经项目、节点多、要求稳定直接上 LoRaWAN别在自组网上浪费时间。5.4 LoRa 的边界速率、频段和响应时延最后说一下 LoRa 的几个硬边界。速率低。哪怕最高速率LoRa 也就几十 kbps传不了图片、音频更不可能实时传输视频。如果你需要远程抓拍几张现场照片LoRa 做不到那是蜂窝方案的活。频段管理。LoRa 用的是免授权频段但各国对免授权频段都有相应的管理要求包括发射功率上限和占空比限制。国内常用的是 470MHz 到 510MHz 这一段的免授权频段但实际部署前建议根据当地允许的频段和功率来配置别盲目调大功率否则不仅违规还可能干扰到别人的设备。实时性。LoRa 的一次数据包传输需要数百毫秒到数秒取决于扩频因子和包长。如果是冷链报警这类需要秒级响应的LoRa 也能做到但必须把周期设计好不要真的把占空比跑满。它适合定期上报和当日报警这两种模式不适合持续高速交互。6. 四种方案横向对比与选型建议前面四章分别讲透了四种方案的原理和实测体会这一章我把它们放到一张表里做最终横评。这张表是我在多个项目中反复验证后总结出来的可以作为你选型时的第一参考。6.1 核心参数对照维度有线 RS485WiFi蜂窝 Cat.1 / NB-IoTLoRa典型传输距离1200m30-80m基站覆盖范围内无限1-10km 空旷传输速率9.6k-115.2kbps几十 Mbps几十 kbps 到几 Mbps0.3-50kbps待机功耗极低较高deep sleep 可降到 uA 级NB-IoT 极低Cat.1 中等极低uA 级发射功耗外供电源约 80-200mA几百 mA 脉冲20-100mA供电要求必须有电源推荐插座供电可电池NB-IoT 可多年电池可跑数年部署成本布线成本高很低模块 流量费网关成本高运维难度低稳定中需处理掉线低但注意卡管理中需管理网关典型场景工厂/机房/固定点位室内 WiFi 覆盖区域偏远点/移动/冷链农业/园区/多节点典型硬件STM32 MAX485ESP8266/ESP32EC200S / BC26SX1278、SX1262从表里可以看出一条很明显的脉络网络基础设施越是现成的部署越便宜越是要自己搭建覆盖成本越高。WiFi 最便宜是因为路由器到处都是蜂窝最省心是因为基站运营商已经建好了LoRa 最贵是因为网关得你自己买、自己架。6.2 我的选型决策清单到这里我可以给出一份可直接套用的决策流程。拿到一个温湿度监测项目按这个顺序问自己现场有没有 220V 电源有有线或者 WiFi 都可以继续看现场有没有网线/网络覆盖没有只能电池直接跳到 LoRa 或 NB-IoT别碰 WiFi现场有没有现成的网络基础设施有网线以太网方案优先稳定省心有 WiFi 覆盖WiFi 方案部署最快什么都没有LoRa 或蜂窝二选一节点分布是集中还是分散集中在几百米内RS485 或 LoRa成本可控跨地域分散蜂窝信号无处不在数据上报频率和实时性要求秒级实时报警有线、WiFi、蜂窝分钟级定期上报LoRa、NB-IoT长期运维的耐心程度希望设备上线后基本忘掉它有线最省心其次是蜂窝愿意偶尔维护网关LoRa 也可以6.3 无论走哪条链路这几点都通用最后分享几个跨方案通用的经验不管你最终选了哪种联网方式都用得上数据格式最好统一。我在多个项目里坚持用统一的 JSON 格式上报设备 ID、时间戳、温度、湿度、电池电压、信号强度RSSI。这样即使以后从 WiFi 方案迁到 LoRa 方案服务端的解析逻辑几乎不用改。信号强度必须上报。温湿度是业务数据信号强度才是健康数据。有了 RSSI 日志排查故障时能直观看到哪些设备处于信号边缘。服务端做离线判断。不要指望传感器端永远在线服务端要根据心跳和上报时间判断设备是否失联超时没上报就告警。这个逻辑不管走 WiFi 还是 LoRa 都成立。就我个人这些年做温湿度监测项目的体会最常犯的错就是把我能跑通 Demo等同于我能稳定运行一年。Demo 阶段跑通 WiFi 传输非常容易但一旦放到现场电源问题、信号问题、网络问题全都会冒出来。所以选型时宁可多花点时间做现场测试也别等全部设备部署完再回头改方案——我在 LoRa 项目里吃过这个亏前期省下的选型时间后期全在维护上还了回来。