企业官网建设流程全解析

1. 项目概述：为什么ESP32是智能家居落地的“黄金交叉点”

你有没有遇到过这样的情况：想给家里的灯加个手机远程开关，结果发现WiFi模块要单独买、蓝牙模块又要另配、还得搭个MCU来协调——光是接线就绕晕了；或者用树莓派做中枢，功能是强，但功耗高、发热大、一插电就嗡嗡响，放抽屉里都怕它自燃。而市面上那些成品智能插座，要么贵得离谱，要么绑定死某个App，换个手机系统连配网都卡半天。这些问题背后，其实缺的不是技术，而是一个真正能“一芯多能、开箱即用、不折腾”的硬件支点。

这个支点，就是ESP32。它不是什么新概念芯片，但却是过去五年里，在真实家庭场景中被反复验证、踩坑、再优化出来的“最稳解”。我从2019年开始用ESP32做温控器原型，到2022年带团队落地整套公寓级灯光+窗帘+环境监测系统，再到去年帮三个老客户把旧房改造成无感联动的智能空间——所有项目里，ESP32都是唯一没换过的主控。它不是性能最强的，但它是在成本、功耗、协议支持、开发成熟度、社区资源这五条线交汇处，唯一一个不明显拖后腿的选手。

标题里说的“WiFi+BLE一站式”，绝不是营销话术。WiFi负责和路由器握手、上云、接App、传大流量数据（比如摄像头预览帧）；BLE则专攻低功耗、短距、快速响应的本地交互——比如门锁指纹识别后的0.3秒内开锁、手环靠近自动亮灯、甚至用iPhone快捷指令直接读取温湿度而不唤醒整个网络。这两套协议在ESP32内部是物理共存、软件隔离、时序协同的。它不像STM32那样得外挂ESP8266+HC-05双模模块，也不像树莓派那样靠USB转接BLE适配器——所有通信链路都在同一块芯片上跑，引脚复用清晰，中断优先级可配，固件升级一次搞定。更关键的是，乐鑫官方的ESP-IDF框架对WiFi/BLE双模并发做了深度优化，实测在AP+STA共存模式下，BLE广播包丢包率稳定在0.7%以内（室温25℃，无金属遮挡），远优于同类方案。

所以这个项目，本质上不是教你“怎么点亮一个LED”，而是带你构建一套可量产、可维护、可扩展的真实家居子系统骨架。它不依赖云服务（可纯局域网运行），不强制绑定App（支持标准HTTP/MQTT/Apple HomeKit协议），所有代码开源可审计，所有硬件BOM表控制在35元以内（含PCB、外壳、电源）。接下来的内容，我会像带新人进车间一样，从选型依据、电路设计、固件分层、协议桥接、到真机调试，一层层拆给你看。你不需要是嵌入式专家，但得愿意拧螺丝、看示波器、查datasheet——因为真正的智能家居，从来不在App图标里，而在你焊锡烟飘起的那一刻。

2. 硬件架构与电路设计：为什么不能直接用开发板

很多人拿到项目标题第一反应是：“买块ESP32-WROOM-32开发板，接个继电器，烧个AT固件，完事。”——这确实能跑通Demo，但放到真实家庭环境里，三个月后大概率会出问题：继电器触点氧化导致灯闪、WiFi断连后无法自恢复、BLE广播被邻居路由器干扰、甚至夏天高温下芯片降频失联。这些不是玄学，全是电路设计层面的硬伤。下面这张表，是我对比了17个商用方案后总结的“家庭级ESP32硬件四要素”：

重点说说电源部分。很多教程教大家用AMS1117，因为它便宜、易焊、资料多。但没人告诉你：当输入电压为12V（常见于灯具供电），输出3.3V/500mA时，它的功耗是(12-3.3)×0.5=4.35W——相当于在指甲盖大小的芯片上贴了个小暖宝宝。我实测过，这种工况下AMS1117表面温度可达110℃，不仅加速电解电容老化，还会让ESP32的ADC参考电压漂移，导致温湿度读数偏差±2℃。换成MP1584EN后，同样负载下温升仅12℃，效率提升至88%，且自带EN脚可由MCU控制电源启停，实现“零功耗待机”。

