企业官网建设流程全解析

我去年帮一位做种植的朋友改造他家的大棚时，被反复追问过一个问题：市面上现成的农业监控设备那么多，为什么非要自己用 STM32 从头搭一套？答案其实很朴素——现成设备要么只给你看数据不给控制权，要么扩展性差到连加一个传感器都得求着厂商，更别提价格里有多少是品牌溢价。自己动手做一套基于 STM32 的智能农业监控系统，本质上是把"检测大棚环境数据"这件事的主动权拿回自己手里，从选型到部署全都透明可控。

这篇文章想和你聊的，正是这套系统的完整设计思路与实际落地经验。它的核心任务非常聚焦：检测农业大棚中各种环境数据，包括空气温湿度、土壤湿度、光照强度、二氧化碳浓度这些直接影响作物生长的关键指标。适合正在做课程设计、毕业课题的电子相关专业学生，也适合想低成本给自家大棚做智能化改造的种植户，以及纯粹想把嵌入式知识用在实际场景里的开发者。

我会从系统整体架构讲起，拆解传感器选型的依据，然后深入 STM32 端的采集逻辑和数据处理，再聊数据显示、远程监控与报警机制，最后把我实际部署时踩过的坑和调试经验一并交代清楚，包括如何校准传感器、如何处理电源波动、怎么让系统在潮湿闷热的大棚环境里稳定运行等细节。这不是一份泛泛的方案文档，而是把我做过的、改过的、烧过板子换来的经验都倒出来，你看完能直接用。

1. 智能农业监控系统的总体框架设计思路

1.1 需求拆解：大棚监控到底要解决什么问题

农业大棚的本质是一个半封闭的人工气候环境，它的核心矛盾在于：作物生长需要相对稳定的温湿度、光照和土壤条件，但棚内环境受外界天气影响极大，夏天太阳一晒温度能飙到 50 度以上，冬天夜间又可能跌破作物耐受下限，土壤干湿程度更是直接决定灌溉策略。传统做法是凭经验看天吃饭，但人的精力有限，也不可能 24 小时盯着棚里的每一寸变化。

所以这套系统的第一目标不是"炫技"，而是把环境数据变成客观、连续、可追溯的记录。具体来说，要采集的数据包括：空气温度和湿度（决定作物蒸腾速率和病害风险）、土壤湿度（决定灌溉时机和用水量）、光照强度（影响光合作用效率和补光策略）、二氧化碳浓度（直接关系光合作用原料供给）。这些数据综合在一起，才能判断大棚当前是否处于适合作物生长的状态，进而指导通风、遮阳、灌溉、补光等执行设备的动作。

我见过不少初学者拿到题目就直接开始写代码，结果做到一半发现传感器数据读出来根本不对，或者采集到的数据在电脑上能看到、出了大棚就断联。根源在于没有先花时间做系统级的设计。这个项目的设计流程应该是自顶向下的：先明确需要哪些数据、数据怎么流转、最终怎么被使用，再往下选硬件、写驱动、做上层应用。

1.2 系统架构选型：从传感器到用户界面的完整链路

整个系统的信息流可以概括为四个环节：感知采集、核心处理、数据远传、展示交互。感知层是各类环境传感器，它们把物理量转换成电信号；核心处理层是 STM32 单片机，负责采集传感器的数据、执行必要的滤波和校准算法、根据预设阈值判断是否触发报警或控制指令；数据远传层通过通信模块把数据送到本地屏幕或远程服务器；展示交互层则是管理人员查看数据的窗口。

关于通信方案的选择，我实际比较过几种常见的路线。近距离场景用串口直连电脑最省事，适合调试阶段；蓝牙方案适合在棚内短距离查看，但穿墙能力一般；WiFi 模块（比如常用的 ESP8266）可以低成本接入家中或大棚附近的路由器，适合有稳定网络的场景；如果大棚在偏远地区没有 WiFi 信号，就得考虑 4G 模块或者 LoRa 组网。我的建议是：第一版先做好串口加 OLED 本地显示，确保采集链路可靠，再逐步接入 WiFi 远程上报，这样每一步的问题都容易隔离。

