STM32盆栽自动管理系统：从湿度监测到微信小程序远程控制详解

简介：基于STM32的盆栽种植自动管理系统设计PDF，面向物联网、嵌入式及微信小程序开发者，针对传统盆栽养护依赖人工经验、数据缺失的问题，提供一套完整的室内绿植智能养护方案。文档从需求分析到软硬件实现均有覆盖，核心功能包括土壤湿度实时监测与自动补水、BH1750光照检测下的PWM调光补光灯、DHT11温湿度采集与蜂鸣器报警、OLED屏本地显示，以及通过ESP8266接入腾讯云IoT平台、利用MQTT协议完成数据同步和微信小程序远程控制。同时梳理了STM32F103RCT6主控、继电器水泵、传感器等模块选型与设计思路，对毕业设计、课程项目或竞赛准备有较强参考价值。资源为单个PDF文件，约40.96MB，目录结构清晰，适合入门至中级学习者按章节研读。已有118人学习下载，可作为嵌入式物联网综合项目的实战参考资料。

1. STM32盆栽自动管理系统到底在解决什么问题：从“盲浇”到“闭环控水”

基于STM32的盆栽种植自动管理系统，配合微信小程序做远程控制，本质上是在做一件小事：把“该浇水”这个判断，从人脑转交给传感器和代码。它不是智能花盆玩具，而是一个典型的STM32采集—控制—上报—远程干预的小型物联网闭环。适合两类人：一是单片机入门后想完整做一个带App端项目的开发者，二是有真实养花需求但经常出差的用户。这套系统真正值钱的部分不在硬件多豪华，而在三个地方：湿度采样的稳定性、自动浇水的控制策略、以及小程序与单片机之间那条不出错的通信链路。标题里“自动管理”四个字，实际管理的核心动作只有一个——浇水，而难点全部围绕它展开。下面按完整落地顺序讲清楚。

2. 三条链路拆开设计：STM32采集、控制执行与WiFi上报的硬件选型

做这种系统最怕一上来就焊板子。我见过不少方案，按网上随手搜的清单买零件，结果土壤湿度模块两周就失效，继电器驱动水泵时把单片机拉复位，WiFi模块和STM32串口波特率对不上，排错排掉一个周末。后来我把系统拆成三条独立链路：采集链、执行链、上报链，分别选型、分别测试、最后再联调。这个顺序值得先定下来：先让采集值可信，再让控制动作可靠，最后才让数据上云上小程序。

2.1 硬件选型清单：每个部件为什么这么选

主控选STM32F103C8T6的理由很实在：三个USART，一个留给调试串口，一个接ESP8266，一个备用，刚好不打架。土壤湿度模块优先选电容式而不是电阻式：电阻式靠两片裸露金属探针测土壤电阻，直流电会在土壤里电解，用久了探针表面腐蚀，读数越来越离谱；电容式探头表面有保护涂层，寿命长，单颗贵几块钱，但省掉的排错时间远不止这几块钱。继电器模块注意看板子上的器件，一定要有光耦隔离和三极管驱动，不要买那种拿单片机引脚直接驱动线圈的裸继电器，否则STM32 IO口很容易被反向电动势打坏。

供电要分层，这是我反复强调的一点：单片机、传感器用5V经AMS1117转3.3V供电，继电器模块可以共用5V，而水泵不能接在LDO后面，必须直接从5V或12V适配器取电。否则水泵一启动，电流冲击会把3.3V电压拉垮，导致单片机看门狗复位。很多“运行到一半随机重启”的玄学问题，最后查出来都是供电共地没处理好，水泵一抽水，主控跟着重启。

2.2 数据流与控制流：一张文字版链路图

把系统串起来看，全部数据只走两条方向。下行控制流：STM32读取土壤湿度ADC值，经过滤波和阈值判断后，决定打开还是关闭继电器，继电器再控制水泵通断。上行状态流：STM32把湿度、水泵状态等通过串口发给ESP8266，ESP8266在路由器上做一个小型HTTP服务，微信小程序通过局域网请求这个服务拿到实时状态，也可以发控制指令进去，ESP8266收到后通过串口转给STM32执行。