再看天线设计。开发板的PCB天线在自由空间测试没问题，但一旦装进金属底盒或靠近水管，信号直接打骨折。我的做法是：PCB上预留IPEX座，天线走线严格按50Ω阻抗控制（线宽0.3mm，介质厚度0.2mm，介电常数4.2），并在天线馈点后加π型匹配网络（两个1pF电容+一个3.3nH电感）。这样即使外壳是铝合金，实测信号衰减也能控制在3dB以内。有客户曾反馈“客厅灯控响应慢”，最后发现是天线被藏在金属灯罩里——换了外置天线后，从点击App到灯亮的时间从1.8秒压缩到0.23秒。

提示：不要迷信“免调试”方案。我见过太多项目因省掉RC吸收回路，导致继电器触点烧蚀后产生电弧干扰MCU，最终表现为随机重启。每次焊接ULN2003A时，务必在继电器线圈两端并联1N4007二极管（阴极接VCC），并在二极管旁串一个100Ω电阻——这是用万用表量过137块故障板后总结的铁律。

3. 固件架构与协议栈配置：如何让WiFi和BLE真正“协同”而非“打架”

ESP32的WiFi和BLE在物理层共享2.4GHz射频频段，就像两条车流共用一条高速公路。如果调度不当，就会出现“BLE广播包被WiFi信标帧撞飞”、“WiFi上传大文件时BLE连接断开”这类经典问题。很多开发者以为调高BLE连接间隔就能解决，结果只是把问题从“频繁断连”变成“响应迟钝”。真正的解法，在于理解乐鑫SDK的底层调度机制，并做针对性干预。

3.1 双模并发的底层逻辑

ESP32的射频控制器（RF Controller）采用时间片轮询（Time-Slicing）方式分配信道使用权。默认配置下，WiFi占用约70%时间片，BLE占30%。这个比例看似合理，但在智能家居场景中完全反直觉：WiFi大部分时间在“守株待兔”（等待路由器Beacon），真正传输数据是突发性的；而BLE需要持续广播（Advertising）、维持连接（Connection）、响应特征值读写（GATT），对实时性要求极高。因此，我将时间片重配为WiFi:BLE = 40:60，并启用“BLE优先抢占”模式（esp_ble_mesh_set_tx_power(ESP_BLE_PWR_TYPE_DEFAULT, ESP_PWR_LVL_P9)）。

具体操作在menuconfig中设置：

Component config ---> Bluetooth ---> Bluedroid Options ---> [*] Enable BLE [*] Enable Bluetooth Low Energy Mesh [*] Enable BLE power control WiFi ---> [*] Enable WiFi [*] Enable WiFi AP mode [*] Enable WiFi STA mode [*] Enable WiFi coexistence with BLE (60) BLE time slice percentage [*] Enable BLE priority preemption

这个配置改变后，BLE广播间隔从默认100ms稳定在95±2ms，连接建立时间从平均1200ms缩短至380ms。更重要的是，当WiFi正在上传固件（OTA）时，BLE仍能保持心跳包不丢——这是实现“手机靠近自动解锁门锁”的基础。

3.2 MQTT over WiFi + BLE GATT的混合协议栈

智能家居的核心矛盾在于：WiFi适合传大数据（如传感器历史记录），BLE适合传小数据（如开关指令）。但用户不关心协议，只想要“手机点一下，灯就亮”。这就需要在固件里建一座桥——让BLE端接收的指令，能无缝转发给WiFi端执行；反之，WiFi从云端收到的指令，也能推送到BLE设备。

我的方案是采用“事件总线”（Event Bus）架构：

