基于ESP32的WiFi+BLE双模智能家居一站式方案实践

从ESP8266时代开始，我就一直在琢磨怎么在家里搭一套真正属于自己的智能家居系统。折腾过红外遥控，折腾过单片机加继电器，最后发现，最省心也最能打的方案，是拿一块ESP32，把WiFi和BLE同时用起来。这块几十块钱的开发板，几乎凭一己之力把设备端、控制端和本地中枢串在了一起，不用买一堆网关、不用接复杂的线，一个芯片就能覆盖智能家居最核心的两条通信链路：WiFi负责稳定上云、接本地服务，BLE负责近场直连手机、快速配网。这篇文章把我的完整思路、硬件选型、固件实现和控制端接入方案一起整理出来，适合正在做毕业设计、DIY全屋智能或者想快速出产品原型的工程师参考，照着抄作业也能跑通。

我会把每一层的技术决策都讲清楚：为什么用WiFi不用以太网，为什么用BLE而不是干脆用蓝牙经典，为什么消息格式要统一，以及那些“不折腾不知道、一折腾吓一跳”的坑。

1. 为什么是ESP32？这套方案的核心思路

1.1 一个芯片解决两个通信刚需

智能家居设备永远不会只面对一种使用场景。人不在家的时候，设备要通过路由器把状态传到云端或者家里的服务器，靠的是WiFi；人站在设备旁边，想直接开个灯、读个温湿度、或者第一次给设备配网，靠的是蓝牙低功耗（BLE）。问题在于，很多方案把通信方式做成单选题：ESP8266只有WiFi，传统蓝牙模块要么功耗高要么配对麻烦，而ESP32是极少数同时具备稳定WiFi和完整BLE协议栈的芯片，关键价格还便宜。

两颗无线模块装在同一个芯片里，由内部射频仲裁机制协调收发，两者都在2.4GHz频段工作，所以物理上天然需要规避互相踩踏。实际开发中，当WiFi业务流量大时，BLE的连接间隔会适当让步；反过来，BLE长时间高频上报，WiFi的吞吐量也会受影响。我的习惯是：WiFi作为常驻链路，BLE连接参数设置得保守一点，比如连接间隔设在30到50毫秒，notify只在数据变化时触发，而不是像串口一样一股脑往外倒。

1.2 一颗ESP32能干多少活

很多没实际用过ESP32的人会低估它的能力。双核240MHz的CPU，带WiFi和BLE，自带ADC、触摸传感器接口、LEDC PWM、RTC低功耗管理，甚至能跑轻量级的HTTP服务器和加密通信。这意味着一个节点可以同时承担采集、控制、显示和上报四项任务，而不需要像以前的STM32方案那样，外挂一堆模块。

我的一个典型节点就是：ESP32接DHT22读温湿度，接BH1750读光照，接一路继电器控制灯，再接一个0.96寸OLED显示当前状态，同时通过WiFi上报到Home Assistant，手机在设备附近时直接用BLE读取数据。这些任务堆在一起，固件跑下来还有很多余量。对比之下，ESP8266做同样的事就得砍功能，STM32则要加WiFi模块、加BLE模块，成本翻倍，调试崩溃的次数也翻倍。

所以我的结论很直接：除非你已经有一个非常成熟的STM32方案，否则智能家居节点直接选ESP32，不折腾。

2. 整体架构与硬件准备

2.1 三层架构：感知执行层、接入层、控制端

这套一站式方案，我用的是非常清晰的“三层模型”：

第一层是感知执行层，也就是各个房间里的ESP32节点，负责读传感器、控制继电器和灯；第二层是接入层，由家用路由器、MQTT broker和Home Assistant构成，所有设备的状态汇总到这里；第三层是控制端，包括手机App、Web面板以及自动化规则。

