简介这份基于单片机的智能家居物联网系统压缩包面向物联网、嵌入式方向的毕业设计或课程设计场景可帮助正在完成单片机课题或希望掌握STM32与物联网联合开发的学生快速入手。项目融合了单片机控制与远程通信能力重点解决环境信息采集、家电控制、云端数据交互等智能家居核心需求。压缩包共2000个文件总大小约82.98MB其中以h和c源码文件为主合计1900多个对应STM32相关固件程序此外还有docx、txt、htm、pdf、md等文档分别承担项目说明、工具下载指引、方案记录与开发参考的功能整体目录划分明确便于按模块阅读。目前已有53人学习浏览。通过这套资料读者可以看清从底层驱动编写到OneNET云平台对接的完整链路并根据附带的README、工具链接等材料搭建开发环境、调试程序对完成课程设计或毕业设计、理解智能家居物联网系统的整体架构都具有较高参考价值。1. 基于单片机的智能家居物联网系统先打通链路再谈智能“基于单片机的智能家居物联网系统”这个名字每年会出现在大量毕业论文、课程设计和开源项目包里也是很多嵌入式工程师第一个独立做完的项目。它的价值不在于板子上贴了多少模块而在于串起了三条链路传感器把温度、湿度、光照变成数字量单片机对这些数字量做本地决策控制继电器和电机再通过 Wi-Fi 模块用 MQTT 协议把状态上报到云端。三条链路断掉任何一条整个演示就只能叫“带灯的单片机”不配叫智能家居物联网系统。这类课题适合两类人一类是正在准备单片机毕业设计或课程设计的在校生手里有一块 51 或 STM32 开发板题目刚批下来还不知从哪下手另一类是产品验证期的工程师想确认“单片机加 Wi-Fi 加云平台”这条路线的稳定性是否够交付。建议不要一上来就研究外壳和 App 界面先把数据链路跑通再谈锦上添花。下面按硬件选型、通信链路、控制逻辑、联调排错四层展开每一层都会给可以直接抄的参数和代码。2. 单片机选型与传感器接入智能家居系统设计的第一层选型决定系统的成本、功耗和调试方式。如果题目只写“单片机”没指定型号绝大多数老师默认你可以用 51 或 STM32如果题目带“物联网”三个字Wi-Fi 模块就是刚需芯片必须能腾出串口、定时器和足够的 GPIO。基于 STM32 的智能家居之所以成为毕设主流不是因为性能最好而是参考代码最多、报错更容易搜到。2.1 51、STM32、ESP32 三种智能家居单片机怎么选选型主频Flash/RAM网络能力物联网协议适合场景STC89C525112 MHz8KB/512B外挂 ESP8266串口透传课程设计、纯逻辑控制STM32F103C8T672 MHz64KB/20KB外挂 ESP8266AT 指令 MQTT毕业设计主流ESP32240 MHz 双核4MB/520KB内置 Wi-Fi/BLEMQTT 原生快速原型、边缘计算51 单片机的优势是寄存器少、上手快蓝桥杯单片机课程设计里很多方案就是基于普中或 STC 开发板做的。但它没有片上调试器中断源少跑 Modbus 这类帧接收程序时要自己精细处理串口时序外挂 Wi-Fi 只能靠 AT 指令透传数据量稍大就容易卡在串口。STM32F103C8T6 是当前“基于 stm32 的智能家居”最常见的载体72MHz、64KB Flash、20KB RAM硬件 I2C、SPI、ADC、PWM 都齐全。我做这个课题时习惯把引脚分配固定成一组PA0 接 DHT11PA1 接光敏电阻PC13 接板载 LEDPA2/PA3 接 ESP8266 串口PB0-PB3 通过 ULN2003 接继电器和步进电机。引脚分配先定死后面写代码不用反复改原理图。ESP32 则适合不想折腾“单片机串口接 Wi-Fi 模块”这条链路的场景。ESP32S3 物联网项目里很多直接跑 ESP-IDF 或 Arduino 框架原生支持 MQTT 和 TLS环境监测类原型一周就能搭出来。它的缺点是外设不够“教科书味”有些评审不认为 ESP32 属于单片机。我的建议是毕设选 STM32ESP8266 更有仪式感自己做产品原型直接用 ESP32。2.2 DHT11 温湿度采集与继电器、步进电机的驱动接入DHT11 是最常见的温湿度传感器单总线协议数据脚由 MCU 拉低 18ms 发起启动信号传感器回 40bit 数据湿度高 8 位、湿度低 8 位、温度高 8 位、温度低 8 位、校验和。每一位的判别要看高电平持续时长26~28us 表示 070us 表示 1。以下代码以 STM32 HAL 库为例读一个字节static uint8_t dht11_read_byte(void) { uint8_t data 0; for (int i 0; i 8; i) { while (HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN) GPIO_PIN_RESET); delay_us(40); // 高电平持续 40us 后采样 data 1; if (HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN) GPIO_PIN_SET) { data | 0x01; } while (HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN) GPIO_PIN_SET); } return data; }这段代码的关键在delay_us(40)之后的采样点0 位高电平只维持 26us 左右40us 时已经变低1 位高电平维持 70us 左右40us 时还是高。数据线要接 4.7kΩ 上拉电阻到 3.3V读取间隔必须大于 1s否则传感器不响应返回的校验和恒为错。实际工程里必须在两个 while 循环中加超时计数防止传感器总线被拉死时整个系统卡住。执行器方面继电器和步进电机最省事的驱动方案是 ULN2003。常有人问 3.3V 单片机能不能驱动达林顿模块答案是 ULN2003 输入端只需 2.4V 以上就能饱和3.3V GPIO 串 1k 电阻直接推没有问题。它一路最大能过 500mA驱动小型继电器线圈和两相步进电机都够用。GPIO 不够时用两片 ULN2003 合起来就是 16 路输出比扩 IO 芯片省事得多。器件工作电压推荐接法常见坑DHT113.3~5V数据线接 PA0加 4.7k 上拉读数间隔低于 1s 会校验失败继电器模块5VULN2003 驱动低电平触发GPIO 直驱会拖垮 3.3V 电压HC-SR501 人体感应5V输出串 1k 电阻后分压到 3.3V长期直连 3.3V GPIO 有烧毁风险ESP8266 模块3.3V独立 LDO就近放 100uF0.1uF 电容供电纹波大时 Wi-Fi 反复重启2.3 供电与电平匹配3.3V 和 5V 器件共存时的 4 个坑一套完整板子至少需要两路电源5V 给传感器和继电器模块3.3V 给 MCU 和 ESP8266。AMS1117-3.3 是最常见的 LDO但输入电压不能超过 15V持续 800mA 以上电流时发热明显而 ESP8266 发射瞬间电流能到 300mA 级别压降一大会直接复位。注意遇到“Wi-Fi 一连就重启”先量电源纹波别急着改代码。电源问题引发的故障现象和程序 bug 几乎一模一样。电平匹配是另一个高发问题。DHT11 和 HC-SR501 工作在 5V输出高电平接近 5V直接进 STM32 的 3.3V GPIO长期使用有风险。常见做法是串 1k 电阻后对地并 2k 电阻分压到 3.3V或者干脆用光耦隔离。继电器模块则相反多数是低电平触发代码里逻辑要反转否则上电瞬间继电器会误动作一次。3. 物联网通信链路MQTT 协议与单片机入网实现科普圈流传过“物联网起源口红说”这类段子真伪不重要它想表达的是物联网技术的价值在于把物理世界变成可远程访问的数据。对单片机项目来说这一步就是把 ESP8266 变成数据通道用 MQTT 协议把传感器数据送到 broker再由 broker 转发给 App 或云平台。3.1 组网方案对比为什么智能家居大多选 Wi-Fi 加 MQTT方案需要网关参考功耗速率智能家居场景Wi-Fi无直连路由器较高Mbps 级单品上云最省事ZigBee需要协调器低250kbps全屋组网、节点多BLE手机/网关低1Mbps近场控制4G/Cat.1无高Mbps 级无宽带环境室内智能家居最优先选 Wi-Fi原因很直接家里本来就有路由器不需要额外网关ESP8266 模块成本不到十元。ZigBee 功耗和组网能力更好但开发要过协议栈调试门槛高。BLE 适合手机近场控制做远程控制还要再加网关。4G 模块单价高、功耗大只在没有宽带的环境才需要考虑。MQTT 是物联网应用层的事实标准发布订阅模型天然适合“一个设备上报、多个终端订阅”的智能家居场景。和 HTTP 轮询相比MQTT 保持长连接服务端可以主动下发指令设备端不用时刻开着 HTTP 服务省电也省流量。3.2 MQTT 发布订阅机制与主题设计MQTT 里有三个角色发布者、订阅者和 broker。设备上报数据时往主题smart_home/{device_id}/up发消息App 和云平台订阅这个主题就能收到云平台要控制设备时往smart_home/{device_id}/cmd发消息设备订阅这个主题就能收到指令。主题用/分层匹配单层#匹配多层比如订阅smart_home//up能收到所有设备的上报。QoS 参数要按场景选。QoS 0 只发一次可能丢QoS 1 保证至少到达一次但可能重复QoS 2 确保恰好一次开销最大。温湿度上报用 QoS 1 比较合适重发一条旧数据代价很小继电器控制指令建议也用 QoS 1但要在设备端做指令去重避免同一个“开灯”消息执行两次。调试时如果用的是 OneNET 这类云平台应用管理里可以直接绑定数据流画折线图省掉所有前端工作。自建 broker 则推荐 EMQXDocker 一条命令就能起服务Web 控制台里能看到每个客户端的连接状态和收发消息数。3.3 端侧通信代码ESP8266 AT 指令与数据封装3.3.1 用 AT 指令建立 Wi-Fi 与 MQTT 连接ESP8266 最常见的用法是刷 AT 固件通过串口收发字符串指令。把 AT 指令封装成一个带超时的函数是整个通信模块的地基uint8_t cmd_expect(UART_HandleTypeDef *huart, const char *cmd, const char *expect, uint32_t timeout_ms) { char buf[128]; uint16_t idx 0; __HAL_UART_CLEAR_OREFLAG(huart); // 清空串口残留数据 HAL_UART_Transmit(huart, (uint8_t *)cmd, strlen(cmd), 1000); uint32_t start HAL_GetTick(); while (HAL_GetTick() - start timeout_ms) { uint8_t ch; if (HAL_UART_Receive(huart, ch, 1, 50) HAL_OK) { if (idx sizeof(buf) - 1) { buf[idx] (char)ch; buf[idx] \0; } if (strstr(buf, expect) ! NULL) { // 匹配到预期关键字 return 0; } } } return 1; // 超时未匹配 }这个函数的核心是把“发指令、等应答、判结果”三件事合成一步。timeout 参数要根据指令特点区分修改 Wi-Fi 模式只要 2~3 秒连接路由器可能要 15 秒连接 MQTT broker 也要留足 10 秒。匹配关键字比匹配 “OK” 更可靠比如连 Wi-Fi 时要匹配WIFI GOT IP否则很容易出现 AT 回了 OK 但实际没拿到 IP 的假成功。调用序列如下cmd_expect(huart2, ATCWMODE1\r\n, OK, 3000); cmd_expect(huart2, ATCWJAP\AP_NAME\,\PASSWORD\\r\n, WIFI GOT IP, 15000); cmd_expect(huart2, ATMQTTUSERCFG0,1,\NULL\,\dev_01\,\token123\,0,0,\\\r\n, OK, 2000); cmd_expect(huart2, ATMQTTCONN0,\broker.example.com\,1883,1\r\n, OK, 10000);ATMQTTUSERCFG的参数依次是链路 ID、协议类型、clientID、用户名、密码、证书相关配置不同 AT 固件版本字段略有差异以固件手册为准。ATMQTTCONN里的broker.example.com要替换成实际 broker 地址最后一个参数 1 表示断线自动重连。连接的建立只是开始后续所有上报都要复用这个链路 ID。3.3.2 用 cJSON 组装上报数据并解析下行指令单片机端拼 JSON 字符串容易出错直接引入 cJSON 库生成和解析都更安全。以下代码把温湿度封装成 JSON 后通过 MQTT 发布char body[96]; snprintf(body, sizeof(body), {\type\:\env\,\temp\:%.1f,\hum\:%.1f}, temp, hum); cmd_expect(huart2, ATMQTTPUB0,\smart_home/stm32/up\,1,0\r\n, , 1000); HAL_UART_Transmit(huart2, (uint8_t *)body, strlen(body), 1000);ATMQTTPUB的参数分别是链路 ID、主题、QoS 和 retain 标志。retain 设为 0 表示消息不保留新订阅的设备不会立即收到旧状态如果想让 App 打开就能看到当前温湿度可以把它设为 1。注意是 ESP8266 返回的“等待数据”提示符收到它之后必须在超时时间内把 body 发过去否则发布失败。下行指令的解析同样用 cJSONvoid parse_cmd(char *payload) { cJSON *root cJSON_Parse(payload); if (!root) return; cJSON *type cJSON_GetObjectItem(root, type); cJSON *value cJSON_GetObjectItem(root, value); if (cJSON_IsString(type) cJSON_IsNumber(value)) { if (strcmp(type-valuestring, relay) 0) { HAL_GPIO_WritePin(RELAY_PORT, RELAY_PIN, value-valueint ? GPIO_PIN_SET : GPIO_PIN_RESET); } } cJSON_Delete(root); // 不删会造成内存泄漏 }单片机内存本来就紧张cJSON_Parse每次都会动态分配内存解析完必须cJSON_Delete否则长时间运行后堆内存碎片化设备会莫名其妙死机。这是物联网设备“跑几天就挂”的头号原因。3.4 断线重连与 keepalive设备不掉线的底线MQTT 连接不是永久的路由器 NAT 超时、Wi-Fi 信号波动、broker 重启都会让连接断开。设备端要定期发心跳同时实现重连。常见的 keepalive 值取 60 秒broker 在 1.5 倍时间内没收到任何报文就会把连接标记为断开。重连策略用指数退避避免大量设备同时重连把 broker 打崩uint32_t retry_ms 3000; while (!mqtt_is_connected()) { if (cmd_expect(huart2, ATMQTTCONN0,\broker.example.com\,1883,1\r\n, OK, 10000) 0) { break; } HAL_Delay(retry_ms); if (retry_ms 30000) retry_ms * 2; // 3s - 6s - 12s - 30s 封顶 } retry_ms 3000;重连成功后要把所有订阅重新做一遍因为 broker 不会记住设备之前的订阅关系。另外要留意 ESP8266 在重连阶段占用的时间这段时间里如果主控还在忙于读传感器建议把采集任务暂停先保证通信链路恢复。4. 本地控制逻辑与智能家居场景联动状态机、定时任务与阈值控制上云之后控制逻辑反而不应该全部放在云端。断网时一套智能家居至少得保证本地开关和阈值控制还能工作否则“智能”会变成“智障”。这一层用状态机解决按键可靠性用定时任务解决周期操作用回差控制解决环境联动。4.1 当单片机遇上状态机按键与开关的可靠处理当单片机遇上状态机通常意味着代码开始从一长串 if 变成有结构的状态转换。智能家居里最常见的状态机是按键消抖。机械按键按下和释放时都有抖动不做处理会出现按一次翻转两次的问题typedef enum { KEY_IDLE, KEY_WAIT_RELEASE } key_state_t; void light_switch_fsm(key_state_t *st, uint8_t key_level) { switch (*st) { case KEY_IDLE: if (key_level 0) { // 检测到按下 toggle_light(); // 翻转灯状态 *st KEY_WAIT_RELEASE; } break; case KEY_WAIT_RELEASE: if (key_level 1) { // 释放后回到空闲 *st KEY_IDLE; } break; default: *st KEY_IDLE; break; } }这段状态机的核心思想是只有从空闲态检测到低电平才触发动作然后必须等按键释放才能回到空闲。这样即使抖动造成电平在几十毫秒内反复跳变也不会多次触发。如果对端的传感器是 Modbus 协议逐字节接收的帧状态机同样适用只是状态多了“等待功能码、等待数据长度、等待 CRC”几步。4.2 定时任务与时间基准从软件定时器到 NTP 对时单片机里做定时任务不要用HAL_Delay阻塞要用系统节拍判断uint32_t now HAL_GetTick(); if (now - last_1s_tick 1000) { last_1s_tick now; dht11_read_and_update(); // 每秒读一次温湿度 }这种写法不会阻塞主循环多个定时任务可以共用同一个节拍变量。注意HAL_GetTick()在系统运行 49 天后会溢出严格产品代码要处理回绕问题课程设计和毕设阶段可以直接忽略。如果需要真实时间而不想加 RTC 芯片可以让 ESP8266 做 SNTP 对时。AT 固件通常支持ATCIPSNTPCFG设置好时区后从 NTP 服务器拿时间再通过ATCIPSNTPTIME?读出来。获取到时间后定时开关灯、定时上报这类功能就不用依赖 App 端定时了。4.3 本地联动规则阈值回差与环境监测自动控制环境监测项目里最常见的是温湿度联动风扇。这里必须用两个阈值而不是一个温度升到 28℃ 开风扇降到 26℃ 才关中间的 2℃ 就是回差。#define FAN_ON_THRESHOLD 28.0f #define FAN_OFF_THRESHOLD 26.0f // 回差 2 度 void env_control_task(float temp) { static uint8_t fan_on 0; if (!fan_on temp FAN_ON_THRESHOLD) { HAL_GPIO_WritePin(FAN_PORT, FAN_PIN, GPIO_PIN_SET); fan_on 1; } else if (fan_on temp FAN_OFF_THRESHOLD) { HAL_GPIO_WritePin(FAN_PORT, FAN_PIN, GPIO_PIN_RESET); fan_on 0; } }如果只有一个 28℃ 阈值温度在 27.9 和 28.1 之间波动时继电器会高频抖动触点寿命和电磁噪音都受不了。回差是工业控制里的标准做法智能家居做阈值联动时必须加上。规则触发条件执行动作备注高温开风扇温度 ≥ 28℃置位风扇继电器回差 2℃低于 26℃ 关湿度过大开窗湿度 ≥ 75%步进电机带开窗器需要限位保护光照过低开灯光照 50 lux打开灯回路可在云端再叠加定时云平台端的联动可以做得更复杂比如 OneNET 平台能直接基于数据流配置告警和应用。但本地规则必须保留一份原因很简单Wi-Fi 断了智能家居至少要能当普通家电用。无源物联网是更前沿的方向但在课程设计和原型阶段有源供电加本地降级逻辑仍然是最稳妥的路线。5. 智能家居物联网系统联调顺序与三个必调参数5.1 从点灯到上云的联调顺序联调最忌讳把所有东西焊好再上电一次要面对的问题太多根本定位不了。我一般按下面的顺序走每步都确认通过再进下一步步骤操作通过标准1烧写点灯程序LED 按预期亮灭2串口打印 DHT11 温湿度数值合理且校验通过3ESP8266 单独连 Wi-Fi串口出现WIFI GOT IP4连 MQTT broker 并上报在 MQTTX 或云端看到 JSON5App 下发继电器指令LED/继电器状态翻转Proteus 里能仿真的单片机型号以 51 和 STM32F103 为主控制逻辑演示没问题但 ESP8266 这类联网外设仿真支持很弱网络链路必须用实物验证。仿真省下的时间最后都会在实物联调里还回去。5.2 MQTT keepalive、串口空闲中断、电源余量三个必调参数第一个必调参数是 keepalive。设备端设 60 秒broker 超时至少设两倍否则公网链路的 NAT 会话超过设备心跳周期被回收设备还以为自己在线实际已经失联。如果走的是云平台按平台文档给出的最小保活时间配置即可。第二个必调参数是串口接收方式。用阻塞式HAL_UART_Receive接收 ESP8266 的 AT 应答主控在等待期间无法处理其他任务。GPIO 抖动、传感器时序、定时任务都会受影响。建议改成 DMA 加串口空闲中断把接收到的数据丢进环形缓冲区主循环只负责解析。第三个必调参数是电源余量。ESP8266 发射峰值电流近 300mAAMS1117 在这种工况下压降明显。条件允许就换成 DC-DC或者至少把电解电容加大到 470uF并保证 3.3V 和 5V 供电完全分开。5.3 用 MQTTX 和 mosquitto_sub 验证数据链路电脑上装一个 MQTTX或者直接用 mosquitto 命令行工具订阅主题就能看到设备上报的原始数据mosquitto_sub -h broker.example.com -p 1883 \ -t smart_home//up -v订阅后如果能看到类似{type:env,temp:26.5,hum:60}的 JSON说明传感器、单片机、ESP8266、broker 四条链路全部通了。接着再发一条下行指令验证控制回路mosquitto_pub -h broker.example.com -p 1883 \ -t smart_home/stm32/cmd \ -m {type:relay,value:1}看到继电器吸合同时 MQTTX 里收到设备侧回发的确认消息整个系统的数据闭环就验证完成。记住验证时要盯着串口日志同时观察设备侧行为别只盯云平台。本文还有配套的精品资源点击获取