• 所有外设操作（继电器开关、DHT22读数、LED亮度调节）封装为独立函数，不直接操作硬件，而是向事件总线发布消息（如EVENT_RELAY_ON,EVENT_TEMP_READ）
• WiFi任务监听总线，将EVENT_RELAY_ON转换为MQTT PUBLISH到home/light/kitchen主题
• BLE GATT服务监听总线，当收到EVENT_RELAY_ON时，立即更新Characteristic值（0x2A56），触发手机App刷新UI
• 关键是：事件总线使用FreeRTOS队列实现，长度设为32，优先级高于WiFi/BLE任务，确保指令不堆积

// 事件总线定义（event_bus.h） typedef enum { EVENT_RELAY_ON, EVENT_RELAY_OFF, EVENT_TEMP_READ, EVENT_HUMI_READ, EVENT_BUTTON_PRESS } event_type_t; typedef struct { event_type_t type; uint8_t payload[16]; } event_t; extern QueueHandle_t event_bus_queue; // 发布事件示例（relay_control.c） void relay_on(void) { event_t evt = {.type = EVENT_RELAY_ON}; xQueueSend(event_bus_queue, &evt, portMAX_DELAY); }

这套架构的好处是解耦。去年有个客户想把系统接入Apple HomeKit，我们只改了WiFi任务里的MQTT发布逻辑，替换成HomeKit的HAP协议，BLE端完全不用动——因为事件总线已经把“开灯”这个语义抽象出来了，不管后面接的是MQTT、HTTP还是HomeKit，前端感知不到变化。

注意：不要在BLE GATT回调函数里直接调用WiFi API！我踩过最大的坑是，在gatt_write_event_handler里调用esp_wifi_connect()，结果导致WiFi任务和BLE任务互相抢占临界区，系统死锁。正确做法是：在GATT回调中只发事件，由独立的WiFi任务去处理连接逻辑。

4. 实操部署与真机调试：从烧录到上线的全流程细节

很多教程止步于“烧录成功，串口打印Hello World”，但真实项目里，90%的问题出在部署环节。下面是我整理的“ESP32智能家居部署七步法”，每一步都对应一个高频故障点：

4.1 烧录前的硬件自检清单

在连接USB线之前，请务必完成以下检查（漏一项，后续调试可能浪费3小时）：

1. 电源电压确认：用万用表量VCC-GND，必须在3.0~3.6V之间。低于3.0V会导致WiFi启动失败（报错wifi: wifi os timer task create fail）；高于3.6V可能击穿Flash。
2. BOOT按钮状态：长按BOOT键不松开，再插USB线——此时ESP32强制进入下载模式。松开后，串口应输出waiting for download。如果直接打印rst:0x10 (RTCWDT_RTC_RESET)，说明没进下载模式。
3. GPIO0电平：用万用表测GPIO0对GND电压，必须为0V（接地）。有些山寨USB转TTL模块的DTR/RTS引脚电平异常，会导致GPIO0悬空，烧录失败。
4. Flash型号匹配：查看原理图，确认Flash型号（如Winbond W25Q32，容量4MB）。在esptool.py中指定--flash_size 4MB，否则烧录后无法启动。

我建议新手用CH340G芯片的USB转TTL模块（非PL2303），因为CH340G的DTR/RTS电平更稳定，且Windows驱动兼容性最好。去年帮一个客户排查“烧录成功率仅30%”的问题，最后发现是他用的PL2303HX模块在Win11下驱动有bug，换CH340G后一次成功。

4.2 首次启动的串口日志解读

烧录完成后，打开串口监视器（波特率115200），正常启动日志应包含以下关键行：

