智能温室环境监测系统实战：从传感器选型到数据上云完整指南

前些日子帮一位做草莓大棚的朋友改造环境监测方案，他原来的做法是每天早上进棚转一圈，摸摸土、看看温度计、凭经验决定要不要开风机。赶上倒春寒那几天，凌晨降温没及时发现，一棚花果受了影响，损失大几千。回来之后我就把之前一直在用的那套智能温室环境监测系统重新整理了一遍，从传感器布点到数据上云，再到联动控制，全部跑通之后，整体成本压到了千元以内，稳定运行了好几个生长季。

这篇文章把这套系统的设计思路、硬件选型、代码实现和部署踩坑完整记录下来。无论你是搞设施农业的种植户，还是物联网方向的开发者，或者是农业相关专业的学生，只要手头有块开发板、几个传感器，照着这篇文章的思路，完全可以搭出一套属于自己的温室环境监测系统。

1. 系统整体设计与架构拆解

1.1 温室种植的核心矛盾：环境不可见

温室大棚的本质，是人为给作物创造一个相对可控的生长环境。但“可控”的前提是“可知”——你得先知道棚里到底发生了什么。温度、湿度、光照、二氧化碳浓度、土壤水分，这五个参数直接决定了作物的光合作用效率、蒸腾速率、根系呼吸和病虫害发生概率。

举个例子，番茄在开花坐果期，白天最适宜的温度是25到28摄氏度，夜间是15到18摄氏度，超过30度或者低于12度都会导致落花落果。棚内空气湿度如果长期高于85%，灰霉病和晚疫病的爆发风险会成倍上升。问题是，一个标准大棚动辄几百上千平方米，不同位置的环境参数差异极大——靠近风口的地方和棚中央的温度能差出四五度，光照更是受遮阴、棚膜老化的影响呈现出明显的不均匀分布。

人工巡检的最大问题在于采样频次太低和覆盖范围太有限。你不可能半夜每半小时起来看一次温度，也不可能在大棚的每个角落都挂一支温度计。环境变化是一个连续过程，而人工巡检是离散的点状采样，这中间的信息断层，就是各种种植事故的根源。

1.2 系统架构分层：感知、传输、平台、应用

这套智能温室环境监测系统采用经典的四层物联网架构，从下往上分别是感知层、传输层、平台层和应用层。

感知层由各种环境传感器组成，负责把温度、湿度、光照、CO2浓度、土壤水分等物理量转换成电信号。传输层负责把传感器采集到的数据可靠地送到上层平台，这里涉及到无线通信协议的选择。平台层承担数据存储、处理、告警规则匹配等功能，是系统的“大脑”。应用层是用户与系统交互的界面，可以是手机App、网页看板，也可以是微信告警推送。

用生活化的方式来理解：传感器是人的五官，负责感知环境；网络是神经，负责传递信号；服务器是大脑，负责分析决策；而手机上的可视化面板是人的手脚和嘴巴，负责执行操作和反馈信息。每一层都有自己独立的任务，层与层之间通过标准化的接口通信，这样任何一层替换升级，都不会影响其他层的正常工作。

1.3 技术选型的逻辑：为什么不是性能最强，而是最合适

在技术选型上，我见过很多一上来就追求“高大上”的方案：用工业级PLC做控制器，用光纤布网，用商业化的农业物联网平台。不是说这些方案不好，而是在“智能温室环境监测”这个场景下，它们存在明显的性价比问题。

综合考虑部署成本、维护难度和实际需求，我最终选择了这样一套组合：ESP32开发板做核心控制器，搭配DHT22温湿度传感器、BH1750光照传感器、电容式土壤湿度传感器和MH-Z19B二氧化碳传感器，通信走WiFi加MQTT协议，数据接入本地部署的轻量化服务，可视化通过Grafana实现。

这个选择背后的逻辑有三条：第一，ESP32自带WiFi和蓝牙，单片就能完成数据采集和网络上传，不需要额外搭配通信模块，硬件成本大幅降低；第二，MQTT是物联网领域的事实标准协议，轻量、可靠、生态成熟，后续接入Home Assistant、Node-RED等平台非常方便；第三，传感器选了民用级里口碑比较稳的几款，精度虽然比不上工业级的Sensor，但对于温室环境监测这个应用场景来说绰绰有余，价格却只有工业级的十分之一。