这里有个容易搞反的点：小程序的请求目标是ESP8266，不是STM32。STM32不直接上网络，网络部分全部交给ESP8266承担，这是最稳的架构。别把STM32程序写得又读传感器又处理网络协议栈，那不是不行，而是出了问题极难排查。分开之后，每一段链路都可以独立测试：先用串口助手单独测STM32上报的JSON是否正确，再用浏览器直接访问ESP8266的IP看返回数据，最后才轮到小程序联调。

2.3 通信架构：先局域网HTTP，再谈MQTT上云

这里要给一个务实建议，很多教程上来就教MQTT、教云平台，但对首次做这类系统的人来说，那个链路太长，中间任何一个环节出问题都查不到根因。我的习惯分两步走。第一步先做局域网方案：ESP8266开HTTP服务，手机小程序在同一WiFi下访问它的IP，开发调试阶段在微信开发者工具里勾选“不校验合法域名”，就能直接走http。第二步，等整套控制系统稳定运行了，再考虑把ESP8266端改成MQTT客户端，接到自建或者第三方的MQTT服务器上，小程序通过合法域名后端转发，实现外网访问。没必要一上来就集成完整的云链路，那是给自己增加排错难度。

这个选型直接决定“值不值得做”：如果只是自己家里养花用，局域网方案完全够，而且足够稳定；如果目标是做成一个可演示的产品Demo，再考虑MQTT。在此之前先别碰，能省下一整周的学习成本。还有一个小细节容易被忽略：金属盆、摆放在阳台死角的花盆会明显削弱WiFi信号，ESP8266尽量选带外置天线版本的模组，或者把ESP8266放在离路由器更近的位置，用杜邦线延长接STM32的串口。

3. 把自动浇水的逻辑做踏实：湿度标定、中值滤波与滞回控制代码

STM32端是整个系统最核心的部分。我见过不少同学把系统做到数据上报通了，但真正自动浇水时，要么土壤干透之前就拼命浇，要么湿度在阈值附近抖动导致水泵频繁启停。问题不在代码语法，而在采样怎么处理、控制策略怎么设计。这一章给出一套能直接在真实盆土上跑的完整思路，代码基于标准库，可以移植到F103或同系列芯片上。

3.1 先处理原始信号：电容式湿度模块的ADC标定与滤波

电容式土壤湿度模块的输出电压和土壤介电常数相关，土壤越湿，输出电压通常越低。STM32 ADC读出来的原始值带噪声，还受供电电压影响，不能直接拿来和固定阈值比较，否则换一个供电电压、换一个花盆，阈值就要重新猜。正确的第一步是标定：把探头完全暴露在干燥空气中，读一个ADC值作为干基准；再把探头完全插入浸透水的土壤里稳定几分钟，读一个值作为湿基准。两个基准点确定后，用线性映射把原始值换算成0到100的湿度百分比，方便后续所有逻辑使用。

#define ADC_CHANNEL_SOIL 0 #define ADC_DRY_VALUE 2100 /* 干燥空气中标定得到的ADC读数 */ #define ADC_WET_VALUE 860 /* 泡水土壤中标定得到的ADC读数 */ #define SAMPLE_COUNT 5 /* 单次采样取5次取中值 */ /* 读取土壤湿度，返回0~100，数值越大表示土壤越湿 */ uint8_t soil_humidity_read(void) { uint16_t samples[SAMPLE_COUNT]; for (uint8_t i = 0; i < SAMPLE_COUNT; i++) { samples[i] = (uint16_t)adc_read(ADC_CHANNEL_SOIL); delay_ms(10); } /* 简单排序取中值，滤掉偶发尖峰 */ for (uint8_t i = 0; i < SAMPLE_COUNT - 1; i++) { for (uint8_t j = i + 1; j < SAMPLE_COUNT; j++) { if (samples[i] > samples[j]) { uint16_t tmp = samples[i]; samples[i] = samples[j]; samples[j] = tmp; } } } uint16_t avg = samples[SAMPLE_COUNT / 2]; /* 把ADC读数映射到0~100 */ if (avg >= ADC_DRY_VALUE) return 0; if (avg <= ADC_WET_VALUE) return 100; return (uint8_t)((ADC_DRY_VALUE - avg) * 100U / (ADC_DRY_VALUE - ADC_WET_VALUE)); }