最需要想清楚的是：WiFi管哪条路径，BLE管哪条路径。在方案里，WiFi承载的是设备与路由器、Home Assistant之间的双向数据流，设备的温湿度变化、开关状态都是走WiFi的。BLE承载的是手机和设备之间的近场控制流，就算家里路由器挂了、WiFi断了，你站在设备旁边依然可以用手机把灯打开。这种“双重通道”设计是整套方案的灵魂，也是为什么我坚持要选自带WiFi和BLE的芯片，而不是妥协成单一通信方式。

2.2 硬件选型与接线规划

开发板方面，预算充足直接上ESP32-DevKitC V4，注意看USB转串口是CP2102还是CH340，不同芯片需要不同的驱动。传感器我推荐DHT22而不是DHT11，虽然贵一点，但温湿度读数稳定得多，DHT11的湿度数据到后面根本没法看。光照传感器用BH1750，走I2C总线，同一个总线上可以挂多个传感器。执行器方面，继电器一定要选带光耦隔离的模块，别省这十几块钱；驱动灯带如果用MOS管，注意选逻辑电平兼容的型号。

接线时重点关注引脚分配，这决定你后面会不会掉进“WiFi一开ADC就失效”的坑。ESP32的ADC2会被WiFi占用，所以模拟传感器尽量接在ADC1引脚上。Boot Strapping引脚不要去接大电容或者强行驱动，可能导致上电后进不了下载模式。我的一份标准引脚规划如下：

电源规划是很多人忽略的重灾区。ESP32峰值电流在WiFi发射瞬间可能超过300mA，劣质USB电源一压就挂，表现就是设备反复重启。我的经验是，每个节点单独配一个至少1A的5V电源，如果继电器直接接在交流负载上，给设备供电的部分最好再加一个DC-DC隔离模块。继电器动作时产生的反电动势如果不处理，轻则让ESP32瞬间复位，重则打坏GPIO口，实测下来，一个续流二极管能解决绝大多数复位问题。

3. 固件开发与核心代码实现

3.1 开发环境：Arduino还是ESP-IDF

智能家居这种项目，我建议从Arduino框架入门，原因很简单：生态成熟、示例多、调试效率高。在Arduino IDE里打开“首选项”，把开发板管理器地址填上：

https://espressif.github.io/arduino-esp32/package_esp32_index.json

国内网络不稳的话，可以换用乐鑫的国内镜像加速。安装完成后，在“开发板管理器”里搜索esp32，选装Espressif官方包。这时候还要注意一点，Arduino IDE安装ESP32包后会把工具链下载到一个目录，如果中途失败，手动删掉partitions和tools目录重新装是最快的办法。

跑量产的场景我反而推荐PlatformIO，版本锁定机制在团队协作时很有用。无论是哪种环境，第一步都要把串口驱动装好，否则总是卡在“Connecting........”这一步，心态直接崩。

3.2 WiFi连接模板：能自愈才是好固件

WiFi连接看似简单，但直接写WiFi.begin()然后阻塞等待，在智能家居场景里一定会后悔。家里路由器重启一次，设备就永久掉线，这种体验能让人退货。我用的连接模板分三层：WiFiMulti配置多个可用网络、事件回调感知断线原因、指数退避重连防止被路由器踢出。

#include <WiFi.h> #include <WiFiMulti.h> WiFiMulti wifiMulti; void onWiFiEvent(WiFiEvent_t event) { switch (event) { case ARDUINO_EVENT_WIFI_STA_CONNECTED: Serial.println("WiFi connected"); break; case ARDUINO_EVENT_WIFI_STA_DISCONNECTED: Serial.println("WiFi disconnected, schedule reconnect"); break; case ARDUINO_EVENT_WIFI_STA_GOT_IP: Serial.print("IP address: "); Serial.println(WiFi.localIP()); break; default: break; } } void setupWiFi() { WiFi.onEvent(onWiFiEvent); wifiMulti.addAP("Home_2.4G", "password"); wifiMulti.addAP("Home_Guest", "guest_password"); WiFi.mode(WIFI_STA); int retry = 0; while (wifiMulti.run() != WL_CONNECTED && retry < 20) { delay(500); retry++; } } void loop() { if (wifiMulti.run() != WL_CONNECTED) { // 不要在这里阻塞等待，其他任务继续跑 digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN)); } // 其他业务逻辑 delay(10); }