选型时还要考虑一个容易忽略的点：传感器和通信模块的供电要求经常不一致。传感器中有不少是 3.3V 或 5V 供电的，继电器模块又往往需要 5V 驱动，如果电源设计不合理，系统会出现各种莫名其妙的复位和读数跳变，这个问题我会在后面专门展开讲。

2. 核心硬件选型与电路连接细节

2.1 STM32 型号选择：适合农业监控的几款主流方案

STM32 家族庞大，选型时主要看三点：引脚数量是否足够、ADC 和通信外设是否够用、功耗和成本是否可接受，以及开发资料是否丰富。控制器的核心任务是轮询读取传感器、处理数据、驱动显示和通信，并不需要非常高的主频，也不需要复杂的人工智能计算，所以主流的选择集中在几个系列上。

如果追求性价比和资料丰富度，STM32F103C8T6 是很合适的选择。这颗芯片是基于 ARM Cortex-M3 内核，主频 72MHz，内置 64KB Flash（实际不少型号标 64KB，可用约 128KB）和 20KB SRAM，GPIO、ADC、I2C、SPI、USART 这些外设一应俱全，非常适合原型验证。它最大的优势是生态极其成熟，网上能找到大量参考代码，就算遇到问题也容易搜到解决方案。

如果考虑低功耗农业场景，比如后续要用电池或太阳能供电，STM32L431 或 STM32L476 系列的低功耗表现会明显优于 F1 系列。但低功耗也意味着开发时要注意休眠和唤醒的设计，复杂度会高一些。如果项目中还要做简单的边缘图像处理（比如用摄像头判断叶片颜色），可以上 STM32F407 系列，但通常监控系统用不到这么大的算力。我的建议是：课程设计或第一版方案选 F103C8T6 就足够，等系统稳定了再考虑低功耗优化。

2.2 环境数据传感器选型与参数对比

传感器的选型直接决定了采集数据的可信度，是这个项目的灵魂。以我的经验来看，各传感器选型的侧重点如下：

首先是空气温湿度。市面上最普及的是 DHT11 和 DHT22（AM2302），两者都采用单总线协议，接线简单，但 DHT11 的精度只有 ±2°C 和 ±5%RH，响应也偏慢，放到农业监控场景里只能说勉强够用。DHT22 精度提升到 ±0.5°C 和 ±2%RH，价格高一倍但值得。如果预算再充足一些，SHT30 这类 I2C 接口的数字传感器稳定性和一致性更好，而且自带校准，省心很多。我自己实际测试过，DHT22 在湿度超过 85% 时读数会出现明显漂移，南方大棚梅雨季节要特别注意。

土壤湿度传感器有两种主流类型。一种是电阻式（常见的有 LM393 加两支探针），利用土壤含水量不同导致的电阻变化来测量，价格便宜，但长期埋在土里探针容易电解腐蚀，精度也一般。另一种是电容式，它通过测量土壤介电常数变化来反映含水量，没有裸露的金属电极，不易腐蚀，寿命长得多。我强烈建议优先选电容式土壤湿度传感器，虽然贵一点，但省掉了频繁更换传感器和维护的麻烦。

光照强度传感器常见的有 BH1750 和 TSL2561。BH1750 是 I2C 接口的环境光传感器，量程能到 65535 lx，直接输出数字量，使用方便，是做补光控制的好帮手。二氧化碳传感器则是整套系统里价格较高的环节，常见的有 MH-Z19 红外传感器，支持 UART 和 PWM 输出，量程 400-5000ppm 足够大棚使用，而且有自校准功能，稳定性不错。不过它有个小坑：上电初期读数会偏高，需要预热几分钟才能稳定。