这里用的是“5次取中值”，而不是求平均。中值滤波比均值更适合湿度信号，因为土壤里偶尔有气泡或探针接触瞬间会造成单点尖峰，均值会被尖峰拉偏，中值则会把一个明显异常的点完全丢掉。SAMPLE_COUNT设为5、采样间隔10ms，总共50ms采完一次，对浇水控制来说响应足够快。两个基准值ADC_DRY_VALUE和ADC_WET_VALUE一定要在真实环境下标定：先在空气里读干值，再在湿土里读湿值，把这两个数填进去，后面所有判断才有意义。ADC参考电压直接用3.3V没问题，但模块供电要取自AMS1117稳压后的3.3V，不能拿USB的5V去怼，否则参考地与标定环境不一致，设备一换就漂。

提示：如果买的是带数字量输出的模块，它内部比较器已经做了阈值判断，你读不到细粒度湿度，只适合做“干/湿”二值判断。自动管理系统请选模拟量输出接ADC，留出后续调整阈值的空间。

3.2 自动浇水控制策略：为什么单阈值一定会抖动，滞回控制怎么写

如果代码写成“湿度低于30就开泵、高于30就关泵”，实际运行不到一天就会发现问题：土壤湿度在浇完水后缓慢逼近临界值，继电器反复吸合释放，水泵跟着哒哒哒频繁启停。湿度本身是缓慢变化但伴随瞬时噪声的信号，单阈值必然造成临界抖动。正确做法是滞回控制，开泵和关泵用两个不同阈值，中间留出缓冲区。湿度低于下限时开泵，等到湿度升到高于上限才停泵，一旦进入浇水过程，即使湿度回到中间区域也不会立刻关闭。

#define HUMIDITY_LOW 25 /* 低于此值启动浇水 */ #define HUMIDITY_HIGH 35 /* 高于此值停止浇水 */ #define MIN_WATER_TIME 10 /* 一次最少浇水10秒 */ static uint8_t watering = 0; /* 当前是否处于浇水状态 */ static uint16_t water_timer = 0; /* 本次已浇水秒数 */ void auto_water_tick(uint8_t humidity) { if (!watering) { if (humidity < HUMIDITY_LOW) { watering = 1; water_timer = 0; relay_on(); } } else { water_timer++; if (humidity >= HUMIDITY_HIGH && water_timer >= MIN_WATER_TIME) { watering = 0; relay_off(); } } }

这个函数建议由1秒定时器调用，water_timer做秒计数，不要用delay阻塞等待，否则传感器采样和串口上报都会被卡住。两个阈值之间10%的滞回区间，足够覆盖土壤湿度的正常波动；如果你用的是粗颗粒基质，水分渗透快，可以把滞回区间加大到15%，否则刚浇完水还没渗透到位，湿度暂时到上限会太早停泵。MIN_WATER_TIME是一个容易被忽略的保护参数：防止“探头刚碰到水分、湿度瞬间跳变导致还没真正浇透就关泵”。实际调试时，先手动开泵观察湿度变化曲线，再反推上限阈值设多少合适，别拿第一天标定的值直接跑三个月。

3.3 串口上报与接收：STM32和ESP8266之间用最简单的协议

STM32和ESP8266之间只交换两样东西：状态和指令。协议设计有一个原则，越是这种两个MCU之间的链路，越不要发明复杂的二进制协议。我用的是“JSON字符串加行尾”方式，STM32定时把状态拼成一行JSON，通过串口发给ESP8266，ESP8266按行读取后缓存，小程序来查就直接返回缓存值。