2. 硬件选型与传感器部署细节

2.1 核心硬件清单与关键参数

整套系统的硬件清单如下表所示：

合计单节点成本大约在220元左右。对于一栋标准大棚（8米宽乘50米长），我建议布置3个采集节点——东西两端各一个，中间一个，这样基本能覆盖棚内不同区域的环境差异。三个节点的总硬件成本控制在700元以内，相比动辄上万的商业农业物联网方案，这个投入对于中小种植户来说是比较容易接受的。

2.2 传感器部署位置与数量规划

传感器部署的位置直接决定了采集数据的参考价值，这一步是最容易被忽视的。

先说温湿度传感器。很多人在部署时图省事，把传感器直接挂在棚膜下面或者靠近门口的位置，测出来的数据会存在严重偏差。正确的做法是：将传感器放置在作物冠层上方20到30厘米处，这个位置是作物实际生长区域的平均环境高度。同时要注意避免阳光直射传感器，否则测出来的温度会明显高于真实环境温度——建议用一个透气但遮光的白色PVC管或者百叶窗结构把传感器罩起来，既保证空气流通，又隔绝辐射热。

光照传感器的部署更讲究。温室内的光照分布极不均匀，靠近棚膜的位置光照强度可能超过五万勒克斯，而作物冠层下方的光照可能只有几千勒克斯。对于监测系统来说，关注的重点是作物冠层接受到的光照，所以BH1750应该安装在冠层上方约30厘米处，感光面保持水平朝上。布点时尽量避开棚架阴影区域，否则采集到的光照数据会出现周期性的大幅波动。

土壤湿度传感器要插在根系密集区域，通常在滴灌带正下方10到15厘米的位置。这里有个小技巧：传感器的探针插入方向应该与滴灌的水流方向平行，这样可以更准确地感知水分在土壤中的横向扩散情况。另外，土壤湿度传感器不要紧挨着滴灌滴头，否则浇水瞬间读数会直接拉满，失去监测意义。

CO2传感器因为体积稍大，一般固定在棚内立柱上，高度在1.5米左右，与作物冠层持平，同时要远离通风口和人员频繁走动的过道，这两处位置的CO2浓度波动太剧烈，不能代表棚内的平均水平。

2.3 供电与布线的工程经验

供电是整个系统稳定运行的基础，这里踩过不少坑，分享几个关键经验。

ESP32的工作电压是3.3V，DHT22和BH1750可以共用3.3V电源，而MH-Z19B需要5V供电，继电器模块建议用独立5V供电以避免电磁干扰影响传感器读数。如果只用USB口给ESP32供电，遇到继电器吸合的瞬间，电压跌落会导致系统重启，所以务必采用12V开关电源加DC-DC降压模块的方案，各级供电互不干扰。

接线方面，所有传感器信号线建议使用屏蔽双绞线，屏蔽层单端接地。尤其是在大棚这种环境里，风机、卷帘电机启动时的电磁干扰非常严重，会导致传感器读数跳变甚至通信失败。信号线走线时要与动力线（220V供电线路）保持至少30厘米的距离，必须交叉时采用垂直交叉而不是平行走线。

所有接线端子都要用防水型接线端子或者热缩管做好绝缘处理。大棚内部湿度长期较高，早晚还会形成冷凝水，普通裸端子铜线裸露的情况下，最快几个星期就会氧化发黑，导致接触不良。整机装进IP65防水盒后，在盒子底部开一个小孔用于穿线，穿线处用防水接头或电子密封胶封堵，防止潮气渗入盒内凝结。这个细节如果处理不好，第一个雨季就会付出代价。

3. 固件开发与数据链路搭建

3.1 MQTT协议与主题设计

数据传输层选择MQTT协议，核心原因是它的发布/订阅模式非常适合传感器数据上报的场景。设备端只需要把数据发布到指定的主题（Topic），平台端对该主题进行订阅，就能实时收到数据。与HTTP协议相比，MQTT的报文开销非常小，一个数据包只有几个字节的额外开销，这对于长时间运行的嵌入式设备来说意味着更低的功耗和更稳定的连接。

在温室监测场景中，MQTT主题的设计要兼顾可扩展性和语义清晰。我采用的是按“场所/设备/数据类型”三层结构来组织：

