一、项目背景与需求分析：天窗漏水痛点、市场现有方案调研、系统功能需求定义、技术选型论证

大家好，我是老李。做嵌入式这行十几年了，踩过的坑比吃过的盐还多。今天咱们聊的这个天窗漏水检测与智能关闭系统，其实是我去年帮一个朋友解决的烦心事。他家里刚装修完，一场大雨，客厅直接变水帘洞。嗯，天窗漏水这事儿，看着小，真摊上了能让你崩溃。

1.1 天窗漏水的真实痛点

先说说痛点。你想想看，天窗漏水一般发生在什么时候？多半是半夜或者你不在家的时候。雨哗哗下，水顺着天窗边缘渗进来，墙面、地板、家具全泡汤。我见过最惨的一家，木地板全翘了，墙皮脱落，维修花了小两万。

为什么会这样？说白了，天窗的密封胶条会老化，排水槽会堵塞，安装时没做好坡度也会积水。我自己的经验是，很多天窗漏水不是一下子发生的，而是慢慢积累。今天渗一点，明天渗一点，等你发现时，墙里已经长霉了。

我记得有个客户跟我说，他家的天窗每次下雨前都要用塑料布盖住，再用砖头压着。你说这哪是享受阳光房，分明是给自己找了个祖宗。

3.2 市场现有方案调研

做项目之前，我习惯先看看市面上有什么现成的东西。说白了，能买现成的就别自己造轮子。但调研一圈下来，发现情况不太乐观。

方案类型	代表产品	优点	缺点
纯机械式	手动天窗、摇杆式	结构简单，成本低	需要人工操作，无法自动检测
电动天窗	某品牌电动开窗器	可遥控开关	无漏水检测功能，价格偏高
智能家居联动	某米生态链产品	可接入智能家居	依赖云平台，断网就废，延迟高
工业级漏水检测	某国产漏水检测器	检测灵敏，报警及时	只报警不关窗，价格贵得离谱

你看这个表就明白了。市面上的方案要么只检测不处理，要么能开关但不检测漏水。真正把检测和自动关闭做到一起的，几乎没有。我当初做调研时就在想，这不就是个典型的嵌入式项目机会吗？

1.3 系统功能需求定义

好，调研完了，咱们来定义功能。我个人习惯是先列一个功能清单，然后按优先级排。别一上来就想做全能，先把核心功能做扎实。

核心功能（必须实现）：

• 漏水实时检测：在天窗边缘、排水槽位置部署传感器，检测到水渍立即触发
• 自动关闭天窗：检测到漏水后，电机驱动天窗自动关闭，无需人工干预
• 本地报警：蜂鸣器或LED灯闪烁，提醒室内人员
• 手动/自动切换：保留手动开关功能，防止自动系统误动作

扩展功能（锦上添花）：

• 远程通知：通过WiFi或蓝牙，把漏水信息推送到手机
• 雨量感应：在下雨前就提前关闭天窗，防患于未然
• 状态记录：记录漏水事件的时间、次数，方便排查问题
• 低功耗模式：电池供电时自动进入休眠，延长续航

1.4 技术选型论证

技术选型这块，我多说几句。很多新手喜欢追新，什么芯片火就用什么。但做产品不是搞科研，稳定可靠才是第一位的。

主控芯片选型：

我推荐用 ESP32。为什么？

• 自带WiFi和蓝牙，省了外挂模块
• 价格便宜，十几块钱一片
• 生态成熟，Arduino、MicroPython都能玩
• 功耗可控，休眠时微安级别

有人可能会说，用STM32不是更稳定吗？没错，STM32确实稳，但你要做远程通知还得加WiFi模块，成本上去了，开发也复杂了。ESP32在物联网场景下，性价比确实高。

漏水传感器选型：

这里有个坑，我踩过。市面上常见的漏水传感器有两种：

• 电阻式：两根裸露的铜线，遇水电阻变化。便宜，但容易氧化，用几个月就不准了
• 电容式：检测介电常数变化。寿命长，但贵一点

我建议用电容式的。虽然贵几块钱，但省心。你想想，天窗漏水检测器装上去，谁没事去拆下来维护？一次装好，用个三五年不出问题，这才是产品该有的样子。

电机驱动方案：

天窗的开关，一般用直流减速电机。驱动芯片我选L298N或者TB6612。L298N便宜但效率低，TB6612体积小、效率高。如果天窗比较重，建议加一个蜗轮蜗杆减速器，这样停电时天窗也不会自己掉下来。

通信协议选择：

远程通知这块，我选MQTT。为什么不用HTTP？你想想，漏水是突发事件，需要实时推送。HTTP是客户端轮询，服务器不能主动推。MQTT是发布/订阅模式，传感器一检测到漏水，消息秒到手机。而且MQTT协议轻量，ESP32跑起来毫无压力。

嗯，这里要注意一点。MQTT需要一个服务器（Broker）。你可以用公共的，比如阿里云、腾讯云的IoT平台，也可以自己搭一个。我个人建议前期用公共平台，省事。等产品成熟了，再考虑私有化部署。

好了，第一章节的内容就到这里。说白了，项目背景和需求分析就是搞清楚三件事：痛点在哪、市场缺什么、咱们怎么做。把这些想明白了，后面的开发才有方向。下一章咱们开始动手搭建硬件电路，到时候我会把原理图、PCB设计、元器件清单都一一讲清楚。