简介基于STM32与ESP8266的智能物联网家居系统源码包面向嵌入式开发者和物联网方向学习者适合用于智能家居原型搭建、课程设计或毕业设计参考。项目以STM32为主控芯片结合ESP8266 Wi-Fi模块涵盖GPIO控制、ADC采集、定时器、串口通信、网络数据收发等关键开发环节能够帮助读者理解传感器数据如何采集、处理并上传至云端或APP的完整链路。压缩包共2000个文件约40.72MB文件类型以C、H源码为主配合JS、JSON、MD等文件大致覆盖固件逻辑、网页/小程序前端交互、设备配置参数和项目说明文档其中数量较多的JS文件也提示资源内包含较完整的上位机或Web端界面适合前后端对照学习。除源码外部分项目还附带设计报告与原理图便于对照硬件连接进行系统性调试。该资源已有1862人学习下载对于想快速入门STM32ESP8266物联网开发、搭建智能家居小系统的读者来说是一份内容充实、结构较完整的参考资料。1. 一款“毕业设计标配”物联网系统为什么先想清楚 ESP8266 的角色拿到这个标题时第一反应是又一个“STM32ESP8266云平台”的三件套。这类项目在STM32毕业设计和物联网入门里出现频率极高但多数人把它做成了“两块板子用杜邦线连起来串口助手看到数据就算成功”。真正的难点不在 GPIO 点灯也不在 AT 指令配网而在于把系统的分层想清楚STM32 到底管什么ESP8266 管什么两者之间用什么协议说话断网了怎么处理。ESP8266 在这类系统里最容易被当成一个“无线串口”——这是能跑通的最低理解但如果你要在答辩或实际环境里让系统稳定工作就得把它放到网络协议栈的位置上看。这篇博文从硬件连接、联网方案、Keil 工程骨架一直讲到调试三板斧照着一套我常用的实现路径让你能复现一个可上报、可控制、可断线重连的物联网家居系统。2. 硬件链路STM32 做什么、ESP8266 做什么以及连接原理图的 3 个关键细节2.1 系统拆解传感器采集、控制执行、无线回传的职责划分一个典型的智能家居节点硬件层面可以拆成四个部分传感器、执行器、主控 MCU、无线模块。传感器负责采集环境数据执行器继电器、蜂鸣器、电机接受指令动作STM32 负责把这些外设的逻辑串起来ESP8266 负责让设备“上线”。我习惯把 STM32 定位成“现场控制单元”ESP8266 定位成“网络接入单元”。为什么不让 ESP8266 直接把传感器读了呢这其实是很多教程绕开的问题。ESP8266 的 GPIO 确实能读 DHT11 这种单总线传感器也能驱动继电器但它在复杂逻辑上并不擅长。一旦你需要在本地做多传感器轮询、按键消抖、多路继电器联动还要保证毫秒级响应ESP8266 的 SDK 开发体验和调试手段都不如 STM32 顺手。反过来STM32 又没有 IP 协议栈无法直接上云。所以两者是一对互补关系STM32 对“现场”负责ESP8266 对“网络”负责。这个分工明确了后续的协议设计才有依据。模块职责接口方式典型器件传感器采集温湿度、光照、烟雾等GPIO / ADC / I2CDHT11、BH1750、MQ-2执行器通断电源、开关门窗GPIO 驱动电路继电器、ULN2003STM32轮询、控制、组帧USART / SPI / I2CSTM32F103C8T6ESP8266TCP/IP、MQTT、上云UART / SPI / I2CESP-01S、NodeMCU执行器驱动这块有个常见误解是直接用 STM32 的 GPIO 推继电器。继电器线圈是感性负载关断瞬间会产生反向电动势轻则干扰系统复位重则击穿引脚。正确做法是 GPIO 输出到三极管或 ULN2003由外部电源驱动继电器线圈同时在线圈两端并联续流二极管。ULN2003 是一个 7 路达林顿管阵列可以同时驱动多路继电器也兼容 3.3V 逻辑电平输入在物联网项目里很实用。选它不是因为“单片机 IO 不够”而是因为隔离和驱动能力更可靠。2.2 ESP8266 与 STM32 的连接原理图串口通信与电平匹配ESP8266 与 STM32 之间最常用的连接方式就是 UART。STM32F103 的 USART1 和 USART2 都可以但建议把 USART1 留给烧录调试USART2 给 ESP8266因为很多 STM32 开发板的 USB 转串口芯片直接挂在 USART1 上调试输出和 ESP8266 通信最好不要抢同一个外设。典型接线是STM32 的 PA2USART2_TX接 ESP8266 的 RXDPA3USART2_RX接 ESP8266 的 TXDGND 共地。电平匹配务必重视。STM32F103 的 GPIO 是 3.3V 逻辑ESP8266 也是 3.3V 逻辑电平本身是兼容的。但如果你用的是 5V 供电的 STM32 开发板板上可能带电平转换电路这没问题如果自己画板就得确认 STM32 的 VDD 是 3.3V。很多 ESP-01S 模块的引脚没有做电平转换强行接 5V TTL 电平会烧模块。在 ESP8266 侧还需要注意 CH_PD或 EN引脚必须拉高模块才会正常工作。ESP-01S 的 GPIO0 在正常运行时要悬空或拉高拉低会进入烧录模式。这个细节没有处理好的话模块表现为“上电后指示灯亮但不响应 AT 指令”非常容易误导排查方向。2.2.1 一键下载电路BOOT 与复位时序如果在调试阶段你需要反复给 STM32 烧写新固件建议直接用 ST-Link 的 SWD 接口占用 PA13/PA14不冲突。手动按复位键进 BOOTLOADER 的方式虽然可行但在项目迭代后期会让人抓狂。更省事的是在 STM32 的 BOOT0 引脚上接一个跳线或按键配合一键下载电路实现“按 BOOT - 复位 - 进下载模式”的流程。ESP8266 的固件烧录同理GPIO0 拉低后重新上电才能进入 UART 下载模式。如果用的是 NodeMCU 开发板板载 USB 转串口芯片已经处理好了这些时序直接用 USB 烧录即可。如果是 ESP-01S 裸模块需要自己搭一个下载电路CH_PD 接 3.3VGPIO0 接一个按键到 GND上电前按住上电后松开然后就可以用串口工具烧写固件了。2.3 电源设计3 个让系统稳定运行 24 小时的关键点电源是整个系统里最容易被低估的部分。ESP8266 在 Wi-Fi 发射瞬间的峰值电流可达 300mA 左右STM32F103 全速运行加上外设也就几十毫安两者共用一个 3.3V LDO 时如果 LDO 的电流输出能力不足电压会被瞬间拉低导致 ESP8266 反复重启或者 STM32 死机。第一个关键点是分路供电ESP8266 单独用一颗 AMS1117-3.3 或更低压差的 LDOSTM32 用另一路不要共用一颗 LDO。输入电源用 5V/2A 的 USB 适配器比较稳妥继电器直接由 5V 驱动STM32 和 ESP8266 各自降压到 3.3V。第二个关键点是去耦电容。ESP8266 的 VCC 和 GND 之间要并一个 10uF 电解电容和一个 0.1uF 陶瓷电容距离模块引脚越近越好。这颗 10uF 电容能吸收发射瞬间的电流尖峰减少电压跌落幅度。STM32 的每个 VDD 引脚附近都放 0.1uF 电容这是 STM32 数据手册明确要求的但很多自制板会省掉导致系统在继电器动作时复位。第三个关键点是地线布局。如果继电器和 ESP8266 用同一个 GND 回路继电器吸合瞬间的大电流会在地线上产生压差干扰 UART 通信。正确做法是功率地继电器、电机和信号地STM32、ESP8266单点连接或者在继电器驱动电路和 MCU 之间加光耦隔离。光耦隔离在毕业设计里不是必须的但如果你发现继电器一动作串口就收到乱码优先检查这一项。3. 联网方案选型AT 指令透传与 MQTT SDK 直连怎么选3.1 方案 AAT 指令透传STM32 通过串口裸收发最常见的联网做法是给 ESP8266 刷一个 AT 固件STM32 通过串口发 AT 指令去操作它。这种方案的优点是逻辑简单ESP8266 只是一个透明管道所有网络行为都由 STM32 串口指令触发。缺点也很明显ESP8266 的协议栈在运行但 STM32 并不知道网络断开这件事需要自己做心跳检测。一个从 AT 固件进入透传模式的指令序列大概是这样ATRST # 复位模块 ATCWMODE1 # 设为 Station 模式 ATCWJAPSSID,PASSWORD # 连接家庭 Wi-Fi ATMQTTUSERCFG0,1,clientId,username,password,0,0, ATMQTTCONN0,broker.emqx.io,1883,1 ATMQTTSUB0,home/bedroom/cmd,1 ATMQTTPUB0,home/bedroom/data,{\temp\:26.5},1逐条拆解一下ATCWMODE1只做 Station不开 AP避免模块既连路由器又开热点导致功耗翻倍ATMQTTUSERCFG里的第 2 个参数1表示使能 MQTT 的认证信息第 4、5 个参数是设备连接到云平台时使用的身份标识ATMQTTCONN里的0是 MQTT 连接号因为 ESP8266 AT 固件 2020 年之后的版本支持多路 MQTT但通常一路就够用了最后的1是 keepalive 周期单位是秒默认 120 秒这里设成 1 秒是为了更快发现断线但代价是每秒钟都会有一次心跳包流量消耗会增加。这种方案用起来很顺手但有一个陷阱通过ATMQTTPUB发送的 JSON 字符串中如果包含中文字符或者特殊符号转义会非常痛苦。数据域里只放 ASCII 字符对于温湿度、开关状态来说完全够用。心跳包的问题同样需要注意如果 STM32 在 60 秒内没有主动上报数据ESP8266 和云平台之间的 MQTT 连接可能会被服务端判定为死链而断开所以 STM32 侧要写一个定时器周期性上报或者发送空的心跳消息。3.2 方案 BESP8266 刷入 NodeMCU 固件或 MQTT 固件STM32 只发 JSON另一个常见做法是给 ESP8266 刷 NodeMCU 固件用 Lua 脚本直接跑 MQTT 客户端STM32 只需要在串口上发送预设好的命令帧ESP8266 解析后自动完成上报。这种方案把 Wi-Fi 和 MQTT 的逻辑全部放在了 ESP8266 侧STM32 的代码量大幅减少调试也更快。用 NodeMCU 的mqtt模块实现订阅的逻辑非常短wifi.setmode(wifi.STATION) wifi.sta.config(SSID, PASSWORD) m mqtt.Client(bedroom_node, 120, user, pass) m:on(connect, function(client) client:subscribe(/home/bedroom/cmd, 1, function(conn) print(subscribed) end) end) m:on(message, function(client, topic, payload) print(topic .. : .. payload) uart.write(0, CMD: .. payload .. \r\n) -- 转发给 STM32 end) m:connect(broker.emqx.io, 1883, 0)这段脚本的核心逻辑是ESP8266 连接 Wi-Fi 后主动建立 MQTT 连接订阅控制主题当云端下发指令时message回调被触发ESP8266 将原始 payload 经过uart.write原封不动地转发给 STM32。好处是 STM32 不需要关心任何网络状态只需要解析CMD:xxx这种串口帧。这个方案的风险点是 Lua 脚本和固件版本的匹配。NodeMCU 固件是按需编译的官方固件生成器上可以勾选需要的模块例如mqtt、gpio、uart等。如果你下载了一个精简固件缺少mqtt模块运行时会报attempt to index global mqtt (a nil value)。烧录时多确认一下固件是否包含了 mqtt 模块否则排查起来很耗时。另一个问题是 ESP8266 在异常复位后Lua 脚本默认从init.lua启动如果脚本里没有做断线重连设备会一直停留在离线状态直到手动重启。3.3 主题规划与 JSON 字段设计让云端和设备层不“鸡同鸭讲”无论选哪种方案MQTT 的主题Topic规划都需要提前想清楚。很多人在项目里图省事所有设备都用一个test/topic设备一多就分不清谁是谁。我常用的主题结构是home/{room}/{node}/{property}比如home/bedroom/node01/temperature表示卧室 1 号节点的温度数据home/bedroom/node01/relay1表示卧室 1 号节点的第一路继电器控制。有人会问属性拆这么细主题数量会不会爆炸对于家庭节点数量不超过十个的场景完全没有问题而且这种结构在云平台的规则引擎里做数据流转非常自然。JSON 字段设计也遵循“小步快跑”的原则。一条上报数据长这样{ node: bedroom_01, type: data, temp: 26.5, humi: 60.1, light: 320, relay1: 0, ts: 1710000000 }ts是 Unix 时间戳由 ESP8266 在转发前补上或者由云平台规则引擎打上。在数据入库之后做趋势分析时时间戳是最重要的字段。另一个实用字段是relay1把执行器的状态也嵌入到上报数据里这样云端 APP 展示设备状态时不需要再单独查询一次控制记录。控制下发的消息则更简洁{ cmd: set_relay, ch: 1, val: 1 }这种成对设计的好处是设备端处理逻辑统一上报上行数据、执行下行指令时不需要为每种业务写一套独立的解析器。STM32 端拿到CMD:{cmd:set_relay,ch:1,val:1}只需要拆 JSON 就够了而不需要自己去定义复杂的二进制协议。4. 用 Keil5 搭建 STM32 工程跑通传感器采集与串口转发4.1 工程配置标准库还是 HAL 库怎么选STM32 的开发环境是 Keil5这个问题上标准库和 HAL 库的选择直接影响后续的编码工作量。对于这种以串口和 GPIO 为主的项目标准库更直接代码量少调试时单步跟踪也更清晰HAL 库的好处是 CubeMX 生成代码引脚分配方便不容易漏配时钟。我的建议是想一次点亮、把精力放在系统逻辑上就选 HAL 库想彻底看懂寄存器级原理的用标准库顺手但要注意 ST 官方已停止维护标准库新板子如 G0/L4 系列不再支持。工程建立之后先处理 GPIO 和时钟的初始化。使用 HAL 库时MX_GPIO_Init()里需要把 PA2/PA3 复用为 USART2 引脚同时把继电器控制引脚例如 PB0-PB3配置为推挽输出。有一个参数值得留意GPIO 的速度等级默认是 LOW但 USART 引脚如果速度等级太低高速串口通信时波形会被拉变形建议把 USART 引脚的速度设为 HIGH时钟频率达到 50MHz这个设置在 CubeMX 的 GPIO_Speed 里可以直接选择。另一个是 ADC 引脚的采样时间传感器如果输出阻抗较高采样时间可以拉长到 55.5 周期避免采样值抖动。4.2 代码骨架ADC 采集、DHT11 读取与串口收发主循环的逻辑顺序可以固定为采集传感器 - 组帧 - 串口发送 - 等待串口指令 - 执行控制。下面是一段用 HAL 库写的简化主流程int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_USART2_UART_Init(); MX_ADC1_Init(); uint16_t adc_val; float temp; while (1) { HAL_ADC_Start(hadc1); if (HAL_ADC_PollForConversion(hadc1, 100) HAL_OK) { adc_val HAL_ADC_GetValue(hadc1); temp (float)adc_val * 3.3f / 4095.0f * 100.0f; } HAL_ADC_Stop(hadc1); char buf[64]; snprintf(buf, sizeof(buf), {\temp\:%.1f,\humi\:%.1f}\r\n, temp, humi); HAL_UART_Transmit(huart2, (uint8_t *)buf, strlen(buf), 1000); if (HAL_UART_Receive(huart2, (uint8_t *)rx_buf, 1, 100) HAL_OK) { // 逐字节累积到命令帧解析 CMD: 前缀 } HAL_Delay(2000); } }逐参数解释一下HAL_ADC_PollForConversion(hadc1, 100)的第二个参数是超时时间单位是毫秒ADC 转换通常只需要几十微秒100 毫秒足够了超时时间设太长会让系统卡死在等待中temp adc_val * 3.3f / 4095.0f * 100.0f这一步是把 12 位 ADC 的原始值换算成实际温度3.3V 是参考电压100 是传感器的灵敏度系数不同传感器这个系数差异很大需要根据手册调整HAL_UART_Receive(huart2, rx_buf, 1, 100)每次只收一个字节是为了不阻塞主循环配合状态机可以逐字解析出完整的控制指令。这个骨架没有用中断接收确实会牺牲一些实时性但好处是代码路径单一做毕业设计或原型验证时最不容易出隐蔽 bug。如果要在生产级项目里用建议改为 DMA 接收 空闲中断在串口收到一帧数据后自动触发解析这个优化点放到最后一章讲。4.3 数据帧封装与状态点上报指令串口组帧格式建议遵循一个固定模板而不是每次发一条 JSON 字符串到底。约定一个最小帧格式CMD:get_state CMD:set_relay,1,1 DATA:{temp:26.5,humi:60}STM32 收到CMD:get_state后把当前所有传感器状态打包成一条DATA:前缀的 JSON 报文发给 ESP8266。这个设计的好处是ESP8266 端的解析逻辑只需判断前缀是CMD:还是DATA:前者是云端下发的控制指令需要转发给 STM32后者是 STM32 上行的数据直接透传上报到 MQTT。在 STM32 端实现一个命令分发函数用strncmp匹配前缀避免使用strstr之类的模糊匹配因为strstr(CMD:set_relay, relay)在子串同名时会误触发。正确的做法是逐字节解析后做全等比较if (strncmp(rx_buf, CMD:set_relay, 13) 0) { int ch rx_buf[14] - 0; int val rx_buf[16] - 0; HAL_GPIO_WritePin(GPIOB, 1 ch, val ? GPIO_PIN_RESET : GPIO_PIN_SET); }这里有个值得注意的点GPIO 的输出电平和继电器动作是反相关系因为驱动电路是三极管或达林顿管GPIO 输出低电平才能让继电器线圈导通所以代码里写的是val ? GPIO_PIN_RESET : GPIO_PIN_SET。如果你直接让 GPIO 输出高电平控制继电器会得到相反的动作结果这也是新手最容易踩的坑之一。5. 上电调试三板斧串口分级输出、断线重连、指示灯状态机先配置好整个系统的调试基线再去折腾联网。第一步是用串口打印把 STM32 和 ESP8266 的通信链路分开验证。常见做法是给串口输出加上分级标签[DBG]表示调试信息[ERR]表示错误[DATA]表示业务数据。STM32 通过printf重定向输出到 USART1ESP8266 的透传数据从 USART2 进这样在串口助手里可以同时看到两路日志快速定位“数据是没采集到还是没发出去”。第二步是断线重连。无论是 AT 方案还是 NodeMCU 方案ESP8266 在 Wi-Fi 断开或 MQTT 掉线后短则几秒长则几分钟才能察觉。一个有效的做法是在 STM32 主循环里维护一个上报计数每 5 秒向 ESP8266 发送一条PING帧如果连续 3 次没有收到PONG响应就判断链路异常随即重启 ESP8266 的电源或拉低 RST 引脚。注意复位 ESP8266 后不要马上发数据需要等待至少 500ms 等模块重新上电完成然后重新执行 MQTT 连接序列。第三步是状态机。用 LED 的亮灭组合指示系统处于什么状态上电自检时 LED 快闪Wi-Fi 连接中 LED 每秒闪一次MQTT 已连接 LED 常亮断线重连时 LED 双闪。这个状态机写在 STM32 里同时把状态通过串口上报到云端。调试时你根本不用看电脑光瞄一眼灯的节奏就知道系统卡在哪一步。本文还有配套的精品资源点击获取