最近被问得最多的智能家居问题不是谁家的音箱音质好也不是哪款传感器精度高而是家里的设备为什么总有几个连不上。WiFi的灯、蓝牙的传感器各说各话手机里装了三四个App网关买了一个又一个。后来我干脆把整套方案收敛到一块ESP32上用WiFiBLE双协议搭建一套“一站式”的智能家居体系从配网、控制、联动到OTA全流程跑通这篇文章就把完整思路、关键代码和踩坑过程写出来给正在折腾智能家居的朋友做个参考。1. 双协议不是折腾自己——WiFi和BLE在智能家居里各管一摊1.1 单协议方案的两种“烂尾”先说一个很现实的观察很多入门者做智能家居第一步就是纠结“用WiFi还是用BLE”。我见过不少全WiFi方案的案例前期调试确实爽每个插座、灯泡都能被手机直接控制但等到数量上去路由器的带机量先扛不住了三五十个设备同时在线内存和无线信道都被占满开始频繁掉线。更尴尬的是功耗一个WiFi温湿度计如果整天连着网那电池基本是按月算的不是按年算的。全BLE方案正好相反传感器节点省电是真省电一颗CR2032撑半年以上很常见但控制链路绕不开“手机直连”这个限制。灯控还好如果是门窗传感器、人体感应这类需要实时上报的状态你会明显感觉到延迟而且手机不可能始终常驻连接所有BLE设备实际体验就是“状态刷新靠运气”。再往后想接语音助手、远程控制BLE打着打着就找不到北了。1.2 ESP32把两个协议塞进同一块板子实际解决了什么树莓派确实是好中枢但成本和功耗摆在那STM32做执行器很稳可你要它同时扛WiFi协议栈加BLE协议栈内存早就吃满了。ESP32的定位刚好卡在中间自带双模无线协议栈的MCU不需要外挂模块一块板子就能同时扮演WiFi设备、BLE扫描端、BLE广播端、网关这几种角色。我后来划分设备边界用的是两条很朴素的生活规律插电设备分布在固定位置比如灯、插座、窗帘电机、面板开关它们不缺电也不怕功耗走WiFi最合适手机可直接到局域网控制。电池设备分布在人员动向附近比如门磁、人体感应、温湿度计它们必须低功耗走BLE广播或BLE连接最合适一颗电池撑一年才是合理体验。这样一来ESP32既是那个“被控制的WiFi设备”又是“收集BLE数据的汇聚点”两块板子、两条协议链路最终在同一个系统里汇合。下面这张表能看得很清楚维度WiFiBLE双协议方案功耗高不适合电池设备极低纽扣电池可撑年余按设备供电方式分流带宽大可跑音视频流小适合小包状态上报传输任务按协议匹配连接方式经路由器手机随时可达手机直连或网关汇聚两者都保留典型设备灯、插座、窗帘电机温湿度、门磁、人体感应插电走WiFi电池走BLE典型问题路由器带机量、死角延迟、手机必须在线各自问题被协议边界隔离所以“一站式”不是把两种协议强行塞进一个项目炫耀技术含量而是让每类设备都用它最擅长的协议干活这才是方案的根。2. 一站式架构怎么搭数据流、配网与状态机2.1 先画清楚上行和下行两条通路动手写代码之前我习惯先把数据流画出来不然功能一多必然乱套。这套方案里有两条核心通路上行通路BLE传感器广播温湿度数据 → ESP32作为扫描端定时抓取并解析 → ESP32把数据通过WiFi以MQTT或HTTP协议上报到Home Assistant或云平台。下行通路手机App或自动化脚本发送控制指令 → MQTT Broker → ESP32收到后立刻执行本地动作开灯、调PWM、拉窗帘必要时再通过BLE转发给周边Mesh节点执行。这里有个设计取舍值得多说一句ESP32在方案里既当执行器又当网关而不是像过去那样“路由器独立网关设备”三层架构。好处是少一个硬件设备就少一个故障点坏处是网关逻辑如果写得不好会连累灯控这种基础功能。所以我的原则是控制指令的优先级永远高于状态上报MQTT订阅回调里不做任何阻塞操作宁可丢一次状态也要保证指令秒响应。2.2 BLE配网不用扫码输密码才是真体验智能家居第一道坎就是配网。很多人习惯用SoftAP配网设备开热点、手机连上去、输WiFi密码。这个流程有几个明显的体验断点——用户要在手机设置和App之间来回切换一不小心连错热点就卡住。我在这套方案里主推BLE配网流程极简打开App点“添加设备”选择家里WiFi点发送十几秒完成。手机蓝牙一直开着整个过程不需要切到系统设置。ESP32侧的实现逻辑分三步上电读NVS非易失存储发现没有有效的SSID进入provisioning模式。启动BLE GATT服务固定UUID特征值里携带设备的SN、固件版本、配网状态同时开始广播广播包里特意塞了一个标识位App可以靠这个标识快速过滤出“这是一台待配网设备”。手机通过GATT write把SSID和密码写入特征值设备存进NVS然后立刻重启去连路由器。这里有个细节我踩过坑配网模式下千万别去连WiFi。如果设备上电后先尝试连接不存在的旧网络DHCP超时要等十几秒这段时间BLE广播已经被人忽略了用户会以为设备坏了。配网模式就是纯BLE屏蔽一切WiFi连接动作配网成功或者超时再切换状态。2.3 状态机与NVS掉电记忆整机的连接状态我维护了一个状态机这是多协议项目里最容易乱的地方IDLE - PROVISIONING - CONNECTING - ONLINE - OFFLINE每种状态对应一个LED闪烁模式、一套日志开关、一组任务调度。NVS只用来存小字段比SPIFFS存文件更合适我存的东西就四个wifi_ssid、wifi_pass、bind_token、device_name。注意一个习惯所有NVS写入都做错误返回检查别忽略返回值闪存写失败是真实存在的尤其劣质开发板在电压不稳的时候。重置逻辑也简单GPIO长按五秒清空NVS并重启恢复到出厂状态。这个功能不是给用户用的是给调试期间的我用的——每次改协议都要清干净重来没这个按键我得一直插拔烧录器。2.4 SoftAP兜底网页配网做个备份BLE配网虽好但有一个场景会翻车家里WiFi换名字了设备还在旧网络里硬撑此时手机蓝牙就算扫到设备也连不上因为设备可能正卡在重连的循环里。另外有些老手机蓝牙栈兼容性差GATT写入会失败。所以我保留了SoftAP作为第二通道。这部分的实现不复杂设备进入SoftAP模式热点名形如ESP32-XXXX内置HTTP服务器手机连上热点后访问192.168.4.1会打开一个内嵌的极简HTML页面输入SSID和密码提交同样的流程存NVS然后重启。网页文件我直接压缩进固件里用Embedded Filesystem或直接转成C数组好处是用户不需要装App也能完成配网量产调试时尤其省事。3. 板子不选对后面全白费——硬件选型与开发环境3.1 ESP32/ESP32-C3/ESP32-S3怎么分市面上ESP32家族型号不少第一次接触很容易懵。我按实际用途给个分类你照着选就行芯片型号内核/主频无线能力适合的角色备注ESP32经典款双核240MHzWiFiBLE 4.2主控/网关/灯控引脚多生态最成熟ESP32-C3单核RISC-V 160MHzWiFiBLE 5.0低功耗传感器节点价格低RTC功耗小ESP32-S3双核240MHzWiFiBLE 5.0带屏网关/语音入口有AI加速和USB原生如果做完整方案我建议主控用经典ESP32传感器节点用ESP32-C3。原因是C3的深度睡眠功耗比经典ESP32更低而且BLE 5.0的长广播和扩展广播参数在多点位部署时更好用。S3确实性能更强但作为家用执行器有点性能过剩把钱省下来多买几个传感器更划算。3.2 开发框架和下载源的一些现实问题开发框架二选一Arduino或ESP-IDF。我个人的习惯是快速原型和验证逻辑用Arduino正式量产和调试协议栈底层用ESP-IDF。Arduino的库封装得简单PubSubClient、WiFiManager这些库拿来即用但遇到需要用esp_bt_controller_mem_release这种底层接口的时候还是要回IDF层查文档。新手最容易卡住的是环境搭建。Arduino要装ESP32开发板包ESP-IDF要拉工具链这俩从GitHub拉都慢得让人怀疑人生。我自己现在用的是国内镜像加速ESP-IDF工具链和Arduino-ESP32包都有镜像别硬等官方链接五分钟能装完的事不值得耗一个小时。烧录方式也有讲究。经典ESP32 DevKit是USB转串口方案烧录需要手动拉低GPIO0再按EN进入下载模式ESP32-C3和S3大多带原生USB直接当串口设备用省心很多。如果用了自动下载电路比如板载CP2102配合DTR/RTSIDE里一般直接点烧录就行不用手动按键。3.3 引脚规划留出来的都是后面要用的很多新手栽在引脚规划上程序写到一半发现I2C引脚和PWM引脚冲突于是飞线、改板子、重写管脚定义非常痛苦。我在这个方案里的引脚分配供你参考I2C固定用经典ESP32的GPIO21(SDA)和GPIO22(SCL)接温湿度传感器或OLED屏。UART0永远留给日志输出不要挂外设调试信息是排查问题的眼睛。外部中断预留GPIO4和GPIO16给PIR人体感应和门磁启用EXT0唤醒功能。PWM输出用GPIO25和GPIO26接灯带和风扇调速。ADCGPIO34和GPIO35只做输入别当输出用这个很多人踩过。保留引脚GPIO12和GPIO13留给后续扩展板。注意一点经典ESP32的GPIO36-39是RTC GPIO但只能输入不能输出而且没有内部上拉接按键会非常痛苦。提前避开能省很多事。3.4 电源是隐形大坑这个必须单独拎出来说。ESP32在WiFi发射瞬间电流可以到500毫安很多开发板用AMS1117做3.3V稳压USB供电时压降严重表现就是连上WiFi的瞬间板子重启或者蓝牙广播一开就崩溃。我踩过这个坑后给主控的供电就不再USB直供了用DC-DC降压模块MP1584这类从5V降压到5V不对是直接用DC-DC把12V或5V降到合适电压再在输入端并联一个1000uF电解电容扛瞬态电流。电池节点那边正好相反要选静态电流极低的LDO我用的TPS62742空载静态电流能到微安级别。如果你用普通LDO哪怕传感器在睡觉静态电流都够让电池半年报废。电源设计是整个方案里最不性感的环节但它决定系统能不能长期稳定跑。4. 分阶段跑通从WiFi灯控到BLE传感器联动4.1 阶段一先把WiFi通路做成稳定可用的我习惯先把最简单的WiFi灯控做扎实再往上面叠BLE功能不然两头同时调试出了问题都不知道怪谁。灯的驱动不复杂用PWM调速而不是继电器因为继电器有机械寿命而且通断声音明显。ESP32的LEDC外设可以输出PWM代码大致是这样#include WiFi.h #include PubSubClient.h const char* ssid your_ssid; // 实际项目中从NVS读取 const char* password your_pass; WiFiClient espClient; PubSubClient mqtt(espClient); #define LIGHT_PIN 25 #define LEDC_CHANNEL 0 #define LEDC_FREQ 18000 // 18kHz高于人耳可听范围避免电感啸叫 void mqttCallback(char* topic, byte* payload, unsigned int len) { if (strstr(topic, light/set)) { int value atoi((char*)payload); ledcWrite(LEDC_CHANNEL, value); } } void setup() { Serial.begin(115200); ledcSetup(LEDC_CHANNEL, LEDC_FREQ, 8); ledcAttachPin(LIGHT_PIN, LEDC_CHANNEL); WiFi.begin(ssid, password); mqtt.setServer(192.168.1.100, 1883); mqtt.setCallback(mqttCallback); } void loop() { if (!mqtt.connected()) { mqtt.connect(esp32-light-01); mqtt.subscribe(home/light/living/set); } mqtt.loop(); }这个阶段的目标不是跑通而是验证重连机制。我会在调试时手动断网、重启路由、改WiFi密码确认设备能在合理时间内恢复连接。用mqtt.setKeepAlive(20)把心跳周期调到20秒以内能避免多数路由器空闲老化踢连接的问题。4.2 阶段二BLE GATT服务和广播端WiFi链路稳住之后开始加BLE。ESP32这边要同时做两件事开启GATT服务提供在线诊断接口以及作为扫描端抓取传感器的广播数据。传感器端我强烈推荐用非连接广播的方式工作而不是建立GATT连接。理由很简单一个温湿度传感器一天上报几百次数据每次都是一次完整的GATT连接握手费电不说还要处理配对、断线重连这些问题。但广播模式就纯粹多了往广播包里塞数据发完就睡谁爱听谁听。传感器端的广播间隔我设置的是1000毫秒数据格式用制造商自定义字段避免和标准服务冲突。ESP32主控这边定期扫描扫描窗口和间隔要根据节点数量调节点少就扫描窗口开大点比如每1000ms窗口扫描500ms节点多了要反过来限制扫描窗口避免BLE任务吃太多CPU导致WiFi响应变慢。4.3 阶段三双协议联动逻辑WiFi和BLE两条链路都通了真正“一站式”的体验在于联动。我最常演示的一个场景卫生间温度超过28度自动打开排气扇。逻辑拆解一下ESP32每隔两秒扫描一次BLE广播缓存解析出温度和湿度字段。数据进环形缓存做简单滤波连续三次超过阈值才触发动作防止瞬时抖动。触发动作通过MQTT发布到本地Home Assistant同时本地直接拉高排气扇PWM。本地不经过云、不经过HA中转就是为了保证内网断网时自动化仍然可用。温度回落到阈值之下后延时五分钟关排气扇。这些时间参数都在NVS里改配置不用重刷固件。这套联动逻辑让我意识到一个道理智能家居的“智能”不一定要靠AI一对简单的阈值联动加上合理的容错体验已经比手动开关好太多了。4.4 配网协议约定手机App到底发什么为了让手机App和ESP32之间不鸡同鸭讲配网时GATT写入的数据格式要提前约定好。我这里用了一个JSON字符串{ cmd: provision, ssid: MyHomeWiFi, pass: base64加密后的密码, token: 设备绑定令牌, ts: 1700000000 }注意密码我用Base64编码后再传因为有些路由器密码带特殊字符直接UTF-8传输在蓝牙GATT的MTU限制下很容易截断。实际写入时如果一次写不完就需要配置长特征值并处理分段写入这部分逻辑在BLE 4.2之后支持得比较好ESP32侧用esp_ble_gatts_set_attr_value配合回调处理即可。5. 调试实录几个坑的完整排查链路5.1 坑一BLE广播和配网服务互相干扰现象冷启动后打开配网App扫不到设备偶尔扫到了写入配网特征值也没响应。排查链路我先开大了所有相关日志把ESP_LOG_LEVEL调成VERBOSE重点看esp_bt_controller和esp_gap模块的输出。发现设备启动后WiFi Driver先初始化并自动重连了旧网络重连失败进入了反复重试状态占用了大量CPU时间BLE广播被饿死。之后我把启动顺序改成检测NVS无SSID → 不初始化WiFi直接初始化BT controller并开始BLE广播 → 配网完成后才重启进入WiFi初始化流程。这个改动让配网成功率从七成提到了接近满分。经验多协议系统里不要默认所有功能都并行工作。初始化顺序和资源分配要写在设计文档里特别是协议栈共用的SRAM需要调用esp_bt_controller_mem_release释放不用的内存。5.2 坑二手机断连后“找不到设备”现象设备运行一段时间后手机App显示设备离线重启ESP32也没用必须重新扫描发现设备。排查链路这个问题坑了我一个下午。我一步步验证先用nRF Connect这款App手动连接设备结果是能连上的说明BLE广播正常再用自己的App连接却拿不到服务列表。对比之后怀疑是GATT服务没有在断线后重新注册。查代码发现我只在setup()里调用了esp_ble_gatts_app_register但断连后GAP事件处理里没有重新注册服务。修复方案是在ESP_GATTS_DISCONNECT_EVT处理完参数清理后重新调用esp_ble_gatts_app_register同时清掉安全配对缓存。经验排查BLE问题时先用第三方调试工具确认板端状态再回到自己的代码找问题。nRF Connect能帮你区分“设备坏了”和“App逻辑有问题”这个步骤能省掉一半的冤枉时间。5.3 坑三MQTT长时间运行后掉线现象设备运行三五天后App收不到状态更新重启ESP32才恢复。排查链路第一反应是网关或路由器问题但换了个路由器依然复现。于是抓日志看MQTT连接状态发现不是突然掉线而是pingresp超时之后主动断连。再查路由器配置发现默认的TCP超时时间比较短MQTT的心跳间隔却设成了60秒导致路由器先把空闲连接清掉了。解决方案是把MQTT keepalive设成20秒同时在mqtt回调里检测到掉线立即重连不做指数退避等待。经验任何长连接协议都要主动适配中间设备路由器/网关的空闲老化机制。如果你部署在别人的网络环境里无法控制路由器配置那就必须缩短心跳间隔。这是上量之后最容易翻车的地方因为本地测试很少能连续跑三五天。5.4 坑四电池节点一个月就没电现象标称用一年的温湿度节点实际一个月就没电了。排查链路万用表串联测静态电流发现待机电流居然有3毫安正常应该是个位数微安。逐个排查板载LDO芯片没关、状态LED仍然点亮、芯片根本没进Deep Sleep而只是delay循环。修复方案是改造硬件把LDO使能脚拉低摘掉不必要的LED代码里用esp_pm_config配置电源策略然后确认睡眠深度为ESP_PM_APB_FREQ_MAX配合RTC唤醒。功耗估算公式我建议每个人都算一遍假设每天唤醒采集100次每次工作50毫秒、电流30毫安加上广播瞬间的峰值一天功耗大概在0.2毫安时左右一颗500毫安时的CR2032理论上能撑两年。如果你算出来的数字是“一个月”那肯定哪里没睡踏实。6. 从演示到部署安全、OTA和规模化6.1 配网安全WiFi密码不能到处飞智能家居的安全问题容易被忽视但配网阶段恰恰最敏感。我的基本原则WiFi密码绝不能出现在BLE广播包里只能通过配网服务的GATT特征值传输并且该特征值要求连接加密后才允许写入。设备绑定逻辑用随机生成的token不用MAC地址做身份识别防止被伪造。在局域网里对IoT设备开启路由器自带的AP隔离功能避免某台设备被入侵后横向扫描你的手机和电脑。量产固件开启flash加密和安全启动这个在ESP32上配置成本不高但对防篡改是关键。6.2 OTA与灰度升级做智能家居不是写完固件就结束了后续还要迭代功能、修漏洞。OTA方案我按两个阶段设计小范围灰度用直连WiFi推送先给测试节点升级稳定后全量推送。固件分区要预留AB分区升级过程中如果检测到启动崩溃bootloader自动回滚到旧版本。这里有个细节OTA升级过程中要暂停BLE广播升级任务非常吃CPU和内存BLE持续工作容易导致升级超时或升级后行为异常升级完成重启后再恢复BLE。6.3 全屋规模化BLE Mesh和Matter如果家里要铺到二三十个传感器单靠ESP32做BLE scanner去周期扫描会越来越吃力。我的建议是16个节点内用现有方案再多就规划引入BLE Mesh。ESP32在Mesh里可以做Friend节点或者LPN节点把低功耗传感器通过Mesh中继汇聚到主控主控再通过WiFi上报到HA。未来如果要兼容各大主流生态Matter是绕不开的方向ESP32已经有官方Matter SDK底层正好是WiFi加BLE的协议栈复用。不过那是后面的故事了先把当前这套双协议跑稳。这套方案我前后改了七版最大的体会是双协议的一站式智能家居难的不是分别调通WiFi和BLE而是让它们在长期维护中稳定协作。如果你打算照着做我的建议是从一个最小闭环出发两块板子、一个App、一条联动逻辑走通了再谈全屋。稳定比功能多更有价值。最后分享一个让我少掉很多头发的小技巧把日志字符串统一打上模块前缀NET:、BLE:、OTA:、NVS:半年后你回来排查问题看着整齐的日志会感谢当初的自己。