Home Assistant 接入 MCP 后：我的智能家居终于不裸奔了

玩智能家居的朋友应该都有过这种体验：一开始兴致勃勃，买服务器、刷固件、写 Automations，感觉自己的家就是未来的钢铁侠豪宅。但随着时间推移，设备越来越多，逻辑越来越复杂，甚至连自己当初写的 YAML 到底在控制哪个灯都忘了。一旦出点小问题，排查起来能让人头秃，最后大多选择“重启 HA 解决 90% 的问题”，剩下的 10% 就这么将就着用。

Home Assistant 界面展示

我也是这种“摆烂党”的一员。家里的 Home Assistant 跑了好几年，核心诉求就是把各个牌子的设备整合进 HomeKit，顺便撒几个自动化脚本。但长年累积下来，设备冲突、逻辑死循环这种“技术债”越堆越高，真心没力气去一行行代码排查。

直到最近，我发现了一个新思路：让 AI 来帮我打工。

尝试本地 Agent 智能化配置

昨天调试本地 Agent 的时候，我顺手用 GLM 5.2 做了个实验。我把 Home Assistant 的部分权限开放给 Agent，告诉它我的需求——把家里那个一直没搞定的冷气伴侣通过 MQTT 接入。

说实话，效果惊艳。我把必要的配置信息丢给它，这货“吭哧吭哧”一会儿，居然真的把冷气伴侣的 MQTT 配置全部搞定，连 YAML 的格式和传感器参数都调好了。这种感觉就像是你本来准备自己通下水道，结果找个师傅几分钟就给你通得干干净净，那种舒爽感懂的都懂。

不过，凡事都有代价。亲测下来，GLM 5.2 确实具备干活的逻辑能力，但如果“约束”做得不够好，它有时候会动一些不该动的东西。有好几次我看着它生成的代码有点“不对劲”，赶紧强制打断，生怕它把我的灯光逻辑改成“蹦迪模式”。而且，如果 Token 不是免费白嫖的，这种试错成本其实不算低，修修补补挺烧钱的。

Home Assistant 通过 MCP 接入 ChatGPT 的效果展示

另辟蹊径：ha-mcp + ChatGPT 的丝滑体验

既然本地模型有点“不可控”且费钱，我开始寻找更省心的方案。这不，让我挖到了一个叫 ha-mcp 的项目。

这个项目的核心逻辑是利用 MCP (Model Context Protocol)，通过 HTTP 的方式直接把 Home Assistant 接入到 ChatGPT 的网页版里。

为什么这个方案更舒服？

1. 半自动化刚刚好：它不像完全自动驾驶那样让人心惊胆战，更像是个副驾驶。ChatGPT 可以读取 HA 的状态、服务调用，甚至帮你写 YAML，但执行步骤往往需要你确认。这种“人机回环”既效率高，又安全感拉满。
2. Token 消耗感人：如果你有 ChatGPT Plus 会员，通过网页版直接调用 HA 的接口，不需要像 API 那样按 token 狠狠扣费。对于我这这种清理陈年旧账的场景，简直就是白嫖福利。
3. 清理技术债神器：以前因为太乱而不敢动的自动化配置，现在直接把需求发给 AI：“帮我看下这三个自动化有没有冲突，并优化一下代码结构”。它不仅能找出逻辑漏洞，还能把那一坨像面条一样的代码整理得清清爽爽。

实际体验与部署建议

接入 ha-mcp 后，我花了一个下午把以前积压的几个“历史遗留问题”全解决了。比如以前因为设备重名导致的开关失效，以及复杂的温湿度联动逻辑，在 AI 的辅助下，原本需要半天的时间，现在几十分钟就搞定了。

对于家里也有 HA 但懒得维护的朋友，强烈推荐试试这个路线。虽然 AI 现在还不能完全替代人工（特别是涉及硬件层面的奇怪 Bug），但在配置优化和逻辑梳理上，它绝对是神器。哪怕你只是想偷懒不想写复杂的 Jinja2 模板，扔给它也是个不错的选择。

技术这东西，最终目的就是为了让人“更懒”地生活。既然有 AI 愿意背锅，何不让他来维护你的智能家居呢？