无管热泵统一接入Home Controller:分体式空调智能化实战指南

发布时间:2026/8/27 1:27:01
无管热泵统一接入Home Controller:分体式空调智能化实战指南 家里两台分体式空调一台卧室一台客厅体验却越来越割裂客厅那台支持手机App卧室那台只有遥控器。夏天在客厅设定好温度回到卧室还要摸黑找遥控器冬天从客厅走到卧室两套系统各调各的家里温差能差出三四度。后来被朋友安利用一套Home Controller把两台无管热泵Ductless Heat Pump也就是我们常说的分体式空调统一协调起来才算真正解决了这个尴尬。这篇文章想聊聊我在这套系统上的完整折腾过程包括为什么无管热泵很难统一控制、不同接入方案的取舍、我在Home Controller上搭建状态模型和自动化的思路以及实际跑起来以后踩过的几个比较典型的坑。如果你也在纠结怎么让家里的空调变“聪明”或者已经有智能家居系统但不知道怎么把多台空调管起来这篇文章应该能帮你节省不少弯路。1. 先搞清楚无风管热泵到底难在哪1.1 它跟中央空调、普通空调有什么不同国内说“无风管热泵”可能有点陌生但说“分体式空调”“壁挂机/柜机”大家就都懂了。这种设备最大的特点是室内机和室外机之间用冷媒管连接不需要铺设风道所以安装灵活、能效比高制冷制热都可以。跟中央空调风管机/多联机相比它胜在便宜和改造友好跟普通的电暖器、风扇比它又多了完整的压缩机系统控制复杂度完全不在一个量级。问题恰恰出在这里无管热泵本质上是一台热泵压缩机系统有制冷、制热、除湿、送风等多种模式加上室内机风扇转速、导风板角度、设定温度等一大堆参数逻辑远比一个灯、一个插座复杂。家用遥控器能做的事情其实很多但一旦想把它接入智能家居这些参数就全部变成了需要处理的“状态量”不能用简单的“开/关”来理解。更麻烦的是很多无管热泵为了节能和舒适内部还有自己的逻辑比如压缩机启动后需要做延时保护制热模式下会有化霜周期室内风机可能在你停机后还会继续吹一会儿。如果外部控制器忽略这些内部状态随意下发开关指令轻则温控不准重则影响压缩机寿命。这也是为什么“给空调接个智能插座”这种方案在普通电暖器上能用在无管热泵上却是行不通的它只能切断整机电源完全没有办法让空调进入正常待机后再停机长期下来对压缩机非常不友好。1.2 厂商私有协议是最大的分水岭如果你去翻各个品牌的空调说明书会发现一个残酷的事实几乎没有哪家厂商愿意公开自家空调的控制协议。红外遥控器的编码是私有格式WiFi模块的局域网接口也各不相同有些品牌的接口协议至今只能靠社区逆向工程才能打通。同一品牌内不同系列的控制方式可能都不一样更别说跨品牌了。比如我客厅那台支持通过局域网API获取运行状态而卧室那台就只有红外接收窗口完全没有串口或者局域网接口。如果不用一套统一的系统去兼容这些差异就会变成客厅设备归客厅App管卧室设备归遥控器管每天在两套逻辑之间来回切换这本质上还是回到了“手动控制”的路径上。Home Controller在这个场景里的价值我认为不是让某个品牌的控制更花哨而是把不同协议、不同品牌的设备抽象成统一模型然后让自动化逻辑只跟“统一模型”打交道。真正干活的物理设备可以是原厂WiFi模块可以是红外发射器可以是DIY网关但在Home Controller看来它们都是“一台空调”有温度、有模式、有风速、有开关状态。这就是我理解的“协调”二字不是取代遥控器而是把所有遥控操作收归到一个大脑里统一决策。2. 方案选型红外、原厂接口、还是DIY网关2.1 红外方案最通用但天生缺少反馈先说最常见也最便宜的红外方案。这是不少智能家居玩家的入门选择买一个带红外发射的智能音箱或者万能遥控器直接对着空调发射红外信号逻辑非常简单要把空调调成制冷24度就发一串对应的红外码。红外方案的优点很直观不拆机、不改线路、不依赖空调品牌只要是带红外接收的老空调基本都能用。缺点也非常致命没有反馈。发射器发出信号之后它并不知道空调到底收到了没有。如果空调正好处于信号盲区或者空调屏幕显示24度但实际因为遥控器没电池已经失灵发射器这边的状态记录和空调真实状态就会慢慢偏离我们管这叫“状态漂移”。实际使用中还有更隐性的问题很多遥控器上同一个功能有“开”和“关”两种完全不同的编码但红外方案通常只记录“发出过什么”不知道当前是开还是关。你早上通过自动化发送了一次开机指令晚上回家想再发一次要么让用户手动确认当前状态要么靠代码硬猜体验很难做好。我自己的建议是红外方案只适合“老空调 临时体验 预算有限”的场景短期用一用没问题但如果你认真想长期跑自动化尤其是带多台空调的联动场景尽量避开。2.2 原厂WiFi扩展模块接入最稳但平台绑架相比红外原厂WiFi扩展模块是另一条路。现在不少日系品牌和国产品牌的空调都能选配或者内置WiFi模块装上以后手机App可以直接控制空调。重要的是这类方案通常有完整的双向通信空调的真实状态、故障码、传感器温度都能被读出来不会发生“以为开了实际没开”的问题。从Home Controller的接入角度看原厂模块最大的价值在于“有真实反馈”。你可以看到当前室温、回风温度、设定温度、实际模式、风机转速甚至能耗数据这些信息是优质自动化的基础。比如我只有拿到“当前模式正在制热”这个状态才能判断是否需要在下一次自动化中先切制热再调温度而不是盲目发指令。但原厂模块也有个绕不开的坑平台绑架。部分原厂App需要通过厂商云服务中转如果厂商服务器不稳定或者你家里网络环境受限控制链路就可能出问题。更头疼的是有些品牌的原厂模块只允许一个控制客户端在线你自己写的自动化在发指令手机App再打开两边可能互踢状态同步也会乱。所以我的建议是选原厂模块之前先查清楚它的局域网接口是否开放、是否允许第三方读取如果只允许自家云和自家App那接入Home Controller就得多花一步处理不一定是零成本的省心事。2.3 自建网关用ESP32/ESPHome拿下控制权如果你是喜欢动手的玩家第三方/自制网关这条路会很有吸引力。国外社区里对Mitsubishi通过CN105接口、Daikin通过RTSP协议、Panasonic通过VIF协议等都有较成熟的方案很多是基于ESP32这类廉价芯片加上小型转接板实现的把空调的调试接口或者专用协议转成MQTT或HTTP再接入Home Controller。这种方案的好处是彻底本地化、可定制性强、不受原厂App和云端限制。我客厅那台空调目前就是用ESPHome配置的CN105接口读取的数据比原厂WiFi模块还多比如压缩机频率、热交换器温度这些折腾起来很有意思。缺点当然也很明显要接线、要焊接、要懂一定的电气常识还要会写一点YAML。我当时为了找到正确的引针定义就翻了几个小时资料好在社区文档足够详细。如果你第一次接触这块建议先在空调说明书和官方维修手册里找一下是否有预留的维护接口别直接拆机硬来。三种方案各有取舍我整理了一个简单的对比表方案成本是否有状态反馈可维护性适用场景红外方案低无通用但状态易漂移老空调、临时体验、预算有限原厂WiFi模块中有稳定但依赖厂商平台有原厂适配器且协议开放自建网关/ESPHome中高有社区维护、可定制爱折腾、追求本地化的玩家对于大多数人我建议先看自己的空调原厂模块能不能被Home Controller稳定识别不行的话再考虑红外或DIY别一上来就拆空调改造风险还是有点高的。3. 核心设计让控制器像管家而不是遥控器3.1 先建状态模型再谈自动化当你能把空调接进Home Controller之后不要急着写自动化第一步先把每台空调的状态模型建清楚。我用的Home Assistant简称HA里空调会被抽象成一个climate实体最关键的几个属性包括hvac_mode当前模式比如制冷、制热、除湿、送风、自动target_temperature目标设定温度current_temperature当前回风温度通常来自空调内机自带的传感器fan_mode风量档位preset_mode预设模式比如睡眠、节能、强力等。为什么强调先把状态模型搭清楚因为自动化脚本本质上是在“读状态 - 做判断 - 下发指令”这个循环里跑如果状态都不可信后面的逻辑就是空中楼阁。我自己踩过的一个坑是把“target_temperature”和“current_temperature”混在一起理解结果自动化判断写成“当前温度高于设定温度就制冷”但实际读到的current_temperature是空调内机附近的回风温度和人体活动区域的温度可能差不少。你以为是卧室整体热其实只是吊顶附近热。所以我现在坚持每台空调都配一个独立的温湿度传感器放在实际活动区域比如床头柜或者沙发旁边自动化判断优先使用独立传感器的数据空调内置传感器只作为参考。这样状态模型就变成“空调真实运行状态 房间真实温度”两层自动化不会再被空调传感器的位置偏差误导。3.2 防抖和回差给压缩机一点面子在自动化逻辑里有一条铁律我觉得值得单独讲不要频繁启停压缩机。空调压缩机启动时电流很大频繁起停既费电又伤机器很多厂商自己也设置了启动延时保护你发指令过去它内部可能还在倒计时。那怎么在Home Controller里避免这个问题答案就是“回差”hysteresis。举个例子我希望卧室温度保持在24度用传统接线方式写自动化可能25.0度就开制冷24.0度就关这时压缩机会频繁启动。正确做法是设定一个上下限范围比如23.5到25.0度温度升到25.0度再开机降到23.5度才停机中间这个差值就是1.5度的回差。回差越大压缩机启停频率越低但温度波动也越大回差太小则压缩机容易频繁启停。家用空调一般建议0.5到1度之间兼顾舒适和寿命。除了回差我还会在自动化里加“最小运行时间”和“最小停机时间”两个条件。比如压缩机启动后至少运行5分钟停机后至少等待3分钟才能再启动这样能把极端情况下的启停频率压下来。社区里的做法多半是用一个辅助变量记录最近一次启停时间然后在自动化条件里判断时间差虽然写起来繁琐一点但对设备保护真的很重要。3.3 用场景联动代替手动调温状态模型搭好了防抖逻辑也写了接下来才是Home Controller真正常态化的玩法做场景联动。我认为一个家用控制器最值得做的地方不是把遥控器上的按钮搬到手机上而是让空调根据环境、时间和人的活动自动调整。我目前常驻的三个场景值得分享一下回家场景门口的人体传感器检测到有人进屋Automatic触发后客厅空调先切到“自动模式”根据室内温度和室外温度决定制冷还是制热目标温度设为舒适温度风量设为自动睡眠场景晚上22点以后卧室空调切换到“睡眠模式”目标温度自动比白天高1到2度风量降到低档同时把室内机显示屏亮度调暗离家场景所有人都离开家后空调进入“节能模式”或者直接关闭但保留除湿模式在湿度传感器的触发下短暂运行防止家里太潮湿。每个场景都设置了一个input_boolean类型的开关方便临时关闭。比如周末在家开派对不希望一进门就触发回家场景直接把这个开关关掉就行不用删自动化。这种用“总开关场景条件”的架构比每个人回家都单独写一套“if else”的自动化要清晰得多排查问题也方便。4. 实操记录从装机到跑通自动化4.1 准备工作和硬件连接我这次的搭建环境是一台旧笔记本刷了HAOS当Home Controller主机客厅空调用原厂WiFi模块接入卧室空调用ESP32 DIY网关通过CN105接口接入。整套系统里额外配了三个温湿度传感器客厅、卧室、走廊和一个门窗传感器。硬件连接这一步重点说一下ESP32网关。Mitsubishi的CN105接口是一个4针或者更多引脚的维护接口一般藏在室内机右侧外壳下面需要拆开面板才能看到。接线前务必断电确认好引脚定义稍有不慎接反可能会损坏主板。我用的ESP32开发板通过一个电平转换小板和空调接口连接然后烧录ESPHome固件。接线本身不复杂但有几个细节容易翻车一是连线要牢固最好用带锁的端子别用杜邦线插两下就松了二是ESP32的供电要稳定我是用了一个5V USB电源单独供电没有从空调取电避免启停瞬间的电压波动把开发板搞挂三是天线位置尽量离开金属外壳ESP32的WiFi信号在空调室内机金属壳附近衰减很明显我第一版塞得太靠里结果经常断连。4.2 把设备接入Home Controller设备初始化完成后开始把它们接入HA。我客厅那台空调的原厂WiFi模块支持局域网API在HA里直接添加对应集成填上IP地址和账号密码实体就一次性全部出现了包括climate实体、还有能耗传感器整个过程十分钟搞定。ESP32那台就不一样了。ESPHome的配置文件需要自己写的我摘一段核心配置供参考climate: - platform: heatpump id: bedroom_heatpump name: Bedroom Heat Pump update_interval: 30s supports: - mode: HEAT_COOL - mode: DRY - mode: FAN_ONLY - mode: HEAT - mode: COOL visual: min_temperature: 16 max_temperature: 30 temperature_step: 0.5这段配置的作用是创建一个climate实体让ESP32通过CN105接口和空调通信。config里标明了支持的模式和温度范围实际空调的真实状态会定期轮询刷新每30秒一次。如果你也想复刻建议先去ESPHome官方文档的Heat Pump Climate页面确认你家的空调品牌和型号是不是在支持列表里不同牌子用的协议完全不同。写好后编译烧录ESP32会自动连上MQTT或原生APIHA里通过ESPHome集成就能发现实体。第一版刷进去之后我打开HA的开发者工具看到“Bedroom Heat Pump”实体下面开始滚动温度、模式、压缩机频率等数据的时候才确认接线和协议都没问题。4.3 自动化落地实例卧室夜间温控网络通了、实体有了最后就是写自动化。以卧室夜间温控为例我最终版的方案是这样的晚上十点到早上八点之间如果独立温度传感器测到卧室温度低于23度切制热目标设到24度如果高于25度切制冷目标设到24度中间的温度波动范围作为回差避免频繁启停。HA里用YAML写大概是这个意思automation: - alias: Bedroom night comfort control trigger: - platform: numeric_state entity_id: sensor.bedroom_temperature above: 25.0 id: warm_trigger - platform: numeric_state entity_id: sensor.bedroom_temperature below: 23.0 id: cold_trigger condition: - condition: time after: 22:00 before: 08:00 action: - choose: - conditions: - condition: trigger id: warm_trigger sequence: - service: climate.set_hvac_mode target: entity_id: climate.bedroom_heatpump data: hvac_mode: cool - service: climate.set_temperature target: entity_id: climate.bedroom_heatpump data: temperature: 24.0 - conditions: - condition: trigger id: cold_trigger sequence: - service: climate.set_hvac_mode target: entity_id: climate.bedroom_heatpump data: hvac_mode: heat - service: climate.set_temperature target: entity_id: climate.bedroom_heatpump data: temperature: 24.0实际跑起来你会发现这个自动化的精髓在于我用的触点是“超过25度”和“低于23度”但目标一直都是24度中间有2度的回差。如果写成“超过24度就制冷低于24度就制热”压缩机就会在24度附近反复横跳夏天夜里可能每隔几分钟就启停一次。这个错误我第一周就踩过当时空调压缩机的声音在夜里格外明显第二天就被老婆吐槽了。5. 常见的坑我替你踩过了5.1 状态不同步App显示和实际不一致这是所有接入方案里最容易遇到的问题。红外方案之所以状态漂移严重因为根本没有反馈即使有反馈的原厂WiFi模块如果同时被原厂App和HA控制两边可能各自维护不同的状态副本互相覆盖。我自己的解决方法是先确认“谁拥有最终控制权”。既然用Home Controller做自动化我就把原厂App从日常控制里退出了只在手动应急时才打开。HA里还会做一次定期轮询每5分钟读取一次空调真实状态如果发现和预期不一致就触发一次修正指令。加上断电事件处理比如来电后所有空调恢复默认状态时HA也能及时同步这套机制目前跑下来没有再出现过“系统觉得开了、实际没开”的情况。5.2 温控精度被空调内置传感器拖累空调内机的回风温度传感器通常装在机器进气口附近位置偏高。夏天开制冷时冷空气下沉传感器附近温度可能比人活动区域高1到2度制冷会过于激进冬天开制热时热空气上升传感器附近温度又偏高空调可能提前停机房间里还觉得冷。我在这个问题上纠结了挺久最后选择了“无视内置传感器”。自动化完全以独立温度传感器为准空调本身的target_temperature只是作为目标值下发至于它内部怎么判断尽可能不去依赖。这样虽然多花了一个传感器的钱但舒适度提升非常明显尤其冬季制热不会出现“房间明显冷但空调停机”的情况。5.3 厂商固件升级后控制失效原厂WiFi模块最让人头疼的一点是固件一旦自动升级原来开好的局域网API可能直接失效或者token变化HA连不上设备。我遇到过一次重启HA没反应排查了一圈最后发现是模块固件更新后不再响应旧版API请求。处理办法第一在厂商App里关掉自动固件升级能关就关第二定期备份HA实体配置和模块的接入信息第三给WiFi模块设置静态IP避免IP变化后自动化找不到设备。如果你用的是DIY方案基本不会遇到这个问题因为ESPHome的固件自己控制升级与否完全由自己决定这也是我越来越倾向DIY方案的原因之一。5.4 多台空调同时运行的“用电打架”这个坑比较隐蔽可能很多人没注意到。夏天极热的时候如果客厅和卧室两台空调同时制冷而家里电表容量有限总功率可能超负荷跳闸。Home Controller里可以做一个简单的功率限制逻辑监测总功率如果超过阈值自动把其中一台切到节能模式而不是全部关闭避免冷热交替带来的不适。我目前用的是HA里的energy dashboard加一个简单的自动化判断功率超过阈值时优先限制后开的那台空调。虽然听起来很简单但实际调试花了不少功夫因为空调的功率会随着运行状态变化制冷刚启动时功率高恒温后下降判断条件不能写得太死板必须加时间和延迟条件。6. 排查技巧速查出现问题先看这几项现象可能原因排查顺序自动化触发了但空调没反应空调处于保护延时先看实体状态确认没有pending指令空调实际运行但HA显示关闭断电/重启后状态未同步手动同步一次检查集成配置温度很平稳但压缩机频繁启停回差太小、目标太单一检查自动化触发的上下限差值制热时房间不热空调却停机内置传感器测温偏高换成实时活动区域温度传感器原厂App能控制但HA连不上厂商固件升级/API变更检查模块日志必要时关自动升级这套系统从最初“两台空调各管各的”到现在“自动跟着温湿度、人活动和时间调整”大概花了我两个完整周末的时间。整个过程里最大的收获倒不是省了每天按遥控器的几分钟而是理解了一件事空调控制这种看似简单的活儿一旦要交给自动化去管最重要的不是指令发得多快而是对设备真实状态的理解和保护逻辑的完善。最后再分享一个小技巧如果你也打算在Home Controller里做空调自动化尽量给每个自动化都加一个input_boolean总开关临时有客人来、开派对、或者周末想手动接管空调的时候直接关掉开关就行不用在一堆YAML里翻哪个节点要禁掉。我自己后来还计划把系统再接上电表的峰谷时段在电价低的时间段提前给房间做预冷预热反正控制逻辑已经跑通了剩下的大概就是继续折腾的乐趣了。