关键点在于：如果wifiMulti.run()已经断线，我不在主循环里死等，而是让线程继续跑，靠事件回调触发重连逻辑。实际测试中，这种方式在路由器重启后30秒内就能自动恢复连接。曾经有一次我把重连间隔写死成100毫秒，结果被家用路由器当作攻击流量踢出去，设成1秒起步、失败翻倍，稳定多了。

3.3 BLE服务：让手机随时直连设备

BLE部分我用的是BLE Server的方式，设备作为外设广播自己的服务，手机作为中心设备连接并读取数据。初始化BLE的代码很简单，但有几个细节不处理会踩坑：必须设置广播数据里的设备名称、必须声明Characteristic的通知属性，还要设置合适的广播间隔。

#include <BLEDevice.h> #include <BLEServer.h> #include <BLEUtils.h> #include <BLE2902.h> #define SERVICE_UUID "6e400001-b5a3-f393-e0a9-e50e24dcca9e" #define CHAR_TEMP_UUID "6e400002-b5a3-f393-e0a9-e50e24dcca9e" #define CHAR_CONTROL_UUID "6e400003-b5a3-f393-e0a9-e50e24dcca9e" BLEServer* pServer = NULL; BLECharacteristic* pTempChar = NULL; BLECharacteristic* pControlChar = NULL; bool deviceConnected = false; class MyServerCallbacks : public BLEServerCallbacks { void onConnect(BLEServer* server) { deviceConnected = true; Serial.println("BLE client connected"); } void onDisconnect(BLEServer* server) { deviceConnected = false; Serial.println("BLE client disconnected"); BLEDevice::startAdvertising(); } }; void setupBLE() { BLEDevice::init("LivingRoomNode"); pServer = BLEDevice::createServer(); pServer->setCallbacks(new MyServerCallbacks()); BLEService* pService = pServer->createService(SERVICE_UUID); pTempChar = pService->createCharacteristic( CHAR_TEMP_UUID, BLECharacteristic::PROPERTY_READ | BLECharacteristic::PROPERTY_NOTIFY ); pTempChar->addDescriptor(new BLE2902()); pControlChar = pService->createCharacteristic( CHAR_CONTROL_UUID, BLECharacteristic::PROPERTY_READ | BLECharacteristic::PROPERTY_WRITE ); pService->start(); BLEAdvertising* pAdvertising = BLEDevice::getAdvertising(); pAdvertising->addServiceUUID(SERVICE_UUID); BLEDevice::startAdvertising(); }

这里的Service UUID我用的是经典的自定义调试服务UUID，实际项目中建议用UUID在线工具生成专属于自己的值。另外，BLE2902这个Descriptor必须加，否则iOS上收不到notify，这是很多新手卡半天的地方。

读温度和上报温度走的是同一个Characteristic，当数据变化时调用pTempChar->setValue()和pTempChar->notify()。控制灯的命令走另一个Characteristic，手机写入一个字节比如0x01/0x00，设备在写入回调里直接控制继电器。BLE通道没有复杂的协议解析需求，传输的内容越轻越好，我通常传紧凑的二进制或短字符串，而不是一上来就上JSON。

3.4 消息格式统一：WiFi和BLE的数据约定

这是整套方案里最容易被忽略、但投入产出比最高的设计。WiFi链路数据量大、走的是MQTT到Home Assistant；BLE链路数据短、走的是手机App。如果两边各写各的数据格式，以后每加一个设备类型就要改一遍代码。

我的做法是定义一套统一的结构化文本，底层不管走WiFi还是BLE，内容都是同一份：

{"src":"livingroom","dev":"env","type":"temp","val":25.3,"unit":"C","ts":1716000000}