greenhouse/shed1/node01/temperature greenhouse/shed1/node01/humidity greenhouse/shed1/node01/light greenhouse/shed1/node01/co2 greenhouse/shed1/node01/soil_moisture

使用MQTT Broker的保留消息（Retained Message）功能，把每个传感器的最新值保存在Broker上，这样新接入的设备或者重启后的看板可以立即获取到当前值，而不需要等待下一个采集周期。

为了减少网络请求次数，实际项目中我没有为每个参数单独发一条消息，而是把同一采集节点的所有数据打包成一个JSON对象，一次性发布出去。消息体大致长这样：

{ "node": "node01", "ts": 1712000000, "temp": 26.5, "hum": 68.2, "light": 32000, "co2": 650, "soil": 42 }

时间戳字段非常重要，因为是异步消息队列，消息到达平台的时间并不严格等于数据采集时间。带上采集时间戳，后续做数据分析时才能准确还原环境变化过程。

3.2 ESP32固件核心逻辑解析

固件开发我用的Arduino框架，不搞复杂的RTOS，逻辑清晰、稳定可靠是第一位的。核心流程就是一个无限循环：读取传感器数据、封装成JSON、发布到MQTT、然后休眠一段时间。

先看完整的代码框架：

#include <WiFi.h> #include <PubSubClient.h> #include <DHT.h> #include <Wire.h> #include <BH1750.h> #include <ArduinoJson.h> #include "MHZ19.h" // 引脚定义 #define DHTPIN 4 #define SOIL_PIN 34 #define RELAY_FAN 25 #define RELAY_PUMP 26 // WiFi配置 const char* ssid = "YOUR_SSID"; const char* password = "YOUR_PASSWORD"; // MQTT配置 const char* mqtt_server = "192.168.1.100"; const int mqtt_port = 1883; const char* mqtt_user = "greenhouse"; const char* mqtt_pass = "your_password"; DHT dht(DHTPIN, DHT22); BH1750 lightMeter; MHZ19 myMHZ19; HardwareSerial co2Serial(2); WiFiClient espClient; PubSubClient mqttClient(espClient); // 发布数据函数 void publishSensorData() { float temp = dht.readTemperature(); float hum = dht.readHumidity(); uint16_t lux = lightMeter.readLightLevel(); int co2 = myMHZ19.getCO2(); int soilRaw = analogRead(SOIL_PIN); int soilPercent = map(soilRaw, 1800, 3200, 0, 100); soilPercent = constrain(soilPercent, 0, 100); StaticJsonDocument<256> doc; doc["node"] = "node01"; doc["ts"] = time(nullptr); doc["temp"] = temp; doc["hum"] = hum; doc["light"] = lux; doc["co2"] = co2; doc["soil"] = soilPercent; char buffer[256]; serializeJson(doc, buffer); mqttClient.publish("greenhouse/shed1/node01/sensors", buffer, true); // 联动控制逻辑 if (temp > 30.0) { digitalWrite(RELAY_FAN, HIGH); } else if (temp < 27.0) { digitalWrite(RELAY_FAN, LOW); } } void reconnectMQTT() { while (!mqttClient.connected()) { if (mqttClient.connect("esp32-node01", mqtt_user, mqtt_pass)) { mqttClient.subscribe("greenhouse/shed1/node01/command"); } else { delay(5000); } } } void setup() { Serial.begin(115200); dht.begin(); Wire.begin(); lightMeter.begin(); co2Serial.begin(9600, SERIAL_8N1, 16, 17); myMHZ19.begin(co2Serial); myMHZ19.autoCalibration(false); pinMode(RELAY_FAN, OUTPUT); pinMode(RELAY_PUMP, OUTPUT); WiFi.begin(ssid, password); while (WiFi.status() != WL_CONNECTED) { delay(500); } mqttClient.setServer(mqtt_server, mqtt_port); mqttClient.setCallback(mqttCallback); configTime(8 * 3600, 0, "ntp.aliyun.com"); } void loop() { if (!mqttClient.connected()) { reconnectMQTT(); } mqttClient.loop(); publishSensorData(); delay(30000); // 每30秒采集一次 }

这里面有几个关键的工程细节需要展开说明。

