简介LightControl是一个基于Java开发的照明控制系统项目面向智能家居、物联网或嵌入式控制方向的中初级开发者可用于学习Java网络通信、设备控制与用户界面设计。资源共35个文件压缩包仅65KB结构紧凑其中27个Java源文件构成核心业务逻辑properties与xml为配置和构建支持jar为依赖库sql为数据库脚本md为项目说明。目前已有53人学习适合作为Java实战入门案例。通过压缩包可获取完整源码、Maven构建配置pom.xml、资源文件及Git忽略规则便于直接导入IDE运行调试结合README与SQL脚本可快速理解设备发现、灯光控制、定时任务、场景预设等模块的实现思路对希望掌握Java桌面或后端开发流程的读者很有参考价值。 晚上十点半我坐在沙发上看着客厅主灯明晃晃地亮着想换成暖光弱一点又不想起身去够开关。这个念头反复出现了很多次终于有一天我决定不再忍了动手做了一套局域网内的智能灯光控制系统起名就叫 LightControl。它的目标很明确不依赖任何云平台不买一堆专用网关把家里已有的灯接进来通过浏览器、手机或者自动定时都能控制。这套系统我跑了一个多月把中间踩的坑和最终的方案完整地记录下来想自己动手做智能家居或者不想被某一家生态绑定的朋友应该能从里面找到不少能直接用的经验。1. 为什么自己动手做一套 LightControl而不是买现成的智能灯1.1 我对市售方案越来越不满意的三个原因市面上能买到的智能灯泡、智能开关确实不少我也装过一些。但用了一段时间之后有三点让我觉得不太舒服。首先是平台绑定问题。买 A 家的灯泡就得装 A 家的 App后续想加 B 家的传感器又得看它能不能接入同一个系统。折腾一圈下来手机里装了好几个控制软件明明只是开关灯却要在一堆 App 之间来回切换。这种“生态围墙”短期看是方便长期看就是给自己挖坑。其次是本地可用性问题。绝大多数成品方案控制指令都要先上云再从云端下发到设备。一旦家里的宽带出故障或者服务商的服务器不稳定你甚至连开灯关灯这种基础操作都做不了。我个人的底线是灯光这种东西应该是本地优先哪怕整个外网都断了家里控制页面照样能打开这才叫可靠。最后是灵活性不足。成品的智能灯泡亮度、色温、场景模式看起来很多真到用的时候总感觉隔着一层。我想实现“按下墙上开关关灯但保留遥控器还能再开”这种逻辑市售产品很难配合。与其去适应它们的设计不如按自己的需求从零搭一套这就是 LightControl 出现的原因。1.2 决定自己做之前先给边界画一条线一开始我差点把这件事想得过于宏大想做 App、做语音助手、做自动化场景还要做能耗统计。还好我在动手前及时冷静下来给这个项目画了几条边界。第一版 LightControl 只做三件事局域网内 Web 控制、两路 PWM 调光、三路继电器开关。定时功能放在二期语音接入放到三期App 干脆不做因为手机浏览器配合 PWA 加到桌面体验已经和原生 App 差不多。这样边界清晰以后整个项目的复杂度立刻降下来。还有一个很重要的决定所有控制逻辑全部跑在 ESP32 上不依赖家里的电脑长期开机。这意味着我需要一个能独立运行、功耗低、价格便宜的控制核心后面我选了 ESP32理由后面细说。对大多数想复刻这套系统的朋友我建议也先想清楚自己的“最小可用版本”是什么先让它稳定跑起来再考虑加东西否则很容易烂尾。2. 硬件怎么搭ESP32 主控、继电器、PWM 调光的完整链路2.1 主控选型ESP32 是“刚刚好”的选择控制核心我最终选了 ESP32 DevKitC 开发板而不是树莓派。核心原因是价格、功耗和性价比的平衡。树莓派做这种控制器当然可以还能跑完整的 Home Assistant但一是贵二是要给它配 TF 卡、供电、散热整机功耗比 ESP32 高一个数量级。而 ESP32 自带 Wi-Fi、蓝牙、双核处理器和丰富的外设市价只要二三十块钱跑一个灯光控制服务器绰绰有余。更重要的是 ESP32 的 PWM 输出能力。它内部的 LEDC 模块可以输出最高几十 kHz 的 PWM 信号频率、分辨率都程序可调这给了我做调光很大的余地。后面讲频闪问题时会提到如果当初选了普通 Arduino Uno想做到同样的效果就得额外加芯片会费不少事。2.2 调光与开关的分工不是所有灯都需要调光我家里三路灯光需求各不相同。客厅主灯是普通 LED 吸顶灯只需要开关不需要调光所以我用一路继电器控制火线通断。书桌灯带是 12V 的 LED 灯带需要无级亮暗调节我给它单独配了一路 MOSFET 做 PWM 调光。卧室床头灯也是 LED但要满足夜间弱光需求所以同样走 PWM。这里想提醒一下不要试图让继电器去做调光的事。继电器本质是机械开关频繁通断不仅会产生噪音、缩短寿命而且因为通断响应速度跟不上人眼感知灯光会出现肉眼可见的闪烁体验非常差。调光这件事交给 MOSFET 或者可控硅来做才是正路。两种驱动方式的分工整理如下灯光类型控制方式关键器件适用场景LED 吸顶灯、白炽灯开关继电器模块只做通断不需要亮度变化12V/24V LED 灯带调光MOSFETPWM需要无级亮暗、场景光墙壁开关替代开关继电器模块保留物理开关的位置和手感交流调光调光可控硅/后沿调光模块需要交流灯具亮度调节但对 EMI 要求高2.3 接线细节继电器怎么驱动、MOSFET 怎么选接线是这套系统里最容易出错的地方尤其是 ESP32 的 GPIO 引脚和强电部分混在一起时稍不注意就是烧板子甚至更严重的问题。我用的继电器模块是低电平触发的光耦隔离型控制端本身带三极管放大电路所以 ESP32 的 GPIO 可以直接接。但如果你用的是裸继电器模块一定要在 GPIO 和继电器之间加一个 NPN 三极管比如 S8050做驱动否则 GPIO 的电流根本拉不动继电器线圈。模块上通常有 JD-VCC 跳线用来把继电器线圈的电源和逻辑电源隔离开建议按照模块说明把跳线设成隔离模式避免继电器吸合瞬间产生的反冲电压影响到 ESP32。PWM 调光部分我选了 AO3400 这颗 N-MOSFET导通电阻低、逻辑电平驱动3.3V 的 GPIO 可以直接开启对 12V 灯带这种负载来说完全够用。栅极要加一个 10kΩ 下拉电阻到地防止 ESP32 启动过程中 GPIO 处于高阻状态时MOSFET 意外导通、灯带突然亮起来。电源部分我用了一个 220V 转 5V 的隔离式开关电源给 ESP32 和继电器模块供电灯带本身用单独的 12V 电源两个电源的 GND 根据需要共地或不共地。第一次通电前我强烈建议先用万用表量一遍各点电压确认没有短路再接灯具这一步能帮你省下大把排查问题的时间。3. 软件设计一套轻量协议让网页、定时和状态同步各司其职3.1 通信方式WebSocket 与 HTTP 分开用控制页面的通信协议我最初想全部用 HTTP后来发现不行。HTTP 是请求-响应模式适合“客户端主动问、服务端被动答”的操作但做实时状态同步非常别扭网页要不停地轮询延迟高、开销大。所以我最终采用了混合方案控制指令用 HTTP状态推送用 WebSocket。ESP32 上我跑了两个服务一个 HTTP 服务一个 WebSocket 服务。网页打开后先通过 HTTP 请求/api/state拉取当前所有灯的状态然后建立 WebSocket 连接。之后网页上每按一次开关就发一条 POST 请求到/api/control带上通道编号和目标值ESP32 收到后执行控制动作再通过 WebSocket 向所有在线客户端广播最新状态。这样只要有一个客户端在控制其他打开的页面都能马上同步不用刷新。消息格式我用的是 JSON简单直观。控制指令长这样{ channel: desk, action: set_brightness, value: 180 }状态广播长这样{ channel: desk, state: on, brightness: 180, timestamp: 1720000000 }这套协议不复杂但对灯光控制这种简单场景来说完全够用而且调试非常方便。3.2 状态机设计开机恢复、多端同步、故障回滚软件层面最重要的不是那些 API而是状态管理。我开始写的版本非常简陋每次控制只管改 GPIO 输出不保存任何状态结果路由器一重启所有灯恢复成默认值家里人就跑来问“为什么书桌灯突然亮了”。这就是吃了没做状态持久化的亏。后来我重新设计了状态机每次控制动作执行成功后把当前状态写入 ESP32 的 NVS 闪存系统启动时先读取 NVS 里的记录恢复各个通道到上次关机前的状态然后再启动 Web 服务。这里有一个细节恢复的顺序要讲究继电器通道应该先设置成关闭状态再延迟几百毫秒设置成开通状态避免上电瞬间所有 GPIO 处于不确定电平导致继电器误动作。多端同步的“故障回滚”也值得一提。我遇到过一种情况网页上发出调节亮度指令但执行过程中灯带负载异常驱动器没有按预期响应。如果服务端直接广播“亮度已经调到 200”其他页面就会显示一个实际上没发生的结果。所以我在指令和状态之间做了区分指令是用户想要的结果状态是硬件实际返回的结果。ESP32 执行完控制后通过 ADC 采样确认灯带电流是否确实变化如果没变化就回滚状态并向客户端返回错误码。这个逻辑在普通灯光项目里很多人会忽略但对可靠性要求高的场景特别有用。3.3 定时任务与离线时钟不依赖云也能准时定时开关灯是智能灯最基本的需求但实现起来有个容易忽略的问题单片机怎么知道现在是几点最省事的方式是联网用 NTP 协议同步时间但这样依赖外网。我的想法是灯光系统本就应该离线可用所以我给 ESP32 加了一个 DS3231 RTC 模块做本地时间基准。每次开机时如果网络可用就通过 NTP 校准一次如果网络不可用就继续用 RTC 的计时而并非做不到。这样定时任务只依赖本地时钟不受云端状态影响。定时任务的调度我用简单的 FreeRTOS 软件定时器就够了每秒钟检查一次当前时间并和周计划表做匹配。比如工作日晚上六点半自动打开书桌灯亮度设为 60%周末早上九点自动关掉所有灯。计划表存在 NVS 里通过 HTTP 接口可以随时修改。这套设计跑了一个月没有出现时间偏移导致错乱的问题DS3231 的温补优势很明显。4. 实测踩坑记录PWM 频闪、Wi-Fi 掉线、继电器粘连的修复过程4.1 调光灯带在手机摄像头下频闪PWM 频率需要匹配驱动器第一版调光代码写得很简单初始化 LEDC 时直接用默认的 500Hz 频率然后调到任意亮度。肉眼看好像没问题但拿手机摄像头对着灯带录像画面里全是波浪纹这说明 PWM 频率太低和传感器快门产生了明显的差拍。这个问题背后的原因是 LED 灯带本身没有高频滤波能力它的驱动方式就是直接通断所以 PWM 频率越低电流纹波越明显。解决办法是提高 PWM 频率但也不能无限高频率太高之后 MOSFET 的开关损耗会增加发热变严重。我在灯带上实测了几个频率2kHz 时摄像头可见轻微条纹5kHz 时基本消失10kHz 时完全干净但 MOSFET 温升比 5kHz 高约 3℃。最终我把默认频率定在 5kHz亮度调节分辨率保持 10 位0~1023。如果你用的是恒流驱动电源来带灯还需要结合驱动器说明书有些驱动器要求 PWM 频率不低于 1kHz否则会出现吱吱声。4.2 Wi-Fi 频繁掉线罪魁祸首是 ESP32 的省电模式系统跑了一周后我遇到一个很烦的问题控制页面经常打不开重启 ESP32 后恢复过一两天又死。一开始怀疑是代码内存泄漏后来排查日志发现设备掉线的根本原因是 Wi-Fi 连接丢失后重连逻辑写得太粗暴。ESP32 默认开启了 modem sleep 省电模式这个模式下 Wi-Fi 模块会在空闲时进入低功耗状态对电池供电的设备是好消息但对我这种需要随时响应外部请求的设备来说就是灾难只要网页和 ESP32 之间的通信间隔稍长Wi-Fi 模块就可能睡过头醒来后路由器已经把它踢掉了。修复方法很直接在初始化 Wi-Fi 时调用esp_wifi_set_ps(WIFI_PS_NONE)关闭省电模式。另外还要设置静态 IP 或 DHCP 租约足够长避免 IP 地址频繁变化。关闭省电之后我连续观察了二十多天没有再出现掉线无法唤醒的情况。如果你是给插电设备做控制类项目建议从第一天就关掉省电模式别像我一样等到线上故障才去排查。4.3 开关与调光同时动作时继电器为什么会粘连有一次我在测试联动场景晚上打开书桌灯时先让继电器吸合给灯带供电紧接着调整 PWM 亮度。结果继电器触点出现粘连灯带不受控制地一直亮着直到我断了总闸才停下来。拆开继电器检查触点表面有明显的拉弧痕迹。原因其实很简单继电器带载吸合或断开时瞬间电流会造成触点拉弧次数多了就会烧蚀粘连。我的 PWM 调光用 MOSFET 控制的是灯带负极继电器控制的是正极电源那问题就变成开灯瞬间先通电源再调光还是先调光再通电源关灯瞬间先断电源再调暗还是先调暗再断电源正确的动作顺序应该是开灯时先把 PWM 占空比拉到最大也就是灯带完全导通状态此时 MOSFET 的压降最小然后再让继电器吸合吸合完成后延时 50ms 再把 PWM 调到目标亮度。关灯时反过来先把 PWM 占空比降到 0等 50ms 让负载电流衰减到接近零再断开继电器。这样继电器触点承受的电流非常小拉弧概率大幅下降。这个时序是用 FreeRTOS 的延时函数实现的代码逻辑不复杂但非常关键。4.4 强电弱电互相干扰导致随机误触发的布线教训最后一个坑是环境问题。系统装好后偶尔会出现灯光自己跳变的情况比如书桌灯突然从 50% 亮度跳到 100%或者卧室灯莫名其妙开了一下又关掉。一开始我怀疑是代码逻辑 bug但看了半天日志发现这些误触发都发生在附近有大功率电器启停的时间点比如冰箱压缩机启动、空调变频器动作。问题出在布线上。最初为了好看我把 220V 交流电线和 ESP32 的 GPIO 信号线一起穿进同一根线槽两者距离非常近。220V 线路上的高 dv/dt 会通过寄生电容耦合到信号线上一旦干扰幅度超过 GPIO 的阈值就会产生一个假的触发信号。后来我把强电线和弱电线完全分两路走间隔至少 10cm并且给 MOSFET 栅极信号线加了 100Ω 串联电阻和 1nF 对地电容构成低通滤波干扰问题基本消失。如果你要在配电箱或者狭小空间里做这类项目这个教训尤其值得借鉴强电、弱电之间要有物理距离共地要谨慎信号线要做滤波否则排查起来非常费时。5. 跑了一个月的真实体验以及后续还能怎么扩展5.1 三路灯光实际运行情况稳定但不完美LightControl 在我家稳定运行大概四十天整体表现算可靠。最常用的场景是客厅主灯定时关闭书桌灯带从 100% 亮度随日落渐渐降到 30%卧室床头灯保留手动调节。家人一开始觉得累赘后来习惯了“手机浏览器点一下就能化调整”的方式反而觉得比墙上的开关方便多了。它不完美的地方也有一个是 ESP32 的 Web 页面响应速度在局域网内通常在 100~300ms 之间虽然体感流畅但和原生 App 的秒开还是有差距另一个是拔掉电源再插上后Wi-Fi 重连需要几秒钟期间控制页面无响应属于妥协接受的程度。另外我的灯具本身不是调光型电源用 PWM 直接斩波会产生轻微的电流声夜深人静时能听到这个后来我把 PWM 频率调成 8kHz 之后基本听不到了但代价是 MOS 管温度略升算是此消彼长吧。5.2 下一步扩展雷达传感器联动与语音接入这套系统稳定后我给它留了扩展接口。一个是把 HLK-LD2410 人体雷达接到 ESP32 的 UART 上这样人在书房时自动把书桌灯调到 70%人离开超过五分钟降到 20%再超过十分钟直接关灯。另一个是接入语音我不打算用带麦克风的专用设备而是准备利用家里现有的智能音箱通过局域网 HTTP 请求直接触发 LightControl 的接口。这两个扩展都不改动核心架构只要在现有 HTTP 服务上增加几个 endpoint 就行。5.3 给想复刻的人的三条实操建议第一安全永远是第一位。这个项目涉及 220V 交流电如果你没有电工基础建议先在 12V 灯带上把逻辑全部调通再考虑接线到墙面的交流灯具。不要为了省钱省略隔离电源和继电器模块上的光耦隔离。第二先写好状态持久化和启动恢复逻辑再去做 Web 界面。很多新手喜欢先把页面做得花里胡哨结果基础状态管理一塌糊涂每次重启设备灯的状态全部乱掉这是最容易劝退人的一个点。稳定的系统核心不是功能多而是状态对。第三留出调试接口。我在代码里加了一个串口调试模式可以实时打印每个通道的当前状态和最后一次控制指令来源。这个调试模式在正式使用中几乎没开过但它的存在让我排查问题时心里有底。做嵌入式控制类项目永远别把后门堵死给自己留一条排查路径能省下大把时间。本文还有配套的精品资源点击获取