I (23) boot: ESP-IDF v4.4.4 2nd stage bootloader I (23) boot: compile time 14:22:05 I (23) boot: chip revision: 3 I (27) boot.esp32: SPI Speed : 40MHz I (31) boot.esp32: SPI Mode : DIO I (35) boot.esp32: SPI Flash Size : 4MB I (40) boot: Enabling RNG early entropy source... I (45) boot: Partition Table: I (48) boot: ## Label Usage Type ST Offset Length I (55) boot: 0 nvs WiFi data 01 02 00009000 00006000 I (62) boot: 1 phy_init RF data 01 01 0000f000 00001000 I (69) boot: 2 factory factory app 00 00 00010000 001e0000 I (76) boot: End of partition table I (80) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x1a5cc (107980) map I (124) esp_image: segment 1: paddr=0x0002a5f4 vaddr=0x3ffb0000 size=0x034b0 ( 13488) load I (131) esp_image: segment 2: paddr=0x0002daac vaddr=0x40080000 size=0x00400 ( 1024) load I (132) esp_image: segment 3: paddr=0x0002dec0 vaddr=0x40080400 size=0x064c0 ( 25792) load I (148) esp_image: segment 4: paddr=0x00034388 vaddr=0x400d0000 size=0x9e200 (647680) map I (342) esp_image: segment 5: paddr=0x000d2590 vaddr=0x40080800 size=0x15110 ( 86288) load I (378) boot: Loaded app from partition at offset 0x10000 I (378) boot: Disabling RNG early entropy source... I (379) cpu_start: Pro cpu up. I (382) cpu_start: Application information: I (387) cpu_start: Project name: smart_home_v2 I (392) cpu_start: App version: 1.2.3 I (397) cpu_start: Compile time: Apr 12 2024 14:22:05 I (403) cpu_start: ELF file SHA256: 3a7b8c...e1f2 I (409) cpu_start: Starting app cpu, entry point is 0x400812dc I (0) cpu_start: App cpu up. I (420) heap_init: Initializing. RAM available for dynamic allocation: I (427) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM I (433) heap_init: At 3FFB3198 len 0000CE68 (51 KiB): DRAM I (439) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM I (445) heap_init: At 40091C28 len 0000E3D8 (57 KiB): IRAM I (452) cpu_start: Pro cpu start user code I (457) spi_flash: detected chip: generic I (462) spi_flash: flash io: dio W (466) spi_flash: Detected size(4096k) larger than the size in the binary image header(2048k). Using the size in the binary image header. I (478) cpu_start: Starting scheduler on PRO CPU. I (0) cpu_start: Starting scheduler on APP CPU. I (224) wifi: wifi driver task: 3ffc5514, prio:23, stack:6656, core=0 I (224) system_api: Base MAC address is not set I (224) system_api: read default base MAC address from EFUSE I (234) wifi: wifi firmware version: 2454441 I (234) wifi: config NVS flash: enabled I (234) wifi: config nano formating: disabled I (244) wifi: Init dynamic tx buffer num: 32 I (244) wifi: Init data frame dynamic rx buffer num: 32 I (254) wifi: Init management frame dynamic rx buffer num: 32 I (254) wifi: Init static rx buffer size: 1600 I (264) wifi: Init static rx buffer num: 10 I (264) wifi: Init dynamic rx buffer num: 32 I (274) wifi: mode : sta (7c:df:a1:xx:xx:xx) I (274) wifi: enable tsf I (284) ble: BLE controller compile version [4441441] I (284) system_api: Base MAC address is not set I (284) system_api: read default base MAC address from EFUSE I (294) phy: phy_version: 4700, 0eb9715, Jul 17 2023, 14:34:26, 0, 0 I (304) wifi: mode : sta (7c:df:a1:xx:xx:xx) + softAP (7c:df:a1:xx:xx:xx) I (314) wifi: Total power save buffer number: 16 I (314) wifi: Init max length of beacon: 752/752 I (324) wifi: Init max length of beacon: 752/752 I (324) wifi: mode : sta (7c:df:a1:xx:xx:xx) + softAP (7c:df:a1:xx:xx:xx) I (334) app_main: WiFi initialized, IP address: 192.168.4.1 I (344) app_main: BLE advertising started I (354) app_main: HTTP server started on port 80 I (364) app_main: MQTT client connected to broker.example.com

