简介：基于STM32与ESP8266的智能家居系统完整工程代码，面向物联网爱好者、嵌入式开发者及企业智能化项目人员。系统以STM32为核心采集温湿度、光照、烟雾等传感器数据，借助ESP8266 Wi-Fi模块上云，并通过微信小程序实现远程监控与设备控制，同时融入机器学习算法进行环境自适应调节，可拓展至酒店、办公室等商用场所。资源共127个文件，压缩包约441KB，主要包含89个C/H源文件、STM32标准固件库及MQTT通信代码，另有微信小程序前端（js、json、wxml、wxss）、电路原理图PNG、Keil工程配置等，目录涵盖src、sensors、firmware、wechat_app等模块，便于直接编译部署与二次开发。已有246人学习下载。整套资料不仅提供可运行的嵌入式代码，还附带工程配置、通信协议实现及项目文档结构说明，适合希望快速入门STM32+ESP8266物联网实战或以此为原型构建商用智能家居系统的开发者参考复用。
1. 基于STM32和ESP8266的智能家居系统：这份代码包到底能干什么
做嵌入式的人接到“智能家居”需求时，第一反应往往是：用什么主控、怎么联网、云端怎么选。这个项目给出的答案很直接——STM32F103系列做主控，ESP8266做Wi-Fi透传，MQTT协议走云端，小程序当交互界面。拿到压缩包之后，你会发现里面没有花哨的RTOS，没有复杂的GUI，就是一套基于标准外设库的裸机工程：MqttKit.c处理协议栈，stm32f10x_rcc.c管时钟树，adc和i2c接传感器，usart和esp8266对话。整套思路对新手非常友好，起码不用一上来就啃Linux和路由器开发。对想快速搭一套可演示的智能家居Demo、或者把传感器采集和远程控制跑通的开发者来说，这个资源的价值在于“能落地”，而不是“看起来很高级”。
2. STM32端的环境搭建与采集逻辑：先把底层时钟和传感器跑稳
2.1 标准外设库工程的骨架：从keilkilll.bat看工程结构
解压后第一眼看到keilkilll.bat，这个批处理文件是很多人忽略但很实用的东西。它的作用是把Keil工程编译产生的中间文件（比如Listings、Objects、.o、.d等）全部清理掉。碰到换电脑、拷工程给别人、或者上传代码到仓库时，跑一下这个脚本，工程体积能从几十MB缩到几MB，省去很多“为什么我编译报错找不到文件”的麻烦。
@echo off del /f /q .\Listings\*.* 2>nul del /f /q .\Objects\*.* 2>nul del /f /q .\*.o 2>nul del /f /q .\*.d 2>nul del /f /q .\*.crf 2>nul del /f /q .\*.htm 2>nul del /f /q .\*.dep 2>nul del /f /q .\*.bak 2>nul echo Cleanup finished. pause这段脚本的逻辑很简单，就是按扩展名批量删除当前工程下的中间产物。正常编译一次后，Objects文件夹里会有大量的.o和.d文件，不清理的话，工程备份传到网盘要传半天。需要说明的是，这个清理脚本不会动源码，源文件全部在src和sensors目录下，删完之后重新打开工程文件编译一次，照样能生成新的中间文件。
2.2 时钟树配置：system_stm32f10x.c里的玄学
STM32跑不起来，八成原因是时钟没配好。这个项目里system_stm32f10x.c直接决定系统主频是多少、外设总线时钟快慢。标准外设库的启动流程是先执行SystemInit，再进入main函数。SystemInit做的事情是：把Flash等待周期设好，把PLL锁相环的倍频系数配好，然后把系统时钟切换到PLL输出。
// system_stm32f10x.c 中的关键配置段 #define PLL_SOURCE_HSI 0x00 // 内部8MHz #define PLL_SOURCE_HSE 0x01 // 外部晶振 #define PLL_MUL 9 // 8MHz * 9 = 72MHz void SystemInit(void) { RCC->CR |= 0x00000001; // 使能HSI while (!(RCC->CR & 0x00000002)); // 等待HSI就绪 RCC->CFGR = PLL_MUL | PLL_SOURCE_HSE; // 选HSE做PLL输入 RCC->CR |= 0x01000000; // 使能PLL while (!(RCC->CR & 0x02000000)); // 等待PLL锁定 RCC->CFGR |= 0x00000002; // 切到PLL时钟 }这里的PLL_MUL设成9，配合8MHz的外部晶振，得到72MHz主频。很多新手直接复制代码后发现串口乱码，那就要检查是不是把晶振换成了12MHz或者25MHz而倍频系数没改。STM32F103的APB1最高36MHz，APB2最高72MHz，如果后面的定时器分频值和预装载值都按72MHz算，一旦主频不对，定时器溢出的间隔就全偏了，传感器采样周期也会出问题。
2.3 ADC多通道采集：光敏电阻和烟雾传感器的数据入口
光照和烟雾这类传感器，输出往往是模拟电压，得靠ADC转成数字量。项目里stm32f10x_adc.c对应的就是这部分工作。常见接法是：光敏电阻和固定电阻分压，电压信号进ADC的某个通道；MQ系列烟雾模块直接输出0~5V或0~3.3V的模拟信号，经分压后进另一个通道。
// ADC1 双通道轮询采样 void ADC_Config(void) { ADC_InitTypeDef ADC_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_ADC1 | RCC_APB2Periph_GPIOA, ENABLE); GPIO_InitTypeDef GPIO_InitStructure; GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 | GPIO_Pin_1; // PA0, PA1 GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AIN; GPIO_Init(GPIOA, &GPIO_InitStructure); ADC_InitStructure.ADC_Mode = ADC_Mode_Independent; ADC_InitStructure.ADC_ExternalTrigConv = ADC_ExternalTrigConv_None; ADC_InitStructure.ADC_DataAlign = ADC_DataAlign_Right; ADC_InitStructure.ADC_ScanConvMode = DISABLE; // 不用扫描模式 ADC_Init(ADC1, &ADC_InitStructure); ADC_Cmd(ADC1, ENABLE); } uint16_t ADC_ReadChannel(uint8_t ch) { ADC_RegularChannelConfig(ADC1, ch, 1, ADC_SampleTime_239Cycles5); ADC_SoftwareStartConvCmd(ADC1, ENABLE); while (!ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC)); return ADC_GetConversionValue(ADC1); }ADC每次读一个通道，采样时间设成239.5个周期，是为了对高阻抗信号源取得更稳的结果。如果传感器输出阻抗较高，采样时间太短会导致采样电容没充满，读数会偏低且跳变严重。实际取环境光时，把PA0和PA1两个通道读出来的值做几次平均，再去映射成“亮/暗/一般”几个档位，这样上报给云端的数据才有意义。烟雾阈值判断也是类似思路，连续两次超过设定阈值才触发告警，避免瞬时尖峰误报。
2.4 I2C读取温湿度传感器：从时序到寄存器
stm32f10x_i2c.c对应的是I2C总线驱动，温湿度传感器（比如SHT系列）就走这条总线。I2C本身只有两根线，SCL和SDA，一主一从通信，时序里最怕的是SCL拉低后从设备没应答，导致总线卡死。标准外设库的I2C用事件标志轮询，每个步骤都要检查EV5、EV6这些标志位。
// I2C1 读取温湿度传感器数据 void I2C_Config(void) { I2C_InitTypeDef I2C_InitStructure; RCC_APB1PeriphClockCmd(RCC_APB1Periph_I2C1, ENABLE); RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE); GPIO_InitTypeDef GPIO_InitStructure; GPIO_InitStructure.GPIO_Pin = GPIO_Pin_6 | GPIO_Pin_7; // PB6=SCL, PB7=SDA GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_OD; // 开漏复用 GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOB, &GPIO_InitStructure); I2C_InitStructure.I2C_Mode = I2C_Mode_I2C; I2C_InitStructure.I2C_ClockSpeed = 100000; // 100kHz 标准模式 I2C_InitStructure.I2C_DutyCycle = I2C_DutyCycle_2; I2C_InitStructure.I2C_Ack = I2C_Ack_Enable; I2C_InitStructure.I2C_AcknowledgedAddress = I2C_AcknowledgedAddress_7bit; I2C_Init(I2C1, &I2C_InitStructure); I2C_Cmd(I2C1, ENABLE); }这段代码把I2C1的速率配置成100kHz，这是最兼容的模式。有些传感器支持400kHz快速模式，但通信线稍长或者外部上拉电阻阻值偏大时，高速下容易出CRC错误。我一般会先用100kHz验证能稳定读到数据，再尝试提速度。I2C总线上的上拉电阻也很讲究，常规做法是4.7kΩ，线长超过20cm建议降到2.2kΩ，否则上升沿太慢，数据会丢位。另外需要注意GPIO模式必须是开漏复用输出（GPIO_Mode_AF_OD），配错了I2C通信就会卡死。
2.5 定时器与USART：给数据打上时间戳再送出去
stm32f10x_tim.c和stm32f10x_usart.c在项目里分管两件事：定时器负责周期采样，USART负责和ESP8266对话。定时器用最基本的TIM2，分频72得到1MHz计数频率，预装载值5000，就是5毫秒一次中断，在中断里置位采样标志，主循环发现标志位被置起来就去读ADC和传感器。
// TIM2 定时中断，5ms 周期置位采样标志 void TIM2_Config(void) { TIM_TimeBaseInitTypeDef TIM_TimeBaseStructure; NVIC_InitTypeDef NVIC_InitStructure; RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, ENABLE); TIM_TimeBaseStructure.TIM_Period = 4999; // 5000-1 TIM_TimeBaseStructure.TIM_Prescaler = 71; // 72MHz/72=1MHz TIM_TimeBaseStructure.TIM_ClockDivision = TIM_CKD_DIV1; TIM_TimeBaseStructure.TIM_CounterMode = TIM_CounterMode_Up; TIM_TimeBaseInit(TIM2, &TIM_TimeBaseStructure); TIM_ITConfig(TIM2, TIM_IT_Update, ENABLE); NVIC_InitStructure.NVIC_IRQChannel = TIM2_IRQn; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 2; NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0; NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE; NVIC_Init(&NVIC_InitStructure); TIM_Cmd(TIM2, ENABLE); }USART1用PA9和PA10做收发，波特率设115200，和ESP8266默认AT指令波特率保持一致。初始化时注意使能USART时钟和GPIO复用时钟，否则串口一只发不出数据。串口发送不要用阻塞式的while等待多次，因为一旦ESP8266没有及时响应，整个系统会卡死在发送函数里，我的做法是发完一帧之后立刻退出发送函数，接收用中断+环形缓冲区，异步处理。把传感器数据和定时器时间戳拼成一个JSON字符串，通过USART发给ESP8266，这部分是STM32端所有工作的最终出口。
3. ESP8266联网与MQTT链路：把数据送上云端并接收下行的控制指令
3.1 ESP8266的AT指令配置：透传模式还是MQTT直接封装
ESP8266在项目里有两种用法。一种是把AT固件刷成MQTT固件，让模块自己完成协议解析和服务器连接；另一种是保留AT指令固件，STM32通过串口发AT命令控制模块连接Wi-Fi、建立TCP连接，再自己封装MQTT报文。从项目文件里的MqttKit.c来看，采用的是第二种思路——STM32侧直接集成MQTT客户端代码，ESP8266只负责TCP透传。这样做的优势是后续想换Wi-Fi模块不用改STM32的协议代码，改改串口AT命令就行。
// 通过USART发送AT指令控制ESP8266 void ESP8266_SendAT(const char* cmd) { printf("AT+%s\r\n", cmd); // 重定向到USART1 Delay(300); // 等待模块返回 } void ESP8266_JoinAP(void) { ESP8266_SendAT("CWMODE=1"); // 设置为Station模式 ESP8266_SendAT("CWJAP=\"MyWiFi\",\"password\""); // 连接路由器 ESP8266_SendAT("CIPMUX=0"); // 单连接模式 ESP8266_SendAT("CIPSTART=\"TCP\",\"192.168.1.100\",1883"); // 和MQTT服务器建立TCP连接 ESP8266_SendAT("CIPMODE=1"); // 进入透传模式 ESP8266_SendAT("CIPSEND"); // 开始透传发送 }这段代码里的IP和端口需要根据自己服务器的实际地址改。AT指令的每条命令都要等模块返回正确的应答标志，比如CWJAP返回WIFI CONNECTED，CIPSTART返回CONNECT OK，CIPMODE返回OK之后才能继续下一步。这里有个明显容易翻车的点：ESP8266的固件版本不同，AT指令集差异很大，旧版用CWJAP，新版可能用CWJAP或CWJAP，响应时间也各不相同。如果是ESP-01这类只有2MB Flash的模块，固件可能只支持到某个版本的AT指令，用之前先串口手动敲一条AT试一下，确认返回的是OK再继续写连接流程。
3.2 MqttKit.c的移植要点：连接、订阅、发布三个核心函数
拿到MqttKit.c之后，首先要看它封装到了什么程度。常见的实现方式是提供MqttKit_Init、MqttKit_Subscribe、MqttKit_Publish三个接口，底层通过串口把报文发出去。MQTT协议本身基于TCP，所以底层只要保证ESP8266的透传管道通畅即可。
// MqttKit 初始化与发布示例 void MQTT_Init(const char* clientId, const char* user, const char* pass) { MqttPacket packet; packet.cmd = MQTT_CONNECT; // 0x10 packet.clientId = clientId; packet.username = user; packet.password = pass; MqttKit_SendPacket(&packet); } void MQTT_Publish(const char* topic, const char* payload) { MqttPacket packet; packet.cmd = MQTT_PUBLISH; // 0x30 packet.topic = topic; packet.payload = payload; packet.qos = 0; // QoS 0，最多一次，适合传感器上报 MqttKit_SendPacket(&packet); }QoS的选择值得多说一句。温湿度、光照数据这类周期性上报，用QoS 0就够了，丢了下一帧马上补上；但如果发的是“烟雾告警”或者“门磁告警”这种事件型消息，建议至少用QoS 1，保证服务器能收到，代价是报文大小变大、响应变慢。MqttKit内部怎么处理QoS 1的应答重传，主要看它有没有实现完整的机制。如果只是较简单地把报文发出去不管确认，那就只能在应用层做重试，比如发告警后等3秒没收到服务器回执就再发一次。
订阅下行控制指令时，消息帧解析要做处理。服务器发来的数据一般是主题+内容的结构，收包后要能从中截取出payload再和预设的控制指令做字符串匹配。这里最常见的坑是收包不完整，处理办法是把收到的数据先存进缓冲区，等检测到换行符或到达包长后再一起解析，不能来一个字节就处理一个字节。我见过不少项目把0x0D 0x0A不当回事，结果控制指令明明发出去了，设备就是没反应，其实就是串口把\r\n拆成了两个回调才导致的匹配失败。
3.3 STM32端的数据封装：JSON不是只在云端才需要
ESP8266把数据发出去之前，STM32得先把数据组装成服务器能认识的格式。MQTT的payload一般不限制格式，但为了方便小程序解析，常规做法是封装成JSON，比如{"t":24.5,"h":60,"l":300,"s":0}分别代表温度、湿度、光照、烟雾状态。C语言拼JSON字符串很简单，难的是浮点转字符串。如果用的是Keil自带的sprintf，需要注意默认库对float支持不全，编译出来的固件可能在运行时格式化失败，输出的全是0。解决方法是下载MicroLib（在Keil的Options for Target里勾选Use MicroLib），或者自己实现一个浮点转字符串函数。
// 把传感器数据封装成JSON字符串 char mqttPayload[64]; int len = sprintf(mqttPayload, "{\"t\":%.1f,\"h\":%.1f,\"l\":%d,\"s\":%d}", temp, humi, light, smoke); MQTT_Publish("sensor/data", mqttPayload);另一个坑是JSON的键名要和微信小程序端保持一致。小程序那边如果写的是payload: data，但设备端发的是payload.d，那不管刷多少遍固件，App端解析不出来。这类问题处理时需要先把ESP8266收到的原始报文抓出来看，把MQTT Broker上订阅到的消息原文和App端收到的对比，定位到底是哪一端丢了字段。
3.4 Flash掉电存储：配网信息与设备状态怎么保存
stm32f10x_flash.c在这个项目里承担一个容易忽略的职责：保存Wi-Fi名称、密码以及设备的开关状态。如果不做这一步，设备每次断电重启都得重新配网，实际使用体验很差。STM32内部Flash的写入按页操作，F103系列一页是1KB或者2KB，和具体的型号有关，写之前需要先擦除整页，不能只擦一个字节。
// 保存配网信息到内部Flash void SaveWifiConfig(char* ssid, char* pass) { uint32_t addr = 0x0800F000; // 分配到最后一页 FLASH_Unlock(); FLASH_ErasePage(addr); for (int i = 0; i < strlen(ssid); i++) { FLASH_ProgramHalfWord(addr + i * 2, (uint16_t)ssid[i]); } FLASH_Lock(); }写Flash有一个风险点：若在写入过程中系统掉电，这一页的数据可能损坏。但平常要注意的是不能用常规的内存指针直接往Flash地址写数据，必须通过标准外设库的FLASH_Program函数。还要注意F103的Flash擦写次数有限，虽然实际能撑很久，但不要在主循环里频繁写Flash，比如开关状态一变化就立刻存一次，容易缩短寿命。比较好的做法是设置一个标志位，状态改变后延迟5秒再写，或者只在掉电前保存一次。
3.5 CAN总线预留：为什么包里会有stm32f10x_can.c
stm32f10x_can.c在项目里更多像一个预留接口。智能家居场景中，CAN总线可以用于扩展有线节点，比如卧室的温控面板、厨房的烟雾探测器，走CAN总线比无线更可靠。如果直接用另一块STM32当子节点，CAN的收发逻辑还能复用。CAN配置里波特率计算和采样点设置是关键，F103的CAN外设挂在APB1总线上，时钟是36MHz，要得到500kbps的波特率需要分频和重同步跳转宽度配合。没有强需求的话，这段代码可以先不深入，知道它是为后续扩展做准备就够了。
4. 联调避坑：把TCP透传、数据解析和掉线重连一次跑通
4.1 现象：ESP8266连接Wi-Fi一直失败，偶尔成功一次后又掉线
- 现象：AT+CWJAP返回ERROR，或者连接成功后过几秒又断开，日志里能看到WIFI DISCONNECT。
- 原因：一个是路由器信道和模块兼容性问题，ESP8266对信道较窄的路由器支持不好，老款路由器信道带宽设在20MHz以下就容易掉。另一个是供电不足，ESP8266在Wi-Fi发射瞬间电流会飙到300mA甚至更高，用STM32开发板的3.3V LDO供电通常不够稳。
- 解决：先排除供电，用独立的AMS1117-3.3或MP1584模块给ESP8266供电，输入端加一个100uF电解电容和一个小容量陶瓷电容。如果还是掉，把路由器信道固定在6或1，频宽设为40MHz，关闭Wi-Fi省电模式。切记ESP8266的EN引脚不能悬空，要拉高。
4.2 现象：MQTT连接能建立，但数据发不到服务器
- 现象：CIPSTART显示的TCP连接正常，CIPSEND之后也返回了大于0的字节数，但服务器端就是收不到主题消息。
- 原因：ESP8266的透传模式和MQTT包结构冲突。透传模式下，模块把所有字节都当成数据流扔出去，但如果服务器是MOSQUitto这类严格校验的Broker，MQTT报文头里的剩余长度字段计算错误，服务器直接丢弃连接。
- 解决：用串口抓包工具看MqttKit发出去的报文十六进制。重点检查CONNECT报文的第一帧是否是10 XX XX 00 04 4D 51 54 54，其中XX代表剩余长度，必须符合MQTT规范。另外检查KeepAlive字段，不要设0，否则部分Broker认为客户端不发送心跳就判定掉线。
4.3 现象：串口收到的控制指令永远是乱码
- 现象：手机小程序发送“灯开”，设备端收到的却是类似\xEF\xBF\xBD的内容。
- 原因：编码不匹配。ESP8266透传时，STM32的USART只认识字节流，不区分UTF-8还是GB2312。小程序端发送的字符串如果是UTF-8编码，设备端直接判断“灯开”这几个中文字符的字节数组就能匹配，但有些小程序框架会转成Unicode或者URL编码，导致字节序列完全不同。
- 解决：在设备端做字符串匹配之前，先把收到的字节流转成ASCII可见字符，匹配规则用英文关键字，比如"light:on"，不要用中文做命令字。这是最省事也最稳的方案。如果确实要用中文，那就要在设备端把收到的字节流和UTF-8编码的字节序列逐一对比，任何一位不对都算不匹配。
4.4 现象：STM32复位后传感器读数跳变异常
- 现象：上电后前几次读ADC数值飘忽不定，用万用表量传感器输出却正常。
- 原因：ADC刚上电时的参考电压还没稳定，内部采样电容也是空的，采样保持时间不够。另一个原因是传感器模块等了5秒就初始化，I2C那边的传感器上电后还需要一段稳定时间。
- 解决：在系统启动时对ADC做一次自校准，然后丢弃前20次采样。传感器初始化加一个至少1秒的延时，等模块稳定再开始通信。如果读到的数值始终偏大或偏小，检查一下传感器的供电电压，模块上有稳压芯片的，3.3V和5V供电读出来的值会不一样。
4.5 现象：其他外设工作正常，但USART2收不到ESP8266的数据
- 现象：STM32发数据给ESP8266能收到，但ESP8266返回的数据进不了串口接收中断，用串口调试助手看也没有输出。
- 原因：GPIO的复用功能配置错误。USART2的TX/RX引脚是PA2和PA3，默认复用功能是USART2没错，但如果PA2上面还挂了一个外接的LED灯，电平被拉低了，数据自然收不到。另外，如果之前用JTAG口调试，SWD引脚冲突也可能导致部分外设异常。
- 解决：PA2和PA3配置为GPIO_Mode_AF_PP，确保这两个引脚没有其他负载。然后再测一下ESP8266的TX引脚是否确实有电平变化，用示波器或逻辑分析仪看波形，能省几个小时排查时间。
5. 把上报周期和遗嘱机制用起来：从能跑通到跑得更稳
系统能跑通只是第一步，想让它稳定运行，还需要处理两件周边事：心跳与掉线重连。MQTT协议里有个KeepAlive字段，单位是秒，表示客户端在多少秒内必须发一次数据给Broker，否则Broker会认为连接死了。如果项目里用MqttKit默认配置，KeepAlive往往为0，这类实时性要求不高的场景建议配成60秒。配合一个周期性任务，每30秒上报一次传感器数据，Broker那边就永远不会断开这条链路。
// 心跳与掉线检测 bool mqttConnected = false; void CheckMQTTLink(void) { if (mqttConnected == false) { MQTT_Init("stm32_device01", NULL, NULL); mqttConnected = true; } }掉线重连不能太快也不能太慢。我见过有人在主循环里不断尝试连接，结果服务器还没响应完，下一次连接请求又发进去了，导致设备轮询堵塞。稳妥的做法是重连失败后延时30秒再试，连续失败5次就休息10分钟，避免模块反复搜索路由器导致功耗升高。重连成功后，需要重新订阅下行指令主题，因为之前的订阅关系在断线后会被Broker清掉。
还有一个容易被忽略的细节：遗嘱消息。如果设备突然断电，Broker可以通过遗嘱主题告诉小程序“设备离线了”，这样App端能及时提示用户而不是一直显示“在线”。MqttKit里如果支持LWT字段，初始化时把这几个字段填好，对体验提升很明显。
用逻辑分析仪测一轮MQTT数据包，看CONNACK返回码。如果是0x00就是完全正常，如果返回0x05说明连接被拒绝，账号密码或Client ID冲突是主要原因。从那以后我把Client ID的生成规则改成了固定的设备MAC后几位，重启后也不会重复，再没出现过连接被踢的情况。这类的排查习惯，就是项目验证经验的重要一环——把这些步骤走一遍基本能确认系统在什么边界条件内是可靠的。希望帮到你。
本文还有配套的精品资源，点击获取