下表是我实测验证过的传感器搭配组合，在性价比和数据可靠性之间比较平衡：

2.3 电路连接要点：从传感器到 STM32 的接线与供电规划

在连接电路时，最需要关注的是电平匹配和电源隔离。STM32F103 的 GPIO 是 3.3V 逻辑电平，而不少传感器模块（如某些继电器模块、LCD 屏幕）是 5V 逻辑，直接接在 GPIO 上可能损坏引脚，或者出现电平不识别的问题。稳妥做法是对 5V 逻辑的信号线加电平转换，或者干脆选择本来就带 3.3V 兼容的模块，实在不行就在串口线上串联 1kΩ 电阻限流。

每个传感器的接线需要按照数据手册来，这里给出我实际使用的引脚分配，供参考：

• DHT22：DATA 接 PA0，VCC 接 3.3V，GND 接 GND，DATA 和 VCC 之间接一个 4.7kΩ 上拉电阻（部分模块板载已有）。
• BH1750：SDA 接 PB7，SCL 接 PB6，VCC 接 3.3V，GND 接 GND。
• 土壤湿度传感器：AO（模拟输出）接 PA1（ADC 通道），VCC 接 5V（注意：部分模块是 3.3V-5V 宽压），GND 接 GND。
• MH-Z19：TX 接 STM32 的 USART3_RX（PB11），RX 接 USART3_TX（PB10），VCC 接 5V，GND 接 GND。

电源部分是我踩坑比较集中的地方。大棚环境里要驱动多种传感器以及后续的通风、卷帘、水泵等执行设备，供电容易不够稳定。我的做法是"电源分级":系统统一使用 12V 直流电源适配器入门，先经过一个 DC-DC 降压模块到 5V,给传感器、通信模块、继电器等供电；然后再用 AMS1117-3.3 从 5V 降压到 3.3V，给 STM32 和部分数字传感器供电。这样可以避免电机启停时电压波动直接冲击单片机和传感器，保证采集数据稳定。

另外一个接线细节是，所有传感器的 GND 必须共地。如果传感器和单片机各自用独立的电源适配器，却没有把地线连在一起，I2C 和 UART 通信会出现大量 CRC 错误或乱码，这是新手排查问题容易忽视的隐蔽原因。调试时如果发现数据乱跳，先用万用表量一下各个模块的地电位是否一致。

3. STM32 端软件设计：从传感器数据采集到处理算法

3.1 传感器驱动移植与初始化逻辑

软件部分的第一步是让各个传感器都能稳定地输出数据。对于 DHT22，它的单总线时序要求比较严格，操作时要按数据手册的时序要求，先将总线拉低至少 18ms 发送起始信号，然后释放总线等待传感器响应，接着读取 40 位数据。读取时每一位的时序差别在微秒级，所以在 STM32 上实现时建议关闭中断或使用定时器做精确延时，我用的是系统滴答定时器，实测稳定。

BH1750 相对简单，I2C 通信，只需发送测量模式指令然后延时等待测量完成，再读取两个字节的数据按公式换算成勒克斯值。土壤湿度传感器则是模拟量，直接配置 STM32 的 ADC 在 PA1 引脚上采样，采样值经过滤波和标定后转换成湿度百分比。

MH-Z19 采用串口通信，使用它的前提是了解其上位机协议：发送 0xFF 0x01 0x86 0x00 0x00 0x00 0x00 0x00 0x79 这组查询指令，传感器会返回 9 个字节的数据，其中第 3、4 字节的高低位就是 CO2 浓度值。由于不能保证每次发送指令后传感器都能在第一时间返回数据，最好在发送后延时 50ms 再读取串口数据，否则可能会读到上一次残留的数据。

3.2 数据滤波与转换：ADC 采样值如何变成有物理意义的湿度值