WiFi侧把这条数据作为MQTT消息发布到主题home/livingroom/env；BLE侧把同一字符串写入Characteristic的notify。这样一来，Home Assistant端解析JSON的逻辑可以复用，手机App的解析逻辑也可以复用，唯一不同的只是传输通道。这个设计后续帮我省了大量时间，比如增加一个空气质量传感器的时候，只需要在设备端组装一条新JSON，上层代码完全不用动。

3.5 功耗优化：长期在线设备的必修课

智能家居节点如果是插电的，功耗压力不大，但如果是电池供电的门磁、温湿度计，功耗直接决定换电池的频率。ESP32默认WiFi全速运行，整板电流能到80到100mA，这显然不适合电池方案。

省电的第一步是让WiFi进入Modem Sleep：

esp_wifi_set_ps(WIFI_PS_MIN_MODEM);

这样在没有数据收发的时候，射频部分会间歇休眠，实测下来平均电流能降到30mA左右。如果还想进一步压，就启用Light Sleep，定时唤醒上报数据后继续睡，这个模式下的平均电流能做到几毫安级别。真正要实现电池用一年的产品，则要切到Deep Sleep，保留RTC定时器，其他全部关掉。

注意，Light Sleep唤醒后，WiFi需要重新建立连接，这个时间通常要一两秒，所以设计上报节奏时要预留出网络重连时间。实测中，每隔30秒唤醒一次上报温湿度，两节AA电池可以用几个月，这个成绩对DIY项目来说完全够用。

4. 控制端与平台接入

4.1 用Home Assistant把设备变成自动化系统

单设备控制只是第一层，智能家居的灵魂在自动化。我选择Home Assistant作为本地中枢，裸机跑在旧笔记本上，设备全部走MQTT接入。在树莓派上装好Mosquitto，然后给每台ESP32配置唯一的MQTT客户端，发布传感器状态，订阅控制命令。

Home Assistant端只需要添加MQTT集成，然后创建传感器实体和开关实体。自动化规则可以写成：客厅温度超过28度时自动打开风扇，或者傍晚光照低于某个值自动开灯。这些规则全部本地运行，不依赖云端。另有一条路径是用ESPHome直接对接Home Assistant，在ESPHome里写yaml就能完成大部分节点配置，但由于我已经有大量手写固件，统一走MQTT反而更一致。

sensor: - platform: mqtt name: "LivingRoom Temperature" state_topic: "home/livingroom/env" unit_of_measurement: "°C" value_template: "{{ value_json.val }}"

4.2 BLE直连方案：不依赖网络的应急通道

BLE的主要场景是两个：第一是快速配网，第二是断网时的本地直控。设备上电后会先进入WiFi配网模式，启动一个名为ESPConfig_XXXX的SoftAP热点，手机连上后访问192.168.4.1填入WiFi账号密码。配网成功后设备自动切换成正常模式并启动BLE服务。

手机控制端我用nRF Connect做过最原始的验证，因为它的GATT信息展示很直观。正式项目里可以自己用Flutter或者微信小程序写BLE控制页面，微信小程序的蓝牙接口对ESP32的兼容性还是不错，只要把BLE服务UUID和Characteristic UUID对应好，基本一把过。用BLE直连控制灯的延迟通常在几十毫秒以内，体感比走WiFi经过MQTT再到设备要快很多。

4.3 安全实践：该锁的地方一定要上锁

智能家居过渡开放比不开放更危险。以下几个地方我必须强调：

第一，固件里不要明文写家里的WiFi密码和MQTT账号。我见过很多开源代码里直接硬编码，一公开仓库就把自己家网络信息暴露了。自己DIY可以用Preferences把密码存在Flash里，配网时写入；做产品则要上加密存储和固件签名。第二，配网用的SoftAP热热点在配网成功后必须主动关闭，最多保留3到5分钟，否则任何人都能重新配网把设备接走。第三，MQTT broker一定要开启账号密码认证，Home Assistant启用长期访问令牌机制。

