简介：这是一套面向嵌入式物联网方向课程设计与毕业设计的智能蜂箱软硬件综合方案，适合STM32开发者、电子竞赛参赛者及单片机入门进阶者参考复刻。资源包含完整工程源码、配置文件与可视化界面资源，以Java程序、XML界面布局、PNG图像素材及Gradle构建脚本为主，共149个文件，压缩包仅2.43MB，结构紧凑便于快速部署。方案覆盖从硬件引脚定义到软件逻辑实现的完整链路，尤其适合不会画PCB的初学者，可按引脚改用面包板与杜邦线连接外设模块，烧录源码即可复现。项目核心逻辑位于HistoryFragment等Java类中，配合界面资源，可直接应用于项目开发、课程大作业、工程实训等场景，也可作为大创竞赛或初期立项的起点进行功能扩展。目前已有276人学习下载，作者深耕嵌入式领域，使用中遇到问题可通过CSDN私信交流，便于快速排错。
1. 智能蜂箱课程设计：为什么一个带zip的软硬件选题值得做
物联网课程设计年年扎堆在智能家居、智能大棚上，十个题里八个撞车。智能蜂箱这个方向冷门，但恰好是「一套完整物联网软硬件」的理想载体：感知层有温湿度、称重、振动三类信号，网络层走MQTT，应用层做看板曲线，数据本身还有故事可讲——蜂群缺蜜时重量往下掉，分蜂前几天振动和声学特征会突变。这个zip标题意味着交付物里同时包含固件源码、后端服务、接线图和设计文档，正好把「从传感器到曲线」的整条链路拆开讲清楚。适合物联网工程、电子信息、计算机方向需要做软硬件课设或毕设的人，也适合想参赛的团队拿来补数据链路的短板。食用菌监控、智能大棚和它同属一类综合题，但蜂箱的数据维度更新鲜，答辩时更容易讲出差异化。
2. 智能蜂箱的物联网三层架构与硬件选型：传感器和主控怎么搭才不翻车
2.1 感知层：温湿度、称重、振动传感器怎么选
先定业务范围。蜂农真正关心三件事：箱内温湿度是否异常（幼虫发育需要34到35度，过高蜂群会弃巢，过低会冻伤幼虫）、整箱重量是否快速下降（说明缺蜜或逃群）、蜂群活动是否正常（分蜂前活动特征变化明显）。所以传感器本体并不复杂，复杂的是选型精度和安装位置。
温湿度传感器，课设图省事选DHT11，但它的精度是±2度和±5%相对湿度，蜂箱里昼夜温差十几度、湿度常年在90%以上，DHT11的湿度读数在高湿段飘得离谱，曲线图上是一排锯齿，评委会直接质疑数据可信度。预算够就上SHT30，I2C接口，±0.3度，长期稳定性好；预算紧用DHT22也行，但采样间隔拉到2秒以上，别贴着datasheet的极限频率读。湿度探头必须选带防水滤膜的型号，裸探头在蜂箱里撑不过一个雨季。
称重模块是全局最容易被低估的部分。整箱蜂加蜂箱自重通常在5到15公斤，分蜂前期能到20公斤，选50公斤量程的悬臂梁式传感器配HX711比较合适。量程别贪大，同一颗24位ADC上，30公斤量程的读数和50公斤的分辨率完全不同。HX711的增益默认128倍，输出速率默认10Hz，做静态称重够用；开80Hz高速模式噪声会明显变大，没任何必要。安装时在传感器与箱体之间加橡胶垫，否则蜜蜂活动引起的箱体振动会被当成重量变化，这是称重毛刺的主要来源。
2.2 网络层：主控选型与物联网三层架构的对应
物联网三层架构——感知层、网络层、应用层——落到蜂箱上分得很清楚：传感器是感知层，WiFi或LoRa是网络层，云端服务和看板是应用层。课设要把三层都完整演示出来，主控选型就得兼顾开发速度和通信稳定性。
常见做法是ESP32直连WiFi。ESP32自带双模蓝牙和WiFi，I2C、UART、ADC资源都够用，Arduino框架下写固件比STM32快一个数量级，调试只用一根USB线。如果学校指定必须用STM32，那就STM32F103配一个ESP8266做透传，本质还是WiFi方案，只是固件里要自己处理AT指令和数据分帧。LoRa适合真实蜂场——一个蜂场几十个蜂箱、离路由器几百米——但课设现场很难凑齐一对网关和多个节点，调试天线就要好几天，不建议当主方案，写进设计文档作为「规模化扩展方案」更稳妥。
网络层有个必须处理的现实问题：演示场地的WiFi靠不靠谱。最稳的做法是固件里同时支持「路由器模式」和「手机热点模式」，把SSID和密码做成配置项，现场用手机热点兜底。MQTT通信协议是通用答案，broker跑在本地电脑上，端口1883，topic用三级结构，第3章会给完整代码。三种方案的选型对比如下：
| 方案 | 开发速度 | 演示稳定性 | 真实蜂场可用性 | 成本 |
|---|---|---|---|---|
| ESP32 + WiFi直连 | 快 | 依赖场地网络，手机热点可兜底 | WiFi覆盖差，只适合教学演示 | 低 |
| STM32 + ESP8266透传 | 中 | 同上 | 同上 | 低 |
| ESP32 + LoRa节点 + 网关 | 慢 | 成对设备，天线调试周期长 | 接近真实部署 | 高 |
2.3 供电、防水与低功耗：蜂箱里的一笔账
供电是课程设计翻车重灾区。ESP32在WiFi发射瞬间电流能到300mA以上，平均在80到150mA，插个充电宝看着能跑，放到户外真实环境半天就没了。常见做法是18650锂电池加TP4056充电模块，再配一块5V升压板给传感器供电；想打出「新能源+低功耗」卖点，加一块6V的5W太阳能板通过充电模块补电，整套成本多三四十块，但展示效果和设计档次的提升很明显。
低功耗要落到代码上，光选低功耗芯片没用。ESP32的modem sleep能省掉大半WiFi功耗，deep sleep能到几十微安，代价是每次唤醒都要重连WiFi和MQTT，重连过程三四秒，这个时间窗采不到数据。课设如果按「定时采集」设计——比如每15分钟醒一次、工作20秒上报——deep sleep完全够用；如果要做「持续监测」，就保持modem sleep加定时上报。细节上还有一笔账：把板载电源指示灯和状态LED跳线断开，整机电流能再降几毫安。
防水防潮这块，很多人体会不深，直到设备闷在蜂箱里一周后集体失灵。蜂箱内湿度常年80%以上，昼夜温差导致结露，水汽顺着排针和传感器引脚爬进电路板。正经做法是电路板刷三防漆或整体灌封，排针连接处打热熔胶，外壳倒装让线缆从下方走形成滴水檐。温度探头挂在副盖上方的空腔里，测的是箱内环境温度而不是巢脾温度，设计文档里要把这个口径写清楚，省得答辩被追问。
3. 固件侧的核心代码：传感器采集、滤波与MQTT上云
3.1 用ESP32读传感器：一个能跑的最小固件
写完选型，进入能抄作业的部分。下面这个固件是课设里最常用的一版骨架：上电连WiFi、连MQTT broker，之后每15秒读一次传感器，把温湿度重量打成JSON发到指定topic。代码在Arduino框架下编译，需要提前装好PubSubClient、DHT sensor library和HX711三个库。
// beehive_node.ino —— 智能蜂箱采集节点（ESP32 + DHT22 + HX711） #include <WiFi.h> #include <PubSubClient.h> #include <DHT.h> #include <HX711.h> #define DHTPIN 4 #define DHTTYPE DHT22 #define LOADCELL_DOUT_PIN 16 #define LOADCELL_SCK_PIN 17 const char* ssid = "your_wifi"; const char* password = "your_pass"; const char* mqttServer = "192.168.1.100"; // 电脑上跑的MQTT broker地址 const int mqttPort = 1883; const char* beeId = "001"; DHT dht(DHTPIN, DHTTYPE); HX711 scale; WiFiClient espClient; PubSubClient client(espClient); void connectMQTT() { while (!client.connected()) { if (client.connect(beeId)) { client.publish("beehive/001/status", "online"); } else { delay(2000); } } } void setup() { Serial.begin(115200); dht.begin(); scale.begin(LOADCELL_DOUT_PIN, LOADCELL_SCK_PIN); scale.set_scale(420.0f); // 校准系数，用标准砝码标定，换传感器必须重标 scale.tare(); // 空箱去皮，开机清零 WiFi.begin(ssid, password); while (WiFi.status() != WL_CONNECTED) delay(500); client.setServer(mqttServer, mqttPort); connectMQTT(); } void loop() { if (!client.connected()) connectMQTT(); client.loop(); float h = dht.readHumidity(); float t = dht.readTemperature(); float weight = scale.get_units(5); // 连续5次读数平均，压掉随机噪声 if (isnan(h) || isnan(t)) { delay(10000); return; } String payload = "{\"id\":\"" + String(beeId) + "\",\"temp\":" + String(t, 1) + ",\"humidity\":" + String(h, 1) + ",\"weight\":" + String(weight, 2) + "}"; client.publish("beehive/001/telemetry", payload.c_str()); delay(15000); }逻辑很直白：setup里依次初始化串口、传感器、称重模块、WiFi和MQTT；loop里每轮先检查MQTT连接状态，然后读数、判错、组JSON、发布。两个细节要重点看。第一个是scale.get_units(5)，HX711单次读数噪声很大，取5次平均能在重量曲线上看到明显改善；但平均次数别超过10次，否则每组数据要等称重模块输出太久，loop周期被拉长。第二个是isnan判断，DHT22偶尔会读出NaN，不拦截就会把脏值发上云，后端数据库里全是坏点，清洗起来很痛苦，这个是血泪经验换来的。
关键参数拆开说。mqttServer指向跑着MQTT broker的电脑，课设场景通常是局域网IP；写公网域名反而容易翻车，演示场地网络策略经常不放行外网，本机broker加同一个路由器最稳。mqttPort默认1883，如果broker开了用户名密码，要在client.connect里传三个参数。beeId是蜂箱编号，多箱部署靠它区分数据，后端订阅topic也靠它。delay(15000)是15秒上报一次，偏演示向；做成真实监测就改成每5分钟一次，能明显降低WiFi功耗和broker压力。
3.2 数据滤波：为什么课设不需要卡尔曼
不少人在滤波上自我加戏，上来就写卡尔曼。卡尔曼确实高级，但课程设计99%的评分点在于数据是否连续、曲线是否平滑、异常是否被处理，而不是滤波算法深浅。对温湿度和称重这类慢变量，滑动平均已经能把HX711噪声压到可接受范围，代码也更好向评委解释。
// 滑动平均滤波，window取5，对慢变量足够 float slidingAverage(float newValue, float buffer[], int window) { static int idx = 0; float sum = 0; buffer[idx] = newValue; idx = (idx + 1) % window; for (int i = 0; i < window; i++) sum += buffer[i]; return sum / window; }这个函数的逻辑是固定长度环形缓冲，每来一个新值覆盖最旧值，返回窗口内均值。window取5，相当于把当前值和前4次读数做平均，对HX711的高频抖动抑制明显。真正要防的是野值——比如蜜蜂突然撞了一下传感器，瞬间读数跳到30公斤，均值会被拉高一大截。正确的顺序是先做野值剔除，超过上下限直接丢弃，再做滑动平均，两个函数嵌套用。卡尔曼在动态称重、无人机这类场景有优势，蜂箱重量一天变化几百克，用它纯属给自己增加答辩风险。
3.3 MQTT上报与topic设计：一个会被追问的细节
topic格式建议用三级结构：beehive/{boxId}/{command}，command取telemetry、status、alert。相比平面topic，后端可以用通配符beehive/+/telemetry一次收齐所有蜂箱的上报数据，扩容只需要改固件里的beeId，后端一行不用动。这是物联网通信技术里很基础但很加分的设计点。
发布端还要处理一个真实问题：WiFi掉线后MQTT长连接会断，client.loop()继续调用也没用。上面固件只做了「重连」，没做「补数据」。掉线期间的采样数据全部丢了，课设可能看不出来，但评委大概率会问「断网十分钟怎么补救」。常见做法是加一个环形队列缓存未发送的payload，重连后按时间顺序补发，队列上限设100条防止内存溢出。这个点写进设计文档，现场演示拔WiFi再插回，数据曲线能自动接上，项目完成度的评价会明显不一样。
4. 云端数据链路与可视化：从订阅消息到曲线展示
4.1 用Python订阅MQTT并写入MySQL：一个能跑的接收端
设备端链路通了，下一步解决「数据往哪去」。常见做法是本地跑一个MQTT broker，再用Python写一个订阅进程，把消息解析后写入MySQL。Windows下快速搭环境，就把下载的MQTT服务zip包解压，手动注册成本地服务开机自启，端口1883，配合下面的订阅脚本正好是一条完整后端链路。
# mqtt_to_mysql.py —— 订阅蜂箱主题，将消息写入数据库 import json import paho.mqtt.client as mqtt import pymysql DB_CONFIG = { "host": "127.0.0.1", "user": "beehive", "password": "your_pass", "database": "beehive_db", "charset": "utf8mb4" } def on_message(client, userdata, msg): try: data = json.loads(msg.payload.decode("utf-8")) conn = pymysql.connect(**DB_CONFIG) cur = conn.cursor() cur.execute( "INSERT INTO telemetry (bee_id, temp, humidity, weight, created_at) " "VALUES (%s, %s, %s, %s, NOW())", (data["id"], data["temp"], data["humidity"], data["weight"]) ) conn.commit() cur.close() conn.close() except Exception as e: print("写入失败:", e) client = mqtt.Client() client.on_message = on_message client.connect("127.0.0.1", 1883) client.subscribe("beehive/+/telemetry") client.loop_forever()这段代码的核心在on_message回调里：解析JSON、连数据库、插入记录。loop_forever()阻塞主线程等待消息，回调里逐条处理，不需要额外开线程。注意beehive/+/telemetry里的加号通配符，它匹配任意蜂箱编号，以后加第二台蜂箱，这个订阅进程不用改。如果broker配置了用户名密码，mqtt.Client()初始化时要传client_id，connect时要带上auth参数。
表结构至少要包含蜂箱ID、温度、湿度、重量、入库时间五列，created_at用数据库的NOW()而不是设备端时间戳。设备时钟脱机后漂移严重，以入库时间作为主时间轴，曲线横轴才能保持单调递增，详细原因放在第5章展开。如果本地没装MySQL，把pymysql换成sqlite3也能跑通，但设计文档里要说明为什么课设场景选SQLite、生产场景选MySQL，这个对比本身就是答辩加分点。数据库课程设计里那套表设计和索引优化，在这里就是三张表加一个时间索引，工作量不大但链路完整。
提示：Windows本地调试时，记得先把broker端口1883加入防火墙放行，否则ESP32大概率一直连不上，这不是代码问题，是环境问题。
4.2 可视化页面与阈值告警：ECharts把数据变成能讲的曲线
数据入库后，需要一个Web页面把曲线画出来。前端不用引框架，一个HTML文件加ECharts就够；后端用Flask或FastAPI都行，返回JSON数组，浏览器直接把数据填进图表。下面贴图表核心逻辑，接口地址按自己后端改。
// dashboard.js —— 拉取最近一小时数据并绘制温度曲线 fetch('/api/last_hour?bee=001') .then(response => response.json()) .then(rows => { const chart = echarts.init(document.getElementById('chart')); chart.setOption({ xAxis: { type: 'category', data: rows.map(r => r.created_at) }, yAxis: { type: 'value', name: '温度(°C)' }, series: [{ type: 'line', data: rows.map(r => r.temp), smooth: true }] }); });浏览器请求后端接口，后端从MySQL按时间正序取最近一小时数据，前端把created_at映射到横轴、temp映射到纵轴，画一条平滑曲线。两条实操经验：第一，接口返回的数据必须按时间正序，否则ECharts画出的线会来回折返；第二，时间过滤写进SQL而不是Python里，表上建好时间索引，连续演示一小时后页面不卡。曲线只画温度太单薄，建议同一页面再加湿度和重量两个子图，答辩时三线联动展示，比单线图有说服力得多。
阈值告警是「智能」二字最直观的落点。后端起一个每分钟扫描一次的定时任务，温度超过35度或低于5度、重量变化率超过每小时500克，就往页面推一条告警。推送通道不推荐短信，费用高且课设没预算；用WebSocket推到浏览器弹横幅，或推送到企业微信机器人，两小时能搞定。代码量不大，但能让整个系统从「数据展示」升级成「异常响应」，这是课程设计评分里很关键的一个档次差。
5. 智能蜂箱课设最容易翻车的六个地方：现象、原因与排查
5.1 数据链路：断线、时间戳与入库错乱怎么排查
先说MQTT断线重连失效，这是出现频率最高的故障。现象很典型：ESP32串口还在打印，WiFi也显示连着，但网页曲线停在某个时间点不动了。原因多半是WiFi掉线后底层TCP连接已经断开，而代码里没有监听WiFi重连事件，只依赖client.connected()判断，MQTT一直在用一条失效连接发送数据。解决要分两层：WiFi层用WiFi.onEvent捕获断线事件并触发WiFi.reconnect()，MQTT层在loop里检查连接状态并调用重连函数。重连逻辑单独抽成一个函数，别用递归重试，否则堆栈会爆。
第二个坑是时间戳错乱。现象是曲线横轴忽前忽后，甚至出现1970年。原因是设备端把本地时间塞进payload，而ESP32在无网条件下用RTC计时，掉电后回到默认时间；即使联网，时区没配置也会整体偏移8小时。最省事的解决方案是后端入库时忽略设备时间戳，统一用数据库NOW()；如果产品化要求保留设备时间，固件里要加NTP同步并做时区校准。数据库端也有坑，MySQL默认时区跟随系统，服务器时区不对会整体偏移，建表时把created_at设为DATETIME并统一用应用层时间最稳。
5.2 硬件现场：冷凝水、漂移与电池撑不过两晚
第三个坑是HX711称重漂移。现象很有意思：数据在夜里慢慢往上爬，白天又降回来，蜂没动但重量曲线像潮汐。原因是应变片受温度影响产生零点漂移，蜂箱白天被太阳晒热、夜里降温，十几度的温差被HX711增益放大后特别明显。解决思路不是换更贵的传感器，而是软件上做周期自动去皮：每天凌晨蜂群静止时读一次空载值作为新零点，存进EEPROM，断电重启还能用。另外在传感器承载台上加硬限位，防止蜜蜂或人为碰触造成不可恢复的形变。
第四个坑是蜂箱内冷凝水导致设备短路。现象是设备运行一周后突然不再上报，拆开闻到糊味或看到电路板上有水渍。原因前面说过，箱内湿度高、昼夜温差大，水汽在电路板表面凝结，排针引脚之间渗水造成微短路。解决方法是电路板刷三防漆，重点覆盖排针焊点和晶振区域；外壳倒装，所有线缆出口朝下并留滴水弯；湿度探头用带防水膜的型号。这一步偷懒省下的十分钟，会在设备报废后花两小时排查。
第五个坑是电池撑不过两晚。现象是第一天演示一切正常，第二天早上Web页面显示离线。原因是ESP32常亮状态下几十毫安起步，加上LDO静态电流和传感器，一块18650撑不过48小时，更别说很多人还带着板载LED一起跑。解决方法是给系统加深度睡眠：白天每15分钟醒来一次上报，其他时间deep sleep，整机平均电流能压到1mA以下；板上指示灯跳线断开，DHT22的采样间隔拉到10秒以上，因为每次温湿度转换本身都耗电。如果上了太阳能板，一定要配防反充二极管，否则夜间电池会通过太阳能板反向漏电。
5.3 交付物：源码版本与zip解压的两个慢性毒药
第六个坑是交付包可复现性差，最典型的表现有两种。第一种是zip里的源码烧录后跑不起来：答辩前一天解压固件、编译、烧录，串口输出乱码或WiFi连不上。原因通常是发布前的固件源码和压缩包里的版本不一致，或者配网信息还留着开发时的旧热点。解决方法是发布前从zip重新解压、全新编译、烧录验证一遍，把WiFi账号密码挪到config.h而不是写在主文件里，再从零走一遍部署流程，把命令整理成checklist写进README。
第二种是zip本身解压报错。现象是解压到一半提示文件损坏或密码错误。原因是有不少网上下载的课程设计zip带伪加密标记，或者打包工具不兼容导致压缩包头信息异常。解决方法是换成熟的压缩工具重压一遍，压缩时选标准zip格式；如果改了密码，在README第一行写明密码，否则接收方只能找发件人要密码或换工具修复，平白消耗大量时间。一个解不开的zip会让整个方案价值归零，发布前自己用干净环境测一次解压，是最便宜的后悔药。
6. 把zip交付组织成能直接答辩的工程：目录、文档与演示技巧
6.1 交付目录怎么组织
一个课程设计zip要让别人在陌生电脑上顺利跑起来，目录结构比代码本身更影响体验。常见做法是四层：01_firmware放ESP32工程，02_server放MQTT订阅和Web后端，03_docs放设计文档和接线图，04_assets放演示视频和截图。README的第一屏必须写清三件事：硬件清单、软件依赖、从零启动顺序。启动顺序按下述流程写，每步带对应命令：
# 顺序执行，本地调试一套带走 mosquitto -c mosquitto.conf -d # 1. 启动MQTT broker python mqtt_to_mysql.py & # 2. 启动数据入库进程 python web_server.py # 3. 启动看板后端新手照着这个顺序走，十分钟内能看到曲线出来。README里再加一节「常见问题」，把第5章那六个坑的排查命令直接贴进去，现场出问题能快速定位。
6.2 答辩演示的三个细节
演示环节翻车率最高的不是功能，是设备不配合。我的习惯是准备双路数据源：真的蜂箱节点加一份预录好的CSV回放数据，Web后端留一个调试接口，读CSV就能模拟MQTT实时上报。现场如果WiFi被挤爆或设备被静电打死，立刻切到回放模式，曲线照常走，答辩不受影响。第二个习惯是演示前把手机热点开好，固件里预置两个网络配置，自动选信号强的那个，这个细节能救回至少三成现场事故。
如果还想给课设加分，把重量曲线和当地天气、蜜源花期做叠加对比，说明「重量下降是自然规律还是逃群前兆」。数据故事完整，评审的印象分通常比单纯堆传感器有用。这些经验是我反复改版踩出来的：早期我总在设备端堆料，后来交付包组织利索了，才发现链路完整比功能多更重要，链路完整又不如数据能讲故事。希望帮到你。
本文还有配套的精品资源，点击获取