所有传感器最终输出的数据格式并不统一。DHT22 和 MH-Z19 直接提供经过换算的物理量，而 BH1750 和土壤湿度传感器给出的则是原始 ADC 值或光强值，需要转换。最有技术含量的是土壤湿度的处理。

土壤湿度传感器输出电压和土壤含水量之间的关系并不是线性的，影响它的变量包括土壤类型、压实程度以及探针附近的盐分浓度。因此我的做法是先标定后使用:把传感器插在干土中记录一个电压下限，再插在饱含水分的湿土中记录一个电压上限，然后按线性插值把电压映射成 0% 到 100% 的湿度值。这样虽然是近似算法，但对灌溉控制来说完全够用。

为了消除偶然波动，我在软件里做了滑动平均滤波。具体做法是：每个传感器保存最近 10 次的采样结果，每获得一个新数据就移除最早的数据并重新计算平均值。这个滤波特别适合 ADC 采集的土壤湿度和光照数据，可以显著减少因土壤颗粒接触变化或瞬间遮挡造成的异常跳变。但 DHT22 的温湿度数据不建议做平均处理，因为它的读数本身带有滞后性，过度平滑会让实际变化看起来更迟钝，反而掩盖了真实的环境变化趋势。

3.3 阈值判断与报警控制逻辑的实现

当数据采集稳定之后，就要进入控制逻辑设计。农业监控系统不只是"看数据"，还要能根据设定的上下限自动做出响应。我设计了一套阈值判断结构，它的核心逻辑是：在每个采集周期，对每个环境参数与预设的阈值范围做比较，超过范围就记录事件、提示报警，并触发对应的执行动作。

以温度和通风控制为例，假设大棚番茄生长适宜的温度范围是 22°C 到 30°C。当空气温度超过 30°C 时，系统启动风机或开天窗通风，如果温度继续升高到 35°C，则同时打开遮阳网，让棚内温度尽快回落。在温度降到 26°C 以下后，执行设备停止工作，留出回差区间避免执行机构频繁启停。这个"回差"的概念也是很多新手容易忽视的：如果没有回差，温度在 30°C 附近上下波动时，继电器会反复吸合，设备寿命和能耗都会被浪费。

土壤湿度控制水阀的逻辑同理。当湿度低于设定下限（比如 35%）时打开电磁阀灌溉，灌溉到湿度回升到 55% 时关闭。光照控制补光灯则是在连续阴雨天、棚内光照低于 3000 lx 时自动接通补光灯。整套控制逻辑放在一个周期循环中，配合一个按键或上位机指令来设置每组阈值，代码结构清晰，排错方便。为了防止传感器损坏导致错误的紧急操作，我还在每个判断分支加了"数据有效性检查"，比如湿度值如果长时间处于极端值时，只记录报警而不驱动执行设备，避免把大棚灌成水塘。

4. 显示、远程监控与数据上云的实现路线

4.1 本地显示方案对比与 OLED 屏幕驱动实践

数据采集和处理之后，总得让人看得见，本地显示是整套系统最直观的输出通道。可选方案有数码管、LCD1602、OLED 屏幕等。数码管显示信息量太少，LCD1602 在强光下可视性一般且有视角限制，我最终选择的是 0.96 寸 I2C 接口的 OLED 屏幕，128x64 分辨率，功耗低、对比度高，大棚内光线复杂时的可视性也比 LCD 好。

OLED 接线只需要 SDA、SCL、VCC、GND 四根线，和 BH1750 共用 I2C 总线，软件上使用常见的 SSD1306 驱动程序初始化后，就可以在屏幕不同区域上刷新数据。我在屏幕上的布局是：第一行显示当前温度和湿度，第二行显示光照强度和 CO2 浓度，第三行显示土壤湿度，第四行显示当前系统状态（比如"正常"或"高温报警"）。刷新频率定为每秒一次，太快会占用 I2C 总线且人眼感知不到差异，太慢又缺乏实时感。