char json_buf[80]; uint8_t humi = soil_humidity_read(); /* 拼状态行，末尾带\r\n方便ESP8266按行解析 */ snprintf(json_buf, sizeof(json_buf), "{\"humi\":%u,\"water\":\"%s\"}\r\n", humi, watering ? "on" : "off"); uart_send_string(UART_ESP, (uint8_t *)json_buf);

串口波特率建议STM32和ESP8266都固定在9600。9600看起来慢，但状态行总共几十个字节，实际传输时间十几毫秒，完全够用。波特率再高，反而容易在ESP8266上电瞬间产生乱码。ESP8266侧收到控制指令后，需要回传一行确认给STM32，STM32串口接收中断里解析到确认帧后才执行动作，这样不会出现小程序点了浇水、ESP8266已收到但STM32串口丢指令的错位。我在工程里会把接ESP8266那个串口的中断优先级设得高于定时器，避免传感器采样循环占着CPU导致串口丢字节。

4. 微信小程序远程控制端：状态轮询、指令下发与协议对齐

不用小程序，这套系统用串口屏或者OLED也能做成自动浇水；加上微信小程序的意义在于远程查看、远程干预。开发小程序首先明确一个前提：微信小程序默认要求访问HTTPS合法域名，这是正式上线的限制。开发调试阶段完全不用被这个规则卡死，在微信开发者工具里打开“不校验合法域名”，手机和ESP8266连同一个WiFi，就能直接用http访问设备。这是局域网联调阶段最快的一条路，也是我推荐的起步方式。

4.1 页面骨架：一张状态卡片加两个操作按钮就够了

小程序页面越简单越好。我见过有同学把仪表盘、折线图、浇水日历全部塞进去，结果联调期间光适配机型就浪费了大量时间。最小可用页面就三块内容：当前土壤湿度百分比、水泵开关状态、一个“浇水N秒”的按钮和一组阈值输入框。湿度实时显示用进度条或数字都可以，水泵状态用一个红绿圆点区分，按钮点击后调起wx.request发指令。页面数据用定时器每5秒拉取一次，不需要WebSocket长连接，因为这个场景状态变化频率极低，轮询的压力和体验都合适。

4.2 状态轮询代码：用wx.request获取ESP8266上的最新状态

下面这段代码是小程序首页核心逻辑。假设ESP8266的局域网IP是192.168.1.123，它提供一个GET /status接口，返回和STM32上报一致的JSON字段。IP地址的获取方法：在路由器后台看客户端列表，或者让ESP8266启动时通过串口打印分配到的IP。

// pages/index/index.js const DEVICE_IP = 'http://192.168.1.123'; // 改成你设备实际的局域网IP Page({ data: { humi: 0, water: 'off', offline: false }, fetchStatus() { wx.request({ url: DEVICE_IP + '/status', timeout: 3000, success: (res) => { if (res.statusCode === 200) { this.setData({ humi: res.data.humi, water: res.data.water, offline: false }); } }, fail: () => { // 超时或IP不通时，标记离线，不显示陈旧数据 this.setData({ offline: true }); } }); }, onLoad() { this.fetchStatus(); setInterval(() => this.fetchStatus(), 5000); } });

几个容易踩坑的地方：timeout参数要设，默认60秒太长，设备一旦掉线，页面要等很久才提示离线；setInterval最好存在this上，页面卸载时clearInterval，否则切页面后轮询还在跑；fail回调不能静默，要把offline置为true，页面上用明显的“设备离线”提示盖在最上层，这是对用户最快的反馈。res.data在ESP8266返回时已经是JSON对象，不需要再JSON.parse。如果你在开发者工具里勾了“不校验合法域名”还报错，先确认手机和电脑的WiFi和ESP8266在同一个网段，这是最常见的低级失误。

4.3 指令下发与阈值设置：前后端字段名必须完全一致