另外想泼一盆冷水：网上经常能看到各种所谓破解WiFi密码的工具和字典下载，作为开发者，这种事情压根不该碰，既违法又毫无技术含量。真正该做的是把自家路由器的弱密码换掉、打开WPA2/WPA3加密、关闭WPS、定期更新固件。你的设备端做得再安全，如果网络入口是裸奔的，所有防护都是白搭。

5. 常见问题与排查实录

5.1 WiFi连不上、反复掉线

排查WiFi问题，第一步永远是看串口日志，别靠猜。ESP32日志会把连接失败原因打得清清楚楚，常见集中情况：

• 路由器只开了5GHz频段，ESP32不支持。
• 2.4GHz信道太拥挤，尤其是公寓楼里邻居热点扎堆。连接稳定但慢的话，可以去路由器后台把信道固定到1、6或11里空闲的一个。
• 密码特殊字符在代码里转义出错，比如中文路由器SSID。
• 设备在快速移动，信号不稳定，建议直接看RSSI。

我踩过一个特别典型的坑：某台ESP32在WiFi开了加密后频繁掉线，后来发现是板载天线附近有一颗螺丝干扰了射频。排查到最后哭笑不得，把金属件移开就全好了。硬件布局对WiFi的影响往往比想象中大。

5.2 BLE扫描不到、连接秒断

BLE扫描不到设备，最常见原因是广播没有开。BLEDevice::startAdvertising()之后还要确认广播对象里真的包含了服务UUID，有些示例代码只创建了服务没把广播打开。手机能搜到但连不上，通常是因为设备名称里的空格或者中文被手机端识别异常，把广播名称改成纯字母数字就好。

关于连接秒断，我遇到过两种情况：一种是Characteristic缺少BLE2902描述符，导致notify订阅失败，手机一订阅就被断开；另一种是MTU协商异常。ESP32默认的MTU比较低，高负载传输时可以主动调高MTU，减少分包距离。

5.3 烧录失败卡在“Connecting”

这个问题几乎是ESP32新手必经之路。本质原因是芯片没有进入下载模式，需要把GPIO0拉低再复位。操作顺序是：按住开发板上的BOOT键不松，插上USB线，然后松开BOOT，这时候Arduino IDE显示“Connecting.........”后能顺利进入烧录流程。如果是自动下载电路失效，可以手动飞线把GPIO0接GND再上电。

串口上全是乱码的话，十有八九是固件运行信息输出波特率设置不对，把串口监视器调到115200就好了；还有可能是CH340驱动版本太老，补一下驱动再试。

5.4 继电器一动作，ESP32就重启

这是我在实际节点调试时遇到的问题：继电器模块没有光耦隔离，线圈吸合瞬间产生反向尖峰，直接把ESP32供电电压拉崩。排查时串口最后一条日志往往是“abort() in IRAM”，肉眼根本看不出原因。

解决办法有两个：一是换质量好的带光耦隔离继电器模块；二是在继电器线圈两端并联续流二极管，阴极接正极，阳极接负极。最好再在ESP32的VSYS输入端加一个1000uF电容扛住瞬态跌落。实测做完这一步，继电器随便切换，系统稳如老狗。

还有一个电源思路供参考：如果节点控制的是大功率负载，例如热水器、空调，最好不要让ESP32直接控制220V，而是让ESP32控制一个接触器，中间用继电器隔离，这样就多了一层物理防护，也更安全。

最后分享一点我的实际体会

这套方案做下来以后，我最大的感触是：不要一开始就想着全家几十个节点一次成型，先把一个卧室节点完整跑通，再把另一台设备加进去，逐步扩展。BLE和WiFi共享一套消息格式这个决定，让我后续每次加设备都变得极其轻松，基本就是复制粘贴再改改GPIO。

现在我家里的客厅节点已经稳定运行大半年，平时走WiFi上报到Home Assistant，某次路由器升级时WiFi意外断了，我站在客厅用手机BLE依然把灯关了，那一刻才真正理解“一站式”这三个字的分量。如果你正准备做智能家居项目，ESP32这颗芯片会是你投入产出比最高的一次尝试。