显示这块有一个容易踩的坑：I2C 总线上挂了多个设备，有些传感器在初始化时会因为地址冲突或者总线被占用而失败。比如某段代码在初始化 BH1750 时，如果 OLED 还没有释放总线，可能会导致 I2C 通信卡死。解决办法是在软件初始化顺序上先初始化 OLED，再初始化各传感器，并在每次 I2C 通信后做一次总线释放处理。

4.2 基于 ESP8266 的 WiFi 数据上报与 MQTT 传输

现代农业监控的趋势一定是远程化，人不可能一直待在闷热潮湿的大棚里。我选择了 ESP8266 作为 WiFi 通信模块，通过 UART 与 STM32 连接，把环境数据实时上报到远程服务器，或者直接推到手机 App 上查看。

在通信协议上推荐使用 MQTT——它非常轻量，天然适合农业这种网络信号不稳定、数据量又不大的场景。STM32 每隔固定周期（比如 10 秒或 30 秒）把一条 JSON 格式的报文通过串口发给 ESP8266，ESP8266 再通过 MQTT 协议发布到服务器上。JSON 报文我习惯写成类似这样的结构：

{ "device_id": "greenhouse_01", "timestamp": 1712345678, "temperature": 28.5, "humidity": 65.2, "soil_moisture": 45.0, "light_intensity": 12500, "co2": 720 }

这样一份数据包含所有核心指标，到达服务器后，前端可以绘制曲线、做历史查询、设置异常报警。整套链路的关键是 STM32 和 ESP8266 之间的串口通信必须可靠，而这恰恰是问题高发地带。从 STM32 发送的串口数据到达 ESP8266 后，如果波特率不匹配或者数据帧格式不对，报文会被丢弃。我在模块间统一采用 115200 波特率，数据格式 8 位数据位、1 位停止位、无校验。为了应对偶发的通信中断，我还在 STM32 端加了一个简单的"链路心跳"机制：STM32 每 5 秒向 ESP8266 发送帧头，ESP8266 解析到之后回复确认帧，如果连续几次没有确认，系统就尝试重新初始化串口或发送复位指令给 ESP8266，保证远程监控的长时间稳定运行。

4.3 数据存储与报警通知的落地做法

远程监控不只是实时看数据，历史数据的存储和异常报警更实用。我的做法是选择了一款开源的物联网平台作为服务器端，它支持设备接入、数据存储、规则引擎和可视化面板，不需要我自己从零写一套服务器。STM32 端只需要把数据通过 MQTT 推送到指定主题，平台端就能自动接管后续的存储与展示。

报警通知这里，我踩过不少坑，最值得说的是"通知疲劳"问题。如果系统每小时发一条"温度偏高"，第一天你还会看一眼，第三天就直接无视了，真正的异常反而被淹没。我的解决思路是：报警条件加上持续时间判定。当温度连续超过阈值 5 分钟以上才触发报警，如果温度只是瞬时波动但很快回落，系统只记录事件但不推送。这个 5 分钟的窗口显著减少了误报率，也避免了夜间被短信轰炸的困扰。

报警通道上，平台自带的邮件通知和 Web 界面消息就够用，如果需要短信或微信推送，可以在平台上接入相应服务，但考虑到成本，第一版建议使用邮件加平台内的消息记录即可。

5. 系统测试与部署实测：从实验室到真大棚的调试记录

5.1 室内模拟环境测试：验证数据链路和阈值逻辑

所有硬件和软件做完之后，不建议直接杀进大棚里，因为问题会被复杂环境放大，排查起来无从下手。我习惯先在室内搭建一个小的模拟环境：把传感器放在桌面，旁边放一个加湿器和一个小太阳取暖器，人为制造温湿度的变化，验证系统能否正确采集、显示和触发报警。

