家里那台老式储水式电热水器其实早就该换了但一直拖着没动。直到去年冬天每次下班回家想洗个热水澡都得裹着羽绒服在浴室里等半小时才下定决心动手改造。我的目标很简单让热水器能联网手机上看得到水温下班路上提前一点打开加热到家刚好能洗。这个项目断断续续做了两三周花了两百多块钱最终有了一套比较完整的方案。整体思路是DIY一套基于ESP32的无线联网热水器控制系统用MQTT做通信手机或电脑网页上就能查看水温、控制加热开关。这篇文章就把这个IoT项目的完整过程写出来从需求拆解、硬件选型、电路搭接、固件逻辑到上层联动和问题排查尽量还原我当时的决策思路和踩坑记录。如果你是电子DIY爱好者或者手里正好有闲置的ESP32开发板想折腾点实用的东西这篇应该能帮你省不少弯路。1. 项目需求分析与整体架构思路1.1 先搞清楚这个物联网项目到底要解决什么问题任何一个IoT项目最忌讳一上来就堆硬件、写代码。我在动手前先把自己关在书房里列了一份需求清单把“我到底想让热水器变得多聪明”这件事掰开了想清楚。第一层需求是远程开关。冬天回家前能远程启动加热到家就有热水。这需要系统能通过手机APP或者网页随时下发开关命令。第二层需求是温度监测。如果我能在回家路上看到当前水温就能判断需不需要提前加热、加热多久。这需要温度传感器能够稳定、实时地把读数上报到云端或者局域网。第三层需求是安全联动。热水器是220V强电设备我不能只做一个简单的继电器开关就完事必须有防干烧、超温预警、断电复位这几道保险。这些需求整理完之后整个项目的功能边界就清晰了。它不是一个追求极致的智能家居作品而是一个“够用、安全、能长期稳定运行”的实用装置。这直接决定了后面的选型和代码编写方向——稳定优先功能其次。1.2 方案选型对比ESP32、树莓派还是现成智能插座确定了需求之后我纠结了很久选什么作为主控。市面上现成的智能插座、智能开关模块非常多像米家、涂鸦的生态产品100块内就能买到手机APP和语音助手全都给你配好。但问题是这些产品几乎没有温度采集功能无法直接告诉我当前水温。我想要的“看到水温再决定开不开加热”它们做不到。自研方案里主控有两条路树莓派和ESP32。树莓派性能强跑Linux随便装Python但功耗高、启动慢、价格这几年被炒得离谱做这种单一控制任务属于大材小用。ESP32则完全不同——双核240MHz内置WiFi和蓝牙价格十几块到三十几块功耗低毫秒级启动GPIO丰富做传感器采集和继电器控制刚刚好。实际体验下来ESP32确实是这个场景的甜点方案。它不像Arduino那样无线通信能力孱弱加扩展模块又贵又麻烦也不像树莓派那样重量级到离谱直接在Arduino IDE或ESP-IDF里写代码WiFi连上就能跑MQTT。我最后选了经典的ESP32 DevKitC V4开发板理由就一个资料最多遇到问题随便一搜就有答案对DIY项目来说社区生态比硬件参数更重要。1.3 整体数据链路设计这套系统的数据流大概是这样的温度传感器 DS18B20 通过单总线协议接在ESP32的某个GPIO上读取热水器内胆温度。ESP32通过WiFi接入家庭局域网以MQTT协议连接到消息服务器broker。ESP32每隔10秒上报一次温度数据同时订阅加热控制主题等待指令。手机、电脑或者局域网内的任何MQTT客户端通过发布消息的方式控制继电器开合进而控制热水器电源通断。如果家里有Home Assistant之类的开源智能家居中枢可以直接通过MQTT集成把设备接进去实现自动化和语音控制。这个方案最大的好处是解耦。ESP32只负责“读温度、控继电器、传消息”上层是手机直连、网页控制还是配合智能音箱完全看我自己想怎么玩后面扩展很灵活。2. 硬件准备与关键电路设计2.1 物料清单与选型要点这一节列一下我实际用到的物料每一项都标注了核心参数和选型理由。物料型号/规格数量参考价格用途主控ESP32 DevKitC V4ESP32-WROOM-32125元WiFi连接、逻辑控制温度传感器DS18B20 防水探头不锈钢封装3米线18元探测热水器内胆水温继电器模块5V 低电平触发光耦隔离继电器模块26元/个控制加热器通断冗余备用电源模块HLK-PM01 220V转5V AC-DC模块110元为ESP32和传感器供电显示屏SSD1306 OLED 0.96寸 I2C112元本地显示温度和工作状态外壳明装塑料配电盒约15cm×10cm18元收纳电路板绝缘保护导线等硅胶线、杜邦线、接线端子若干-10元电路连接按键微动开关21元/个本地手动开关、功能键选择DS18B20而不是更便宜的NTC热敏电阻是因为DS18B20直接用单总线协议输出数字信号不需要ADC校准和分压电路而且自带防水不锈钢探头可以直接贴在热水器内胆外壁或者插入测温盲管长期稳定性好得多。NTC虽然便宜但每一只都需要单独标定温度一变非线性误差就让人头疼DIY项目里我建议能数字就数字。继电器模块选的是低电平触发款这个有点讲究。低电平触发意味着在GPIO输出高电平时继电器不动作只有拉低才闭合。这么设计的原因是考虑到ESP32上电瞬间GPIO状态不确定如果误触发高电平采用高电平触发的继电器可能瞬间吸合一下在有强电负载的情况下这是安全隐患。低电平触发搭配上拉电阻能在一定程度上降低上电误动作的概率。2.2 温度传感器接线与测量原理DS18B20的接线是我整个电路里最简单也最容易出问题的一环。它只有三根线红色接VCC3.3V或5V都行黑色接GND黄色或白色是数据线需要接一个4.7kΩ的上拉电阻到VCC。关键点在于这个4.7kΩ上拉电阻很多人第一次接DS18B20时容易忽略它。没有上拉电阻数据线在通信间隙处于浮空状态读出来的温度经常是85℃或者干脆是-127℃。这个85℃是DS18B20的上电复位值不是真实温度看到这个值基本就能判断是上拉电阻缺失或者接线接触不良。我实际将传感器探头用导热硅脂涂抹后绑扎固定在热水器内胆外壳的金属表面然后外面再裹一层保温棉。这里注意不要贴死在加热管正上方的位置那个位置温度可能虚高影响判断。测量水温的物理方法很简单金属内胆导热性好外壁温度基本能反映内胆水温差个两三度属于正常。如果想要更精确的读数可以加一个测温盲管把传感器塞进水里去但那样安装复杂度会高很多。在代码里我用的是一线库OneWire和DallasTemperature。初始化后每循环读取一次温度中间加500毫秒左右的等待时间给传感器转换时间。这里还有一个细节DS18B20的精度默认是12位转换时间最长750毫秒读取太频繁会导致转换还没完成就拿到旧数据。稳定运行时期我设的读取周期是10秒完全够用。2.3 强电控制回路继电器与安全隔离设计热水器的控制是整个项目中风险最高、最不能马虎的部分。原装热水器的电源线是硬接在墙壁插座上的我的方案是做一个中间控制箱把220V电源先引到控制箱里经过继电器触点再送到热水器的加热管。具体链路是墙壁插座回路 → 控制箱进线火线L、零线N、地线PE→ 继电器公共端COM和常开端NO串联在火线上 → 出线接到热水器电源端。零线和地线直接穿透连接不断开。这样做的好处是即使继电器失效也不至于让热水器外壳带电地线始终保持通路。我用的是双继电器方案两个继电器的触点串联在一个回路里。这在普通DIY项目里看起来有点多余但我的考虑是万一某个继电器的触点因为电弧或过载烧结在一起无法断开时另一个继电器还能执行断开命令。热水器是长期大功率负载我家这台标称1500W触点在切断电流瞬间产生的电弧对继电器寿命影响很大。实际上关于继电器寿命问题后面还有故事我在第5节再详细说。控制箱内部布局我花了很长时间才设计好。强电部分220V交流接线、继电器触点端子和弱电部分ESP32开发板、OLED屏、传感器接线左右分区中间用一块塑料隔板分开避免任何一个螺丝掉落或者飞线破损的情况下发生短路。所有强电接线端子都用热缩管包裹线头压接牢固剥线长度合适不露铜丝。这是我在这个项目里最坚持的一条底线——强弱电彻底分离接线端每个都检查三遍再通电。2.4 供电方案与功耗优化ESP32本身的工作电流在WiFi开启时能到80mA甚至更高偶尔峰值能冲到240mA如果用充电宝或者USB充电头供电当然可以但既然已经要打开220V接线了我觉得最好在控制箱内部做一个AC-DC电源模块把220V直接降成5V给主控供电这样整个控制箱只需要一根进线、一根出线外观干净也少一个外挂电源适配器。我选的HLK-PM01是灌封式模块输入85-265V AC输出5V/600mA体积小稳定性不错。这个模块的3W功率要算一笔账ESP32芯片跑WiFi平均功耗约0.4WOLED屏幕约0.1WDS18B20约0.005W加起来最多0.6W左右模块余量充足不会在长时间运行下发热严重。如果想进一步降低功耗可以在固件里做WiFi调制策略。比如在“非加热时段”每30秒只开一次WiFi上报温度其他时间进入调制解调器睡眠模式这样平均电流可以压到20mA以内不过我这个项目接的是市电功耗优化意义不大主要还是保障响应实时性。但是如果你打算做一个电池版的传感器节点这个思路值得借鉴。3. 固件开发与联网通信实现3.1 开发环境与工程结构软件部分我在Arduino IDE环境下开发理由还是那个资料多、上手快。ESP32的Arduino内核支持已经很成熟库管理里直接搜索安装就能用不需要像ESP-IDF那样配置一堆工具链。我需要用到的核心库有WiFi.hESP32 WiFi连接。PubSubClientMQTT客户端库。OneWire DallasTemperatureDS18B20温度读取。Adafruit_SSD1306 Adafruit_GFXOLED显示。ArduinoJson可选处理较复杂的MQTT消息负载本项目的消息非常简单可以不用。工程编码结构上我把代码分成了三个文件——主程序、网络管理模块、设备控制模块。虽然Arduino IDE不像真正的IDE那样支持多文件工程管理但用标签页功能也能实现模块化管理。这样做的目的是后面OTA升级时代码修改不会牵一发动全身。3.2 WiFi配网与断线重连机制WiFi连接是ESP32物联网项目的第一个坎。一开始我用的是写死SSID和密码的方式测试没问题后交给家人用结果路由器重启一次配置弄丢了就要重新烧录固件。所以后来我加入了WiFiManager自动配网库第一次上电时设备会打开一个热点手机连上去填WiFi账号密码设备自动保存参数并重启连接。之后即使换了路由器只需要按一下复位键重新配网不需要再连电脑了。断线重连也是自研固件必须处理的问题。WiFi断了如果不重连MQTT自然也会断开设备就彻底失联了。我写了一个网络状态机轮询检查WiFi连接状态如果发现没连上就尝试调用WiFi.reconnect()重试10次还是不行的话就重启ESP32。这不是偷懒而是ESP32在某些驱动异常情况下重启是恢复网络最简单有效的手段参考了家电设备的“断电重启”思路。WiFi连接成功之后我还会做一个网络时间同步NTP为日志和后续的定时任务做准备。这个同步只用一次秒级完成不影响整体逻辑。3.3 MQTT通信协议接入主题设计与消息格式MQTT是整个系统通信的骨干。我搭了一个开源的Mosquitto broker跑在家里的树莓派上但其实任何支持MQTT的broker都能用。ESP32端只需要配置好broker地址、端口、用户名密码然后订阅一个主题、发布一个主题通信就算通了。我的主题设计分两层发布ESP32 → brokerwaterheater/status/temperature消息内容为当前水温例如45.6。订阅broker → ESP32waterheater/cmd/setpow消息内容为ON或OFF。这种命名方式参考了一些成熟IoT平台的做法一级是设备id或设备类型二级是数据类型三级是具体属性。以后如果家里有多台设备可以轻松扩展成waterheater2/status/temperature这样的结构不会互相干扰。消息负载我只用了纯文本没有用JSON因为每个主题的语义已经足够明确纯文本最省流量、最容易调试。用命令行MQTT客户端或者ESP32串口监视器看日志时一眼就能看出哪条消息是温度、哪条是控制指令排查问题非常直观。只有当一条消息里要携带多个字段时才考虑JSON。ESP32端完整的工作循环是这样的上电初始化传感器、OLED、WiFi、MQTT逐一初始化。进入主循环每10秒读一次温度发布到MQTT刷新OLED显示。同时检查订阅主题的缓冲区收到开关指令就驱动继电器并把当前状态上报到另一个状态主题。每60秒检查一次WiFi和MQTT连接状态必要时重连。这整个逻辑用状态机的方式写代码结构清晰得多各个功能模块互不干扰。3.4 OTA远程升级不用拆外壳的固件更新方式做一个挂在墙上的控制箱最不想做的事情就是“刷机时拆下来、刷完再挂回去”。OTAOver-The-Air无线升级能在不拆机的情况下更新固件对后期维护太重要了。ESP32的Arduino库内置了ArduinoOTA支持配置回调函数之后Arduino IDE的端口列表里会出现一个网络端口编译完之后选择这个网络端口上传几秒钟就能完成固件更新不需要连接USB线。配置时设置好OTA密码防止局域网内其他人恶意刷机。OTA功能的代码量很小但有一个重要前提WiFi和网络必须正常。如果固件里WiFi逻辑有bug导致设备无法联网OTA自然就不生效此时只能拆机走串口烧录。所以我在OTA功能上线前先把WiFi重连机制做到尽量健壮确保OTA和正常业务逻辑在同一个任务里互不干扰。顺带提一句我这里使用的是本地局域网OTA如果你想让设备支持远程在线升级比如通过云平台推送固件那就需要把固件包传到某个HTTP服务器上ESP32下载后写入新的分区。这个方案更复杂需要涉及固件签名、安全校验、失败回滚等机制DIY场景一般用不上我这次也没做那么深。3.5 本地化控制接口与云平台对比如果家里没有搭建什么智能家居中枢只是想用手机控制那MQTT远程控制其实已经够用了——手机装一个MQTT客户端APP比如MQTT Dash往里填上broker地址、订阅主题、发布主题就能开关加热。但这种方式对家人来说门槛还是偏高界面也不友好。云平台方案如阿里云IoT、AWS IoT Core有免费额度可用官方也提供现成的手机APP或小程序SDK做出来的效果比较好。但接云平台需要把MQTT broker的地址、证书都配置进去还要处理设备影子、OTA策略、设备认这些概念调试复杂度成倍上升。我最后选择的是本地Mosquitto Home Assistant方案因为家里已经跑了一套智能家居平台HA的MQTT集成能自动发现设备直接在HA的界面上加一个“加热”开关卡片家庭成员用着毫无压力。要理解本地和云端的取舍可以这么比喻云端方案像是把家里的钥匙托管给物业你在外面也能让物业帮忙开门但一旦断网物业也进不了你家本地方案像是把钥匙挂在门口花盆底下全家人知道就行你在楼下拿手机连上家里的WiFi就能开门但出了门就无能为力。这两者不冲突可以同时做我的最终架构是本地优先、云端可选断网时至少家庭局域网内还能正常控制。4. 上层控制与场景联动4.1 手机APP直接控制前面提到MQTT客户端APP是最直接的控制途径。整个过程只需要配置以下几个参数Broker地址树莓派局域网IP例如192.168.1.100。端口1883无加密或8883TLS加密。订阅主题waterheater/status/状态waterheater/status/temperature温度。发布主题waterheater/cmd/setpow按钮类型设置为发送ON或OFF。配好之后APP界面上就能实时显示温度数值和电源状态点一下按钮就能开关热水器。实测下来从点击按钮到继电器吸合整个过程延迟约200-300毫秒这个时延在控制热水器这种场景下完全可以接受基本感觉不到延迟。如果你不是MQTT重度用户也可以不安装任何APP直接在浏览器里访问一个小网页页面里放两个按钮和温度显示通过WebSocket连接broker即可。网页控制的好处是任何设备都能用不需要装软件。我当时写了一个简单的网页控制台放在Home Assistant的侧边栏手机上收藏一下用起来效果还不错。4.2 智能音箱联动语音控制加热接入Home Assistant之后语音控制就是水到渠成的事。HA的MQTT集成会把我的设备自动映射成一个switch实体把该实体暴露给语音助手如小度、天猫精灵或HomePod通过HomeKit Bridge家人就可以直接说“打开热水器”或者“查询热水器水温”了。实际体验下来语音控制在特定场景下确实比手机方便很多。尤其是手上湿着在浴室里没法掏手机的时候喊一嗓子就能开加热这种幸福感是写在脸上的。不过语音控制也有需要留神的地方——误触发。如果家里有小孩或者电视里恰好有人喊“打开热水器”那可能就会让你的热水器提前开工。所以我在HA里设置了语音命令确认机制中等以上安全级别下执行前会要求二次确认。从纯技术角度看语音控制本身只是HA自动化的一环真正有价值的是把MQTT消息、HA实体、语音命令对齐的这个过程它能帮你对智能家居的抽象模型有更深的体感。4.3 自动化场景回家模式与恒温策略有了温度上报和控制接口各种自动化策略就可以上了。我配置了以下几条规则回家模式家庭成员手机连上家庭WiFi且定位进入某范围区域时如果当前水温低于40℃自动开启加热。预约加热每天固定时段比如下午6点到7点强制开启加热如果水温已达到60℃则停止避免反复加热。离家节能所有人离开家超过30分钟后强制关闭加热防止浪费。恒温策略这块值得一提。储水式热水器如果长时间保持加热状态不仅电费高还容易积累水垢。很多人以为一直开着最舒服但实测下来白天上班时段水温从60℃降到40℃的散热速度很慢约每小时1-2℃下班前提前一小时加热完全来得及。我试过几种策略之后综合用电和体验最后选了“预测式加热”而不是“恒温保温”一个月电费省了三四十度左右。这些自动化规则全部用HA的自动化编辑器配置不涉及写代码。最核心的一条触发条件是温度阈值判断配合水温上报周期10秒设置得当的话水温误差能控制在±1℃左右不会让热水器频繁启停。5. 实测数据、问题复盘与改进方向5.1 连续运行一周的数据记录系统稳定运行之后我记录了一组从早到晚的温度变化和加热启停数据。时间水温℃加热状态备注06:0046关夜间散热2℃07:3058开早间起床洗浴08:0062关达到目标12:0055关自然散热17:0048开下班预热18:0060关回家模式从记录来看一天内水温自然降幅在8-10℃之间加热一次约需30-40分钟达到60℃符合预期。WiFi和MQTT连接整周无断线设备功耗稳定在1W以下含电源转换损耗一个月电费增加基本可以忽略。但我也发现一个问题设定水温60℃之后热水器内置温控器会在水温达到后自动断开加热我的继电器却仍然保持吸合状态。这意味着即使系统侧已经“断电”热水器内部的温控器还是可能因为水温回落而自行启动加热。这算是预料之中的情况毕竟我控制的是热水器电源而不是内部的加热控制回路。要实现颗粒度更细的恒温控制需要直接改造热水器内部控制线但这个DIY项目我选择不触碰内部线路——万一弄坏内胆或者绝缘层后果不只是漏水那么简单。5.2 继电器触点的耐用性测试与替换继电器触点耐久性是我这个项目里踩过最深的一个坑。跑了大约10天之后有一天我打开控制箱想看看内部情况意外闻到一股淡淡的焦糊味。拆开继电器模块外壳一看触点表面已经发黑有明显的电弧烧蚀痕迹。问题根源在于——大功率热负荷切断时继电器触点在分离瞬间产生电弧即使在额定电流范围内频繁开关也会加速触点材料损耗。我那个标称10A的继电器带1500W负载按理说电流只有6.8A应该余量充足但经验告诉我继电器标称电流是按阻性负载在常温下计算的热水器加热虽然也是阻性但电源接通瞬间的浪涌电流可能达到稳态的几倍长期冲击下触点寿命会大打折扣。我最终把继电器升级为带密封式防电弧外壳的30A继电器模块同时把开关频率降下来。加热逻辑改为目标温度到达后不再立即断开而是继续保温等温度超过目标3℃再断电。这个策略听上去有点浪费电实际上利用热水器本身的余热极大减少了大电流通断次数触点寿命显著改善。5.3 从“能做出来”到“能长期运行”与工业级IoT的差距思考这个DIY项目做完之后我反而对物联网工程里的“生产级”要求有了更深的体会。自己做的系统能用但离工业级还差得远——比如我用的MOSFET和继电器是普通民用级没有冗余设计代码里没有看门狗重启之外的故障恢复机制WiFi密码过期后必须手动处理。这些在工业场景下全部有对应的规范和机制。一个典型例子是安全认证机制。我这套系统在局域网内用明文MQTT传输没做TLS加密如果家里有恶意设备理论上可以被窃听甚至注入控制指令。工业IoT平台强制要求双向证书认证、设备唯一密钥、消息签名就是为了杜绝这类问题。我在改造项目后续版本时至少打算在broker上启用TLS给ESP32配一把自签证书这样即使消息被截获也看不懂、改不了。另一个差距是数据可靠性。温度传感器如果松动或者引线折断我的固件只会在日志里打印错误继续上报一个异常值。工业场景下这类数据异常必须触发告警、自动尝试恢复路径甚至把设备切换到安全模式。这些思考也让我意识到DIY项目可以追求快速实现但该有的安全底线绝对不能省尤其是涉及强电、水、家庭场景时。6. 常见问题速查与排查技巧6.1 温度读取异常及排查现象可能原因排查方法温度显示85℃不变DS18B20初始化失败/断线检查数据线上拉电阻确认接线端子压接牢固温度显示-127℃传感器供电异常或数据线短路测量VCC与GND电压确认3.3V/5V供电正常温度波动剧烈传感器探头未贴合金属表面或处于通风处重新涂抹导热硅脂固定探头并包裹保温棉每次开机温度不同传感器损坏数据线干扰更换探头尝试缩短信号线长度或加屏蔽处理DS18B20最让人困惑的一点是如果信号线超过3米寄生电容可能导致波形变形读数容易出错。我的解法是使用屏蔽双绞线传输数据屏蔽层单端接地问题就消失了。6.2 WiFi掉线或MQTT失联处理设备长时间运行后偶尔出现“离线”这几乎是所有DIY联网设备都躲不开的问题。我的排查步骤按优先级排列先看ESP32板载LED和OLED显示如果显示IP地址正常说明WiFi是通的问题出在MQTT连接。再看broker端日志MQTT连接断开时broker会记录原因常见的错误包括心跳超时、客户端ID冲突。检查WiFi信号强度如果控制箱离路由器太远信号强度低于-70dBm就需要加中继器或者调整ESP32天线位置。我最终把MQTT的心跳间隔设成45秒保活时长120秒并在代码里加了“心跳丢失自动重连”的逻辑。还有一种常见情况是ESP32长时间运行后内存泄漏导致崩溃这个问题比较难排查解决办法是每隔24小时用esp_task_wdt做一次自动重启不影响日常使用。实际养成定期看日志的习惯也很有必要通过串口打印观察Heap剩余值的变化能提前发现内存泄漏。6.3 继电器异常与安全隐患排查继电器不吸合或者常吸不断是强电控制最危险的故障。我的处理原则是先断电再排查绝不带电操作金属端子。用万用表二极管档测继电器线圈两端正常应能听到滴答声并伴随触点通断声。如果线圈有电压但无动作说明继电器损坏或驱动三极管故障更换模块。如果继电器动作但触点无输出用万用表电阻档测常开触点闭合状态存在接触电阻过大或烧蚀的可能。安装完成之后每周进行一次继电器自检很有必要——通过App发一次开关命令然后人工到控制箱前确认动作声音和负载状态。自检虽然老土但确实是电站和工业企业都在用的基本操作家用场景反而容易被忽略。6.4 核心安全警告与合理预期最后我必须反复强调这个项目涉及220V强电所有接线操作都必须在断电状态下完成非专业电工请勿自行改装。如果你对电气安全没有把握建议先把这个项目当成“温度监测器”来做只采集水温不上继电器等自己有把握了再扩展强电控制部分。硬件和固件只提供控制信号不能替代正规电器的安全标准电热水器的防电墙、漏电保护器、地线这些原装安全配置一个都不能少。结合我自己的体会DIY项目的最大价值不是做出一个产品而是通过完整走一遍“需求→设计→选型→实现→维护”这个闭环把工程思维和细节意识训练起来。做热水器控制涉及温度传感、无线通信、强电隔离、异常处理几乎每个环节都能深挖一套做完很多IoT开发里的基础概念都被点亮了。7. 后续还能怎么玩这个项目做完之后我一直在想它还能扩展什么方向。如果你手里也有类似需求我这里有几个思路可以参考。第一是加电量统计。买一个非侵入式电流互感器如ZMPT101B或SCT-013串在进线端检测加热电流就能算出热水器的实时功率和单日累计用电量。数据上报到MQTT后HA里能直接画出电耗曲线配合定时场景做更精细的能耗管理。第二是做群组联动。比如太阳能热水器辅助加热场景当太阳能水温不足时系统自动启动电加热太阳能足够时完全关断电加热。这需要两个温度传感器、两套加热控制逻辑但原理和我这套一模一样。第三是换用带TLS加密的MQTT通信并接一个云平台作为外网控制入口。这样你在外面能控制同时家里断网时本地局域网控制也不受影响体验更加完整。这个项目的所有代码和接线图我都在持续整理后续可能开源出来。如果你也有做类似项目的想法或者在某个环节卡住了欢迎在评论区聊聊你遇到的问题我尽量把踩过的坑讲清楚。