简介一套面向计算机类毕业设计与课程作业的智能养花系统源码以微信小程序为载体覆盖环境监测、设备控制、数据展示与用户交互等模块融合人工智能与物联网的基础应用既适合学生参考完成课程设计也适合开发者学习小程序工程化实践。压缩包共33个文件包括json页面配置、js交互逻辑、wxss样式布局、wxml模版结构等核心代码另配png/jpg图片素材与md说明文档整体大小仅962KB目录组织清晰便于按模块阅读和二次开发。目前已有102人学习下载。通过阅读源码能够掌握小程序从页面注册、组件通信到数据渲染的完整写法也能借鉴智能养花场景下的功能拆分、状态管理及界面布局思路对需要毕设演示或课程汇报的学习者而言这是一份可以直接运行并扩展的完整案例附带的说明文档也降低了上手门槛。1. 智能养花系统给课程设计和毕设的一整套可落地的物联网链路把“毕设课程作业_智能养花系统”这类题目拆开看它背后其实是一条非常经典的物联网采集与控制闭环土壤湿度、空气温湿度、光照被传感器采集主控通过 WiFi 上报服务端接收数据落库网页或小程序把曲线画出来再根据干湿状态自动启停水泵。真正卡住学生的地方不在硬件贵不贵而在链路能不能稳定跑通——我见过太多人调了三天的传感器最后发现是把 AO 和 DO 引脚接反或是水泵一启动板子就重启、服务端收到了消息却没写进数据库。这篇笔记就按这条链路从选型、接线、代码到排错完整走一遍适用对象就是做毕业设计或课程作业、想在有限时间内做出可演示系统的同学。2. 硬件选型与最小系统主控、传感器和水泵的取舍智能养花系统的硬件部分并不复杂难点在于每个模块都有几种常见型号可选接线和供电的细节又直接影响后面所有代码的调试体验。这一章先把硬件的选型逻辑和接线关系定下来后续章节的代码就都基于这套配置来写。2.1 主控平台怎么选ESP32、ESP8266 与 STM32 的取舍课设和毕设里最常见的主控方案有三类ESP32、ESP8266、STM32 搭配 ESP8266 模块。三者都能联网但开发体验差别很大。我的建议很简单没有硬性课程要求就直接上 ESP32有指定型号要求再考虑另外两种。主控方案联网方式开发难度参考成本适合做什么ESP32板载 WiFi/蓝牙中等约 30-50 元采集 控制 可视化的完整链路ESP8266板载 WiFi低约 15-25 元采集上报为主的简化版STM32 ESP8266 AT外挂模块透传较高约 40 元课程强制要求用单片机原理的作业ESP32 的优势是 ADC 和 PWM 资源充足还带 I2C 接口后面想加 BH1750 光照传感器、OLED 显示屏都不会捉襟见肘。它的 WiFi 协议栈在芯片内部独立运行不占用用户主循环写代码时不太需要考虑网络协议对实时性的拖累。ESP8266 虽然便宜但板载模拟输入只有一个而且 ADC 精度不如 ESP32传感器超过两路就得外挂 ADC 芯片反而把简单问题复杂化。STM32 方案在部分嵌入式课程里是指定要求需要用串口 AT 指令控制 ESP8266 模块联网涉及的协议解析和缓冲区管理对新手并不友好除非老师明确要求否则没必要给自己加这道坎。2.2 传感器接线与供电一张表把引脚关系说清下面这张表以 ESP32 开发板为例覆盖了智能养花系统最常用的三路传感器和一个继电器模块。接线前先对照表确认能省掉后面一大半玄学问题。传感器/模块信号引脚接 ESP32 位置供电特别注意FC-28 土壤湿度AOGPIO34ADC3.3V不要接 DO 引脚DHT11 温湿度DATAGPIO43.3V数据线建议加 4.7k 上拉BH1750 光照SDA / SCLGPIO21 / GPIO223.3VI2C 地址可能是 0x23 或 0x5C继电器模块INGPIO255V先确认高电平触发还是低电平触发土壤湿度模块的 AO 引脚输出的是探头分压值。大致规律是土壤越干AO 输出电压越接近供电电压土壤越湿输出电压越低。很多人把这个数值直接当百分比用这是后面数据失真的主要来源正确做法是先读 ADC 原始值和对应电压再按标定区间做映射。模块上的 DO 引脚是带电位器的比较输出只能输出高或低电平如果误接 DO读数会一直是 0 或 4095这是新手必踩的一个坑。供电方面ESP32 开发板上的 3.3V 输出电流有限带土壤湿度和 DHT11 没问题继电器模块建议从 5V 引脚取电。所有模块的 GND 必须和主控连在一起否则 ADC 的参考电位不一致读数会莫名漂移。还有一点如果传感器模块用 5V 供电AO 输出可能超过 3.3V直接接 ESP32 的 GPIO 有损坏风险所以土壤湿度模块优先用 3.3V 供电。2.3 执行器部分继电器与水泵的电源隔离浇灌执行器一般是继电器控制小型潜水泵或蠕动泵。继电器模块有两种常见设计普通晶体管驱动型和光耦隔离型课设建议直接买光耦隔离款价格只差几块钱但输入引脚和水泵电源之间没有电接触对主控更安全。接线时用常开触点 NO平时断开需要浇水时继电器吸合接通水泵。控制逻辑要格外注意一点很多继电器模块是低电平触发也就是 IN 引脚被拉低时继电器吸合这跟单片机常规的“输出高电平控制”思维正好相反。代码里不能在初始化阶段让引脚处于不确定状态而是要先设置为 OUTPUT 并拉低或拉高到“不触发”的一侧再延时几秒等系统稳定后才允许控制逻辑操作这个引脚。电源隔离是整套硬件里最值得花心思的地方。水泵是感性负载断电瞬间会产生反向电动势如果和主控共用一个电源很可能把 ESP32 瞬间拉复位表现就是“一浇花板子重启”。我自己做这类项目时水泵会单独用一路 5V 或 12V 直流电源继电器模块的供电也从这路取但 IN 信号仍由 ESP32 控制两边只连通 GND。如果条件不允许完全分开供电至少要在水泵两端反向并联一个 1N4007 二极管把断电瞬间的反向电动势吸收掉这是整流二极管当续流二极管的经典用法能解决大部分复位问题。3. 嵌入式端数据采集与上云从引脚读值到 MQTT 发布硬件接好之后第一件事不是直接写全套业务逻辑而是先用最小固件确认每个传感器能读到真实数据。顺序应该是裸读 ADC 值 → 确认电压关系 → 接入 WiFi → 走 MQTT 发布 → 再考虑控制。跳步调试是后面所有问题的根源。3.1 最小可跑固件先读一次真实土壤湿度用 Arduino 框架开发 ESP32最少只需要几行代码就能在串口监视器里看到土壤湿度传感器的原始值。下面这段代码只做采集和打印不做任何业务判断。#include Arduino.h #define SOIL_ADC_PIN 34 void setup() { Serial.begin(115200); analogReadResolution(12); // ESP32 默认 12 位 ADC取值 0-4095 pinMode(SOIL_ADC_PIN, INPUT); } void loop() { int raw analogRead(SOIL_ADC_PIN); float voltage raw * 3.3f / 4095.0f; Serial.printf(RAW%d voltage%.3fV\n, raw, voltage); delay(1000); }代码里analogReadResolution(12)把 ADC 设置成 12 位精度对应数值范围 0 到 4095这是 ESP32 的默认配置显式写出来是为了防止后续误改。电压换算用的是raw * 3.3 / 4095这里的 3.3 是开发板参考电压实际可能略有偏差但用于观察干燥和湿润的变化趋势完全够用。delay 1000 只是串口观察时的频率正式上报不需要每秒读一次。把传感器探头分别插进干土和湿土观察串口数值变化。干土时 RAW 通常接近 3000 以上湿土时可能降到 1000 以下不同模块和土壤差异较大记录一组自己的干湿范围值后面标定会用到。如果发现数值始终不变检查接线是否接到了 DO 输出。3.2 数据上云用 MQTT 把传感器值推给服务端传感器读数确认正常后第二步是让设备接入局域网并把数据发布到 MQTT Broker。MQTT 是目前物联网设备上报最常用的协议原因在于它是服务端主动订阅、设备主动推送的长连接模型HTTP 做不到服务端实时感知设备状态。最小可运行的上云代码包含 WiFi 连接、MQTT 连接、周期发布三个部分。#include WiFi.h #include PubSubClient.h const char* ssid 你的SSID; const char* password 你的密码; const char* mqttHost 192.168.1.10; const int mqttPort 1883; const char* clientId plant-esp32-01; #define SOIL_ADC_PIN 34 WiFiClient net; PubSubClient client(net); void checkWiFi() { if (WiFi.status() ! WL_CONNECTED) { WiFi.disconnect(); // 先断开再重连比直接 reconnect 更可靠 WiFi.reconnect(); } } void reconnectMQTT() { while (!client.connected()) { if (client.connect(clientId)) { client.subscribe(plant/cmd); // 订阅命令主题 } else { delay(2000); } } } void publishSensor() { int soilRaw analogRead(SOIL_ADC_PIN); float soilV soilRaw * 3.3f / 4095.0f; String payload String({\device\:\demo01\,\soilRaw\:) soilRaw String(,\soilV\:) String(soilV, 2) String(,\uptime\:) String(millis()) String(}); client.publish(plant/sensor/soil, payload.c_str(), false); } void setup() { Serial.begin(115200); analogReadResolution(12); WiFi.mode(WIFI_STA); WiFi.begin(ssid, password); while (WiFi.status() ! WL_CONNECTED) { delay(500); } client.setServer(mqttHost, mqttPort); } void loop() { checkWiFi(); if (!client.connected()) reconnectMQTT(); client.loop(); publishSensor(); delay(5000); }这段代码有几个参数需要说明。clientId在同一个 Broker 下必须唯一如果多个设备同时用同一个 ID后面连上的会把前面踢下线。publish最后一个参数false表示 QoS 0适合演示场景如果要求消息不丢改成true也就是 QoS 1Broker 会确认接收代价是网络开销略高。发布周期由delay(5000)控制5 秒一条在演示时够用长期运行建议放宽到 60 秒。载荷里的uptime用millis()表示设备开机时长这只是演示用的相对时间正式项目应通过configTime()获取 NTP 时间戳否则服务端落库后无法按真实时间画曲线。MQTT 主题命名采用两级结构plant/sensor/soil服务端用通配符plant/sensor/#订阅就能一次收下所有传感器数据后续加温湿度不用改服务端逻辑。3.3 采样与上传节奏多长时间上报一次才合理土壤湿度的变化以分钟甚至小时为单位没必要每秒上报。上报频率取决于你的运行模式和演示需求我一般按下面三档来设置。运行模式上报周期适用场景一天数据量估算演示模式5-10 秒答辩现场看曲线实时刷新约 1 万-1.7 万条常规模式60 秒长期稳定运行、入库分析1440 条省电模式5-10 分钟电池供电、定时唤醒144-288 条从数据库压力看常规模式一天 1440 条数据MySQL 完全没压力。演示模式一天一两万条也撑得住但前端 ECharts 一次性加载全部点会卡需要做时间范围聚合。省电模式适合 ESP32 加锂电池的场景用esp_sleep_enable_timer_wakeup定时唤醒采集后立即休眠。如果你的项目需要展示“自动浇水”的完整过程我建议常规模式跑 60 秒同时在服务端记录浇水事件用事件日志补足传感器曲线说明不了的细节。4. 服务端与可视化让浇水记录变成页面上的曲线嵌入式端把数据送到 MQTT Broker 之后剩下的工作全在服务端订阅消息、解析 JSON、写入数据库、提供查询接口、用 WebSocket 把实时数据推给前端页面。这一章按“订阅入库 → 接口 → 前端展示”的顺序推进。4.1 服务端选型为什么用消息队列而不是直接 HTTP很多第一次做这个项目的同学会问一个问题既然设备能连 WiFi为什么不直接用 HTTP POST 往服务器发数据答案在于 MQTT 的实时性和主动性。HTTP 是设备主动请求、服务端被动响应服务端无法第一时间知道设备掉线MQTT 是长连接Broker 可以保留设备最后一次上报的状态设备重连后还能继续收命令服务器也能主动往plant/cmd下发指令。后端技术栈没有唯一答案我见过三种常见组合取决于课程要求和个人底子。课程侧重点推荐技术栈理由嵌入式为主Python Flask MySQL语言上手快paho-mqtt 库成熟软件工程方向SpringBoot MySQL体现 Java 后端建模能力快速出效果Node.js MQTT.js WebSocket前后端同构实时推送代码量最少如果只看链路完整度Flask 方案最省时间订阅 MQTT 的进程可以和 Web 服务放同一个进程里跑课程设计阶段不需要上 Docker 或消息队列中间件。架构上保持简单ESP32 → MQTT Broker → Python 订阅进程 → MySQL → REST/WebSocket → Vue 页面。4.2 数据入库与接口把 MQTT 消息变成可查询的历史记录服务端的核心是一个 MQTT 订阅进程负责把plant/sensor/#主题下的消息解析成结构化数据写入 MySQL。下面是用 Python paho-mqtt 实现的最小订阅入库脚本。import json import mysql.connector import paho.mqtt.client as mqtt conn mysql.connector.connect( host127.0.0.1, userplant, passwordplant123, databasesmart_plant ) cursor conn.cursor() def on_connect(client, userdata, flags, rc): if rc 0: client.subscribe(plant/sensor/#, qos1) def on_message(client, userdata, msg): try: payload json.loads(msg.payload.decode(utf-8)) sql ( INSERT INTO sensor_log(device_id, soil_raw, soil_voltage, uptime_ms) VALUES (%(device)s, %(soilRaw)s, %(soilV)s, %(uptime)s) ) cursor.execute(sql, payload) conn.commit() except Exception as exc: # 把异常写进文件不要静默吞掉 with open(ingest_error.log, a, encodingutf-8) as log: log.write(f{msg.topic} {msg.payload!r} - {exc!r}\n) client mqtt.Client() client.on_connect on_connect client.on_message on_message client.connect(127.0.0.1, 1883, keepalive60) client.loop_forever()对应的建表 SQL 比较简单字段和 JSON 的 key 一一对应即可。CREATE TABLE sensor_log ( id INT AUTO_INCREMENT PRIMARY KEY, device_id VARCHAR(32) NOT NULL, soil_raw INT, soil_voltage DECIMAL(4,2), uptime_ms INT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );代码里有几个容易踩坑的地方。conn.commit()必须执行否则数据停留在事务缓冲区表里查不到。keepalive60表示客户端每 60 秒向 Broker 发送心跳低于 Broker 默认的 keepalive 即可我一般习惯给到 60。cursor.execute用了%(key)s命名占位符要求传入的 dict 里的 key 必须和 SQL 里的占位符完全一致这是最常见的报错来源。异常处理里把原始报文和异常信息写进文件排查时比在终端干等有用得多。4.3 前端展示曲线、日志和控制按钮的联动前端展示层用 Vue 或原生页面加 ECharts 就能实现。历史数据通过 REST 接口拉取实时新数据通过 WebSocket 推送。前端逻辑简化为三步页面加载时请求最近一小时数据画曲线WebSocket 收到新点追加到曲线尾部点击浇水按钮往plant/cmd主题发布命令。// 历史数据初始化 fetch(/api/sensor/history?hours1) .then(res res.json()) .then(points { chart.setOption({ xAxis: { type: time }, series: [{ type: line, data: points.map(p [p.created_at, p.soil_raw]) }] }); }); // WebSocket 实时追加断线自动重连 function connectWS() { const ws new WebSocket(ws://127.0.0.1:9000/ws); ws.onmessage (event) { const point JSON.parse(event.data); chart.appendData({ seriesIndex: 0, data: [[point.created_at, point.soil_raw]] }); }; ws.onclose () setTimeout(connectWS, 3000); // 重连间隔 3 秒 } connectWS();服务端用 Flask-SocketIO 或简单的 WebSocket 库把订阅进程收到的最新一条广播给所有前端连接。命令下发同样走 MQTT服务端发布到plant/cmd设备端已经在 3.2 小节订阅了这个主题。命令格式建议带msg_id用于设备端去重防止页面重复点击导致水泵连续启动。{cmd: water, duration: 8, msg_id: 20240601-abc123}设备端收到后解析cmd字段控制 GPIO 输出并把msg_id和实际执行时间回传一次作为确认。这个过程就是物联网标准的“下发 → 执行 → 回执”闭环也是答辩时最容易被追问的部分提前做好能加分。5. 智能养花系统常见问题排查5 条最容易让人放弃的坑与修法这一章把我在调试这类项目时最常遇到的 5 个翻车场景列出来。每条按“现象 → 原因 → 解决”的顺序写现象用来对照你自己的设备原因说明底层逻辑解决方式是可以直接抄的步骤。5.1 土壤湿度传感器读数永远不变或者跳满量程现象串口打印的 RAW 值一直停在 0 或 4095 附近把探头插水里都不变化。有人会开始怀疑模块坏了反复换传感器没用。原因最常见的原因是信号线接到了 DO 引脚而不是 AO 引脚。DO 是模块上电位器设定的阈值比较输出只能输出高或低电平模拟量根本不会出现在 DO 上。另一个常见原因是探头插在干燥板结的土里探头金属片和土壤接触面积太小相当于开路读数就会偏向满量程。解决先用万用表量 AO 引脚对 GND 的电压干土和湿土应该能看出明显压差。确认接入的是 GPIO34 而不是其他不支援 ADC 的引脚。如果万用表显示 AO 电压有变化但 ESP32 读数不变检查是不是拿了一个只支持输入不能做 ADC 的引脚比如部分 GPIO 在默认配置下没有 ADC 功能。把探头插到湿润泥浆里再测一次两点电压差值至少 0.5V 以上才算接线正常。5.2 WiFi 断开后设备不再重连必须按复位键才能恢复现象路由器重启或者设备移动到另一个 AP 覆盖范围后设备一直连不上 WiFiMQTT 也不上线其他代码逻辑好像还在跑。原因很多初版固件把WiFi.begin()写在 setup 里只调用一次WiFi 断线后系统不会自动重新发起连接主循环里的client.loop()虽然还在执行但底层网络已经断了。解决在loop()里加网络状态检查每次循环判断WiFi.status() ! WL_CONNECTED就执行WiFi.disconnect()和WiFi.reconnect()。更稳妥的方式是使用 ESP32 的 WiFi 事件系统注册断开事件回调自动重连。void onWiFiEvent(WiFiEvent_t event) { if (event ARDUINO_EVENT_WIFI_STA_DISCONNECTED) { WiFi.begin(ssid, password); // 断开后自动重连 } }事件方式的好处是断开瞬间立即触发重连不需要等主循环轮询。注意WiFi.reconnect()在某些 SDK 版本里偶尔会卡住所以我在重连前先disconnect()相当于把网卡状态重置一遍再重新拉起。5.3 MQTT 消息能收到但数据库里没有新增记录现象服务端终端里能看到on_message打印出的 JSON 报文但打开数据表发现一条新数据都没有。这是最让人抓狂的排查过程因为第一步看起来完全正常。原因通常是三类问题叠在一起。第一JSON 字段名和 SQL 占位符对不上比如设备端发的是soilRawSQL 里写的却是soil_rawpymysql 会直接报 KeyError。第二conn.commit()没有调用MySQL 事务没提交数据停留在会话缓冲区表里当然查不到。第三异常被except Exception吞掉没有打印也没有写文件看起来就像一切正常。解决先把异常处理改成写文件代码见 4.2 小节确保任何错误都有记录。然后用cursor.execute前打印 payload 内容和建表字段逐个比对注意大小写和驼峰命名。最后确认订阅进程里每个execute后面跟了commit。如果还查不到直接在 MySQL 命令行执行SELECT COUNT(*) FROM sensor_log;看总数是否增加排除客户端工具刷新缓存的问题。5.4 水泵一启动 ESP32 就重启现象手动点击浇水按钮后继电器吸合水泵刚转起来ESP32 立刻复位串口监视器重新打印启动日志。有时候不是每次必现但低水位时概率更高。原因水泵启动瞬间电流比额定电流大好几倍如果继电器模块和水泵共用 ESP32 开发板的 5V 供电电压会被瞬间拉低到复位阈值以下。另一个隐藏原因是水泵断电瞬间的反向电动势会通过共用的电源地线干扰主控复位引脚。解决按 2.3 小节的方案做电源隔离水泵单独用一路电源继电器模块从这路电源取电和 ESP32 之间只共用 GND。如果已经换了独立电源还偶发复位在水泵两个端子之间反向并联一只 1N4007 二极管阴极接电源正极阳极接负极。同时检查 GPIO25 初始化时是否先拉到了不触发电平避免上电瞬间 GPIO 默认状态触发继电器误启动。5.5 前端实时曲线过一阵就不更新刷新页面才能恢复现象页面刚打开时曲线正常追加数据过了十几分钟或半小时后曲线不再变化手动刷新页面又正常了然后过一阵又停。原因WebSocket 连接被服务端或浏览器断开了而前端没有处理close事件也没有心跳保活机制。常见断连原因是服务器一段时间内没有收到任何数据帧触发代理或框架的空闲超时。解决前端在onclose里加上自动重连重连间隔用 3 秒起步同时后端每 15 秒主动发一个心跳包保持连接活跃。服务端广播逻辑里要处理 WebSocket 客户端掉线的情况不能往已断开连接里写数据否则可能抛异常导致广播线程退出。# 伪代码服务端心跳防止连接空闲断开 import asyncio async def heartbeat(websocket): while True: await websocket.send({\type\:\ping\}) await asyncio.sleep(15)前端收到ping类型消息直接忽略即可不参与曲线数据追加。这样处理后页面挂一整天曲线都能持续更新答辩演示时不用中途刷新页面救场。6. 浇灌策略进阶标定、滤波和事件日志的配合自动浇花最容易暴露问题的地方不是链路而是阈值本身。很多项目把土壤湿度 ADC 原始值直接拿来做判断比如小于 1000 就浇水。问题是不同土壤、不同品牌的传感器、甚至同一块地不同深度的读数差异都很大按固定阈值写死的逻辑换个花盆就失灵。6.1 和 6.2 分别解决“阈值怎么定”和“读数怎么稳”两个问题。6.1 阈值怎么定三档土壤标定法我建议不要用网上抄来的经验值而是自己花十分钟做一次干湿标定。取同一盆待测土壤分成三份一份在阳光下晒干或烤箱低温烘干一份喷水到“手握成团、松手散开”的半干状态一份加足水搅拌成饱和泥浆。三份分别把探头完全插入并压实记录 ADC 读数各测 5 次取平均。土壤状态示意 RAW 值相对湿度百分比干燥32000%半干2100约 50%饱和900100%映射公式用线性插值percent (raw_dry - raw) / (raw_dry - raw_wet) * 100。注意这里的 100% 表示该土壤能持有的最大水分不是土壤中水的绝对体积比。浇灌下限可以设在 30% 到 40%也就是说当 percent 低于这个值时启动水泵。不同植物需求不同多肉可以放到 20%一般绿叶植物建议 35% 起步。6.2 中值滤波和防抖让阈值判断更稳土壤湿度传感器直接读原始值时数值会因土壤颗粒接触状态波动同一位置连续读 5 次可能差出几百。直接拿单次值去判断浇水会导致水泵频繁启停。我习惯在映射前加一个中值滤波读 5 次取排序后的中间值。int readSoilFiltered() { int samples[5]; for (int i 0; i 5; i) { samples[i] analogRead(SOIL_ADC_PIN); delay(50); } // 简单的选择排序5 个元素足够快 for (int i 0; i 4; i) { for (int j i 1; j 5; j) { if (samples[j] samples[i]) { int tmp samples[i]; samples[i] samples[j]; samples[j] tmp; } } } return samples[2]; // 中值 }中值滤波能滤掉尖峰噪声但防止频繁启停还需要加防抖逻辑。常见做法是连续 3 次采样都低于阈值才启动水泵启动后设置最短运行时长和冷却时间比如单次浇水不超过 8 秒之后至少 30 分钟内不再触发。冷却时间用时间戳判断不放在循环里 delay否则会阻塞 MQTT 消息处理。整个项目收尾前把浇水动作也落库。单独建一张water_event表记录触发方式手动或自动、触发时传感器读数、请求时长和实际执行时长。这份事件日志既能用来复盘阈值设得合不合理也能在答辩时拿出数据说明系统不是拍脑袋设计。第一个养花系统项目收工那天我把阈值拍脑袋设成 3000结果花盆已经泡着水系统还判成“干”。补上标定和滤波之后自动浇水才真正敢交给用户。这件事后来成了我做所有传感器项目的习惯先标定后滤波再谈控制。希望帮到你。本文还有配套的精品资源点击获取