这一阶段最容易发现的问题集中在传感器初始化和数据跳变上。我第一次把所有传感器接好上电后，OLED 屏幕上的 CO2 浓度一直显示 0，排查了接线和供电都正常，最后发现是 MH-Z19 的串口引脚没有正确配置成复用功能，导致串口数据收不到。这种情况下示波器不一定人人都有，但用 USB 转 TTL 工具把 MH-Z19 单独接到电脑上测试一下，就能快速定位是传感器本身的问题还是单片机的配置问题。

室内测试阶段还做了一件重要的事：标定土壤湿度传感器的上下限。我准备了干土和加了足量水的湿土，分别记录 ADC 值，然后用线性插值公式嵌入代码。在室内把传感器插在调好的泥浆中，读取的湿度值换算后和预期值偏差在 5% 以内，这个精度对灌溉控制已经足够。

5.2 大棚实地部署的环境影响：高温、高湿与电源不稳定

从实验室转移到大棚后的第一周，问题就陆续冒出来了。首当其冲的是高温问题：设备箱在中午的强光下内部温度可以达到 50°C 以上，DHT22 在这种温度下读出的湿度值明显偏低，OLED 屏幕亮度也会下降。我的解决方案是设备箱加装小型散热风扇并做通风孔，同时把传感器探头用延长线引出箱体，直接放在大棚作物层的环境中，让传感器探头和环境充分接触，而不是被箱体内部的微气候干扰。

第二个问题来自高湿环境下的可靠性。大棚内湿度常年很高，如果电路板裸露在外，水汽会在引脚间凝结，导致信号短路或读数不稳定。我使用三防漆对主控板进行了喷涂处理，把传感器接口处用热缩管密封，接线端子做了防水处理。三防漆这东西成本不高但对系统的长期稳定性贡献很大，强烈建议部署在大棚等高湿环境的系统都用上。

第三个问题就是电源波动。大棚内不少用户会同时开风机、卷帘机，这些大功率设备启停瞬间，电网电压会有明显的波动。我用 12V 电源适配器给整套系统供电，实测在风机启动瞬间，STM32 偶尔会复位。排查后发现是 DC-DC 模块的输入滤波不足，在输入端并联了大电解电容和大棚风机的电源错开使用后，复位问题基本消失，并建议把监控系统的供电线路和风机等大功率设备分路布线，从源头杜绝干扰。

5.3 实际运行数据记录：一个 72 小时连续运行的分析

系统稳定运行后，我采集了一组连续 72 小时的数据作为验证，也发现了不少能指导后续优化的规律。以下是一个 3 月春季大棚的数据片段：

从这批数据中可以明显看到一个有意思的现象：白天光照强、温度高时，CO2 浓度反而低，原因是作物进行旺盛的光合作用消耗了大量 CO2；夜间没有光照，作物以呼吸作用为主，同时大棚密闭，CO2 浓度就升高。这对环境控制的启示是：白天如果 CO2 浓度降到接近 400ppm 的室外背景水平，可以考虑通风补充外界 CO2，或者在大棚内释放 CO2 气肥；夜间则可以适当通风降湿，避免过高的湿度引发灰霉病等病害。这套系统让我第一次清楚地"看到"了作物与环境之间的这种呼吸节律，而这正是单纯靠经验很难感知的东西。

6. 系统扩展方向与实际投入成本参考

6.1 边缘控制进阶：从监控到自动灌溉和远程手控

这套系统的第一版只做到了监测和简单的阈值控制。但在实际使用中，我发现纯靠阈值控制还有不足——比如土壤湿度的下降速度在不同天气条件下差异很大，晴天可能两天就降到下限，阴雨天一周都不用浇水。这种情况下固定阈值就不够智能了。

比较实用的扩展方向是加入"累计日照强度"的概念。具体实现方式是记录当天光照强度的积分值，如果白天光照不足，夜间就自动补偿补光时长；如果累计蒸发量大，就提前预判是否需要灌溉。这种控制逻辑虽然增加了代码量，但能让系统从"被动响应"升级为"主动调节"，作物长势有肉眼可见的改善。再加入一个远程手动控制通道，在手机端不仅能看到数据，还能点一下按钮直接打开水泵或天窗，对实际生产来说非常方便。