手动浇水按钮的逻辑，是向ESP8266的/control接口发POST请求。这里最常出现的翻车点：小程序端发的是cmd字段，ESP8266解析的是command字段；或者duration小程序端发的是字符串，ESP8266按整数解析，导致浇水时长变成0。协议字段必须在编码前固定下来，不要边写边改。

// 手动浇水：按下按钮，开泵durationSec秒 waterOnce(durationSec) { wx.request({ url: DEVICE_IP + '/control', method: 'POST', data: { cmd: 'water', duration: durationSec }, success: (res) => { if (res.data.ok) { // ESP8266已经确认收到并转发给STM32 this.setData({ water: 'on' }); } } }); }, // 写阈值：low/high分别对应启动湿度和停止湿度 setThresholds(low, high) { wx.request({ url: DEVICE_IP + '/control', method: 'POST', data: { cmd: 'threshold', low: low, high: high } }); }

建议开发时先在ESP8266控制台日志里打印收到的完整请求体，确认JavaScript对象经过wx.request传输后字段名没有被改动，再联调STM32执行。还有一个容易被忽略的问题：wx.request的data对象里number类型参数，后台接收后可能是整数也可能是字符串，ESP8266解析时要做一次强制类型转换。对命令来说，两次快速点击会产生两条浇水指令，STM32端要加“正在浇水时忽略新的浇水指令”保护，上一章的watering状态变量正好直接拿来用。

5. 盆栽管理系统高频踩坑实录：湿度漂移、继电器抖动与设备失联排查

把一个盆栽自动浇水系统从“能演示”做到“敢出远门”，中间要度过一段专门排错的阶段。下面五条是这类项目里高频出现的真实问题，也是我自己调试时反复踩过的坑。每一条按现象、原因、解决来写，可以直接对照排查。这一章没有高深技巧，但决定了你的系统能不能连续稳定运行一周以上。

5.1 湿度数值开机后一直漂移，标定完过几天又不准

现象：上午标定好的ADC基准，下午读数整体偏了20到30，甚至空气中也读不回原来的干值。原因通常是两个：电容式湿度模块本身有温漂，以及3.3V供电不稳导致ADC参考电压漂移。更隐蔽的一个原因是模块探针周围土壤的空气间隙变大，传感器周围局部状态和整体盆土状态不一致。解决：传感器不要埋在表面，插到盆土中下层、靠近根系活动区的位置，埋入深度固定住，不要每次浇水后重新插拔；供电用AMS1117稳压后单独给传感器供电，不能和继电器共用一个5V转3.3V路径；标定尽量在目标环境温度下进行，换季时重新标定一次。另外每根土壤湿度传感器的线性曲线都有差异，批量做多盆时每盆单独标定，不要复用同一个基准值。

5.2 ESP8266串口第一包数据乱码，状态刷新偶尔卡住

现象：ESP8266上电后，STM32发过来的JSON偶尔是乱码，或者干脆收不到，复位一次又好一阵。原因：STM32和ESP8266上电时序不一致，STM32启动快，初始化完就开始发串口，而ESP8266固件还在启动阶段，波特率没稳定，这期间的数据全部丢失；另外双方波特率配置不一致也会出现偶发错乱。解决：STM32在初始化完成后延迟3到5秒再向ESP8266发送数据，等对方串口就绪；ESP8266端按换行符做分帧解析，收到不完整行直接丢弃；最关键的是把波特率固定下来，两边代码和透传固件配置里都写明9600，不要用自动波特率检测。

5.3 继电器频繁吸合，水泵哒哒响，过两天继电器不动作

现象：湿度在阈值附近时，继电器以几秒一次的频率反复切换，几天后触点烧蚀，连手动控制都不响应了。原因：单阈值控制造成临界抖动，继电器配合水泵这种感性负载，频繁吸合时触点很容易拉弧损坏。解决：用上一章的滞回控制把切换频率降下来；加最小浇水时长保护，一次浇水至少持续数秒，不允许刚开就关；硬件上继电器线圈两端反向并联一个续流二极管，防止关断瞬间反电动势打坏驱动三极管。建议在程序里加一个统计变量记录继电器累计动作次数，调试阶段每500次打印一次，这个数据能帮你判断土壤湿度波动是否异常。