DHT22温湿度传感器的读取频率不能太高，它的数据更新周期最慢达到2秒，所以采样间隔至少要留出2秒以上的余量。我把采集周期设为30秒一次，这个频率对于温室环境监测来说已经非常充足了——温室环境的惯性很大，温度通常要几分钟到十几分钟才会出现显著的梯度变化，30秒的采样间隔足以捕捉到所有的环境波动。

土壤湿度传感器的模拟量映射需要单独校准。map(soilRaw, 1800, 3200, 0, 100)这个映射关系是我在目标土壤中实测得到的。具体的做法是：把传感器插入干燥的土中，记录ADC读数为3200；然后慢慢加水到土壤接近饱和状态，读取干燥后的ADC数据约为1800。不同质地的土壤校准结果差异很大，沙土和黏土的电解质含量不同，会导致同样的含水量对应不同的AD值。因此更换大棚或者更换土壤类型后，务必重新做一次两点校准。

MH-Z19B的自动校准功能建议关闭。很多CO2传感器的自动校准逻辑是假设传感器会定期暴露在新鲜空气中（400ppm基准），但温室环境里因为植物呼吸和有机物分解，CO2浓度长期处于500到800ppm甚至更高，自动校准会把传感器读数带到错误的方向。正确做法是在传感器安装前，在室外通风良好的地方通电运行30分钟以上，然后开启一次手动校准，之后再关闭自动校准功能。

3.3 数据存储与可视化面板搭建

数据到平台之后的处理，我选择了轻量组合：Eclipse Mosquitto做MQTT Broker，Node-RED做数据流处理，InfluxDB做时序数据库，Grafana做可视化面板。这套组合全部是开源软件，部署在一台树莓派4或者旧笔记本上就能跑得很顺畅。

数据流的路径是：ESP32采集数据后发布到Mosquitto，Node-RED通过MQTT输入节点订阅该主题，收到数据后解析JSON，提取出时间戳和各传感器值，然后写入InfluxDB对应的measurement。在InfluxDB中，表结构大概是：

measurement: greenhouse_sensors tags: node, type fields: value timestamp: 采集时间

这种设计的好处是任意新增传感器类型都不需要改表结构，只需要在写入的时候指定新的tag值。查询的时候按节点筛选，按时间范围聚合，灵活性和扩展性都很好。

Grafana的Dashboard配置是整个系统体验感最直观的部分。我通常会在一个面板上同时展示当前温度、湿度、光照、CO2、土壤水分五个指标，每个指标用一个大数字显示当前值，下面配一张最近24小时的趋势曲线。趋势曲线比单点数值更有价值——比如温度是逐步爬升还是突然跳变，这背后的原因完全不同。

Grafana的阈值告警功能也建议一并配置。比如温度上限设为35摄氏度、下限设为5摄氏度，湿度上限85%，CO2上限1500ppm，土壤湿度下限20%。达到阈值后，Grafana会向配置好的通知渠道发送告警。实测下来，这套开源组合在数据展示能力上完全不输商业化的农业物联网平台，唯一的门槛是需要花点时间学习配置。

4. 传感器校准与联动控制策略

4.1 传感器校准：数据可信度的关键

传感器用了一段时间之后，很多人会发现数据开始“漂”——和标准仪表对比，偏差越来越大。这不是传感器坏了，而是所有电子元器件都存在温漂和时漂的特性，需要定期校准。

DHT22的湿度校准在家庭条件下也有办法做。最原始也最可靠的方法是“饱和盐溶液法”：在一个密封容器里放入某一种盐的饱和溶液，容器内部会维持一个固定的相对湿度环境。比如氯化钠饱和溶液在25摄氏度下可以维持75%左右的相对湿度，氯化镁饱和溶液可以维持33%左右。把传感器放进容器密封放置2小时以上，然后对比传感器读数和理论值，偏差如果超过5%RH就必须修正。

BH1750光照传感器的校准相对简单。用同一时刻的照度计读数作为参考值，计算出一个修正系数。由于BH1750出厂一致性较好，正常情况下修正系数接近1，但如果传感器透光窗口被灰尘或水汽遮挡，读数会明显偏低，这时候清洁一下通常就能恢复。