6.2 硬件成本明细与自制系统 vs 市售成品

很多人关心这套 DIY 系统的成本。根据我实际采购的价格，硬件成本大致如下，不同时期和渠道会有浮动，大致参考：

合计大约 190 元到 230 元之间，和市售动辄上千元的农业监控设备相比，价格优势明显。当然，市售成品也有它的价值：开箱即用、售后有保障、传感器经过出厂校准。自制方案的核心优势不在省钱，而在可扩展性和可维护性——传感器的测量位置、数量、类型全都可以自己定制，数据也完全归自己所有，不会受第三方平台限制。

6.3 数据驱动的进一步玩法：本地农业模型与多棚组网

如果这套系统已经运行稳定并积累了一个季度的数据，可以做的事情就更有意思了。一方面，可以把历史数据和作物生长状态对应起来，摸索出适合自己大棚作物的最优环境参数组合；另一方面，如果家里不止一个大棚，可以做 LoRa 组网，每个棚部署一套子节点，网关统一收集后集中上报，避免每个棚都单独装一套 WiFi 系统。

还有一些更前沿的方向，比如把光照、温度、湿度、CO2 浓度和时间序列数据喂给简单的机器学习模型，预测未来几个小时的棚内温度变化趋势，提前做好通风和降温准备。这些扩展都依赖稳定可靠的底层数据采集，而这套 STM32 系统正好可以作为可靠的"数据底座"，为后续更多智能化功能留出想象空间。

7. 从第一版到稳定运行：我的调试验收经验清单

最后再分享一份可复用的调试验收清单，这是我反复折腾之后总结出来的，照着做可以少走很多弯路：

• 第一步：硬件上电前用万用表检查所有电源轨的对地短路情况，确认 3.3V 和 5V 输出正常，再插主控板。
• 第二步：分模块测试。单独烧写一个 DHT22 的读取程序，确认读到的温湿度在合理范围；再单独测试每个传感器，确认接线和驱动代码正确。
• 第三步：联调传感器后，让系统空跑 12 小时以上，观察是否有死机、花屏或数据异常。
• 第四步：做一次人为干预测试。比如用嘴对着传感器呵气，观察湿度是否快速上升；用手机闪光灯照 BH1750，观察光照值是否变化；用手捏湿土壤传感器，观察湿度读数是否升高。
• 第五步：把阈值设置代码写好之后，故意把阈值设到一个必然触发的值，验证报警机制是否正常推送。
• 第六步：最后才是整机部署。部署后前三天每天定时用手机远程查看数据，比对本地的 OLED 显示，确认传输链路没有丢包或者延迟异常。

我在实际测试中还发现一个值得特别提醒的细节：DHT22 相邻两次读取的最小时间间隔要保持在 2 秒以上，如果代码里读取间隔太短，传感器会响应超时甚至返回固定的 0 值。而 BH1750 的测量模式如果设成了连续测量，读取频率太高会发热导致读数略微偏高。这些都是文档里不会特别强调、但实际运行中一定会遇到的细节。

这套系统从设计到稳定运行，我前前后后花了大概三周时间，其中一半时间花在调试传感器读数和处理电源干扰上。但恰恰是这些看似琐碎的问题，逼着我把嵌入式开发的底层逻辑真正理清了。现在放到大棚里已经稳定运行三个月，偶尔翻看后台的历史数据曲线，能看到作物在一个更平稳的环境里生长，这种从数据到收成的对应关系，可能就是我最初想自己动手的原因。如果你也准备做一套自己的农业监控系统，希望这份从选型到部署的完整记录能帮你绕过我已经踩过的坑，直接把精力花在真正有价值的调试和优化上。