重点关注三处：

• spi_flash: detected chip: generic→ 表示Flash识别正常，如果显示unknown，说明Flash型号不匹配或焊接虚焊；
• wifi: mode : sta (...) + softAP (...)→ 表示WiFi已同时启动STA（连路由器）和AP（热点）模式，这是实现“无网配网”的关键；
• app_main: BLE advertising started→ 表示BLE广播已开启，手机蓝牙扫描应能看到设备名（如SmartHome-Light-XXXX）。

如果卡在wifi: mode : sta之后不再往下走，大概率是WiFi密码错误或路由器开启了MAC过滤。此时需检查wifi_config_t结构体中的sta.password是否正确（注意中文字符、特殊符号会被截断）。

4.3 局域网配网的实战技巧

ESP32的SmartConfig（一键配网）在实际家庭中失败率高达40%，原因很现实：iPhone的iOS系统从14.5开始限制后台WiFi扫描，导致SmartConfig广播包收不到；安卓手机厂商定制ROM会关闭UDP广播权限。我的替代方案是“AP+Web配网”，流程如下：

1. 设备上电后，自动创建热点SmartHome-Setup-XXXX（SSID末四位为MAC地址后缀）；
2. 手机连上该热点，浏览器访问192.168.4.1，进入配网页面；
3. 页面通过AJAX POST将路由器SSID/密码发送到/api/config接口；
4. ESP32收到后，保存到NVS分区，重启WiFi STA模式连接目标路由器；
5. 连接成功后，自动关闭AP模式，释放IP资源。

这个方案的优势是：不依赖手机系统权限，所有交互走HTTP，兼容性100%。但要注意一个细节——AP模式下的DHCP服务器必须设置租期为120秒（默认3600秒），否则手机连上后获取不到IP。代码中需调用：

tcpip_adapter_dhcps_option_t opt; opt.mode = TCPIP_ADAPTER_DHCP_SERVER; opt.option = DHCP_OPTION_LEASE_TIME; opt.value = (uint8_t*)&lease_time_sec; // lease_time_sec = 120 tcpip_adapter_dhcps_option(TCPIP_ADAPTER_IF_AP, &opt);

去年帮一个老年客户部署时，他反复说“连不上”，最后发现是他家路由器SSID里有中文“华硕AC1900”，而ESP32的WiFi驱动对UTF-8编码支持不完善。解决方案是：在配网页面增加“SSID编码提示”，当检测到非ASCII字符时，弹窗提醒“请将路由器SSID改为英文，如ASUS_AC1900”。

5. 常见问题与排查技巧实录：那些手册里不会写的坑

在真实项目中，问题往往不是“能不能跑”，而是“为什么有时灵有时不灵”。以下是我在127个现场部署案例中总结的TOP5高频问题，附带可直接复用的排查脚本和硬件修复方案。

5.1 WiFi断连后无法自动重连：不是代码问题，是天线接地

现象：设备运行2-3天后，WiFi信号强度从-45dBm掉到-85dBm，ping不通网关，但串口日志显示wifi: state: run -> init (100)，然后反复循环。

根因分析：这不是固件Bug，而是PCB设计缺陷。ESP32的RF地（RF_GND）必须与数字地（DGND）单点连接，且连接点必须靠近天线馈点。很多低成本PCB把RF_GND和DGND大面积铺铜短接，导致数字噪声窜入射频通路，WiFi基带芯片误判信道质量，主动降级到1Mbps速率（等效于信号消失）。

实测验证：用示波器探头接地，轻触PCB上天线附近的RF_GND铜皮，如果信号强度瞬间回升，即可确认是接地问题。

修复方案：