土壤湿度传感器的校准是影响实际种植判断最重要的一个环节。具体做法是：取棚内代表性土壤，自然风干后装入花盆，插入传感器记录ADC读数A0；然后加水至土壤完全饱和，静置半小时让水分均匀分布，记录ADC读数A1。之后将湿度和ADC的对应关系近似为线性映射，写入固件。土壤湿度传感器的读数受土壤质地影响极大，而且会随着土壤盐分累积发生漂移，所以至少每个种植季开始前要做一次重新校准。

4.2 环境阈值与设备联动策略

监测数据只是第一步，真正的价值在于用数据驱动控制决策。在温室场景下，最基础也最有效的联动控制包括三项：风机降温、卷帘遮阳、水泵灌溉。

风机控制的逻辑我用的是滞回控制，而不是简单的单阈值触发。比如温度上限设定为30摄氏度，下限设定为27摄氏度，当温度高于30度时启动风机，低于27度时关闭风机。中间空出的这3度是滞回区间，可以防止风机在阈值附近频繁启停。如果没有这个滞回区间，风机可能在30度上下反复开关，一分钟内动作十几次，不仅浪费电能，还会严重缩短风机电机的使用寿命。

卷帘遮阳的控制同样采用滞回策略。当光照强度超过5万勒克斯时逐步展开遮阳网，低于3万勒克斯时收回。注意这里说的是“逐步”而不是“一次到位”，因为遮阳网瞬间全开会导致棚内温度和光照骤变，反而对作物造成胁迫。实际执行时，我把卷帘电机拆成了多次小幅度动作，每次运行10秒后停止5分钟，观察温度变化后再决定是否继续。

水泵灌溉的控制逻辑相对复杂一些，需要同时考虑土壤湿度和时间窗口。土壤湿度低于25%时启动灌溉，达到40%时停止；同时还要设定禁止灌溉时段——比如中午11点到下午2点之间不浇水，避免高温时段冷水灌溉对根系造成冷激。这些规则我用Node-RED里的函数节点实现，每收到一次传感器数据就会运行一次规则引擎，判断对应设备的状态是否需要切换。

4.3 告警推送与远程监控配置

告警是监测系统“最后一道防线”。在无人看管的夜间，一个及时的温度告警可能意味着避免一整棚作物的损失。

实测最方便的告警渠道是企业微信或者钉钉的群机器人Webhook。在群里添加一个自定义机器人，拿到Webhook地址后，用Node-RED里的HTTP请求节点，把Grafana触发的告警消息POST到这个地址，就能实时推送到手机上。告警内容用模板设置好，格式类似：

【温室告警】1号棚温度异常 当前值：35.6°C 阈值：30.0°C 时间：2025-03-20 02:31:08

告警规则分级很关键。我把所有告警分成两级：一级是注意级，比如温度超过35度或者低于5度，推送通知即可；二级是紧急级，比如温度超过40度或设备掉线超过30分钟，需要电话联系或者多路重复推送。Grafana里根据阈值设置不同优先级的规则，通知渠道分别配置即可。

除了告警，远程查看数据的能力也非常实用。Grafana本身自带Web界面，端口映射到内网后，在外面也能随时查看棚内环境状态。考虑到租用公网服务器成本较高，更推荐在内网路由器上做端口映射，配合域名解析访问；如果对安全性要求较高，配置一层Tailscale之类的内网穿透方案，既安全又不用额外花钱租公网IP。

5. 常见问题与排查技巧实录

5.1 高频故障排查速查表

在这里把这几年运行中遇到的高频问题整理成一张速查表，方便大家直接照着排查：

5.2 数据质量问题的深层原因

系统跑起来之后，最大的坑往往不是硬件故障，而是数据质量的问题。数据表面上在更新，但数值本身是不准确的，这类问题排查起来比“直接没有数据”要困难得多。

举个例子，有一段时间棚内的湿度数据显示经常到98%以上，连续好几天都是这样，导致系统频繁触发高湿告警。去现场检查才发现，是因为传感器安装的位置太靠近作物冠层，而夏季早晨叶片上凝结的露水直接落在了传感器外壳上，水膜蒸发时带走了局部热量，导致传感器周围形成了一个局部的微气候环境。解决办法是调整安装位置，把传感器稍微移高一些，远离叶片滴水的范围。

