尧图精选

ESP32双模智能家居实战:WiFi+BLE配网与控制

🕒 发布时间:2026/10/2 1:10:16 📁 来源:尧图网络
家里十几个智能设备手机里却装着七八个App开关灯用一个、调空调用一个、看摄像头又得换一个。这种体验我相信折腾过智能家居的人都不陌生。ESP32这颗芯片火了好几年原因很简单它把WiFi和BLE两种无线协议集成了同一颗SoC上价格却压到了十几块钱。这意味着你可以用一片ESP32同时搞定“设备上网”和“手机近场控制”两件事——网关、传感器、执行器一肩挑不需要额外买昂贵的智能家居中枢。这篇博客我想把我实际搭建的一套基于ESP32的WiFiBLE双模智能家居方案完整梳理一遍从硬件选型、引脚规划、配网逻辑到固件实现再把踩过的坑和排查技巧都摊开讲清楚适合刚入手ESP32想做点实在东西的朋友也适合已经被各种协议折腾到想回归简单的老手。1. 方案架构与整体设计思路1.1 为什么选ESP32而不是ESP8266或树莓派既然要做智能家居选型首先得把账算清楚。ESP8266价格更低、生态成熟但它只有一个核、外设资源少WiFi和BLE不能同时工作——它压根就没有BLE。树莓派性能强跑个Home Assistant轻轻松松但一块树莓派Zero也要小两百还要配TF卡、电源、外壳功耗和体积放在智能家居设备里都偏大用它的场景更偏向做“中枢”而不是“终端节点”。ESP32的位置正好卡在中间双核240MHz的Xtensa处理器、520KB SRAM、4MB Flash起步的内存配置WiFi 802.11 b/g/n和BLE 4.2双协议栈共存。最关键的是一颗ESP32模块我用的是经典的ESP32-WROOM-32D十几块钱既能当终端设备也能跑简单的TCP服务器或者MQTT客户端。实测下来一片ESP32做一盏灯的控制板再挂两三个温湿度传感器负载非常轻松Core 0跑WiFi协议栈Core 1跑应用逻辑互不干扰。还有一个容易被忽略的选型理由ESP32的ADC、I2C、SPI、UART、PWM、触摸传感器这些外设都是现成的。智能家居里最常见的传感器DHT11/20、DS18B20、BH1750、PIR人体红外和最常见的执行器继电器、LED灯带、舵机、蜂鸣器全部可以直接挂在ESP32上不需要额外的单片机做信号预处理BOM成本可以压缩得很薄。1.2 双模协同WiFi负责广域BLE负责近场很多人刚接触ESP32时有个误区觉得既然有WiFi了为什么还要加BLE这不是多此一举而是两套协议在智能家居场景里分工天然不同。WiFi的优势是带宽大、能上互联网缺点我也踩过配网流程反人类、休眠功耗偏高。一个新设备买回家第一步就要在手机App里找WiFi、输密码如果路由器开了隐藏SSID或者5GHz/2.4GHz频段隔离常会卡在配网半路上。BLE则完全不同手机靠近设备就能广播用户不用知道家里WiFi密码是什么就能先把设备激活。我的方案里把二者的角色定为BLE承担“首次配网、近距离调试、低功耗唤醒通道”WiFi承担“日常通信、云平台对接、局域网内互相控制”。开机后ESP32先启动BLE广播用户在手机小程序里扫描到设备、填入WiFi凭据ESP32拿到SSID和密码后连接路由器连接成功后再把BLE广播关掉进入纯WiFi工作模式。实际上WiFi和BLE在ESP32内部共用2.4GHz射频前端硬件上不可能真正同时收发但乐鑫的共存机制Coexistence做得相当成熟两者以时分方式切换实测局域网内WiFi链路延迟掉到20ms以内BLE的连接事件也能稳定维持。所以这个“各司其职”的设计在工程上是完全可行的而且比用两颗芯片简单得多。1.3 从功能模块拆解整体架构我最终搭建的方案分为四层第一层是传感器和执行器层包括DHT20温湿度模块、BH1750光照模块、PIR人体感应、一个两路继电器模块。这些外设挂在ESP32的GPIO上属于底层的“手脚”。第二层是ESP32主控层负责采集传感器数据、执行控制逻辑、维护连接状态。设备固件里跑了一个轻量级任务调度器——其实就是FreeRTOS自带的任务机制把不同的功能拆成独立任务避免某个传感器I2C读取卡住时拖垮整个控制链路。第三层是无线接入层包含两个接口BLE GATT服务用于近场配置和控制WiFi TCP/HTTP接口用于局域网内访问同时通过MQTT协议向本地的EMQX Broker上报状态。这样手机不在同一个局域网时也能通过公网Broker中转拿到设备状态。第四层是交互层我写了一个内嵌在ESP32 Flash里的Web页面所有静态资源用ESPAsyncWebServer提供浏览器打开设备IP就能看到仪表盘实时温湿度曲线和开关控制都在里面。用BLE做配网、Web页面做可视化、MQTT做远端下发这套组合基本覆盖了一个简单智能家居节点从“激活”到“日常使用”的全链路。2. 硬件设计与引脚规划细节2.1 开发板选型与引脚避坑市面上的ESP32开发板五花八门但核心就两类一类是带USB转串口芯片的通用开发板比如经典的30引脚DevKitC另一类是面向产品化的裸模块。做智能家居原型验证我建议直接选DevKitC形态的板子带稳压电路、一键下载按键、MicroUSB口插上电脑就能用Arduino IDE烧录省去自己焊下载电路的时间。但是引脚规划这里我有几条很实在的经验都是拿时间换出来的。ESP32的GPIO不是每个都能随便用的比如GPIO6到GPIO11连接着板载Flash正常运行时绝对别接外设。GPIO12是MTDI引脚上电时如果被拉高会导致芯片进不了下载模式所以这个脚我宁可空着。GPIO16和GPIO17调试时经常用但它们在模块内部接了PSRAM的话也不可用具体看模块型号。我自己画引脚分配表时会专门留一张文档记录每个引脚的用途防止改接线时忘掉之前的定义。还有一个经常翻车的地方是GPIO34到GPIO39是纯输入引脚没有内部上拉也不能输出PWM。如果某些教程让你把PIR传感器接到GPIO34那没问题但千万别拿它去驱动继电器。我实际项目中把PIR接在GPIO34上读取数字信号完全正常想输出电平控制蜂鸣器就换到了GPIO25。2.2 供电方案与外设连接智能家居设备通常直接使用USB 5V供电或者墙壁电源里的5V/3.3V但接传感器时有个容易被忽略的点ESP32开发板上的3.3V稳压器一般只有几百毫安的输出能力如果同时给WiFi模块、DHT20、OLED屏幕、PIR供电3.3V轨会在WiFi发包瞬间瞬间跌落轻则传感器读数跳变重则直接重启。我的做法是分轨供电USB的5V直接送给继电器模块继电器线圈额定5V3.3V轨只负责ESP32、传感器和逻辑电平部分。WiFi发射时板的瞬态电流能冲到300mA以上所以我尽量选用输出电流足够的LDO或者直接依赖开发板自带的稳压器外设电流太大时单独用AMS1117-3.3再从5V取一路。实测下来同一路3.3V带ESP32两个I2C传感器是稳的如果再加上WS2812灯带这种吃电流的外设就单独接5V并把数据线串一个330欧电阻。接线方面还有几个细节I2C总线上拉电阻必须有但ESP32内部已经有了部分上拉外部再并联4.7k电阻也可以如果传感器模块已经有上拉则可以不加。DHT20这类I2C设备地址如果冲突跳线帽可以改地址但多个同一型号传感器并存时更省事的办法是直接用GPIO模拟I2C接到不同的引脚或者换用单总线的DS18B20。这里没有绝对标准核心是提前设计好地址分配别等焊完线才发现冲突。2.3 继电器、传感器与指示灯接线实战我的执行端用了两路5V继电器模块低电平触发。这里有一个一定要警惕的点继电器模块的逻辑触发端不要直接接3.3V的GPIO就完事很多模块上的光耦端其实是可以用3.3V驱动的但如果你买的模块没有光耦隔离继电器线圈工作时会有反向电动势可能会干扰ESP32甚至把GPIO打坏。我都是买带光耦隔离的模块同时在继电器线圈两端反向并联一个1N4007二极管虽然模块上可能已经有了但自己加一颗不亏。传感器接线上我把DHT20I2C接口挂到GPIO21SDA和GPIO22SCLBH1750同样挂在这条I2C总线上地址一个0x38一个0x23互不冲突。PIR人体传感器输出接GPIO34采用脉冲模式检测到人体时输出3.3V高电平我配合一个100ms的软件消抖在固件里做过滤。指示灯用一个板载LED接GPIO2逻辑和烧录时都会闪烁方便肉眼判断状态。给出一份我实际使用的接线表方便直接抄作业外设信号引脚ESP32 GPIO说明DHT20SDA / SCLGPIO21 / GPIO22I2C接口地址0x38BH1750SDA / SCLGPIO21 / GPIO22同一条I2C总线地址0x23PIR人体感应OUTGPIO34仅输入高电平触发继电器1IN1GPIO25低电平触发控制客厅灯继电器2IN2GPIO26低电平触发控制风扇板载LEDLEDGPIO2状态指示全程可用烧录模式EN/IO0板载按键需按住IO0再复位3. 软件开发流程与核心实现3.1 开发环境搭建和国内源加速写固件时我用的Arduino IDE加espressif的ESP32开发板包。这里有个很影响体验的坑在Arduino IDE的“开发板管理器”里搜索ESP32时默认源在国外下载速度和成功率都不稳定。解决方法是给Arduino IDE配置国内的高校镜像源在“文件-首选项-附加开发板管理器网址”里填上镜像地址比如清华的tuna镜像对应的json链接然后重启IDE再安装。我这边实测镜像源的下载速度能快几倍而且不容易中途断掉。如果不用Arduino IDEPlatformIO也是一个稳定选择。PlatformIO通过platformio.ini文件指定board为esp32dev用framework-arduinoespressif32作为框架依赖管理比Arduino IDE清晰得多。我的项目一开始用Arduino IDE方便快速验证后面代码多了、要同时维护开发和生产两套配置时切成PlatformIO版本管理更干净。这里强烈建议把ESP32开发板包版本固定住不要每次遇到问题就“最新版”。我遇到过几次乐鑫更新核心库后某些依赖的第三方库API变化导致编译失败的情况。具体版本号可以在开发板管理器里看到锁定在自己验证过的一个稳定版本上项目能跑就尽量别动工具链。3.2 固件整体代码结构与任务划分项目代码基于FreeRTOS任务划分主程序里面创建了三个任务void setup() { Serial.begin(115200); WiFi.mode(WIFI_AP_STA); // 启动蓝牙配网 startBLESetup(); // 启动本地Web服务器 startWebServer(); // 启动传感器轮询任务 xTaskCreatePinnedToCore(sensorTask, sensorTask, 4096, NULL, 1, sensorTaskHandle, 1); xTaskCreatePinnedToCore(controlTask, controlTask, 4096, NULL, 1, controlTaskHandle, 1); }WiFi在连接成功前工作在AP_STA模式这样用户既可以扫描到设备热点也能通过BLE收到配网信息。连接路由器成功后我再把WiFi模式切换为STA此时BLE配网服务会关掉广播避免一直开着浪费功耗。这里有一个重要的细节BLE和WiFi任务都涉及射频不能同时在两个核上跑而蓝牙协议栈的Host层跑在Core 0的控制器里。所以我把蓝牙相关操作全部放在Core 0上业务逻辑放在Core 1避免优先级反转和硬件中断互相踩踏。传感器任务用了一个状态机每2秒读一次DHT20和BH1750。读取I2C传感器时要考虑首次上电或传感器异常时返回的脏数据我的处理方式是连续三次读取失败才判定为故障单次失败时使用上一次的缓存值这样不会因为某次总线忙就误报高温。3.3 BLE配网服务的GATT设计BLE配网是整个方案里比较核心的环节。我在ESP32上初始化一个BLE服务UUID用的自定义值也可以直接在乐鑫示例代码基础上改服务里定义了两个characteristic一个用来接收手机发来的WiFi SSID和密码另一个用来通知手机配网结果。手机端我用微信小程序作为配网工具实现起来不难小程序里通过wx.openBluetoothAdapter初始化蓝牙扫描外围设备时只过滤掉设备名含有“ESP32”前缀的设备匹配后连接并监听对应characteristic的通知。配网流程我把SSID和密码按JSON字符串直接塞进一个characteristic里写入比如“{“ssid”:“myhome”,“passwd”:“12345678”}”ESP32收到后解包调用WiFi.begin然后在另一个characteristic里异步通知手机“connected”或“failed”。用BLE配网的好处在于整个过程不需要用户进入手机系统设置去连热点小程序内一步到位。而且BLE的通信距离足够近场使用不存在WiFi热点配网时“连上了热点却上不了网”的尴尬。我推荐在固件里给配网加一个超时机制如果60秒内没有收到有效配网信息ESP32自动恢复BLE广播并重新等待避免设备卡在半配网状态。收到配网信息但WiFi连接失败时也要复位BLE让用户可以重新尝试。这个逻辑看似简单却是实际使用中体验差异最大的地方很多配网的失败都是死在“一次失败就不知道怎么恢复”上。3.4 WiFi连接与本地Web控制页面WiFi连接成功后Web服务器开始工作。我用的ESPAsyncWebServer库它基于异步TCP不会阻塞主循环配合SPIFFS或LittleFS存放Web静态资源。Web页面里有设备状态卡片、温湿度曲线、继电器开关按钮。前端通过fetch接口轮询后端返回的JSON比如GET /api/status会返回如下数据{ temp: 26.5, humidity: 58.2, light: 430, relay1: 0, relay2: 1, rssi: -51 }原来我考虑用WebSocket实现实时推送后来发现局域网内HTTP轮询完全够用500ms拉一次JSON对ESP32压力也不大而且省去了维护WebSocket连接状态的复杂性。只有需要低延迟控制的时候比如灯光亮度调节滑条我发现HTTP请求的延迟也能稳定在20ms以内WebSocket不是必需品。这里也有一个安全层面的经验局域网Web页面如果暴露到公网务必加一层简单认证。我在ESPAsyncWebServer里实现了一个简单的HTTP Basic认证用户名和密码硬编码在固件里平时不开放公网映射。做智能家居控制页面最简单的原则就是能局域网控制就别公开到公网除非你做好了完整的身份认证和流量审计。3.5 OTA升级与配置持久化智能家居设备最大的特点是要长期运行早期固件的bug不可能一次性休完所以OTA在线升级是我在上线前就考虑进去的。ESP32支持通过HTTP下载bin文件升级我实现了一个简单的升级页面在Web服务器上添加一个/update接口上传编译好的固件bin文件调用Update API开始写Flash写完后自动重启。OTA升级对应的分区表必须在编译时调整默认的Arduino分区表通常只有1.3MB左右的APP空间而带OTA的分区表要同时容纳app0和app1两个固件槽。我在menuconfig里选择“Huge APP (3MB No OTA/1MB SPIFFS)”还是“16M Flash (3MB APP/9MB FS)”这类方案时要根据自己实际Flash大小选。我用的是4MB Flash的模组就给每个OTA槽分1.5MB左右再留一点LittleFS空间存Web页面。配置持久化我用Preferences库把WiFi SSID、密码、设备名称这些东西存到NVS分区。配网成功后立即写入NVS下次开机直接读取并尝试连接如果没有有效配置才启动BLE配网。这一点对智能家居很重要设备停电重启后不能每次都重新配网不然家里老人根本用不了。4. 实操实录从烧录到联网的全过程4.1 第一次烧录固件的正确姿势买回开发板后先把CP2102或CH340的驱动装上这两个是最常见的USB转串口芯片。然后打开Arduino IDE选择开发板为“ESP32 Dev Module”烧录速度我一般选921600bps但第一次用USB线连接可能不稳定我建议先用115200bps把代码烧进去之后再提速。ESP32进入下载模式有两个办法一是按住BOOT按键点下载后再松开二是上传代码时如果IDE自动控制不了复位时序手动按住BOOT能保证进入下载模式。实测DevKitC板载的自动下载电路大多数时候没问题但如果选错了开发板类型或串口占用后却下载失败就手动按BOOT这个辅助操作能解决八成下载失败。接线全部接好之后第一次上电最好先用一个简单的Blink程序验证板子没问题再烧录完整的智能家居固件。我第一次就把传感器和继电器全部接好再烧固件结果某个GPIO的高电平异常导致一直不断重启最后挨个拔外设才定位到问题这个弯路很浪费时间。正确流程是先烧最小系统、确认能跑再加外设调逻辑。4.2 配网实测过程与日志解读配网阶段我打开手机微信小程序扫描到名为“ESP32-HomeKit”的设备。这个设备名是在固件里通过bleAdvertising.setName配置的方便识别多个设备。点击连接填入我家的WiFi名称和密码小程序提示发送成功随后ESP32的串口打印出连接日志I (48241) wifi:new phy init I (48311) wifi:mode : sta (xx:xx:xx:xx:xx:xx) I (48882) wifi:connection established... I (48912) wifi:ip address: 192.168.1.134看到ip address出现说明WiFi已经连接成功。这时再用浏览器访问http://192.168.1.134就能打开内置的Web控制面板。这些日志是通过USB串口看到的。实际设备部署之后没有电脑可看我把关键状态又通过BLE上报了一份手机小程序在设备连接后也能读取到当时的IP地址和WiFi信号强度这个设计在排查设备离线问题时特别管用——设备没联网时用户还能通过BLE近场查看它的状态。4.3 多设备联动的场景实现单设备能联网控制只是第一步智能家居最关键的是联动。我在这套方案里做了几个典型自动化场景全部在ESP32本地固件里实现不依赖云端场景一是“人来灯亮”PIR传感器检测到高电平如果当前光照强度低于200lx傍晚或阴天自动开继电器1持续两分半钟没有再次检测到人自动关灯。这里的逻辑很简单但有一个容易忽略的点继电器频繁开关会影响寿命所以我在固件里做了最小切换间隔无论PIR怎么抖动同一分钟内只允许一次开关动作。场景二是“联动报警”当温度超过28℃且湿度超过75%时继电器2自动开启风扇等温度降到26℃以下再关中间有1℃的滞回区间防止风扇在临界点附近反复启停。场景三是“远程开关”通过MQTT订阅一个主题比如home/bedroom/relay1/set云端或者手机App下发0或1来控制继电器。同时设备订阅了自己状态的反馈主题通过发布home/bedroom/relay1/state让其他系统实时感知。这些自动化规则我存放在JSON配置里在Web页面上可以调整阈值用户体验比直接改固件好很多。固件内部用一个配置管理器把用户修改的参数保存在NVS中重启后不会丢。4.4 内嵌Web页面的前端实现要点Web控制页面的代码不多但有几个细节值得分享。首先页面全部静态文件放在LittleFS里文件系统镜像需要先用Arduino IDE的ESP32 Sketch Data Upload插件烧录否则Web服务器找不到HTML文件访问IP会404。前端代码我用的原生HTMLJavaScript没有引第三方框架因为引了jQuery、Vue这类库后文件体积很容易超过LittleFS的容量限制。用原生fetch轮询数据、用CSS做一个简陋但清晰的仪表盘完全够用。字符串拼JSON时注意转义问题避免把界面搞崩。页面里的图表我用的是Canvas绘图没有用ECharts因为这个库体积太大。自己在Canvas上画一个简单的温湿度折线图并不难还能直观显示最近两小时的变化趋势。实际上手写Canvas也就一百行左右的代码比为了一个折线图塞进一个几百KB的库要划算得多。5. 排查技巧与常见问题实录5.1 下载不了固件的常规排查顺序将ESP32插上电脑但Arduino IDE提示“A fatal error occurred: Failed to connect to ESP32”这是最常见的报错。我遇到这个问题时首先检查串口号是不是被其他程序占用打开设备管理器看驱动是否正常然后换USB线。这里有个很坑的点普通手机充电线可能只有电源线没有数据线看起来插上了实际上串口根本没枚举。如果驱动正常且串口可见按住BOOT键不放再点上传上传开始后再松手这是最保险的进下载模式方法。如果还不行就检查GPIO0是否被外设拉低了——我第一次接继电器模块时用了一个把GPIO0拉低的外设导致芯片永远进不了运行模式。开发阶段尽量别在GPIO0上接任何东西它是标准的下载控制脚保持悬空最好。5.2 传感器读数异常与I2C总线故障DHT20或者BH1750读数飘忽甚至返回65535或NaN多半是I2C总线问题。检查接线时SDA和SCL是否接反是一个高频错误。再加上ESP32的I2C引脚不是固定的如果你在用Wire.begin(21,22)之后又在外部拉了别的引脚做Wire那么通信会异常。另一个常见问题是总线上有设备地址冲突。BH1750的地址可以通过ADDR引脚拉高或拉低切换DHT20如果和别的I2C设备预留地址重复就改地址跳线。我的排查方法是写一个I2C扫描程序枚举总线上所有应答的设备地址5分钟内定位问题#include Wire.h void setup() { Serial.begin(115200); Wire.begin(21, 22); Serial.println(I2C Scanner); } void loop() { for (byte addr 1; addr 127; addr) { Wire.beginTransmission(addr); if (Wire.endTransmission() 0) { Serial.print(Found I2C device at 0x); Serial.println(addr, HEX); } } delay(3000); }如果你发现扫描不到任何设备先查上拉电阻。ESP32虽然有内部上拉但某些第三方的传感器模块自带下拉或者用了过长的跳线造成信号畸变。稳妥的做法是外接两个4.7k欧电阻到3.3V这是I2C总线的标准做法。5.3 WiFi频繁掉线或延迟飙高的成因ESP32连WiFi后掉线常见原因按优先级排查首先是电源问题。WiFi发射瞬间电流大如果你的电源适配器质量差或者USB线太长电压跌落会导致ESP32射频部分异常表现为信号弱或者掉线重连。我遇到过用劣质USB线时测电压只有4.4VWiFi发送数据时电压降到4.0V以下设备频繁重启。换一根粗短线就好。其次是路由器设置了5GHz优先或者频段漫游。ESP32只支持2.4GHz路由器如果开启“双频合一”手机可能已经跑到5GHz了ESP32还在2.4GHz挣扎看起来信号满格但延迟很高。解决方法是把智能家居设备的2.4GHz SSID独立出来关闭AP隔离、关闭WiFi节能模式减少无谓的漫游扫描。最后是WiFi与BLE的共存问题。如果设备在启用BLE广播的同时WiFi也不能断比如我为了保留手机近场调试能力没有彻底停掉BLE实测会发现WiFi丢包率上升。乐鑫官方建议非必要不要同时保持高强度BLE连接和WiFi吞吐我的方案是在配网完成、进入日常工作模式后把BLE的广播间隔拉长甚至完全关闭广播只保留可被主动扫描发现的能力。这样既降低了干扰也减少了功耗。5.4 继电器误触发与GPIO状态抖动的处理GPIO在复位期间会出现短暂的高阻态或电平浮动如果继电器是低电平触发而GPIO默认在复位时被外部电路拉低设备一上电继电器就会闪断一次。很多人以为继电器闪断是固件bug其实很可能是硬件电平在MCU启动完成前的“预触发”。我的处理方式有两层在继电器模块的触发输入引脚上并一个10k下拉电阻让未定义状态期间默认是高电平不触发固件启动后先初始化GPIO为高阻输入再配置为输出并立即输出高电平再接逻辑。另外继电器模块如果是低电平触发代码里一定要把默认状态设为HIGH而不是LOW否则一上电就直接吸合。我还遇到过继电器吸合瞬间导致ESP32重启的问题。原因是继电器线圈断电时反电动势干扰了电源。解决方法是继电器使用独立5V电源同时靠近继电器电源引脚加一个100uF电解电容和0.1uF陶瓷电容吸收尖峰。这个电容组合便宜、效果好做硬件时就别省这几毛钱。6. 更多落地经验和后续扩展方向6.1 功耗优化与电池供电可能性其实我的这套方案一直用USB电源因为家里不缺插座。但一旦想做成无线传感器节点、或者放到没有插座的角落功耗就成为必须面对的问题。ESP32光是WiFi连上路由器后的平均电流就有80mA左右如果一直开着18650电池也只能撑一两天。所以做低功耗节点时的思路是平时用深度睡眠Deep Sleep把电流压到10uA级别定时醒来采集一次传感器数据通过WiFi上报后马上再睡。BLE在这里也能帮上忙在深度睡眠期间保留一个极低功耗的唤醒源比如外部GPIO触发的EXT0唤醒或者定时器唤醒。PIR检测到人时立刻唤醒ESP32再连WiFi上报这样既保证了响应速度又不像WIFI常驻那样耗电。对智能家居里的门磁、人体感应这类节点来说一节18650撑半年到一年是可以实现的。6.2 多设备管理与本地化控制的组织方式家里不可能只有一个ESP32。多个设备各自连同一个路由器它们之间如何互相发现、如何统一管理我也有一些实际做法。虽然地址也可以通过Web页面的设备列表填写但更工程化的办法是让每个设备启动时向局域网广播自己的信息用UDP组播其他设备或者主控节点监听后自动维护一张设备表。这样不需要人工记住每个IP。设备与设备之间的联动我目前用的是MQTT在本地Broker中转没有走云端。这个选择的理由是本地Broker响应快、断网时本地自动化依然可以运转而且隐私更好。你可以把ESP32当作一个MQTT客户端订阅其他节点的状态主题再结合规则做联动。和云平台方案比多了一次搭建Broker的成本但换回来的是稳定性和可控性家用数量不多时这个搭设成本可以接受。6.3 和我踩过的那些坑说再见最后聊几个散碎但对体验影响很大的点。第一个是串口波特率ESP32默认的log波特率是115200如果你改了monitor_speed却没改代码里的Serial.begin终端会乱码。调试时我习惯统一成115200很好记。第二个是Flash分区表的坑如果编译时内存或者文件系统空间不够报错PSTR not in RAM这种看不懂的信息先检查分区表。很多人喜欢把分区表改成最大APP大小结果LittleFS的空间就没了Web页面资源烧不进去。分区表的选择一定要符合实际需求有OTA就选OTA分区有文件系统就留文件系统。第三个是LED指示灯的控制逻辑我在GPIO2上接了状态灯但GPIO2是板载Flash的SPI-CLK引脚之一实际连接了Flash在启动阶段会有特殊电平变化导致它接的LED会闪两下。不要把这当成故障如果你在GPIO2上接了其他负载需要确认它不会影响启动。第四个是配置持久化的粒度不要每次保存配置都往NVS里写一堆键值NVS有擦写寿命限制。我采取的方式是只有配网成功或用户主动点“保存设置”时才调用Preferences的end和put操作运行时参数全部放内存里这样可以把NVS擦写频率降到极低。6.4 这套方案的下一步演变从“单设备控制”往“全屋场景”走我有几个已经验证过可行的扩展方向。如果你手头的ESP32节点多了可以考虑写一个Android或者iOS的小App而不是每次都开浏览器输IP。其实控制端用WebView套壳把Web页面包进去就能省掉一次原生开发的功夫。另一个方向是把ESP32接入Apple HomeKit或者米家生态这一步需要借助Home Assistant或者自定义的HomeKit Accessory Protocol实现复杂度比现在这套方案高不少但做出来后用户可以用系统自带的家庭App直接控制这些DIY设备交互体验会上一个大台阶。乐鑫官方已经提供了ESP-HomeKit SDK的参考实现我之前评估过可行但投入时间不少适合作为进阶项目。再一个是把传感器数据周期性推送到一个轻量级时序数据库比如InfluxDB配Grafana做可视化面板。ESP32本身存储和算力都不适合做数据历史但上报给服务器后全屋的温湿度、用电量变化都可以变成分析图表后续还能结合简单的算法做异常检测。我目前已经把自己的温度数据接入到了本地InfluxDB跑了两周曲线非常稳定这套数据链路非常适合当作智能家居数据体系的地基。我个人在实际使用中最大的体会是ESP32这套WiFiBLE双模方案并不是单纯省了一颗蓝牙芯片的钱而是给设备的交互方式留出了极大的灵活性。配网靠BLE、控制靠WiFi、排查靠BLE近场调试三种场景各取所长整个系统的易用性比纯WiFi方案高出一个档次。如果你也想从零搭一套属于自己的智能家居节点别急着堆功能先把一块ESP32、一个继电器、一个温湿度传感器玩明白把配网、控制、上报这条链路走通然后再慢慢往里边加场景、加联动。这才是最稳、也最有成就感的一条路。
上一篇/下一篇内容由系统自动关联 返回资讯列表 →