我家里那台用了五年的除湿机本来已经被我划入“凑合用吧”的范畴结果在回南天里连续三天水箱满溢、地板湿滑之后我终于决定把它拆了。拆开之后发现事情比我想象的简单——核心压缩机、蒸发器、冷凝器都完好坏掉的只是那颗廉价的机械湿度开关和发霉的浮子阀。与其花2000块换新不如动手把这块砖头一样的旧家电改造成一台真正属于IoT时代的设备。这篇项目记录不是教你把除湿机刷个固件换个壳那么简单。我走了一遍完整的改造链路从硬件拆机、控制板改线、ESP32主控接入、湿度回差算法、MQTT云端上报到OTA升级和App远程控制。如果你手里恰好也有一台“食之无味弃之可惜”的老家电或者你正在做传统设备智能化改造这篇文章应该能帮你省掉不少弯路。1. 传统除湿机的三个硬伤为什么非改不可先说清楚我为什么盯上除湿机而不是空净、加湿器或者风扇。除湿机这个品类在物联网改造的性价比上是最高的原因有三个。1.1 湿度控制的“盲操作”问题传统除湿机只有旋钮或者按键式湿度设定有的甚至干脆没有湿度显示只有一个“运行/停止”灯。这意味着你完全不知道当前环境湿度是多少、机器有没有在有效工作。我家那台湿控精度大概在正负10%RH左右标称设定50%RH实测会在43%到58%之间摆动。压缩机频繁启停噪音大、耗电高除湿效果反而不稳定。你可能会说买个湿度计不就完了。但湿度计放在房间这头除湿机在房间那头你要跑过去看了湿度再跑回来调机器本质上还是人肉反馈回路。IoT要解决的第一件事就是把这个反馈回路自动化。1.2 水箱满溢与排水难题除湿机最烦人的不是除湿效果差而是水箱满了。传统机器靠浮子开关触发停机满水之后必须手动倒水不然就会溢出来。回南天那几天我每天倒两次水一次是早上出门前一次是晚上睡觉前但下午的高湿时段机器经常因为满水停掉房间湿度又飙回去。这个问题背后其实是“无人值守”能力缺失。一台除湿机如果不能自动排水或者远程告警它就必须有人在现场。智能化的第一步不是加个WiFi模块而是让设备具备“能自己判断、能叫人处理”的能力。1.3 定时开关的粗放逻辑大部分除湿机只支持机械式定时器按下去就是几小时拔起来就是关。但不同季节、不同天气下除湿需求的曲线是完全不一样的。梅雨季早上湿度最高午后略降回南天可能是全天候高湿空调房里的湿度波动又和压缩机启停节奏强相关。理想的控制逻辑应该是目标湿度可配置实时监测、动态启停还能根据历史数据预判什么时候该开、什么时候该关。这套逻辑用机械旋钮没法做但用EP32加传感器集群几十行代码就能实现。2. 硬件改造方案不破坏原机电路的控制接入思路确定改造方向之后第一个决策点来了是直接做一台“智能插座”式的控制方案还是拆机改控制板。2.1 智能插座方案的局限与拆机方案的价值如果你只是想把除湿机变成“能用手机开关”那一个WiFi智能插座就能搞定几十块钱五分钟装好。但这种做法只能控制整机通断电没办法读取运行状态、没办法感知水箱状态、也没办法精确控制压缩机和风扇说白了就是一个带远程开关的定时器。我这次选择了拆机改造——直接绕过原机控制板的部分功能用主控板接管压缩机和风机的启停。改动不算大原机的变压器、整流桥、按键开关都保留我只在原控制板上并联接出三路信号压缩机继电器控制信号、风机档位信号、水箱浮子开关信号。这样既不破坏原机的安全保护机制又能实现全自主控制。2.2 主控选型ESP32-C3在成本和功能间的平衡主控我用了ESP32-C3这块板子的核心优势是支持WiFi和蓝牙5.0、价格不到十块钱、开发环境成熟Arduino和ESP-IDF都能跑、功耗也够低。做IoT改造其实没必要上树莓派或者全志A64这类Linux板卡一是成本高二是杀鸡用牛刀三是Linux启动太慢断电重启之后恢复时间太长。选型时可以考虑的参数对比主控方案WiFi支持开发难度成本启动时间推荐场景ESP32自带低约15元1秒内单设备控制、传感器采集ESP32-C3自带低约9元1秒内精简IoT节点功耗更优树莓派Zero 2W外接/自带中约120元10秒边缘计算需要本地推理Arduino WiFi模块外接中约40元1秒内教学原型不推荐长期部署实测下来ESP32-C3的信号强度在普通住宅里够用我放在客厅角落隔两堵墙连路由器RSSI稳定在-58dBm左右。如果你家隔墙多或者需要更远的通信距离可以接受稍高功耗。2.3 传感器布局与校准湿度采样不能只靠一个点湿度传感器选了SHT30温湿度一体I2C接口精度正负2%RH。比DHT22强不少主要是长期稳定性好不容易漂移。但这里有个容易被忽略的问题传感器的位置。如果把传感器放在除湿机出风口旁边读到的湿度会严重偏低因为出风口附近是被机器除过湿的干空气。我踩过一次坑第一版固件把传感器贴在机器侧壁结果机器刚启动20分钟控制逻辑就认为“已经达到45%RH”自动停机了实际房间湿度还有65%。正确的做法是传感器远离出风口和回风口最好安装在房间中部或者墙壁上通过一根三芯延长线把I2C的信号引出去。如果实在没条件外置放在除湿机顶部远离风道的位置也可接受但需要在固件里做数据平滑避免瞬时波动触发误判。2.4 继电器控制与水箱满水检测改造中最需要注意的细节压缩机和风机的控制我用了两个5V继电器模块单路10A触点容量。注意除湿机压缩机是感性负载启动瞬间电流可能是额定电流的3到5倍继电器的触点容量至少要有压缩机稳定运行电流的3倍余量。我家这台压缩机额定功率180W启动电流接近2A用标称10A的继电器完全没问题。水箱满水检测就更为关键了这里有个非常容易踩的坑原来的浮子开关是串联在控制板上的如果你直接把它断开可能影响到原板逻辑报错停机。我的处理方式是直接从浮子开关两端并联引出两根线接到ESP32的GPIO上通过上拉电阻读取状态。这样原机自带的满水停机保护依然有效同时主控也能感知水箱状态。改装接线完成后务必用万用表逐路测量电压确认没有短路再上电。我见过不少人在这一步直接烧掉主板就是因为图省事没做检测。3. 固件逻辑与联动策略湿度回差、排水预判与看门狗硬件改完接下来是灵魂部分——怎么写固件逻辑。这一部分决定你的机器是“能联网的普通除湿机”还是“会思考的智能除湿机”。3.1 湿度回差控制算法为什么不能死守一个阈值最开始我的代码逻辑很简单湿度大于55%就开小于50%就关。结果压缩机每五分钟启停一次噪音忽大忽小电费倒是小事机器寿命也受影响。原因在于湿度是一个缓慢变化但带有随机波动的物理量采样值天然有噪声你把它卡在一个不合理的窄区间里必然导致频繁触发。后来我加了回差hysteresis控制设定目标湿度50%RH回差设置为5%RH实际逻辑就是湿度大于55%RH开机小于45%RH关机中间区间保持当前状态不变。这样做的好处是压缩机两次启动之间的间隔不会太短实测稳定在30分钟以上机器运行平稳多了。如果你有更高追求还可以在回差的基础上增加PID控制算法但除湿机这种大惯性系统变量有滞后性PID参数调起来难度较大我实测过效果反而不如回差控制来得直接。3.2 排水预判逻辑别等水箱满了才告警满水告警是IoT除湿机的基本操作但更好的做法是通过逻辑提前预判。我增加了水箱水位与湿度下降速率的关系推断每次浮子开关触发之后记录从“除湿启动”到“满水触发”的累计时间结合当前湿度下降速率估算下一次满水大概在多久之后。比如设备发现最近三次从启动到满水的时间分别是4小时、3.5小时、4.2小时就会在满水前30分钟推送一条“预计水箱还有30分钟满了建议去清理”的消息到手机。虽然这个算法比较粗糙但实际体验比“突然停了推送告警”要优雅得多。3.3 断线重连与看门狗机制家电级稳定性的底线改造完的设备以后是要长年累月运行的WiFi断线、传感器无响应、网络抖动之类的问题都会遇到。如果控制逻辑卡死最直接的后果就是压缩机不停机可能造成过冷或者安全隐患。我做的第一道保护是硬件看门狗ESP32的看门狗定时器周期设置为60秒主循环里必须定期喂狗。一旦程序卡死或者死锁看门狗自动复位重启。第二道保护是任务看门狗所有外设读取任务必须在5秒内完成一次否则置位错误标志进入安全模式——强制切断压缩机和风机的继电器输出保证机器不会持续运行。第三道是WiFi断线自动重连逻辑采用指数退避策略第一次断线后10秒重连失败等30秒再失败等60秒最长间隔不超过5分钟。重连成功后立即上报当前的运行状态快照让云端恢复同步。这套机制运行两个月没出现过一次需要人工干预的卡死。3.4 核心代码逻辑参考这里给出控制逻辑的核心代码框架方便你自己改。// 除湿机主控逻辑Arduino框架ESP32-C3 void loop() { // 喂狗 vTaskDelay(pdMS_TO_TICKS(100)); // 读取湿湿度 readSHT30(temperature, humidity); // 水箱状态读取 bool waterFull digitalRead(FLOAT_SENSOR_PIN) HIGH; // 回差控制 if (waterFull) { setCompressor(false); publishState(water_full); } else if (humidity HUMIDITY_ON_THRESHOLD !compressorOn) { setCompressor(true); publishState(dehumidifying); } else if (humidity HUMIDITY_OFF_THRESHOLD compressorOn) { setCompressor(false); publishState(standby); } // 上报数据这里用5分钟聚合上报 if (millis() - lastReportTime 5 * 60 * 1000) { reportTelemetry(temperature, humidity, compressorOn, waterFull); lastReportTime millis(); } // WiFi断线重连 if (WiFi.status() ! WL_CONNECTED) { reconnectWiFi(); } // 喂狗 esp_task_wdt_feed(); }这里有一个细节想特别强调上报数据不要用固定周期5分钟上报一次已经足够。如果每秒钟上报一次MQTT消息量大云平台消费端压力大而且你的流量卡可能一个月就跑掉几百兆。这种海量遥测数据上报导致的平台压力在真实IoT场景里是会出生产级P0事故的——遇到过的人应该懂我在说什么。4. 云平台接入与OTA从本地控制到远程管理设备端能跑起来只是第一步真正的IoT改造还得有云端的配合。这一节聊聊我踩了几个版本坑之后定下来的方案。4.1 MQTT与物联网平台选型自建还是托管最开始我图省事用了一个公网测试MQTT broker用了不到一周就发现不可靠连接经常断、消息延迟大、断线之后消息丢失。后来认真比对了几个方案。方案费用稳定性难度适合场景自建EMQX云服务器服务器费用较高需自己运维中有技术基础、要完全掌控数据AWS IoT Core按消息计费有免费额度极高低同时需要设备影子、OTA Job等功能阿里云IoT平台按设备计费极高低国内网络环境好、生态完善涂鸦/米家等现成平台需要认证高低不折腾但灵活性受限我自己最终选的是AWS IoT Core因为在同一个平台上能同时处理消息订阅、设备影子、OTA Job和策略管理。尤其是我还需要跑OTA升级——这就是热搜里提到的AWS IoT OTA用户策略的典型应用场景。通过IoT Core的Job服务可以批量下发固件版本、查看升级状态、回滚异常固件。如果你只是想自己家里用不涉及大量设备和复杂策略用EMQX自建在技术难度上可能略高但也完全可行而且数据完全私有。4.2 设备影子机制让配置同步变得干净很多时候我们不需要设备毫秒级实时在线。比如远程设定目标湿度如果设备当时断网了你发的指令它收不到怎么办AWS IoT的设备影子Device Shadow就是解决这个问题的。设备影子的逻辑是云端的“虚拟设备”保存一份desired状态设备上线后通过shadow同步拿到最新desired并执行再把reported状态上报回去。我没用AWS上的托管shadow而是自己用MQTT的retained消息实现了一个简化版配置类指令发送到dehumidifier/config主题消息保留在broker上设备上线时订阅一次读到最后一条配置并执行设备执行完把实际状态发到dehumidifier/status。效果和官方shadow几乎一样但少了一层依赖自由度更高。核心就在于MQTT retained消息的巧妙使用。4.3 数据采集与告警别把自己埋在数据海里改造过程中会存下来温湿度历史数据、运行时长、启停次数、耗电估算等信息。但家庭场景真的需要每秒一个数据点吗不需要。我用的是5分钟聚合粒度每5分钟上报一次平均值一天288个点半年数据量也就几万条家庭自用数据库完全没压力。告警逻辑则是湿度异常比如超过75%RH持续15分钟、水箱水位满、设备离线超过10分钟分别推送提醒。推送通道用过微信测试号后来迁移到了邮件和Telegram Bot稳定多了。这里有朋友可能想直接用企业微信个人使用会涉及一些认证问题不太推荐。5. 实测数据与避坑记录继电器粘连、传感器漂移与离线风暴最后这部分是大量实测和踩坑经验含金量不比代码低。我按踩坑的严重程度排一下。5.1 避坑一继电器触点粘连可能是生死攸关的问题改造完第一周一切正常。第八天晚上手机收到“设备离线”告警我过去一看机器停了但压缩机还在嗡嗡响——继电器触电粘连了控制信号断了但主回路仍然导通。这是感性负载的经典问题。继电器断开瞬间会产生反向电动势在触点之间拉出电弧时间久了触点表面烧蚀、碳化最终粘连。解决方法是给继电器触点并联RC吸收电路也叫snubber电路用100Ω电阻串0.1uF电容焊在继电器输出端。另外频繁启停也会加速触点老化这也是我在前面强调回差控制的原因之一。5.2 避坑二长期高湿环境下的传感器漂移SHT30的标称精度是正负2%RH但在持续高湿环境85%RH以上运行两周后读数开始偏低。我记得某一天实测湿度75%传感器只读到62%导致固件误判“湿度已经达标”一直没开机。校准方法很简单找一个密封袋放一小杯饱和氯化钠溶液盐和水混合后保持相对湿度约75%RH把传感器放进去静置两小时然后读取校准偏移量在固件里做补偿。我后来还加了定期自动校准提醒每30天推送一次“该检查传感器了”。5.3 避坑三批量设备同时上报会导致离线风暴我帮朋友也改了两台除湿机加上自己家里那台一共三台设备。起初我把上报周期都设成“整点后第3分钟上报”结果三台设备同时连接瞬间的并发请求把本地路由器的连接表挤爆了所有设备全部掉线重连。这就是典型的“海量物联网数据采集”小规模翻版。即便只有几台设备没有做时间抖动jitter处理也会出现踩踏。解决方法是在上报周期里加上随机偏移每台设备生成一个0到60秒的随机等待时间避免所有设备同时上报。5.4 实测效果评估改造完成到现在两个多月我记录了几组关键数据指标改造前改造后湿度稳定精度正负10%RH正负3%RH以内压缩机每日启停次数40-60次15-20次每日耗电量估算3.2度2.1度水箱满溢事件每月约4次0次有提前告警需要人工干预次数每天至少1次几乎为0当然改造后相比原机也有短板比如启动速度略慢因为主控要先连WiFi不过这个影响很小因为除湿机的启停是以小时计的慢两秒启动完全无所谓。还有一个值得一说的事MQTT的遗嘱消息Last Will and Testament我一开始没配置结果设备异常掉线时云端完全不知道推送“湿度超限”但设备不工作也没人发现。后来补上了遗嘱消息设备断开时自动向主题推送“offline”状态告警体系才真正完整。总的来说这台除湿机的改造最大的收获不只是省了一台新设备的钱而是把整套传统家电智能化改造的路径完整跑通了——从拆机、选型、写固件、接云、OTA到真实环境长期运行、排错、优化每一步都有真实数据和事故教训打底。如果你也想动手改一台老设备我的建议是先别急着买传感器和开发板把你手上的设备拆开看一遍电路画一张接线图搞清楚哪些信号可以安全引出、哪些必须保留原逻辑再开始动焊。最后再分享一个小技巧改装设备时把原机自带的出风口挡板拆掉用一块亚克力板重新做一个上面预留好传感器和显示屏的开孔。这样既不影响风道又好走线后续维护也方便。我第一版就是没考虑到这个最后传感器线被挡板卡断过一次重焊了三次才稳定。