1. 在RF_GND和DGND之间割开一道0.3mm宽的槽；
2. 用0603封装的10nF电容（X7R材质）跨接槽两侧，作为射频通路；
3. 在电容旁并联一个0Ω电阻（方便后期调试断开）。

提示：不要用磁珠替代电容！磁珠在2.4GHz频段阻抗不稳定，实测会导致BLE广播功率波动±3dB。

5.2 BLE连接后特征值读写超时：时钟源漂移的隐性杀手

现象：手机App能扫描到设备、建立连接，但读取温湿度特征值时总是超时（GATT_ERROR），重试3次后断开。

根因分析：ESP32的BLE协议栈依赖高精度时钟源（32.768kHz晶振）。如果晶振负载电容不匹配（如标称12.5pF却用了22pF电容），会导致时钟频率偏移超过±500ppm，BLE连接间隔同步失败，特征值响应帧被对方视为无效丢弃。

快速诊断：用频谱仪测晶振输出，正常应为32.768kHz±10Hz。如果没有仪器，可用以下代码粗略判断：

// 在app_main()中添加 rtc_clk_slow_freq_t slow_freq = rtc_clk_slow_freq_get(); printf("Slow clock freq: %d Hz\n", slow_freq); // 应为RTC_SLOW_FREQ_32K_XTAL

如果输出RTC_SLOW_FREQ_8MD256，说明晶振未起振。

修复方案：

• 更换晶振为NDK NX3225SA系列（温漂±10ppm）；
• 负载电容严格按晶振规格书选型（如NX3225SA-32.768K-STD-CSR-6，配12.5pF）；
• 晶振走线远离数字信号线，下方铺完整地平面。

5.3 多设备组网时信道冲突：别怪ESP32，先看你的路由器

现象：家里部署了5个ESP32节点，初期正常，两周后部分节点BLE广播丢失，WiFi吞吐量下降50%。

根因分析：2.4GHz频段只有13个信道（中国），但WiFi用1、6、11信道，BLE用37、38、39信道，它们在频谱上是重叠的。当路由器固定在信道6，而多个ESP32的BLE广播恰好落在信道6的边带，就会形成持续干扰。

实测数据：用RTL-SDR采集频谱，发现信道6中心频率2.437GHz，其-20dB带宽覆盖2.422~2.452GHz；而BLE信道37中心2.402GHz，但实际占用带宽2.400~2.404GHz——两者无重叠。真正的问题是：路由器的邻道泄漏（ACLR）超标，导致信道6的能量泄漏到信道37。

解决方案：

• 登录路由器后台，将WiFi信道改为1或11（远离BLE信道）；
• 在ESP32固件中，将BLE广播信道从默认的37/38/39，改为37/38/39+1（即38/39/40），但需注意40信道在部分国家非法；
• 最稳妥方案：启用BLE信道跳频（esp_ble_gap_config_adv_data_raw()中设置adv_channel_map = ADV_CHNL_ALL），让广播在三个信道间轮转。

5.4 OTA升级失败：Flash擦写次数的物理极限

现象：设备运行半年后，OTA升级总是失败，串口报错E (1234) ota: Failed to write to flash，但手动擦除Flash后又能升级一次。

根因分析：ESP32的Flash（通常为Winbond W25Q32）擦写寿命约10万次。OTA升级时，不仅写入新固件，还会反复擦写NVS分区（存储WiFi配置、设备ID等），导致某一块扇区提前失效。

数据佐证：用espefuse.py --port /dev/ttyUSB0 get_flash_crypt_cnt查看Flash加密计数器，如果FLASH_CRYPT_CNT值异常高，说明Flash磨损严重。

长效方案：

• 将NVS分区从Flash迁移到外部EEPROM（如AT24C02），通过I2C访问；
• 或启用SPIFFS文件系统，将配置文件存入SPIFFS，利用磨损均衡算法延长寿命；
• 最简单有效的方法：在OTA前，先执行nvs_flash_erase()全擦除，再烧录——虽然慢，但能规避坏块。

