这套方案我前后做了差不多三个月从最早只想搞定一个远程开关灯到最后把温湿度采集、门窗告警、窗帘控制、遥控器聚合都塞进了一个以ESP32为核心的体系里。中间踩了不少坑也推翻过好几次架构。今天这篇不写客套话直接把这套WiFiBLE一站式智能家居方案的选型逻辑、架构设计、核心代码、调试实录和教训全部分享出来。如果你正准备用ESP32做点自己的智能家居这篇应该能帮你少走很多弯路。做这套方案的初衷很简单市面上的智能家居套装一个网关一个App一套私有协议设备买回来就被生态绑死了。我想用ESP32自己搭一套既能走WiFi远程控制、又能用BLE在近场快速配网和低功耗通信的方案把“联网”和“控制”分成两层来做既保留灵活性又不会在功耗和响应速度之间被卡死。整套系统下来成本控制在两百块以内所有代码和应用场景完全可控这才是DIY智能家居该有的样子。1. 方案选型为什么锁定ESP32WiFi和BLE怎么分工1.1 ESP32这颗芯片到底强在哪很多人在选型时会纠结到底用ESP8266还是ESP32甚至有人会考虑STM32加外部WiFi模块的方案。我的结论很简单如果目标是“一站式”智能家居直接上ESP32别犹豫。ESP32的核心优势在于它把WiFi、BLE、双核CPU、丰富外设、低功耗模式全部塞进了一块芯片。ESP8266只有WiFi没有BLE想要近场配网和低功耗广播就得外挂模块麻烦不说稳定性也是个隐患。STM32加外部WiFi模块的组合性能确实强但开发效率低很多系统复杂度也上去了而且WiFi协议栈的维护成本很高——你不可能像用ESP32那样轻松搞定OTA、TLS、MQTT这些上层应用。我手头这批ESP32-WROOM-32模组搭载双核Xtensa处理器主频240MHzSRAM 520KBFlash 4MB。这个配置跑WiFi协议栈加BLE协议栈再同时跑一个Web服务器和一个MQTT客户端完全没有压力。更重要的是价格正常渠道十几二十块钱一片坏了不心疼适合做遍布全屋的多节点部署。1.2 WiFi和BLE在整套方案里各管什么这是整套架构最核心的思考。一开始我也想过全部用WiFi但很快发现配网环节是个大问题。新设备上电之后怎么知道你家路由器的SSID和密码总不能让每个设备都先连上一个热点再手动输密码。BLE完美解决了这个痛点。我最终的分工是这样BLE负责“近场配网”和“低功耗广播”。设备上电后先广播一个特定Service手机App扫描到之后通过BLE连接把WiFi的SSID、密码以及服务器地址写进设备Flash里。配网完成后BLE通道可以继续保留用于在设备附近时直接控制也可以关闭以省电。WiFi负责“远程通信”和“数据交换”。设备以STA模式连接家庭路由器与局域网内的MQTT Broker或Web服务器交互。用户在外网时通过端口映射或云端中转控制设备。你可能会问为什么不让BLE把配网和控制全包了因为BLE在穿墙能力和传输速率上远不如WiFi隔一堵墙信号就衰减得很厉害。而智能家居里“人在家里近距离操作”和“人在外面远程查看”这两种场景是并存的分开处理才是最合理的。GPS定位还会漂呢一套通信协议想通吃所有场景结果一定两头都做不好。1.3 智能家居无线协议横向对比既然聊到选型我把主流的几种方案放在一起对比一下这样你能更清楚为什么ESP32的WiFiBLE组合是当前DIY智能家居的“最优解”。方案频率速率功耗配网体验组网能力DIY友好度ESP32 WiFi2.4GHz最高150Mbps中高需配网辅助通过路由器/AP组网高BLE2.4GHz约1Mbps低天然适合广播即发现星型可扩展Mesh高ZigBee2.4GHz约250kbps低需要网关协调器网状网络强低需硬件认证LoRa868/915MHz等极低极低手动或专用工具星型/点对点一般需网关看到没有ZigBee的网状网络确实好但你要买认证模块、要买协调器网关、协议栈还要授权DIY玩家很难玩转。BLE Mesh在ESP32上已经能通过蓝牙Mesh协议栈实现但复杂度不低我建议先跑通星型结构后续再扩展。WiFi加BLE这套组合最大的优势就是开发成本低、生态工具链成熟、配网体验顺畅而且单芯片就能搞定不需要额外的网关硬件。2. 整体架构设计与功能拆分2.1 设备端、控制端、服务端三层角色划分任何智能家居项目只要一展开就会乱成一锅粥。我的经验是动手写代码之前先想清楚整个系统的角色边界。这套方案我划分成三个层次设备端就是一个个ESP32节点负责采集环境数据温湿度、光照、人体红外和执行控制动作开关灯、开合窗帘、继电器通断。设备端我分成了“传感器节点”和“执行器节点”但在代码层面统一抽象成了“受控终端”一条WiFi链路加一条可选的BLE链路。服务端我家里的树莓派上跑着MQTT Broker同时也跑了一个简单的Web服务。设备端上报数据到MQTT主题控制指令通过MQTT下发。树莓派在这里扮演的是中枢和消息路由的角色。如果你不想额外搞一个树莓派也可以让ESP32直接内嵌Web服务器手机连上设备热点或同网段直接访问设备IP这适合单设备场景但对多设备的统一管理不够友好。控制端手机App是我自己写的用的Flutter同时做了一个网页版控制台。网页版挂在树莓派上用浏览器就可以打开操作。这样做的好处是无论你是Android、iOS还是电脑打开浏览器就能控制家里所有设备不用为平台发版操碎心。2.2 我最后落了哪些功能做智能家居最忌讳贪多嚼不烂。我最终收敛成五个子模块每一块都真正跑通了环境监测DHT22采集温湿度BH1750采集光照强度。采集周期默认60秒数据通过MQTT上报树莓派端记录到SQLite里可以生成温湿度曲线。灯光控制继电器控制卧室主灯和客厅灯带。支持手动开关、定时开关和亮度调节配合PWM调光灯带。门窗告警门磁传感器接在ESP32的GPIO上中断触发检测门被打开。门窗状态变化时设备端即时上报一条MQTT消息树莓派推送到手机通知。这块用到了ESP32的深度睡眠唤醒平时功耗极低。遥控器聚合家里的空调遥控器、电视遥控器用的都是红外ESP32自带红外发射功能。我把各个遥控器的红外码学习一遍存进Flash里手机端点一下就能发对应指令。客厅的ESP32节点就兼任了红外“万能遥控器”。远程OTA升级每一个ESP32节点都支持OTA。新功能上线时我会通过MQTT对设备端下发OTA触发指令设备端从HTTP服务器拉取固件并更新。没有OTA的智能家居就是一个大型翻车现场设备挨个拆下来刷固件根本不现实。完整拓扑大概是路由器 —— 树莓派(MQTT Broker Web服务) —— 若干ESP32节点(传感器/执行器) —— 手机App/浏览器(控制端)。所有节点之间通过WiFi数据交互首次配网走BLE平时靠MQTT保活。3. 核心模块实操硬件准备、BLE配网、WiFi双模式、Web内嵌3.1 硬件选型与接线清单硬件这块我踩过的坑比代码多得多。先把清单给你都是我测过稳定的设备/模块型号/规格用途备注主控ESP32-WROOM-32开发板或模组主控芯片建议买带屏蔽罩的温湿度DHT22采集温湿度比DHT11精度高注意上拉电阻光照BH1750采集光照强度I2C接口不要接错地址引脚人体感应HC-SR501 PIR传感器检测人体活动灵敏度与延时可通过电位器调门磁干簧管小磁铁门窗开关状态中断触发配合浅睡眠继电器一路或两路5V继电器模块控制灯具/插座注意隔离和电源别共用调光MOSFET模块或者PWM LED驱动器LED灯带调光功率大时要加散热红外红外接收管(TSOP4838)红外发射LED学习/发射红外码发射时电流要限流电源5V/2A电源适配器加AMS1117-3.3供电别用劣质电源无线稳定性跟电源纹波直接相关接线记住几个关键点DHT22数据引脚一般接GPIO4或GPIO5我统一规定传感器类接GPIO4继电器控制接GPIO16到GPIO21这一排原因是这些引脚比较稳定不容易在上电瞬间输出毛刺导致误动作。第二天你可能会问为什么不是所有引脚都能用。有几个坑GPIO0是烧录模式选择脚不能接对电平敏感的设备GPIO12是MTDI引脚接入上拉的传感器可能启动失败GPIO34到GPIO39只能做输入不能做输出。把这些规则记住能少烧好几块板子。3.2 一路走到尾BLE配网流程的完整设计配网是整个体系体验好坏的分水岭。拿手机连摄像头的方式去配网连上设备热点再输密码提交也不是不行但我试过之后果断放弃了。路由式配网要切换WiFi连接、设备要开AP热点、SSID和页面都对不上时排查体验非常差。BLE配网则直接把“找到设备”和“下发配置”合并成了一步。第一步ESP32上电后初始化BLE服务端注册一个自定义Service。我定义的UUID是这样规划#define SERVICE_UUID 6e400001-b5a3-f393-e0a9-e50e24dcca9e #define CHARACTERISTIC_UUID 6e400003-b5a3-f393-e0a9-e50e24dcca9e第二步这个Characteristic支持写属性。手机App扫描到设备后连接并写入一段JSON{ ssid: HomeWiFi, password: 12345678, mqtt_host: 192.168.1.100, mqtt_port: 1883 }第三步ESP32接收完这段数据先存入Flash的NVS区掉电不丢失然后立即重启重启后读取NVS里的配置尝试连接WiFi并建立MQTT连接。整个配网过程不到五秒体验上和商用智能家居的扫码配网几乎没差别。代码核心部分大概是这样的#include BLEDevice.h #include BLEUtils.h #include BLEServer.h #include Preferences.h Preferences prefs; class MyCallbacks : public BLECharacteristicCallbacks { void onWrite(BLECharacteristic *pCharacteristic) { std::string value pCharacteristic-getValue(); if (value.length() 0) { prefs.begin(wifi, false); prefs.putString(config, value.c_str()); prefs.end(); delay(200); ESP.restart(); } } };注意BLE写入MTU默认只有23字节一段JSON可能会被拆成多包。我实测iPhone和Android的行为还不完全一样Android可以协商MTU到185字节iOS有时会按默认走。为了避免切片导致的脏数据我建议在App端把JSON压缩到最小或者干脆分别用三个Characteristic写三项配置。这个方法更稳妥我最终采用的是三个Characteristic对应SSID、密码、MQTT服务器地址的写法。3.3 WiFi的STAAP双模式保证设备永远“找得到”设备配完网之后如果路由器重启或者WiFi密码改了设备会陷入离线状态。这时候你需要一个可靠的兜底机制。我用的是“STAAP共存”模式设备平时以STA模式连接家庭路由器但在连接失败或者断连超过一定时间之后自动开启一个名为“ESP32_Config_XXXX”的软AP热点。AP热点上跑着一个极简化的配网页——就一个表单填SSID、密码、服务器地址提交之后ESP32收到数据存NVS并重启。这样就算你人在房子里没有电脑、没有装App只要有手机打开WiFi列表连上这个热点在浏览器里输入192.168.4.1就能完成重新配网。我把这个软AP设计成“仅当STA处于未连接状态时才启用”一旦STA连上路由器就关闭AP避免两个接口同时吃发射功率导致干扰。STA模式的自动重连逻辑我也做了加强WiFi.setAutoReconnect(true); WiFi.persistent(true);实际跑下来这两个配置能解决大部分家用路由器偶发重启引起的断线问题。但路由器死机时ESP32也无法自己恢复——它毕竟只是终端不是网络设备。我更推荐在树莓派上写一个定时脚本每五分钟ping一次各设备IP连续三次不通就通过MQTT向设备下发一条重启指令。听起来粗暴但在智能家居这种场景里“能远程重启的设备才是好设备”。3.4 内嵌Web服务器每个ESP32都是一个迷你控制台我采用分层架构时并没有完全放弃让ESP32自己做Web服务器的方案。事实上单节点调试场景下ESP32内嵌的Web页面是最快的问题定位工具。我用的库是ESPAsyncWebServer异步模型ADS和CSS全部内嵌到Flash里页面加载快资源占用可控。我做的页面功能很简单但很实用显示实时温湿度、光照强度、设备在线状态三个开关按钮控制继电器/灯带一个WiFi配置框用于STA模式下动态调整目标服务器一个OTA固件上传进度条给设备端网页“加餐”时有一个地方要特别注意Web页面中用了比较密集的AJAX轮询去刷新数据会加重ESP32负担。一般两秒一次比较合适开了WiFi省电模式后可以放宽到三秒。整个Web服务器跑起来SRAM占用大概35KB在ESP32的520KB内存下完全没压力。4. 具体实现从开发环境到核心代码的全面解析4.1 开发环境怎么搭Arduino IDE还是ESP-IDF还是PlatformIO我先说结论家庭使用和快速开发选ArduinoIDE企业往量产走选ESP-IDF个人后期项目多了想管理依赖你可以试PlatformIO。我这次所有代码跑在Arduino IDE框架下。有人可能会吐槽ArduinoIDE太简陋它的优点其实被低估了——ESP32的Arduino核心包封装极其完善BLE、WiFi、MQTT、WebServer这些组件全是现成库加上Arduino的核心代码更新很快你不需要去啃ESP-IDF的组件系统。而且ArduinoIDE支持直接从菜单栏安装ESP32开发包我用的版本是2.x的Arduino IDE配合esp32核心2.0.9。如果你是离线环境记得手动下载板卡包国内用户建议配一个镜像源否则会卡死在下载那一步。ESP-IDF是乐鑫的官方开发框架性能上限更高、组件划分更精细但学习曲线明显陡峭。对纯DIY方案来说Arduino完全够用。反正底层是同一套协议栈Arduino核心本质上是ESP-IDF的封装真正跑起来差异不大。如果你后面要做商用产品建议迁移到ESP-IDF因为内存管理、功耗控制、加密模块这些精细配置在Arduino下憋屈得很。4.2 从零开始写BLE配网全流程代码我先把BLE配网部分的完整流程代码框架展示出来你直接参照这个改就行#include BLEDevice.h #include BLEUtils.h #include BLEServer.h #include Preferences.h #include WiFi.h #define SERVICE_UUID 6e400001-b5a3-f393-e0a9-e50e24dcca9e #define CHAR_SSID_UUID 6e400002-b5a3-f393-e0a9-e50e24dcca9e #define CHAR_PASS_UUID 6e400003-b5a3-f393-e0a9-e50e24dcca9e #define CHAR_SERVER_UUID 6e400004-b5a3-f393-e0a9-e50e24dcca9e Preferences prefs; String wifi_ssid ; String wifi_password ; String mqtt_server ; class ConfigCallbacks : public BLECharacteristicCallbacks { void onWrite(BLECharacteristic *pCharacteristic) { String value pCharacteristic-getValue().c_str(); if (pCharacteristic-getUUID().toString() CHAR_SSID_UUID) { wifi_ssid value; } else if (pCharacteristic-getUUID().toString() CHAR_PASS_UUID) { wifi_password value; } else if (pCharacteristic-getUUID().toString() CHAR_SERVER_UUID) { mqtt_server value; prefs.begin(cfg, false); prefs.putString(ssid, wifi_ssid); prefs.putString(pass, wifi_password); prefs.putString(server, mqtt_server); prefs.end(); ESP.restart(); } } }; void setupBLE() { BLEDevice::init(ESP32_Sensor_01); BLEServer *pServer BLEDevice::createServer(); BLEService *pService pServer-createService(SERVICE_UUID); // 创建三个Characteristic并绑定回调... }这里有两个细节经验。第一个是服务名。BLE广播名称“ESP32_Sensor_01”决定了手机App里显示成什么样建议按“设备类型_位置_编号”来命名比如ESP32_Light_Bedroom_01。第二个是设备状态回写的必要性。配网结束后设备端应该往App反向写一条“配网成功正在连接WiFi”让用户知道发生了什么。只看设备重启用户会以为卡死了。我加了三个Characteristic里的只读状态位分别表示“等待配网”“正在连接WiFi”“已连接”三个阶段。4.3 WiFi连接和数据上报MQTT是比HTTP更优雅的通道最初我用的是HTTP API——设备端定时POST JSON到树莓派的端点。后来发现两个问题一是HTTP轮询太浪费资源二是设备状态变化没法及时推送到控制端。MQTT以发布订阅模式解决了这两个痛点。设备端的发送逻辑很简单。传感器节点每60秒读取一次DHT22和BH1750把数据封装成JSON后发布到主题home/sensor/bedroom。执行器节点订阅home/devices/bedroom_light/set主题收到消息后解析JSON执行相应动作再把执行结果回发到home/devices/bedroom_light/state。#include PubSubClient.h #include WiFi.h WiFiClient espClient; PubSubClient mqttClient(espClient); void mqttCallback(char* topic, byte* payload, unsigned int length) { String message; for (unsigned int i 0; i length; i) { message (char)payload[i]; } // 解析JSON并执行控制逻辑 handleCommand(topic, message); } void publishSensorData() { StaticJsonDocument256 doc; doc[temp] temperature; doc[hum] humidity; doc[lux] lux; char buffer[256]; serializeJson(doc, buffer); mqttClient.publish(home/sensor/bedroom, buffer); }MQTT的QoS服务质量默认是0也就是发出去就不管了。指令控制类消息我使用QoS 1保证至少送达一次避免“按了开关却没反应”的诡异Bug。数据上报类保持QoS 0少一点网络开销丢了也无所谓反正下一分钟还会上报。4.4 OTA升级没有这个功能你一定会后悔前面说了OTA重要这里把实现要点讲透。我的每个ESP32节点都能通过HTTP拉取固件并更新。树莓派上跑了一个简单的Nginx目录下放编译好的.bin固件文件通过MQTT向目标设备下发OTA指令设备收到后跳转到OTA升级流程。核心逻辑#include Update.h #include HTTPClient.h void startOTA() { HTTPClient http; http.begin(http://192.168.1.100/firmware/esp32_sensor.bin); int httpCode http.GET(); if (httpCode HTTP_CODE_OK) { int contentLength http.getSize(); if (Update.begin(contentLength)) { Update.writeStream(http.getStream()); if (Update.end()) { ESP.restart(); } } } }OTA有几个坑必须说清楚第一OTA期间断电会变砖升级前一定要确保供电稳定插座要插紧不要边充电边搬动设备。第二ESP32的Flash分区必须是默认的“Huge APP”或者自定义的“OTA”分区模式否则无法使用OTA功能。第三每次编译固件时如果改了分区表会导致旧的OTA缓存失效。第四我记得最惨的一次是全家五台设备同时OTA路由器直接假死那之后我学乖了OTA策略改成“先更新一台等它上线并稳定24小时再批量更新其余设备”。5. 常见问题与调试实录5.1 WiFi断连、连不上、一直重连怎么办这是智能家居调试里最常遇到的问题。我的排查顺序和方法整理成表格给你现象可能原因排查方法STA连不上路由器密码错误、路由器2.4GHz被关闭、MAC地址被过滤先用手机热点测试设备逐步排查网络侧问题连接成功但频繁掉线电源纹波过大、同频干扰、路由器带机量不足换一个稳定的5V/2A电源调整ESP32发射功率从19.5dBm降到12dBm能连上但MQTT连接一直失败Broker IP错误、端口被防火墙拦截、用户名密码错误在代码里加MQTT连接失败重试日志检查树莓派防火墙规则同一区块设备集体离线路由器2.4GHz信道拥塞或AP重启在路由器管理后台把2.4GHz信道改为1、6或11中空闲的那个发射功率我多说一句。ESP32默认发射功率是19.5dBm全功率跑功耗高、热量大还会加剧对同频段蓝牙的干扰。实测家里小户型12dBm完全足够功耗和稳定性平衡最好而且发热明显下降。设置在WiFi.begin()之后调用WiFi.setTxPower(WIFI_POWER_12dBm)即可。5.2 BLE扫描不到设备、配网不成功的排查BLE配网的失败通常集中在三块第一块是广播名称和Service UUID不匹配。App过滤时一般同时匹配设备广播名称前缀和Service UUID两边不统一就看不到设备。调试时我用nRF Connect这个工具直连查看广播包一目了然。第二块是BLE连接建立后立刻断开。多半是两个设备之间的SPAM广播冲突也就是ESP32在握手过程中持续广播导致连接不稳。解决方式是在连接建立后把广播停下来等连接断开再恢复广播。BLE官方文档也是这么建议的。第三块是Characteristic写入的MTU值太小。前面已经提过给每个配置单独开Characteristic是绕过这个限制最省事的做法。如果一定要写一个大JSON就要在接收端做重组和校验还要自定义包序号开发成本大不划算。5.3 继电器误动作和GPIO毛刺问题这个坑新手最容易忽视。ESP32上电瞬间部分GPIO会输出一个短暂的高电平脉冲如果这个引脚刚好接的是继电器控制端就会出现“设备刚上电灯就闪了一下”的诡异现象。解决方法是控制继电器模块的信号脚不要直接接在GPIO上中间加一个下拉电阻10K到GND让引脚在默认状态下被强制拉到低电平。同时把代码里的引脚初始化和模块使能逻辑放到setup函数最前面尽量提前把引脚设置为输出低电平减少毛刺可以造成的影响窗口。继电器模块本身也要注意5V继电器线圈需要驱动电流较大如果用ESP32的3.3V去驱动最好选带光耦隔离的模块并且单独给继电器供电ESP32和继电器模块共用一个5V电源时线圈吸合产生的电流尖峰会导致WiFi断流。要么分开供电要么在5V进线处加一个大电容470uF以上缓冲。5.4 Flash写入寿命和数据保存策略智能家居设备会频繁保存状态比如灯的开合状态、温湿度阈值配置。如果直接写Flash不仅磨损快还有可能在写入过程中断电损坏配置。ESP32的NVS底层是Flash擦写寿命约10万次看似很多但如果你每秒写一次一天就是8万多次完全不设防用法不到两天就把Flash写废了。我的经验是把状态变化通过MQTT上报到树莓派记录本地存储的只有“最新服务器地址”“WiFi配置”这种极其低频的数据。那些“灯是开是关”的实时状态设备重新上电后不一定要恢复——我采用“可控恢复”的方式灯的状态变化后在内存里保存一份每半小时持久化一次到NVS。这样就算掉电最多丢失半小时内的状态变化Flash的写入频率也不会成为瓶颈。5.5 实测最顽固的一个BugMQTT长连接被路由器掐断有一次我发现设备运行几天后就会离线但WiFi连接还是正常的设备能Ping通路由器和树莓派却就是收不到MQTT消息。排查了很久最后定位为MQTT的Keep Alive机制和路由器的NAT超时踢除冲突。TCP长连接在路由器上会有NAT会话老化时间如果Broker和客户端之间长时间没有数据包路由器会悄悄清掉这条NAT映射但两端的TCP层并无感知于是连接就“僵尸化”了。解决办法是两件事同时做客户端MQTT的Keep Alive设为60秒并且在空闲时定时发送PINGREQ在树莓派的Mosquitto配置文件里把keepalive_interval参数放宽到1800秒避免Broker提前把客户端判定为超时。加了这两个改动之后设备在线时长从两三天提升到了四十多天再没出现过僵尸连接。6. 功耗、安全与从单设备到多设备的扩展方向6.1 把电池供电节点搞到能用三个月深度睡眠实战家居节点不全是有线供电的比如门窗磁传感器、人体感应传感器装箱子里塞电池也能用半年这就要靠ESP32的深度睡眠。ESP32在深度睡眠模式下可以做到10uA级别的电流这个数值在电池场景下非常可怕——一节18650电池约2000mAh理论上能撑二十年当然实际达不到因为要考虑唤醒周期和工作电流。实际测算下来门窗磁节点一节18650电池用九个月到一年没问题。深度睡眠的工程实现是这样的esp_sleep_enable_ext0_wakeup(GPIO_NUM_32, 0); // 低电平唤醒 esp_deep_sleep_start();GPIO32我接的是干簧管的一端另一端接3.3V。门磁分开时干簧管断开GPIO32为高电平。磁铁靠近闭合时干簧管接通GPIO32被拉到低电平产生下降沿事件ESP32被唤醒上报“门已关闭”并再次进入深度睡眠。几个节点靠这个机制每天早上看手机就能知道门窗状态功耗还控制得极低。普通传感器节点也可以做定时唤醒。esp_sleep_enable_timer_wakeup定时器设置一小时唤醒一次采集温湿度上报后继续睡比一直挂WiFi能省掉一大半功耗。注意深度睡眠期间WiFi是断开的所以唤醒后要重新初始化WiFi并连接MQTT这个连接过程要设计成容错性的连不上不代表故障下个周期重试就行。6.2 安全加固不能家里的门禁系统还是个裸奔的Web页面其他都调试跑通后如果你打算把这套方案用于真实家居甚至让室外也能访问控制页面的时候安全必须提到日程上。我强烈建议从第一天起就按下面的思路加固关闭所有不必要的开放端口。树莓派上只开放本地端口外网访问通过内网穿透的方式走加密隧道绝不把HTTP的1883端口或控制台8080端口直接映射到公网。MQTT开启用户名密码认证并且接入设备使用独立账号权限按主题范围隔离控制。Mosquitto的配置文件里可以针对每个用户名配置读写权限的最细粒度。OTA和Web服务启用TLS。ESP32支持BearSSL和mbedTLS可以加载PEM证书做HTTPS加密。在局域网内TLS开销不算大但能防止局域网内的其他设备偷窥通信内容。增加无线连接白名单。家用路由器都可以设置仅允许指定MAC地址的设备接入2.4GHz网络把ESP32节点的MAC都加入白名单能大幅压缩被恶意配网或劫持的风险面。6.3 从单设备到全面布设的组网建议最后聊聊扩展。我这套方案跑通后把客厅、卧室、厨房、阳台都布上了ESP32节点总数现在是十一台。但这十一台设备不是一上来就全部部署的我的经验是先做一台稳定一周再复制。单台设备的代码调通后批量节点之间只是改改GPIO映射、设备ID、传感器类型核心框架完全一致。如果你计划部署超过二十台ESP32WiFi网络会成为瓶颈。2.4GHz在多个信道上的干扰会显著影响稳定性。这时候有两个方向一是把设备按区域分配到不同信道的路由器和AP上避免竞抢一个信道。二是在核心区域部署ESP32做“边界路由器”利用ESP32自带的BLE功能做低功耗控制的近场分支减少所有节点都挤WiFi的情况。我还没把BLE Mesh推上位主要原因是ESP32的BLE Mesh开发复杂度较高而现有场景在二三十台设备规模下WiFi星型网络配合MQTT已经足够稳定。如果以后设备量突破五十台我会认真考虑引入蓝牙Mesh作为低功耗子网把光照传感器、门磁这类超低带宽节点从WiFi网络里解放出来。到时候整套方案的形态还会有一次大的变化。说回这两年维护这套系统的体会技术选型不是越新越好而是越匹配你对系统的掌控力越好。ESP32的WiFiBLE组合让我用一套硬件、一套代码同时解决配网、远程、低功耗三个维度的事对整个系统每一行代码、每一个模块都有主动权。居家智能家居最怕的不是动手能力不够而是整个系统变成了无法维护的黑箱。自己搭这套方案的收获远不止“能用手机控制灯”这件事当你把配网、状态上报、OTA、掉电恢复这一整条链路都盘顺之后你会发现后面再做任何IoT开发都会顺手很多。