5.4 断电重启后自动浇水逻辑“失忆”，该浇水时不浇

现象：停电后再上电，STM32程序从头跑，之前正在浇水过程中的状态全部清零，如果土壤本来就是干的，要一直等到下一次湿度采样低于阈值才触发，中间可能干了好几个小时。原因：所有状态都存在RAM里，掉电即失。解决：在片上Flash里保存三个关键值：上次浇水完成的日期、当前土壤偏干状态标志、累计浇水量。上电后先读取这些值，如果恢复时发现断电前处于浇水状态且土壤仍干，就继续执行浇水直到湿度到达上限或超时。更简单可靠的做法：每次浇水完成后在Flash写一个时间戳，上电后检查距上次浇水是否超过24小时且当前湿度低于阈值，两个条件都满足才允许进入浇水流程，避免断电恢复后立即误浇。

5.5 小程序时而连不上ESP8266，刚配好IP第二天又失效

现象：昨天还能打开页面看湿度，今天进小程序一直提示设备离线，但路由器后台里ESP8266明明在线。原因：ESP8266的IP是路由器DHCP分配的，路由器重启或租约到期后IP变了，小程序里写死的还是旧IP；另外手机如果自动连了WiFi的5G频段，而ESP8266只支持2.4G，两者不在同一局域网内自然不通。解决：在ESP8266固件里设置静态IP，固定成192.168.1.123这种不容易和手机冲突的地址；手机调试期间关闭5G频段，或者把路由器2.4G和5G SSID分开命名；路由器后台检查是否开启了AP隔离，开启后设备间互相不可见，必须关闭；以上都做了仍偶尔失联，把小程序的轮询间隔从5秒放到10秒，减少并发请求对ESP8266的压力，这个处理也能延长模块寿命。

6. 让系统从能跑变得跑得住：周期保护、补光联动与三天验收法

到这里，你已经有了一个能自动浇水、能小程序远程控制的STM32盆栽系统。最后想分享的不是更多功能，而是让这套系统连续稳定运行的习惯。最重要的一个习惯是给自动浇水加周期保护：即使传感器读数正常，也要限制单位时间内的浇水次数和最短间隔。

void auto_water_tick(uint8_t humidity) { /* 距离上次浇水不足12小时，强制跳过本次启动 */ if (!watering && hours_since_last_water() < 12) { return; } /* 当天累计浇水超过6次，停止自动启动，转人工确认 */ if (!watering && today_water_count() >= 6) { return; } /* 正常滞回控制逻辑 */ }

这里的hours_since_last_water返回距上次浇水结束的小时数，today_water_count返回当天已浇水次数，两个函数分别基于RTC和片上Flash计数器实现。12小时和6次是常见起步值，如果你用的是保水性差的沙质土，可以放宽到8小时和8次；如果盆土很厚保水，收紧到24小时和3次更安全。次数上限和最短间隔比湿度阈值更重要，因为传感器可能被根系顶歪、探针脱离土壤缝隙、或者盆底积水导致读数永远偏湿，周期保护是最后一道安全网。

补光联动可以作为自然扩展：用一个光敏电阻接另一个ADC通道，当检测到光照低于设定值且当天日照时长不足时，自动打开补光灯；这套逻辑和浇水的滞回控制一模一样，可以直接复用。最后做一个三天验收法：连续运行72小时，每天早上记录湿度数值、晚上看一次继电器动作计数、观察水泵停机后是否还有滴漏；如果动作次数稳定在每天2到4次以内，湿度曲线能回到设定区间，才算真的出师。出远门前，水箱加满、排水口检查一遍，手机上最后看一眼状态再关门。我自己的教训是：别在验收前一天临时改阈值，改完一定要重新跑满24小时，你永远不知道新的参数会在半夜触发什么奇怪组合。希望帮到你。

本文还有配套的精品资源，点击获取