1. 项目概述与整体架构不少朋友第一次听“STM32智能鞋柜系统”第一反应都是“鞋柜还能怎么智能”等到真正把功能列出来会发现这套小系统几乎是单片机入门阶段最完整的一类综合训练传感器采集、执行器控制、人机交互、状态机调度全都会碰到。我最早看到这类项目是在某高校的课程设计里后来陆陆续续有几位做嵌入式开发的朋友都在自己家倒腾过原因很简单——它足够实用成本能做到百元以内而且踩坑的密度非常合适。这个系统解决的核心问题很直接鞋子收纳后容易闷潮、滋生细菌尤其是梅雨季节和运动鞋用户隔天打开鞋柜一股味道扑面而来。智能鞋柜做的事情本质上就是三件事——感知环境、判断状态、执行干预。感知用的是温湿度传感器识别“柜内是否过于潮湿”用称重传感器识别“某个格子到底有没有放鞋”用人体红外和门磁识别“用户是否正在使用鞋柜”判断和执行则是主控芯片把这些输入综合起来决定要不要开启烘干风扇、紫外线杀菌灯、除湿加热片以及自动照明。整套系统的工程量并不大但麻雀虽小五脏俱全。实际开发中涉及到的技术点包括单片机外设初始化、时序传感器的数据读取、称重信号的ADC采集与滤波、继电器的驱动与隔离、状态机的逻辑设计、甚至可以通过蓝牙或WiFi模块把数据同步到手机App。我见过有些实现只做了温湿度检测加LCD显示那就只是把传感器接上去报个数谈不上“系统”真正的智能鞋柜核心在于多路输入信号之间的联动逻辑比如“人在的时候杀菌灯绝不能亮”“湿度超过阈值但是格子里没鞋就别空转烘干”这类细节。这个项目的适配人群很明确学过STM32基础外设GPIO、定时器、USART、ADC想做一个综合性项目来巩固能力的学生或转行开发者以及本身对家居自动化感兴趣、想给家里做一个实用小设备的爱好者。如果你目前连GPIO点灯都还不算熟建议先别碰这个项目因为鞋柜系统涉及的传感器时序和联动逻辑会同时出现基础不扎实容易越调越乱。反过来如果你已经把“点灯”“按键”“中断”这些基础操作都跑通过做这套系统大概一到两周时间就能拿出能演示的完整版本。2. 主控选型与系统设计思路2.1 为什么选择STM32而不是其他主控智能鞋柜系统的核心控制单元目前最常见的选型就是STM32F103系列尤其是C8T6这个小封装型号。原因不是“大家都在用所以我也用”而是这套系统的资源需求刚好卡在它的甜点区。先盘一盘系统需要用到的资源一路温湿度传感器单总线、三路左右的称重传感器需要ADC、人体红外GPIO输入、继电器控制GPIO输出、OLED屏幕I2C或者SPI、按键GPIO输入、可能还有蓝牙串口。把这些资源列出来对主控的要求就是有足够多的GPIO、至少一个ADC、至少一个I2C/SPI、至少一个USART、Flash和RAM能装得下功能代码。STM32F103C8T6的配置是64KB Flash、20KB RAM、37个GPIO、3个USART、2个I2C、2个SPI、2个ADC72MHz主频——正好全部覆盖需求并且余量充足价格裸片在十几块钱的水平开发板配套资源极其丰富遇到问题搜解决方案基本都能搜到。有人可能会问“用ESP32不是更香自带WiFi和蓝牙价格也差不多。”ESP32确实是好芯片但它有个实际问题——3.3V逻辑电平、ADC线性度一般而且对很多刚接触单片机的人来说ESP32的物联网属性会分散注意力本来应该聚焦在“传感器控制逻辑”上结果跑去折腾WiFi配网了。STM32F103的优势在于它是最经典的入门级ARM Cortex-M3芯片资料体系完整从寄存器手册到各种库函数版本都相当成熟用来做这类以“本地逻辑控制”为主的项目非常稳妥。如果后续想加手机控制外接一块ESP8266作为WiFi协处理器就够了主控仍然专注于数据采集和策略执行分工明确排查问题也更容易定位。2.2 系统功能模块划分在设计初期就把整个系统拆成几个清晰的功能模块会大幅降低后期调试的混乱程度。按照数据流向智能鞋柜系统可以划分为四层感知层、决策层、执行层、交互层。感知层负责采集环境与状态信息包括DHT11温湿度传感器读取柜内温度和相对湿度、薄膜压力传感器或称重模块判断鞋子是否在位、人体红外模块检测附近是否有人、门磁开关判断柜门状态。这些信号有模拟量也有数字量需要主控分别处理。决策层是主控芯片内部运行的控制逻辑核心是一个状态机包含待机、除湿、杀菌、手动控制等状态。决策逻辑的输入来自感知层输出是执行层的控制信号。比如“柜内湿度达到70%以上且检测到至少一个格子里有鞋且当前没有人靠近”这一组条件同时满足系统自动进入除湿烘干状态。执行层包括继电器控制的风扇、加热片或半导体制冷片、紫外线杀菌灯、LED照明灯。执行器的共同点是它们都是强电或大功率器件绝对不能直接用GPIO驱动必须通过继电器或MOS管隔离和放大。交互层负责人与系统的信息交换包括OLED屏幕显示温度湿度、当前工作状态、各格子的鞋子在位情况再加上几个实体按键供手动切换工作模式。如果接了蓝牙或WiFi模块交互层还可以扩展为手机App或小程序远程查看状态、远程下发指令。2.3 系统工作流程的逻辑推演整套系统的运行逻辑可以这样描述上电后主控先完成所有外设初始化OLED显示欢迎界面随后进入待机状态。在待机状态下系统周期性读取温湿度数据并在屏幕上刷新。当湿度超过设定阈值例如70%RH系统不立即启动烘干而是先检查称重传感器——因为如果一个格子是空的对它进行烘干没有任何意义反而浪费电能、增加设备损耗。只有当“湿度超标 有鞋子在位 无人靠近红外无触发”三个条件同时成立系统才启动该格子对应的风扇和加热装置。紫外杀菌的逻辑强调安全优先紫外线对人体有伤害所以杀菌功能只在无人环境下允许运行。具体实现时除了人体红外传感器输入判断“是否有人”门磁传感器也会参与联锁——无论当前处于什么状态只要检测到柜门被打开紫外线灯必须立即关闭这就是所谓的“硬联锁”逻辑。我在实际代码里把这两路信号直接接入控制函数的判断条件并且在硬件上也加了串联的继电器常闭触点作二次保护软件逻辑出错时硬件还能兜底。人机交互方面手动模式与自动模式并行存在。用户可以通过按键强制启动烘干或杀菌也可以切换回全自动模式。手动操作时系统会记录操作时间超过设定时间比如30分钟自动停止执行器防止因为用户忘记关闭造成设备长时间空转或者安全隐患。3. 硬件核心细节与电路设计3.1 传感器选型对比与分析智能鞋柜系统里传感器是最容易掉进坑里的环节。不少初学朋友习惯“哪个模块便宜买哪个”结果买回来发现数据跳变严重、示数漂移、甚至通信时序对不上。我这里把常用方案放在一起做个对比。温度湿度检测最常见的方案是DHT11和DHT22也叫AM2302。DHT11精度是±2℃、±5%RH采样周期至少1秒价格便宜大约两三块钱DHT22精度是±0.5℃、±2%RH价格翻了好几倍。对于鞋柜这个应用场景我们关心的不是“今天气温到底精确到0.1℃”而是“柜内是否变得潮湿”DHT11完全够用。需要注意的是DHT11的抗干扰能力一般如果柜内有继电器动作导致电源波动读数会出现偶发的跳变我在代码里加了连续读取三次取中值的滤波策略实测效果好很多。鞋子在位检测常见的方案有薄膜压力传感器、称重传感器加HX711、红外对射传感器。薄膜压力传感器的优点是便宜、好接线贴在鞋柜隔板底部即可但长期受压后会疲劳输出信号的重复性会变差。称重传感器加HX711的优点是精度高能测出具体重量可以进一步判断“放的是拖鞋还是运动鞋”但电路复杂一些成本和体积也更大。红外对射属于开关量检测可靠性高但需要在鞋柜隔板两侧安装发射管和接收管结构上比较受限。人体检测HC-SR501人体红外模块是被动红外PIR检测人体辐射的红外线变化静态不太敏感只要人稍微移动就能触发。鞋柜场景里用户开柜门取鞋必然是运动的所以用它来判断“附近是否有人”很合理。需要注意这个模块背后有两个旋钮可以调节延迟时间和灵敏度出厂默认延迟时间太长几十秒用在鞋柜上要调到最短档位。门磁检测干簧管加磁铁是最简单可靠的门状态检测方案结构稳定、几乎不会误判。把干簧管固定在柜体上磁铁贴在柜门上门关闭时干簧管导通门打开时断开主控通过GPIO上下拉读取电平即可。3.2 驱动电路与继电器隔离设计执行器控制部分是电路设计的重点。风扇、加热片、紫外线灯这些负载的工作电流从几十毫安到几安培不等而STM32的GPIO输出能力仅几毫安直接驱动是不可能的必须经过功率放大。常规做法用小功率NPN三极管或者MOS管驱动继电器线圈再由继电器触点去控制交流或直流负载。我习惯用的方案是STM32 GPIO引脚串联一个1kΩ限流电阻接到NPN三极管比如S8050的基极三极管的集电极接继电器线圈的一端线圈另一端接5V电源线圈两端反向并联一个1N4007二极管作为续流二极管。这个二极管非常重要继电器线圈是电感断电瞬间会产生反向电动势如果没有续流二极管这个电压尖峰可能击穿三极管或干扰单片机的电源轨严重时直接导致STM32复位。实测中我见过好几个项目就是因为漏了这颗二极管继电器一动作单片机就重启。GPIO先置低电平确保上电瞬间继电器不吸合再初始化外设。初始化完成后再把GPIO拉高去控制继电器这个顺序虽然看起来不起眼但能避免上电瞬间的误动作。另外继电器选型注意线圈电压常见的是5V和12V两种5V继电器可以用USB供电或者AMS1117-5.0稳压芯片供电12V继电器则需要额外的电源轨除非系统里本来就有12V风扇或加热片否则建议用5V继电器加12V负载方案控制部分统一5V供电。3.3 供电系统与电源轨分配智能鞋柜的供电设计是个容易被忽视但至关重要的模块。系统里有3.3V逻辑器件STM32、OLED、传感器模块和5V外围器件继电器线圈、部分传感器模块如果加了12V风扇或加热片还需要12V电源轨。我的推荐方案是这样的外部用12V/2A的电源适配器统一供电进入系统后分成两路。一路直接给12V风扇和加热片供电另一路经过降压模块降到5V给继电器和模块供电5V再经过AMS1117-3.3降到3.3V给STM32和OLED供电。这种层级式供电的好处是功率级的12V与逻辑级的3.3V之间有清晰的隔离继电器吸合瞬间的电流波动不容易直接干扰到单片机的电源。实际调试时最常遇到的问题是风扇一启动OLED屏幕就闪动甚至花屏或者DHT11读数突然跳到错误值。这大概率是电源纹波问题——启动负载瞬间电流变化导致电压跌落。解决办法首先检查5V降压模块的输出电容是否足够在模块输出端并联一个470μF电解电容和104瓷片电容组合能吸收大部分瞬态波动其次让所有继电器线圈的地引脚尽量靠近电源地接入点避免形成大电流环路实在不行还可以在单片机电源引脚和地之间加一颗100Ω电阻串联磁珠组成简易π型滤波。这些措施组合起来基本上能让系统在风机频繁启停的情况下都稳定运行。4. 软件逻辑与核心代码实现4.1 主程序框架与状态机设计软件部分是智能鞋柜系统的灵魂。我建议用有限状态机FSM来组织整个程序逻辑而不是简单地用一个大循环加一堆if-else。状态机的优势在于每个时刻系统处于明确的状态状态转移条件清晰后续增加新功能只需要加状态和迁移条件不需要大改主循环。对于智能鞋柜最少需要定义四个状态IDLE待机系统默认状态仅周期性采集并显示数据DRYING烘干对应除湿模式风扇和加热片工作STERILIZING杀菌紫外线灯工作必须满足安全联锁条件MANUAL手动控制用户通过按键临时干预一般带超时自动退出主循环里最重要的是“快读慢调”的思想传感器状态和数据要高频刷新但执行器的决策不需要每次都重新做。一个典型的主循环伪代码如下while (1) { /* 高频段刷新传感器数据 */ dht11_read_data(humidity, temperature); // 读取温湿度 hx711_read_weight(weight); // 读取称重数据 ir_status gpio_read_level(PIR_PIN); // 读取人体红外 door_status gpio_read_level(DOOR_PIN); // 读取门磁状态 /* 决策段更新状态机 */ update_state_machine(humidity, weight, ir_status, door_status); /* 执行段根据状态控制执行器 */ apply_actuator_controls(); /* 交互段更新OLED显示 */ oled_refresh(humidity, temperature, current_state); delay(200); // 主循环周期200ms }主循环周期200ms是一个经验值DHT11至少需要1秒采样间隔称重模块读取本身需要时间人眼对于OLED刷新速度大约需要100ms以上才能感知流畅200ms折中下来能耗最低、交互体验也能接受。4.2 DHT11时序读取与数据校验温湿度传感器是整个系统里通信时序最讲究的一个模块。DHT11单总线协议是半双工的主控发信号启动一次转换DHT11回传40位数据每一位由高低电平的组合表示“0”或“1”。时序细节如果处理不好最常见的结果就是读出来的湿度永远是0或者是一个固定垃圾值。读取DHT11标准流程如下主机拉低数据线至少18ms然后释放置高DHT11检测到起始信号后回应DHT11拉低80μs再拉高80μs表示准备发送数据然后连续发送40位数据每一位先拉低50μs接着拉高高电平持续26~28μs表示“0”持续70μs表示“1”40位数据中前16位是湿度、中间16位是温度、最后8位是校验和实际写代码的时候最关键的是捕捉电平变化的时间长度。因为STM32的HAL库函数本身有调用开销直接用HAL_Delay是绝对不行的——μs级别的时序必须用定时器或者DWT-CYCCNT这类硬件计数器来卡。我比较推荐用定时器的输入捕获功能来测量每次电平变化的时间精度高且不占用CPU忙等。如果为了简单用GPIO轮询加DWT延时也能做但需要仔细校准空循环的延时时间。DHT11的数据经常会因为线长、电源纹波出现错位所以代码里务必做校验和验证uint8_t dht11_parse_data(uint8_t data[5]) { uint8_t sum data[0] data[1] data[2] data[3]; if (sum ! data[4]) { return 1; // 校验失败 } humidity (data[0] 8) | data[1]; temperature ((data[2] 8) | data[3]) * 0.1f; return 0; // 校验成功 }校验失败时不要直接把错误数据用于决策应该保留上一次有效数据并且连续多次失败时在OLED上提示传感器故障。这是做嵌入式系统的基本素养——宁可显示旧数据也不要跳出一个荒诞读数去启动烘干设备。4.3 烘干策略与称重联动烘干功能的核心逻辑并不复杂但策略细节需要反复推敲。我最初做的时候简单处理为“湿度大于70%就启动烘干”结果发现每次洗过澡卫生间水汽扩散到鞋柜附近系统就开始烘干一天能启动十几次不仅费电加热片频繁启停也容易损坏。后面我改成“条件与”策略只有当湿度大于阈值、对应格子有鞋、距离上次烘干结束超过冷却时间三分钟三个条件同时满足才进入烘干状态。这三点看似简单但每一条背后都有实际考虑。湿度阈值解决“何时需要烘干”有鞋判断解决“烘干给谁用”冷却时间解决“反复启停保护设备”。称重传感器在这个策略里扮演关键角色。HX711加称重传感器的核心代码实现包含初始化、读取原始值和标定三步。初始化时要把HX711的SCK和DOUT引脚分别连到STM32的GPIODOUT为高时表示数据未准备好按HX711时序拉高再拉低SCK来读取24位数据。标定时要先记录空载值再放一个已知重量的物体比如500g砝码求出比例系数float hx711_calibrate(int32_t empty_value, int32_t known_weight_value, float known_weight_kg) { return (float)(known_weight_value - empty_value) / known_weight_kg; }之后每次读数实际重量 (当前读数 - 空载值) / 比例系数。由于称重传感器输出信号很小ADC读数往往存在噪声我习惯在软件里做滑动平均滤波取最近五次读数的平均值再参与判断。这个滤波对减小震动和温度漂移的干扰有明显效果代码实现也很简单只需要一个长度为5的环形缓冲区。4.4 紫外线杀菌的安全联锁设计紫外线杀菌是这套系统里对安全性要求最高的功能设计上必须把“失效保护”思想贯彻到底。软件层面的联锁逻辑我做了三层第一层杀菌只能在无人状态下运行。人体红外传感器检测到有人靠近时无论出于什么状态都立刻切换到待机模式杀菌灯断电。第二层门磁联锁。门打开时杀菌灯必须无条件关闭这个判断放在执行器控制函数的最前面优先级高于任何状态机逻辑。第三层手动超时自动退出。用户如果开启了杀菌模式系统自动设定一个工作周期比如10分钟时间到立即停止杀菌不允许无限期工作。除此之外我还建议在硬件上加一道保险——紫外线灯供电回路串联一个由门磁控制的常闭继电器门一旦打开物理上断开紫外线灯的供电回路。这等于说就算单片机程序跑飞了、GPIO输出错误、软件判断失效紫外线灯也不会在开柜门的时候亮起。做安全相关功能的时候一定要理解一个道理软件逻辑是理想情况硬件保护是最后防线两道都做才算合格。5. 常见问题与实操排查5.1 典型故障现象速查表这套系统做下来我把遇到过的问题整理成一张排查表你在调试时如果遇到类似现象可以直接对号入座。故障现象可能原因排查方法继电器一动作单片机就重启继电器线圈没有续流二极管或电源功率不足检查线圈两端是否反向并联1N4007电源适配器电流是否足够湿度读数偶尔跳变到错误值DHT11受电源干扰数据线过长电源端加滤波电容缩短数据线代码连续读3次取中值称重读数缓慢漂移传感器未充分预热温度变化引起上电后预热5分钟再校准软件做滑动平均滤波OLED屏幕花屏或闪烁I2C通信速率不匹配或电源纹波较大慢速模式初始化电源加470μF电容紫外线灯开柜门没关断联锁逻辑顺序错误或门磁信号未接入确认门磁信号确实在GPIO上有变化把联锁判断放在执行函数最前端烘干启动频繁湿度阈值设置过低将相对湿度阈值从60%提高到70%增加冷却时间限制5.2 调试方法论与排查工具嵌入式项目调试最怕的是“现象猜谜”。如果你只通过观察LED灯来判断运行状态出了问题几乎只能靠猜。我强烈建议一开始就加上一套调试输出通道哪怕只是通过USART往电脑串口打印调试信息都能让排查效率翻倍。串口调试信息至少应该包含当前时间戳、温湿度原始值、称重ADC原始值、人体红外和门磁电平、当前状态机状态、执行器开关状态。把这些信息打印出来系统运行时你在串口监视器里就能看到整个决策过程的完整链路——哪一步输入异常一目了然。比如烘干不启动你一看日志发现“湿度超标”这个条件根本没成立那问题就锁定在DHT11读数上而不是去反复拆继电器。硬件层面建议常备一个数字万用表和逻辑分析仪。万用表用来检查继电器线圈两端电压是否正常、电源轨有没有跌落逻辑分析仪主要看DHT11单总线时序是否符合手册要求。我第一次调DHT11的时候就是发现数据线高电平时间整体偏短排查下来是GPIO配置成开漏输出后没有正确接上拉电阻这种问题用逻辑分析仪一眼就看出来了纯靠猜可能要折腾大半天。调试过程中还有一个实用技巧——“单步变量替换法”。当系统某功能行为异常先不要怀疑最复杂的逻辑把它的输入固定成已知值看输出是否正确。比如怀疑烘干策略有问题就先强制设置湿度为80%、称重值为1kg看看系统会不会进入烘干状态。这套方法能快速把问题限定在“输入采集”还是“逻辑处理”或者“输出执行”哪一个环节避免在错误的圈子里反复绕路。5.3 开发周期与迭代建议给准备动手做这个项目的朋友一个时间参考如果每天能挤出三四个小时的整块时间一个月内完成一版能稳定运行的样机是没问题的。时间分配建议留大概40%给硬件电路焊接、传感器调试、供电系统验证30%给软件状态机开发、功能联调、调试输出完善30%给整体测试和优化长时间运行稳定性、功耗评估、不同环境条件下的反复验证。第一版建议先做“最小可行版本”一块STM32最小系统板、一个DHT11、一个继电器控制风扇、一块OLED屏把温湿度检测到自动排风这条链路打通。跑通之后再逐步加称重、紫外线、门磁、按键这些外围功能。我见过很多朋友一上来就画大板子把所有模块焊在一起结果某个模块出问题拆都不知道从哪儿拆起。先简后繁、逐个模块验证是这类综合项目最稳妥的开发路线。6. 从需求出发的实用建议做完整套系统我更想强调的一点是智能家居项目的复杂度很大程度来自需求本身而不是技术本身。如果需求定义是“监测湿度并在手机上看到数据”那一个传感器加蓝牙就能搞定如果需求是“全自动烘干杀菌”才需要状态机和联锁逻辑。找清楚需求的边界工程量和成就感完全不同。从实际生活场景看智能鞋柜最有价值的两个功能是自动除湿和离家杀菌。自动除湿靠的是温湿度传感器加上可靠的烘干策略这部分做好基本能解决鞋柜闷潮异味的大头离家杀菌强调的是安全人可以接受不在场时自动杀菌但绝不能接受系统失灵时伤人。我家里实际使用的时候设定的是湿度超过65%且连续10分钟不回落到60%以下才启动烘干这个阈值经过几次调整运行效果比较理想——既不会频繁启动也不会让鞋子长时间处于潮湿环境。如果你后续想把这个项目往更完整的方向扩展有几个方向可以参考。一是增加WiFi模块把温湿度数据和设备状态推送到手机App或者小程序人在外面也能看到柜内情况、远程启动烘干二是增加除臭模块比如活性炭风扇联动在杀菌结束后自动吹一段时间把臭氧和气味排出三是用手机NFC标签记录每一双鞋的摆放位置和穿用频率通过称重数据做更精细的收纳建议。这些方向都可以在现有状态机框架上做增量开发不需要推翻重来。最后分享一个我在多次调试中悟出的心得嵌入式系统的“智能”并不神秘它只是把人的判断逻辑翻译成了可重复执行的规则。写代码之前先把“什么时候该干什么”用自然语言写在纸上写清楚边界条件和例外情况再动手去写状态机思路会清晰得多。很多朋友一上来就写代码写完发现逻辑漏洞百出回头补丁摞补丁其实问题就出在没把需求规则梳理清楚。这套方法不仅适用于智能鞋柜做任何单片机控制类项目都值得一试。