尧图网页设计 
简介基于STM32F103C8T6微控制器开发的智能家居健康环境监测系统完整代码工程面向物联网与嵌入式开发者适用于室内温湿度、光照强度、PM2.5颗粒物浓度及甲醛等有害气体浓度的实时采集与远程监控。系统通过ESP8266无线模块将数据上传至华为云物联网平台配合QT上位机实现远程数据可视化与手动/自动双模式控制自动模式下依据预设阈值联动空气净化设备异常时由蜂鸣器与LED声光报警模块即时通知用户。资源包为zip压缩格式共3个文件包含inscode工程文件、HTML说明页面与gitignore配置整体仅6KB结构紧凑。目前已有114人学习附带的HTML说明页面有助于快速了解项目结构可作为课程设计、毕业设计或智能家居产品原型开发的直接参考帮助开发者快速掌握STM32多传感器采集、ESP8266无线通信、云平台数据对接及嵌入式控制逻辑的完整链路有效缩短原型验证与迭代周期。整体方案融合多传感器采集、嵌入式控制、无线通信与云平台技术为舒适、安全、智能化的居家环境监测提供了完整解决思路。1. 项目从哪来为什么做这套STM32智能家居监测系统先交代一下背景。我之前帮朋友做了一套家庭环境监测的小东西最初的诉求很简单想知道家里温湿度、光照强度和空气质量到底怎么样最好能有个屏幕直接看也能远程用手机瞄一眼。做着做着发现这事远不止“读个传感器”那么简单——数据采集、滤波、显示、菜单交互、串口协议、WiFi上报一环扣一环任何一个环节松动整机表现就会很拉胯。市面上其实不缺成型的智能家居方案小米那种全套智能家居我也研究过但问题在于它是个封闭生态想接入自己的传感器、想改数据展示逻辑都得绕很大一圈。相比之下STM32做监测系统有天然优势外设丰富、功耗可控、成本低廉而且代码完全掌握在自己手里。这篇博客我打算把这个项目的完整思路、代码设计、选型逻辑和踩坑过程都摊开讲一遍适合正在学STM32、想拿一个综合项目练手的读者也适合要做毕业设计或者想给家里自己做一个小监测站的实践派。搜索热度里“stm32智能家居”“关于单片机32的智能环境监测系统的开源代码”这类词一直居高不下但真正把设计过程和代码逻辑讲透的文章不多。多数人拿到例子就复制粘贴跑通了就完事遇到新需求立刻抓瞎。我希望这篇能让你不仅要会跑还要知道为什么这样写、换一种传感器该怎么改、加一个新功能该动哪些代码。2. 硬件架构与选型思路先把需求翻译成电路2.1 监测对象拆解先别急着买传感器任何系统设计的第一步都不是选芯片而是明确你要采集哪些物理量。我这边定下来的是四路温度、湿度、光照强度、烟雾/空气质量。每一路对应的传感器方案都各有取舍下面是实际对比后我选型的记录表监测对象低成本方案高精度方案我最终的选择选择理由温湿度DHT11SHT30DHT11入门够用单总线协议简单成本几块钱光照强度光敏电阻ADCBH1750光敏电阻ADC占一个ADC引脚即可省I2C资源线性度够用空气/烟雾MQ-2CCS811MQ-2能测烟雾和可燃气体性价比高模拟量输出直接屏幕OLED 0.96寸TFT彩屏OLED 0.96寸I2C接口省引脚显示清晰代码驱动简单做完这个表格大概就能发现一个规律选型不是越贵越好而是看你的系统瓶颈在哪。DHT11的温湿度精度确实一般±2℃、±5%RH但监测环境趋势完全够用如果后续有更严苛的精度需求换SHT30时只需改驱动函数业务逻辑层不用动。这是我在写代码时就做了接口抽象的好处后面细说。2.2 主控选型STM32F103C8T6为什么是万金油STM32家族很大但我强烈建议第一次做这个项目的人用STM32F103C8T6别上来就追H7或者F4。原因有三条。第一资料密度全网最高遇到问题搜一下基本都有解这点在嵌入式开发里比芯片性能重要得多第二价格实在小批量几块钱一片炸了不心疼第三它的外设组合在这个项目里刚好够——ADC、I2C、USART、TIM、GPIO中断全都有但又不至于让你陷入繁琐的配置地狱。唯一要提醒的是引脚复用冲突。F103C8T6的PB3、PB4、PA15在默认状态下是JTAG调试引脚如果你把它们当普通GPIO用必须在初始化时先关闭JTAG功能只保留SWD。我第一次做的时候就把PB4接了DHT11结果一直读不到数据查了半天才发现是这个问题。后面会详细讲这个坑的排查过程。2.3 引脚分配规划一步到位避开后续改动引脚分配这块我建议在焊板子之前就画好表宁可多想一小时不要排线排到崩溃再返工。我这个项目的分配如下PA0光敏电阻分压点接ADC1_IN0PA1MQ-2模拟输出接ADC1_IN1PB4DHT11数据线需要关闭JTAGPB6OLED的SCLI2C1PB7OLED的SDAI2C1PA2USART2_TX接ESP8266的RXDPA3USART2_RX接ESP8266的TXDPA9USART1_TX调试串口输出PA10USART1_RX预留上位机通信为什么把ESP8266挂在USART2而不是USART1因为USART1我经常用来打调试日志如果WiFi也挂在上面日志和数据互相干扰排查问题的时候会非常痛苦。板子上的资源分配本质上是给“未来排错”留余地。3. 数据采集核心代码从传感器时序到干净数值3.1 DHT11单总线时序最容易被新手忽略的细节DHT11用的是单总线协议一根线上完成双向通信。主机发一个开始信号DHT11回响应然后连续输出40位数据湿度整数、湿度小数、温度整数、温度小数、校验和。代码逻辑看起来不难真正的坑在于时序要精确尤其是起始信号之后的等待时间。uint8_t DHT11_ReadData(uint8_t *humidity, uint8_t *temperature) { uint8_t data[5] {0}; uint8_t i, j; // 主机拉低至少18ms再拉高20-40us作为起始信号 DHT11_GPIO_Mode_Output(); HAL_GPIO_WritePin(DHT11_GPIO_Port, DHT11_Pin, GPIO_PIN_RESET); HAL_Delay(20); HAL_GPIO_WritePin(DHT11_GPIO_Port, DHT11_Pin, GPIO_PIN_SET); DHT11_GPIO_Mode_Input(); delay_us(40); // 检测响应低电平80us 高电平80us if (!HAL_GPIO_ReadPin(DHT11_GPIO_Port, DHT11_Pin)) { while (!HAL_GPIO_ReadPin(DHT11_GPIO_Port, DHT11_Pin)); // 等待拉高 while (HAL_GPIO_ReadPin(DHT11_GPIO_Port, DHT11_Pin)); // 等待拉低 } // 读取40位数据 for (j 0; j 5; j) { for (i 0; i 8; i) { while (!HAL_GPIO_ReadPin(DHT11_GPIO_Port, DHT11_Pin)); // 等待高电平 delay_us(40); if (HAL_GPIO_ReadPin(DHT11_GPIO_Port, DHT11_Pin)) { data[j] | (0x80 i); // 高电平超过40us判定为1 } while (HAL_GPIO_ReadPin(DHT11_GPIO_Port, DHT11_Pin)); // 等待低电平 } } // 校验和验证 if ((uint8_t)(data[0] data[1] data[2] data[3]) data[4]) { *humidity data[0]; *temperature data[2]; return 1; } return 0; }程序里最关键的是读每一位数据时用了一个40微秒的延时判断。DHT11的协议规定低电平之后的高电平持续26-28微秒表示“0”持续70微秒表示“1”。所以在高电平开始后的第40微秒去采样就能区分出0和1。这个延时如果不准读出来的数据就会乱七八糟。还有一个容易踩的坑DHT11每次读取间隔必须大于1秒否则它还在上一次的采样周期里返回的数据不会刷新。很多人的代码跑起来显示温度长期不变排查了半天供电、接线最后发现是没做读取间隔限制。我在这里用了一个简单的非阻塞计时方案uint32_t lastReadTick 0; if (HAL_GetTick() - lastReadTick 2000) { if (DHT11_ReadData(hum, temp)) { lastReadTick HAL_GetTick(); } }注意HAL_GetTick()返回的是系统上电以来的毫秒计数这个方案比HAL_Delay好得多因为它不会阻塞主循环MCU在等待期间还能处理按键、刷新屏幕、处理网络数据。3.2 ADC采集与均值滤波光敏电阻和MQ-2的接入细节光敏电阻和MQ-2都是模拟量输出处理逻辑相似接一个分压电路用STM32的ADC采集电压再映射成物理量。这里要重点讲一下分压电阻的计算因为很多人就直接抄网上的图结果输出范围完全不匹配。以光敏电阻为例光敏电阻的阻值随光照变化范围很大典型值从几千欧强光到几百千欧黑暗。我用的是10K下拉电阻串联到3.3VADC采样点放在光敏电阻和10K电阻的连接处。这样强光时光敏电阻阻值小采样点电压接近3.3V黑暗时光敏电阻阻值大采样点电压趋近0V。采集代码如下uint16_t ADC_Read(uint32_t channel) { ADC_ChannelConfTypeDef sConfig {0}; sConfig.Channel channel; sConfig.Rank ADC_REGULAR_RANK_1; sConfig.SamplingTime ADC_SAMPLETIME_55CYCLES_5; HAL_ADC_ConfigChannel(hadc1, sConfig); HAL_ADC_Start(hadc1); HAL_ADC_PollForConversion(hadc1, 10); uint16_t value HAL_ADC_GetValue(hadc1); HAL_ADC_Stop(hadc1); return value; }ADC本身是12位的读到的原始值是0-4095。要转成电压就是voltage value * 3.3f / 4095.0f。但实际使用中我发现直接拿单次采样值来做显示和判断数据波动得让人头疼。MQ-2这种传感器本身输出就有噪声光敏电阻在光线稍变时数值也会跳动。解决办法是加滑动平均滤波。我维护了一个长度为5的环形缓冲区每次采样新的值就替换最旧的值然后取平均。5次这个窗口是我实测下来比较合适的折中——太小压不住噪声太大会让响应变慢光照突变时要等好几秒才能反映到屏幕上。#define FILTER_SIZE 5 uint16_t ADC_FilteredRead(uint32_t channel, uint16_t *buffer) { static uint8_t index 0; uint32_t sum 0; buffer[index] ADC_Read(channel); index (index 1) % FILTER_SIZE; for (uint8_t i 0; i FILTER_SIZE; i) { sum buffer[i]; } return sum / FILTER_SIZE; }这里有个关键细节滤波缓冲区必须是每个通道独立一份不能共用一个数组否则两个通道的数据会互相污染。我一开始就是共用了缓冲区结果光照值偶尔会串进空气质量里查问题查了好一阵子。3.3 数据转换别用float裸奔注意MCU算力虽然STM32F103有硬件浮点单元的是F4系列F103本身不带FPU所以浮点运算全靠软件模拟速度慢不说还占Flash空间。在小数据量的场景里问题不大但如果是做周期性高频采集建议用整数运算替代浮点。比如温度显示DHT11给的是整数直接存整数就行光照强度如果要显示成“亮/暗/适中”的等级用ADC原始值和阈值比较就够了不用精确算成勒克斯。MQ-2那边我做了个简单的线性换算ppm (float)rawValue / 4095.0f * 100.0f这个精度肯定不够严谨但对家庭场景的“有没有烟雾”判断已经足够。如果你后续要做更精确的空气质量检测建议换用CCS811或者SGP30走I2C数字接口精度和稳定性都会上一个台阶。4. 人机交互设计OLED显示与按键状态机的配合4.1 为什么用OLED而不是TFT彩屏热搜词里有“tft屏幕绘制圆弧”这个方向我确实也试过用TFT彩屏跑这个项目ST7789/ILI9341这类屏幕显示效果确实炫能画曲线、出图表但代价是接口占用多、刷新帧率低时闪烁明显、驱动代码量大而且如果你要绘制圆弧、柱状图这种比较“花”的界面还得学一套图形库的画法。对于监测系统这种“以文字和数字为主”的界面OLED 0.96寸I2C版本完全够用代码量小性能开销低蓝色单色显示也够清晰。当然如果你就是想要TFT那种高分辨率和彩色效果也不是不行。我后来在给系统加“历史曲线”功能时确实考虑过换TFT但评估后放弃了——历史曲线更适合放在手机端看屏幕端只显示当前值和简单的趋势箭头就够了这是“边界设计”思路设备端不做重复工作屏幕只负责摘要细节交给云端。4.2 两级菜单状态机从轮询到事件的切换按键交互这块我用的是两个按键一个确认一个切换。屏幕显示两级菜单一级菜单是四个监测页面温度/湿度/光照/空气短按切换键循环翻页在某个页面短按确认键进入“详细模式”会显示对应物理量的历史最高值、最低值和当前值。这里不用复杂的操作系统用一个简单的状态机就够了typedef enum { MENU_MAIN, MENU_DETAIL_TEMP, MENU_DETAIL_HUMI, MENU_DETAIL_LIGHT, MENU_DETAIL_AIR } MenuState; MenuState currentState MENU_MAIN; void Menu_ProcessKey(KeyEvent event) { switch (currentState) { case MENU_MAIN: if (event KEY_SHORT_PRESS) { currentIndex (currentIndex 1) % 4; OLED_ShowMainPage(currentIndex); } else if (event KEY_LONG_PRESS) { currentState (MenuState)(MENU_DETAIL_TEMP currentIndex); OLED_ShowDetailPage(currentIndex); } break; case MENU_DETAIL_TEMP: case MENU_DETAIL_HUMI: case MENU_DETAIL_LIGHT: case MENU_DETAIL_AIR: if (event KEY_SHORT_PRESS) { currentState MENU_MAIN; OLED_ShowMainPage(currentIndex); } break; default: break; } }按键检测这里有个非常容易犯的错在定时器中断里直接做延时消抖。我之前在做一个用TIM定时器做延时的功能时不小心把消抖逻辑写进了中断回调结果整个主循环被拖慢传感器数据刷新频率肉眼可见地下降。正确的做法是中断里只记录“按键按下”事件主循环里轮询处理或者用标志位再把消抖和状态机逻辑放在主循环执行。事件驱动和轮询的区别就在这里——中断里做最少的活把处理逻辑交给主循环。4.3 屏幕刷新的隐藏性能陷阱OLED的驱动IC是SSD1306它内部有个显存我们需要把要显示的整屏数据通过I2C写入这个显存。看似简单但I2C传输速率默认在100KHz左右写一屏128×64位8字节一页共8页的数据起码要传1KB多算一下时间就不难理解为什么OLED刷新会“卡”。我的优化方案是分级刷新第一级每500毫秒刷新一次数值区域只更新变化的数字部分第二级每秒刷新一次整个数据区域防止残留和字符重叠第三级只在页面切换时调用全屏清屏。这样既保证了实时性又不会因为频繁全屏刷新导致闪烁。如果你用TFT屏幕还要画圆弧、柱状图这类图形请务必要开DMA或者用硬件SPI纯IO模拟刷一屏彩屏的颜色MCU基本就干不了别的活了。5. 数据上报链路串口帧协议与ESP8266入网的折腾5.1 自定义串口帧别把裸数据丢给WiFi模块监测系统的完整闭环最后一步是“远程查看”。我用的方案是STM32通过USART2连接ESP8266ESP8266走WiFi把数据发到MQTT服务器手机端订阅对应topic就能看到数据。第一步是定义串口协议。为什么不能直接发字符串“25.5”过去因为接收端没法判断数据什么时候开始、什么时候结束也没法做校验万一中间丢了一个字节整条数据就废了。我定义了一个简单但可靠的帧格式帧头(2字节) 数据长度(1字节) 数据类型(1字节) 数据区(N字节) CRC8校验(1字节) 帧尾(2字节)帧头固定为0xAA 0x55帧尾固定为0x0D 0x0A接收端只要识别到帧头就开始缓存接收到帧尾就校验长度和CRC。这样即使之前的数据流没有对齐也能在下一个完整帧到来时恢复同步。数据区的内容我用JSON子集的方式组织方便上位机解析比如uint8_t payload[64]; sprintf((char*)payload, {\t\:%d,\h\:%d,\l\:%d,\a\:%d}, temp, humi, light, air);5.2 ESP8266的AT指令接入MQTT流程ESP8266我用的是AT固件避免自己写SDK开发效率高很多。接入流程大致是ATCWMODE1 # 设置Station模式 ATCWJAPSSID,password # 连接WiFi ATMQTTUSERCFG0,1,client_id,username,password,0,0, # MQTT用户配置 ATMQTTCONN0,broker_address,1883,1 # 连接MQTT服务器连接成功之后上报数据就是一个ATMQTTPUB命令带上topic和payload的事。这里有个很实际的坑AT指令串口默认波特率是115200但ESP8266模块在上电初始化期间会在串口上输出一堆乱码boot信息这些乱码会和正常的AT响应混在一起。我的解决方案是上电后延时2秒等boot信息输出完毕再发AT指令同时STM32端做响应解析时把非“OK”“ERROR”等关键字的行直接忽略。5.3 断线重连策略不能傻等WiFi模块的稳定性永远是个话题。路由器重启、信号波动、MQTT服务器超时任何一次断连都会让ESP8266卡在某个状态。如果代码里不做重连机制系统状态就成了“看起来还在跑数据其实已经断了”。我用的是一个超时计数的思路每5秒检查一次ESP8266的状态用ATPING命令测网络连通性连续3次失败就判定为网络断开进入重连流程。重连流程用倒计时方式执行比如先连WiFi等10秒不行再重试WiFi连上后再连MQTT等5秒不行再重试。关键在于重连不能阻塞主循环否则传感器采集和屏幕显示都会一起卡死。如果你不想自己造这个轮子可以考虑基于MQTT和Flash的智能家居监控平台方案直接把数据接入HomeAssistant这类开源平台但代价是ESP8266端要刷专门的固件灵活性会降低。我这次还是选择自己写主要为了把协议细节吃透。6. 两类典型故障的完整排查链路6.1 延时函数卡死从“程序不跑了”到定位SysTick冲突这个坑我印象特别深。系统运行一段时间后“死机”了屏幕停在最后一帧按键也没反应。我一开始以为是程序跑飞了后来接上调试器才发现卡死在HAL_Delay里。为什么HAL_Delay会卡死因为基于HAL库的HAL_Delay依赖于SysTick中断维护的uwTick计数器。如果我在某个中断回调里也调用了HAL_Delay就可能导致SysTick中断被嵌套或阻塞。更常见的情况是在定时器中断服务函数里写了HAL_Delay。中断里调延时等于让MCU在中断里死等这时候如果有更高优先级的中断进来或者SysTick的优先级配置不当就会产生死锁。修复方案其实很简单// 能不用阻塞延时就不用尤其在中断里 // 中断里需要等待某个外设用超时循环代替HAL_Delay void ToggleLED_WithTimeout(void) { uint32_t timeout 100000; while (timeout--) { // 等待外设就绪 } }后来我把所有中断里的阻塞延时代码都换成了“状态标记 非阻塞检查”或者“超时循环”问题再没出现过。这也是嵌入式开发的一条铁律中断服务函数只做时间敏感的操作尽量不要在里面等待任何东西。6.2 ADC数值漂移的定位过程第二个典型的故障是ADC采集的光照值莫名其妙地漂数值忽高忽低即使灯光恒定读出来的值也会上下跳几十甚至上百。排查链路我是这样走的。第一步怀疑供电不稳于是用万用表量3.3V电源纹波正常第二步怀疑光敏电阻质量问题换了一个依旧第三步怀疑ADC参考电压发现STM32F103的内部参考电压VREFINT确实存在一定温漂但不至于这么夸张第四步把ADC引脚悬空测了一遍发现悬空时数值都能乱跳说明问题在引脚和采集参数本身。最终找到了两个叠加因素。第一ADC采样时间设置太短SAMPLETIME用的是1.5周期对于高阻抗源光敏电阻分压点输出阻抗很高内部采样电容还没充满就开始转换数值自然不准。解决办法是把采样时间增加到55.5周期甚至239.5周期。第二光敏电阻VP线上的走线没有做保护靠近电源线存在工频干扰。软件上我用滑动平均滤波进一步压制同时硬件上在ADC引脚和GND之间加了一个0.1uF的电容双管齐下之后数值就稳定了。这个案例最能说明问题很多“软件bug”其实是硬件问题排查时设备端的数据链路看得越细越能少走弯路。7. 项目重构与功能扩展的可行路径7.1 从F103换到G0/G4时的代码改造思路这套系统跑通之后我后续给它做了几次升级。一次是感觉DHT11的精度不够换成了SHT30驱动层改动很小因为我把传感器数据接口做成了统一的结构体typedef struct { int16_t temperature; uint16_t humidity; uint16_t light; uint16_t airQuality; } SensorData;只要新传感器驱动能填上这四个字段业务逻辑层完全不用动。这就是接口抽象的价值——你在写代码时多花的一点心思会在后期升级时成倍地回报你。如果要从F103换到功耗更低的G0系列主要工作是重写Clock配置和部分外设的HAL库调用方式但业务架构可以平移。如果换到带有硬件FPU的G4系列浮点运算可以提速不少滤波算法就可以升级成卡尔曼滤波或者更复杂的模型了。7.2 用定时器捕获做风速计一个低成本扩展方向热搜词里有“stm32定时器捕获测频率”这个方向很适合作为本项目的低成本扩展。如果你在户外放一个风速计风速信号本质是一个频率信号——风杯每转一圈干簧管或者霍尔传感器就产生一个脉冲。用STM32的TIM输入捕获模式测量两个上升沿之间的时间差换算成频率再按风速计的标定系数算出风速。我在这个项目上测试过TIM2的CH1配置为输入捕获上升沿触发中断里记录CCR值主循环里计算两次捕获之间经过的脉冲数再换算频率。因为输入捕获功能不占额外的GPIO复用现成的TIM资源就可以对系统的硬件改动几乎为零。7.3 历史数据本地存储Flash环形队列另外一个进阶方向是设备端掉电保存历史数据。STM32F103的Flash是64KBC8T6或128KBCBT6用最后几页存历史记录足够了。我实现了一个简单的环形队列每次整点存一条数据包括时间戳和四个监测值。存储时注意Flash的擦写寿命一般10万次所以不能频繁擦写同一个扇区要设计磨损均衡逻辑——记录当前写指针写满一个扇区就跳到下一个。这里不展开全部代码但有一点必须提醒Flash写入前必须先擦除而且擦除以扇区为单位如果写入过程中掉电可能损坏一批数据。工程级的做法是存双份备份或者存一条加一条CRC校验读取时跳过损坏条目。家庭监测场景不追求极致可靠性但基本的数据完整性设计还是要有。8. 一些项目复盘后的真心话整套系统从硬件设计到跑通前后花了我大概两周的业余时间。回头看项目本身难度不算大真正的价值在于让你把STM32的常用模块——GPIO、ADC、TIM、USART、I2C——全部串起来形成一个完整的业务闭环。有一点我觉得比技术细节更重要别急着写代码。先把框图画出来确认每个模块的输入输出是什么再动手。我第一版就是边写边想结果写到后面发现引脚分配不合理返工了好几次。第二版提前规划好引脚和协议开发效率直线上升。另外想说说的就是调试习惯。很多人一上来就喜欢用printf打印调试信息这在程序简单时没问题但系统复杂度上来之后建议还是把日志做成分级模式正常运行时静默只有打开调试开关才输出细节。我用的方案是编译条件开关#define DEBUG_ENABLE 1 #if DEBUG_ENABLE #define LOG_INFO(...) printf([INFO] __VA_ARGS__) #define LOG_ERROR(...) printf([ERROR] __VA_ARGS__) #else #define LOG_INFO(...) #define LOG_ERROR(...) #endif量产或正式运行的时候把DEBUG_ENABLE置0日志代码自动消失不会拖慢系统也不会刷爆串口。最后再分享一个我实际使用中的小技巧PCB上给ESP8266焊一个排针座不要直接焊死。调试阶段我要反复拔插模块刷固件、量电压排针座让我省了非常多的功夫。类似地电源入口处放一个自恢复保险丝哪怕传感器短路也不会烧板子。这些细节不会写进原理图但实际用起来能救命的东西往往就是它们。希望这套从选型到代码、再到踩坑排查的完整过程能帮你少走点弯路。如果你照着搭了一套跑起来之后想再加功能欢迎沿着我写的扩展路径继续折腾——嵌入式这行,永远是在“跑起来”之后才真正开始有意思。本文还有配套的精品资源点击获取 STM32智能家居环境监测系统开发实战：从传感器选型到MQTT数据上报
简介基于STM32F103C8T6微控制器开发的智能家居健康环境监测系统完整代码工程面向物联网与嵌入式开发者适用于室内温湿度、光照强度、PM2.5颗粒物浓度及甲醛等有害气体浓度的实时采集与远程监控。系统通过ESP8266无线模块将数据上传至华为云物联网平台配合QT上位机实现远程数据可视化与手动/自动双模式控制自动模式下依据预设阈值联动空气净化设备异常时由蜂鸣器与LED声光报警模块即时通知用户。资源包为zip压缩格式共3个文件包含inscode工程文件、HTML说明页面与gitignore配置整体仅6KB结构紧凑。目前已有114人学习附带的HTML说明页面有助于快速了解项目结构可作为课程设计、毕业设计或智能家居产品原型开发的直接参考帮助开发者快速掌握STM32多传感器采集、ESP8266无线通信、云平台数据对接及嵌入式控制逻辑的完整链路有效缩短原型验证与迭代周期。整体方案融合多传感器采集、嵌入式控制、无线通信与云平台技术为舒适、安全、智能化的居家环境监测提供了完整解决思路。1. 项目从哪来为什么做这套STM32智能家居监测系统先交代一下背景。我之前帮朋友做了一套家庭环境监测的小东西最初的诉求很简单想知道家里温湿度、光照强度和空气质量到底怎么样最好能有个屏幕直接看也能远程用手机瞄一眼。做着做着发现这事远不止“读个传感器”那么简单——数据采集、滤波、显示、菜单交互、串口协议、WiFi上报一环扣一环任何一个环节松动整机表现就会很拉胯。市面上其实不缺成型的智能家居方案小米那种全套智能家居我也研究过但问题在于它是个封闭生态想接入自己的传感器、想改数据展示逻辑都得绕很大一圈。相比之下STM32做监测系统有天然优势外设丰富、功耗可控、成本低廉而且代码完全掌握在自己手里。这篇博客我打算把这个项目的完整思路、代码设计、选型逻辑和踩坑过程都摊开讲一遍适合正在学STM32、想拿一个综合项目练手的读者也适合要做毕业设计或者想给家里自己做一个小监测站的实践派。搜索热度里“stm32智能家居”“关于单片机32的智能环境监测系统的开源代码”这类词一直居高不下但真正把设计过程和代码逻辑讲透的文章不多。多数人拿到例子就复制粘贴跑通了就完事遇到新需求立刻抓瞎。我希望这篇能让你不仅要会跑还要知道为什么这样写、换一种传感器该怎么改、加一个新功能该动哪些代码。2. 硬件架构与选型思路先把需求翻译成电路2.1 监测对象拆解先别急着买传感器任何系统设计的第一步都不是选芯片而是明确你要采集哪些物理量。我这边定下来的是四路温度、湿度、光照强度、烟雾/空气质量。每一路对应的传感器方案都各有取舍下面是实际对比后我选型的记录表监测对象低成本方案高精度方案我最终的选择选择理由温湿度DHT11SHT30DHT11入门够用单总线协议简单成本几块钱光照强度光敏电阻ADCBH1750光敏电阻ADC占一个ADC引脚即可省I2C资源线性度够用空气/烟雾MQ-2CCS811MQ-2能测烟雾和可燃气体性价比高模拟量输出直接屏幕OLED 0.96寸TFT彩屏OLED 0.96寸I2C接口省引脚显示清晰代码驱动简单做完这个表格大概就能发现一个规律选型不是越贵越好而是看你的系统瓶颈在哪。DHT11的温湿度精度确实一般±2℃、±5%RH但监测环境趋势完全够用如果后续有更严苛的精度需求换SHT30时只需改驱动函数业务逻辑层不用动。这是我在写代码时就做了接口抽象的好处后面细说。2.2 主控选型STM32F103C8T6为什么是万金油STM32家族很大但我强烈建议第一次做这个项目的人用STM32F103C8T6别上来就追H7或者F4。原因有三条。第一资料密度全网最高遇到问题搜一下基本都有解这点在嵌入式开发里比芯片性能重要得多第二价格实在小批量几块钱一片炸了不心疼第三它的外设组合在这个项目里刚好够——ADC、I2C、USART、TIM、GPIO中断全都有但又不至于让你陷入繁琐的配置地狱。唯一要提醒的是引脚复用冲突。F103C8T6的PB3、PB4、PA15在默认状态下是JTAG调试引脚如果你把它们当普通GPIO用必须在初始化时先关闭JTAG功能只保留SWD。我第一次做的时候就把PB4接了DHT11结果一直读不到数据查了半天才发现是这个问题。后面会详细讲这个坑的排查过程。2.3 引脚分配规划一步到位避开后续改动引脚分配这块我建议在焊板子之前就画好表宁可多想一小时不要排线排到崩溃再返工。我这个项目的分配如下PA0光敏电阻分压点接ADC1_IN0PA1MQ-2模拟输出接ADC1_IN1PB4DHT11数据线需要关闭JTAGPB6OLED的SCLI2C1PB7OLED的SDAI2C1PA2USART2_TX接ESP8266的RXDPA3USART2_RX接ESP8266的TXDPA9USART1_TX调试串口输出PA10USART1_RX预留上位机通信为什么把ESP8266挂在USART2而不是USART1因为USART1我经常用来打调试日志如果WiFi也挂在上面日志和数据互相干扰排查问题的时候会非常痛苦。板子上的资源分配本质上是给“未来排错”留余地。3. 数据采集核心代码从传感器时序到干净数值3.1 DHT11单总线时序最容易被新手忽略的细节DHT11用的是单总线协议一根线上完成双向通信。主机发一个开始信号DHT11回响应然后连续输出40位数据湿度整数、湿度小数、温度整数、温度小数、校验和。代码逻辑看起来不难真正的坑在于时序要精确尤其是起始信号之后的等待时间。uint8_t DHT11_ReadData(uint8_t *humidity, uint8_t *temperature) { uint8_t data[5] {0}; uint8_t i, j; // 主机拉低至少18ms再拉高20-40us作为起始信号 DHT11_GPIO_Mode_Output(); HAL_GPIO_WritePin(DHT11_GPIO_Port, DHT11_Pin, GPIO_PIN_RESET); HAL_Delay(20); HAL_GPIO_WritePin(DHT11_GPIO_Port, DHT11_Pin, GPIO_PIN_SET); DHT11_GPIO_Mode_Input(); delay_us(40); // 检测响应低电平80us 高电平80us if (!HAL_GPIO_ReadPin(DHT11_GPIO_Port, DHT11_Pin)) { while (!HAL_GPIO_ReadPin(DHT11_GPIO_Port, DHT11_Pin)); // 等待拉高 while (HAL_GPIO_ReadPin(DHT11_GPIO_Port, DHT11_Pin)); // 等待拉低 } // 读取40位数据 for (j 0; j 5; j) { for (i 0; i 8; i) { while (!HAL_GPIO_ReadPin(DHT11_GPIO_Port, DHT11_Pin)); // 等待高电平 delay_us(40); if (HAL_GPIO_ReadPin(DHT11_GPIO_Port, DHT11_Pin)) { data[j] | (0x80 i); // 高电平超过40us判定为1 } while (HAL_GPIO_ReadPin(DHT11_GPIO_Port, DHT11_Pin)); // 等待低电平 } } // 校验和验证 if ((uint8_t)(data[0] data[1] data[2] data[3]) data[4]) { *humidity data[0]; *temperature data[2]; return 1; } return 0; }程序里最关键的是读每一位数据时用了一个40微秒的延时判断。DHT11的协议规定低电平之后的高电平持续26-28微秒表示“0”持续70微秒表示“1”。所以在高电平开始后的第40微秒去采样就能区分出0和1。这个延时如果不准读出来的数据就会乱七八糟。还有一个容易踩的坑DHT11每次读取间隔必须大于1秒否则它还在上一次的采样周期里返回的数据不会刷新。很多人的代码跑起来显示温度长期不变排查了半天供电、接线最后发现是没做读取间隔限制。我在这里用了一个简单的非阻塞计时方案uint32_t lastReadTick 0; if (HAL_GetTick() - lastReadTick 2000) { if (DHT11_ReadData(hum, temp)) { lastReadTick HAL_GetTick(); } }注意HAL_GetTick()返回的是系统上电以来的毫秒计数这个方案比HAL_Delay好得多因为它不会阻塞主循环MCU在等待期间还能处理按键、刷新屏幕、处理网络数据。3.2 ADC采集与均值滤波光敏电阻和MQ-2的接入细节光敏电阻和MQ-2都是模拟量输出处理逻辑相似接一个分压电路用STM32的ADC采集电压再映射成物理量。这里要重点讲一下分压电阻的计算因为很多人就直接抄网上的图结果输出范围完全不匹配。以光敏电阻为例光敏电阻的阻值随光照变化范围很大典型值从几千欧强光到几百千欧黑暗。我用的是10K下拉电阻串联到3.3VADC采样点放在光敏电阻和10K电阻的连接处。这样强光时光敏电阻阻值小采样点电压接近3.3V黑暗时光敏电阻阻值大采样点电压趋近0V。采集代码如下uint16_t ADC_Read(uint32_t channel) { ADC_ChannelConfTypeDef sConfig {0}; sConfig.Channel channel; sConfig.Rank ADC_REGULAR_RANK_1; sConfig.SamplingTime ADC_SAMPLETIME_55CYCLES_5; HAL_ADC_ConfigChannel(hadc1, sConfig); HAL_ADC_Start(hadc1); HAL_ADC_PollForConversion(hadc1, 10); uint16_t value HAL_ADC_GetValue(hadc1); HAL_ADC_Stop(hadc1); return value; }ADC本身是12位的读到的原始值是0-4095。要转成电压就是voltage value * 3.3f / 4095.0f。但实际使用中我发现直接拿单次采样值来做显示和判断数据波动得让人头疼。MQ-2这种传感器本身输出就有噪声光敏电阻在光线稍变时数值也会跳动。解决办法是加滑动平均滤波。我维护了一个长度为5的环形缓冲区每次采样新的值就替换最旧的值然后取平均。5次这个窗口是我实测下来比较合适的折中——太小压不住噪声太大会让响应变慢光照突变时要等好几秒才能反映到屏幕上。#define FILTER_SIZE 5 uint16_t ADC_FilteredRead(uint32_t channel, uint16_t *buffer) { static uint8_t index 0; uint32_t sum 0; buffer[index] ADC_Read(channel); index (index 1) % FILTER_SIZE; for (uint8_t i 0; i FILTER_SIZE; i) { sum buffer[i]; } return sum / FILTER_SIZE; }这里有个关键细节滤波缓冲区必须是每个通道独立一份不能共用一个数组否则两个通道的数据会互相污染。我一开始就是共用了缓冲区结果光照值偶尔会串进空气质量里查问题查了好一阵子。3.3 数据转换别用float裸奔注意MCU算力虽然STM32F103有硬件浮点单元的是F4系列F103本身不带FPU所以浮点运算全靠软件模拟速度慢不说还占Flash空间。在小数据量的场景里问题不大但如果是做周期性高频采集建议用整数运算替代浮点。比如温度显示DHT11给的是整数直接存整数就行光照强度如果要显示成“亮/暗/适中”的等级用ADC原始值和阈值比较就够了不用精确算成勒克斯。MQ-2那边我做了个简单的线性换算ppm (float)rawValue / 4095.0f * 100.0f这个精度肯定不够严谨但对家庭场景的“有没有烟雾”判断已经足够。如果你后续要做更精确的空气质量检测建议换用CCS811或者SGP30走I2C数字接口精度和稳定性都会上一个台阶。4. 人机交互设计OLED显示与按键状态机的配合4.1 为什么用OLED而不是TFT彩屏热搜词里有“tft屏幕绘制圆弧”这个方向我确实也试过用TFT彩屏跑这个项目ST7789/ILI9341这类屏幕显示效果确实炫能画曲线、出图表但代价是接口占用多、刷新帧率低时闪烁明显、驱动代码量大而且如果你要绘制圆弧、柱状图这种比较“花”的界面还得学一套图形库的画法。对于监测系统这种“以文字和数字为主”的界面OLED 0.96寸I2C版本完全够用代码量小性能开销低蓝色单色显示也够清晰。当然如果你就是想要TFT那种高分辨率和彩色效果也不是不行。我后来在给系统加“历史曲线”功能时确实考虑过换TFT但评估后放弃了——历史曲线更适合放在手机端看屏幕端只显示当前值和简单的趋势箭头就够了这是“边界设计”思路设备端不做重复工作屏幕只负责摘要细节交给云端。4.2 两级菜单状态机从轮询到事件的切换按键交互这块我用的是两个按键一个确认一个切换。屏幕显示两级菜单一级菜单是四个监测页面温度/湿度/光照/空气短按切换键循环翻页在某个页面短按确认键进入“详细模式”会显示对应物理量的历史最高值、最低值和当前值。这里不用复杂的操作系统用一个简单的状态机就够了typedef enum { MENU_MAIN, MENU_DETAIL_TEMP, MENU_DETAIL_HUMI, MENU_DETAIL_LIGHT, MENU_DETAIL_AIR } MenuState; MenuState currentState MENU_MAIN; void Menu_ProcessKey(KeyEvent event) { switch (currentState) { case MENU_MAIN: if (event KEY_SHORT_PRESS) { currentIndex (currentIndex 1) % 4; OLED_ShowMainPage(currentIndex); } else if (event KEY_LONG_PRESS) { currentState (MenuState)(MENU_DETAIL_TEMP currentIndex); OLED_ShowDetailPage(currentIndex); } break; case MENU_DETAIL_TEMP: case MENU_DETAIL_HUMI: case MENU_DETAIL_LIGHT: case MENU_DETAIL_AIR: if (event KEY_SHORT_PRESS) { currentState MENU_MAIN; OLED_ShowMainPage(currentIndex); } break; default: break; } }按键检测这里有个非常容易犯的错在定时器中断里直接做延时消抖。我之前在做一个用TIM定时器做延时的功能时不小心把消抖逻辑写进了中断回调结果整个主循环被拖慢传感器数据刷新频率肉眼可见地下降。正确的做法是中断里只记录“按键按下”事件主循环里轮询处理或者用标志位再把消抖和状态机逻辑放在主循环执行。事件驱动和轮询的区别就在这里——中断里做最少的活把处理逻辑交给主循环。4.3 屏幕刷新的隐藏性能陷阱OLED的驱动IC是SSD1306它内部有个显存我们需要把要显示的整屏数据通过I2C写入这个显存。看似简单但I2C传输速率默认在100KHz左右写一屏128×64位8字节一页共8页的数据起码要传1KB多算一下时间就不难理解为什么OLED刷新会“卡”。我的优化方案是分级刷新第一级每500毫秒刷新一次数值区域只更新变化的数字部分第二级每秒刷新一次整个数据区域防止残留和字符重叠第三级只在页面切换时调用全屏清屏。这样既保证了实时性又不会因为频繁全屏刷新导致闪烁。如果你用TFT屏幕还要画圆弧、柱状图这类图形请务必要开DMA或者用硬件SPI纯IO模拟刷一屏彩屏的颜色MCU基本就干不了别的活了。5. 数据上报链路串口帧协议与ESP8266入网的折腾5.1 自定义串口帧别把裸数据丢给WiFi模块监测系统的完整闭环最后一步是“远程查看”。我用的方案是STM32通过USART2连接ESP8266ESP8266走WiFi把数据发到MQTT服务器手机端订阅对应topic就能看到数据。第一步是定义串口协议。为什么不能直接发字符串“25.5”过去因为接收端没法判断数据什么时候开始、什么时候结束也没法做校验万一中间丢了一个字节整条数据就废了。我定义了一个简单但可靠的帧格式帧头(2字节) 数据长度(1字节) 数据类型(1字节) 数据区(N字节) CRC8校验(1字节) 帧尾(2字节)帧头固定为0xAA 0x55帧尾固定为0x0D 0x0A接收端只要识别到帧头就开始缓存接收到帧尾就校验长度和CRC。这样即使之前的数据流没有对齐也能在下一个完整帧到来时恢复同步。数据区的内容我用JSON子集的方式组织方便上位机解析比如uint8_t payload[64]; sprintf((char*)payload, {\t\:%d,\h\:%d,\l\:%d,\a\:%d}, temp, humi, light, air);5.2 ESP8266的AT指令接入MQTT流程ESP8266我用的是AT固件避免自己写SDK开发效率高很多。接入流程大致是ATCWMODE1 # 设置Station模式 ATCWJAPSSID,password # 连接WiFi ATMQTTUSERCFG0,1,client_id,username,password,0,0, # MQTT用户配置 ATMQTTCONN0,broker_address,1883,1 # 连接MQTT服务器连接成功之后上报数据就是一个ATMQTTPUB命令带上topic和payload的事。这里有个很实际的坑AT指令串口默认波特率是115200但ESP8266模块在上电初始化期间会在串口上输出一堆乱码boot信息这些乱码会和正常的AT响应混在一起。我的解决方案是上电后延时2秒等boot信息输出完毕再发AT指令同时STM32端做响应解析时把非“OK”“ERROR”等关键字的行直接忽略。5.3 断线重连策略不能傻等WiFi模块的稳定性永远是个话题。路由器重启、信号波动、MQTT服务器超时任何一次断连都会让ESP8266卡在某个状态。如果代码里不做重连机制系统状态就成了“看起来还在跑数据其实已经断了”。我用的是一个超时计数的思路每5秒检查一次ESP8266的状态用ATPING命令测网络连通性连续3次失败就判定为网络断开进入重连流程。重连流程用倒计时方式执行比如先连WiFi等10秒不行再重试WiFi连上后再连MQTT等5秒不行再重试。关键在于重连不能阻塞主循环否则传感器采集和屏幕显示都会一起卡死。如果你不想自己造这个轮子可以考虑基于MQTT和Flash的智能家居监控平台方案直接把数据接入HomeAssistant这类开源平台但代价是ESP8266端要刷专门的固件灵活性会降低。我这次还是选择自己写主要为了把协议细节吃透。6. 两类典型故障的完整排查链路6.1 延时函数卡死从“程序不跑了”到定位SysTick冲突这个坑我印象特别深。系统运行一段时间后“死机”了屏幕停在最后一帧按键也没反应。我一开始以为是程序跑飞了后来接上调试器才发现卡死在HAL_Delay里。为什么HAL_Delay会卡死因为基于HAL库的HAL_Delay依赖于SysTick中断维护的uwTick计数器。如果我在某个中断回调里也调用了HAL_Delay就可能导致SysTick中断被嵌套或阻塞。更常见的情况是在定时器中断服务函数里写了HAL_Delay。中断里调延时等于让MCU在中断里死等这时候如果有更高优先级的中断进来或者SysTick的优先级配置不当就会产生死锁。修复方案其实很简单// 能不用阻塞延时就不用尤其在中断里 // 中断里需要等待某个外设用超时循环代替HAL_Delay void ToggleLED_WithTimeout(void) { uint32_t timeout 100000; while (timeout--) { // 等待外设就绪 } }后来我把所有中断里的阻塞延时代码都换成了“状态标记 非阻塞检查”或者“超时循环”问题再没出现过。这也是嵌入式开发的一条铁律中断服务函数只做时间敏感的操作尽量不要在里面等待任何东西。6.2 ADC数值漂移的定位过程第二个典型的故障是ADC采集的光照值莫名其妙地漂数值忽高忽低即使灯光恒定读出来的值也会上下跳几十甚至上百。排查链路我是这样走的。第一步怀疑供电不稳于是用万用表量3.3V电源纹波正常第二步怀疑光敏电阻质量问题换了一个依旧第三步怀疑ADC参考电压发现STM32F103的内部参考电压VREFINT确实存在一定温漂但不至于这么夸张第四步把ADC引脚悬空测了一遍发现悬空时数值都能乱跳说明问题在引脚和采集参数本身。最终找到了两个叠加因素。第一ADC采样时间设置太短SAMPLETIME用的是1.5周期对于高阻抗源光敏电阻分压点输出阻抗很高内部采样电容还没充满就开始转换数值自然不准。解决办法是把采样时间增加到55.5周期甚至239.5周期。第二光敏电阻VP线上的走线没有做保护靠近电源线存在工频干扰。软件上我用滑动平均滤波进一步压制同时硬件上在ADC引脚和GND之间加了一个0.1uF的电容双管齐下之后数值就稳定了。这个案例最能说明问题很多“软件bug”其实是硬件问题排查时设备端的数据链路看得越细越能少走弯路。7. 项目重构与功能扩展的可行路径7.1 从F103换到G0/G4时的代码改造思路这套系统跑通之后我后续给它做了几次升级。一次是感觉DHT11的精度不够换成了SHT30驱动层改动很小因为我把传感器数据接口做成了统一的结构体typedef struct { int16_t temperature; uint16_t humidity; uint16_t light; uint16_t airQuality; } SensorData;只要新传感器驱动能填上这四个字段业务逻辑层完全不用动。这就是接口抽象的价值——你在写代码时多花的一点心思会在后期升级时成倍地回报你。如果要从F103换到功耗更低的G0系列主要工作是重写Clock配置和部分外设的HAL库调用方式但业务架构可以平移。如果换到带有硬件FPU的G4系列浮点运算可以提速不少滤波算法就可以升级成卡尔曼滤波或者更复杂的模型了。7.2 用定时器捕获做风速计一个低成本扩展方向热搜词里有“stm32定时器捕获测频率”这个方向很适合作为本项目的低成本扩展。如果你在户外放一个风速计风速信号本质是一个频率信号——风杯每转一圈干簧管或者霍尔传感器就产生一个脉冲。用STM32的TIM输入捕获模式测量两个上升沿之间的时间差换算成频率再按风速计的标定系数算出风速。我在这个项目上测试过TIM2的CH1配置为输入捕获上升沿触发中断里记录CCR值主循环里计算两次捕获之间经过的脉冲数再换算频率。因为输入捕获功能不占额外的GPIO复用现成的TIM资源就可以对系统的硬件改动几乎为零。7.3 历史数据本地存储Flash环形队列另外一个进阶方向是设备端掉电保存历史数据。STM32F103的Flash是64KBC8T6或128KBCBT6用最后几页存历史记录足够了。我实现了一个简单的环形队列每次整点存一条数据包括时间戳和四个监测值。存储时注意Flash的擦写寿命一般10万次所以不能频繁擦写同一个扇区要设计磨损均衡逻辑——记录当前写指针写满一个扇区就跳到下一个。这里不展开全部代码但有一点必须提醒Flash写入前必须先擦除而且擦除以扇区为单位如果写入过程中掉电可能损坏一批数据。工程级的做法是存双份备份或者存一条加一条CRC校验读取时跳过损坏条目。家庭监测场景不追求极致可靠性但基本的数据完整性设计还是要有。8. 一些项目复盘后的真心话整套系统从硬件设计到跑通前后花了我大概两周的业余时间。回头看项目本身难度不算大真正的价值在于让你把STM32的常用模块——GPIO、ADC、TIM、USART、I2C——全部串起来形成一个完整的业务闭环。有一点我觉得比技术细节更重要别急着写代码。先把框图画出来确认每个模块的输入输出是什么再动手。我第一版就是边写边想结果写到后面发现引脚分配不合理返工了好几次。第二版提前规划好引脚和协议开发效率直线上升。另外想说说的就是调试习惯。很多人一上来就喜欢用printf打印调试信息这在程序简单时没问题但系统复杂度上来之后建议还是把日志做成分级模式正常运行时静默只有打开调试开关才输出细节。我用的方案是编译条件开关#define DEBUG_ENABLE 1 #if DEBUG_ENABLE #define LOG_INFO(...) printf([INFO] __VA_ARGS__) #define LOG_ERROR(...) printf([ERROR] __VA_ARGS__) #else #define LOG_INFO(...) #define LOG_ERROR(...) #endif量产或正式运行的时候把DEBUG_ENABLE置0日志代码自动消失不会拖慢系统也不会刷爆串口。最后再分享一个我实际使用中的小技巧PCB上给ESP8266焊一个排针座不要直接焊死。调试阶段我要反复拔插模块刷固件、量电压排针座让我省了非常多的功夫。类似地电源入口处放一个自恢复保险丝哪怕传感器短路也不会烧板子。这些细节不会写进原理图但实际用起来能救命的东西往往就是它们。希望这套从选型到代码、再到踩坑排查的完整过程能帮你少走点弯路。如果你照着搭了一套跑起来之后想再加功能欢迎沿着我写的扩展路径继续折腾——嵌入式这行,永远是在“跑起来”之后才真正开始有意思。本文还有配套的精品资源点击获取