另一个典型的案例是光照传感器的读数在傍晚时分出现异常波动。排查后发现是棚内灯具的光线干扰——晚间的补光灯和传感器之间距离太近，灯光直射导致传感器捕捉到了非自然光源的光照。解决方法是调整传感器安装角度，加装一个遮光筒，只让上方天空光进入感光面，从物理上屏蔽侧向光线干扰。

5.3 断线重连与固件远程升级机制

系统运行过程中，WiFi断网、MQTT Broker重启这类故障是无法完全避免的。一颗成熟的产品化固件必须考虑充分的容错机制。

在固件层面，ESP32的断线重连采用带退避的重试策略。第一次重连失败后等待5秒，第二次等待10秒，按指数递增，最大不超过5分钟，避免在WiFi信号不稳定时频繁重连导致功耗升高和网络拥塞。同时开启ESP32的看门狗定时器，一旦某个传感器读取阻塞超过10秒（比如I2C总线挂死），就自动重启整个系统恢复状态。这个机制在长时间无人值守的运行场景下非常重要。

代码中看门狗的启用方式是这样的：

#include "esp_task_wdt.h" void setup() { esp_task_wdt_init(10, true); // 10秒超时 esp_task_wdt_add(NULL); } void loop() { // 业务逻辑 esp_task_wdt_reset(); // 每次循环喂狗 }

OTA（空中升级）功能也值得加上。固件版本更新不用每次跑到大棚里插线刷写，通过HTTP从服务器拉取新的固件包即可完成升级。OTA的核心是做好升级失败的回退保护，ESP32的Arduino框架自带Update库，可以先把新固件写入另一个分区，校验通过后再切换启动分区，这样即使升级过程中断电，系统也能启动到旧版本，避免变砖。

5.4 成本核算与后续扩展方向

最后把这套系统的成本账算一笔。单个采集节点硬件成本约220元，三个节点就是660元；树莓派加各类外设约400元；各类线材、端子、防水盒、安装辅料约200元。整套系统硬件总成本在1300元左右。如果手头有闲置的旧电脑，树莓派这笔钱还能省下来。

对比市场的商业方案，单栋大棚的物联网监测系统报价普遍在8000到2万元以上，自建方案在保证核心功能的前提下，成本只有商业方案的五分之一到十分之一。更重要的是，自建系统的数据完全自己掌握，不受第三方平台限制，后期想要扩展新的传感器或者控制设备，只需要改改代码和配置就能实现，而商业平台往往需要额外付费开通功能模块。

这套系统的扩展路线也比较清晰。如果后续有多个大棚需要接入，可以统一规划一套平台层，每个大棚只增加传感器节点，平台和数据库不需要重复建设。再进一步，可以接入图像识别模块分析作物长势，通过历史气象数据结合温室内外环境做预测性调控——比如根据天气预报提前调整通风策略，而不是等温度超限后才被动响应。这些方向都在现有架构的基础上扩展，不需要推翻重来。

6. 写在最后的经验之谈

这套系统从最初的原型验证到现在的稳定运行，中间改了好几版。说实话，最难的并不是写代码或者接电路，而是搞清楚你到底需要监测什么、控制什么。数据不是越多越好，传感器也不是越贵越好。一套能够长期稳定运行的系统，一定是和你自己的种植习惯、大棚条件、作物需求深度绑定的。

我个人在实际操作中最深的体会是：环境监测系统的核心价值不在于“多智能”，而在于“多可靠”。一个每周都要折腾一次的“聪明系统”，远不如一个装上之后半年不用管的“笨系统”有价值。所以在设计和部署时，把可靠性放在第一位：供电冗余、通信容错、结构防水、定期校准，这些基础工作做到位了，系统才会真正成为你生产中的得力助手，而不是又多了一个需要伺候的设备。

还有一个小技巧想分享给准备动手的朋友：在正式部署之前，先拿一套设备在自家阳台或者小拱棚里跑两到三周，把传感器数据和你实际感受到的环境变化对照一下，确认读数靠谱了再往大棚里装。这个“试用期”能帮你避免很多现场调试的尴尬。

温室环境监测系统是一个典型的物联网落地场景，技术门槛不高，但涉及的知识面很广——传感器、嵌入式、网络通信、数据可视化、农业种植，每一块都需要一点积累。希望这篇文章能帮你少走一些弯路，把更多精力留给真正重要的部分：种出更好的作物。