5.5 温湿度传感器读数漂移：不是传感器坏了，是PCB热设计缺陷

现象：DHT22读数显示温度35℃，但用手摸设备外壳仅28℃，用红外测温枪实测环境温度26℃。

根因分析：ESP32自身功耗约120mA@3.3V，满载时发热2.5W。如果温湿度传感器（如DHT22）紧贴ESP32芯片布局，热传导会导致读数虚高。实测数据显示：DHT22距离ESP32芯片<5mm时，读数偏差+3.2℃；距离>20mm时，偏差<±0.3℃。

修复方案：

• 重新设计PCB，将DHT22放置在板边，远离电源芯片和ESP32；
• 在DHT22周围挖空铜皮，减少热传导路径；
• 增加软件补偿：采集10秒内ESP32内部温度传感器（temperature_sens_read()）读数，按公式compensated_temp = dht22_temp - 0.8 * (esp32_temp - 25)校准。

实操心得：所有传感器类节点，必须做“热隔离测试”。方法很简单：用吹风机热风档（60℃）吹PCB背面10秒，立即读取传感器值，如果变化>1℃，说明热设计不合格，必须整改。

6. 系统扩展与工程化建议：从单点设备到家庭中枢

当你已经稳定运行了3-5个ESP32节点（灯控、温控、门磁），下一步自然会思考：如何让它们真正“智能”起来？不是简单的App联动，而是基于环境上下文的自主决策。这里分享三个经过验证的扩展方向，每个都附带最小可行代码片段。

6.1 基于时间+光照的自适应照明

核心逻辑：不是“人来开灯”，而是“当环境光<50lux且时间在18:00-06:00时，渐亮到70%亮度”。这需要融合BH1750光照传感器和RTC时钟。

关键代码：

// 光照阈值与时间窗口定义 #define LIGHT_THRESHOLD_LUX 50 #define NIGHT_START_HOUR 18 #define NIGHT_END_HOUR 6 // 主循环中判断 if (bh1750_read_lux(&lux) == ESP_OK) { time_t now; struct tm timeinfo; time(&now); localtime_r(&now, &timeinfo); bool is_night = (timeinfo.tm_hour >= NIGHT_START_HOUR) || (timeinfo.tm_hour < NIGHT_END_HOUR); if (lux < LIGHT_THRESHOLD_LUX && is_night) { // 渐变开灯：从0%到70%用10秒 for (int i = 0; i <= 70; i += 5) { ledc_set_duty(LEDC_LOW_SPEED_MODE, LEDC_CHANNEL_0, i); ledc_update_duty(LEDC_LOW_SPEED_MODE, LEDC_CHANNEL_0); vTaskDelay(100 / portTICK_PERIOD_MS); } } }

这个方案的价值在于：避免了“人走灯灭”的机械感。去年给一个独居老人装的系统，他晚上起夜时，走廊灯会自动以10%亮度亮起，持续30秒后渐暗——既不刺眼，又保证安全，比任何运动传感器都可靠。

6.2 多节点协同的“无感回家”模式

当玄关门磁触发+客厅光照<30lux+当前时间在17:00-23:00，自动执行：

• 玄关灯亮100%
• 客厅灯亮50%
• 空调启动制热（目标26℃）
• 播放欢迎语音（通过ESP32内置DAC驱动小喇叭）

实现要点：所有节点通过MQTT Topic订阅home/event/entry，当门磁节点发布{"event":"door_open","location":"entrance"}时，其他节点解析JSON并执行本地动作。为避免网络延迟，门磁节点在发布MQTT前，先通过BLE广播一个简短事件码（如0x01），附近节点用BLE扫描到后立即预启动，MQTT消息到达后再做最终确认。

6.3 低成本能耗监控：用ACS712电流传感器替代智能