上一篇我主要写的是体验：把 Home Assistant 接入 OpenClaw 之后，交互方式会比传统自动化自然很多。
这篇就更实际一点，专门讲三个问题：
怎么接
怎么配
安全怎么做
先说结论：如果你的 OpenClaw 和 Home Assistant 在同一个局域网，接入其实并不复杂。因为 Home Assistant 本身就有比较完善的 REST API，只要把访问地址和认证打通，再把常用操作封装一下，后面就能让 OpenClaw 通过自然语言去查状态、控设备、做联动。
一、为什么这套接法不难
很多人一听“AI 接智能家居”，第一反应是很复杂，像是要搞很重的插件链路或者特殊中间件。
其实未必。
Home Assistant 本身已经把最难的那部分做好了：
有标准化实体
有服务调用机制
有 REST API
有长期访问令牌
有自动化和脚本系统
所以从 OpenClaw 这一侧来看，核心工作并不是“重新发明控制系统”，而是：把 Home Assistant 已经有的能力，通过 HTTP 接口接进来，再封装成适合 AI 调用的 skill。
换句话说：
Home Assistant 负责设备和状态
OpenClaw 负责理解你的话，并决定该调哪个接口
二、接入前需要准备什么
如果你想把 Home Assistant 接进 OpenClaw，最少需要准备下面几样东西。
1. Home Assistant 的访问地址
这个最好是局域网地址，因为你本来就是内网部署，没必要一上来就暴露公网。
例如：
http://192.168.1.100:8123
http://homeassistant.local:8123
只要满足一个条件就行：OpenClaw 所在机器能访问到这个地址。
2. 长期访问令牌
生成方式很直接：
个人资料 → 安全 → 长期访问令牌 → 创建令牌
拿到之后，OpenClaw 后续调 Home Assistant API，就靠这个 Token 认证。
3. 你想让它管哪些东西
不要一上来就想“全都接”。更推荐先明确一个范围，比如：
灯光
开关
温湿度传感器
空调
自动化
继电器
燃煤炉相关实体
你先告诉系统“哪些能管，哪些不能动”，后面 skill 设计和权限边界会清楚很多。
三、怎么把 Home Assistant 接给 OpenClaw
如果你的 OpenClaw 和 Home Assistant 都在同一个局域网，最直接的方案就是：
把 HA 的地址告诉 OpenClaw
把长期访问令牌提供给它
说明你希望它接管哪些实体和能力
让它写一个专用 skill，把常用操作封装起来
这个思路的关键不是“让 AI 自己乱调接口”，而是让它先把常用操作整理成稳定能力，后面你再通过自然语言去调用。
你需要发给 OpenClaw 的信息
最少可以整理成这三项：
HA 访问地址：比如 http://192.168.1.100:8123
长期访问令牌：在 HA 里生成
可管理范围：比如灯光、传感器、空调、锅炉数据、自动化
如果你想让它更快上手，最好再补两类信息：
重点实体名：比如卧室空调、客厅灯、锅炉温度传感器
危险动作边界：哪些能直接执行，哪些必须先问你
你可以直接这么发
如果你懒得自己整理格式，直接给 OpenClaw 发一段类似下面的话就够了：
帮我接入 Home Assistant。
HA 地址是： http://192.168.1.100:8123
我会单独给你长期访问令牌。
你先帮我接管这些东西：灯光、开关、温湿度传感器、卧室空调、燃煤炉相关传感器。
先实现这些能力：查询状态、开关设备、调空调温度、异常提醒推送到飞书。
高风险动作先别直接执行，先问我确认。
如果你想一步到位，也可以再补一句：
顺便帮我写一个 Home Assistant skill，把常用操作封装好，后面我直接用自然语言调用。
这样它就知道，不只是临时调接口，而是要给你整理出一套长期可用的接入方式。
接入后你就可以怎么说
一旦 skill 和基础接口打通，后面就不需要每次都手动调 API 了，直接正常聊天就行。
例如状态查询：
客厅温度多少
卧室空调开着没
锅炉现在什么状态
灯是不是还亮着
例如设备控制：
把客厅灯关了
卧室空调调低一点
打开锅炉监控相关设备
切换到离家模式
例如自动化和提醒：
锅炉温度异常就发飞书提醒我
每天晚上汇总一次家里关键传感器状态
定时关闭客厅灯
这也是 AI 接 Home Assistant 最舒服的地方：接入过程偏技术，但接完之后使用方式就很自然。
四、接入后它能做什么
1. 状态查询
客厅温度多少
卧室空调开着没
锅炉现在什么状态
灯是不是还亮着
2. 设备控制
开关灯
切换继电器
打开或关闭设备
调整空调温度
切换模式
3. 传感器监控
温湿度数据读取
人体感应状态查询
门磁状态查询
燃煤炉相关数据监控
异常值检测
4. 自动化联动
温度异常时推送飞书
某个设备运行超时提醒
门窗状态异常提醒
某传感器触发后执行场景
5. 定时任务
定点开关设备
定时播报状态
定时检查锅炉数据
每天固定时间汇总某些实体状态
五、最直接的接法：REST API + 自定义 skill
如果按我的思路，最直接、最稳的一种方案就是：用 Home Assistant REST API，给 OpenClaw 写一个专用 skill，把常用操作封装起来。
这样做好处很多：
不用每次都让 AI 自由拼接口
常用功能可控
更容易做权限边界
出问题更好排查
更适合长期维护
这套方案里，OpenClaw 实际上只需要掌握几件事：
Home Assistant 地址
Token
常用实体或服务
哪些操作允许执行
然后 skill 里把常用能力封装成明确动作，例如：
查询实体状态
调用开关服务
调用灯光服务
调用空调温度调整
触发某个自动化或脚本
这个思路很重要：AI 负责理解意图，但真正执行最好还是走你封装好的稳定接口。
六、推荐的配置思路：先小后大
第一步：先做“读”
先别急着控制，先把查询跑通。
查温度
查灯状态
查空调模式
查燃煤炉传感器数据
第二步：再做“控”
控制动作建议从低风险设备开始。
灯
普通开关
非关键继电器
空调温度调节
第三步：最后做“联动”
条件联动
异常提醒
飞书推送
场景串联
定时任务
七、安全这块，真的别糊弄
1. 长期访问令牌别泄露
Home Assistant 的长期访问令牌，很多时候权限是比较高的。如果别人拿到了，轻则查询你家里设备状态，重则直接控制设备、触发自动化。
所以至少要做到：
不要把 Token 明文发到群里
不要贴进博客正文
不要截图时带出来
不要写进公开仓库
配置文件注意权限控制
Token 本质上就是钥匙。
2. 不要一股脑开放所有实体
建议优先只开放这些相对安全、常用的对象：
灯
普通开关
温湿度传感器
状态查询类实体
某些安全边界明确的脚本
而像下面这些，要谨慎：
门锁
安防相关设备
大功率设备
电热设备
关键继电器
可能造成安全风险的执行器
更稳的做法是：AI 不直接碰高风险实体，而是只允许它调用你预定义好的安全脚本。
3. 局域网部署本身就是安全加分项
你现在这个环境有个天然优势：OpenClaw 和 Home Assistant 都在同一个局域网。
这意味着你不一定要把 Home Assistant 暴露到公网给它访问。只要内网互通，很多风险就已经降了一截。
4. 把高权限动作做成“确认式”
如果某个动作风险比较高，就别让它一句话直接执行到底。更合理的方式是：
先识别你的意图
再反问确认
你确认后再执行
比如：
要不要关闭锅炉
要不要把全屋电源切成离家模式
窗帘要不要一起关上
八、这套方案适合谁
你已经在用 Home Assistant
家里实体和自动化已经有一定规模
你不满足于固定规则
你希望交互更像聊天，不像写命令
你能接受一点配置工作
你愿意自己把权限边界管好
如果你只是追求简单开关灯，那直接用传统 Home Assistant 其实就够了。
九、结语
从技术实现上看，Home Assistant 接入 OpenClaw 确实不算特别难。因为 Home Assistant 已经把 API、认证、实体模型这些基础都铺好了。
真正要想清楚的反而不是“能不能接”，而是：
准备开放哪些能力
怎么封装常用操作
哪些动作必须做安全边界
哪些事情让 AI 自主，哪些事情必须确认
想清楚这些之后，这套系统就会非常顺。
对我来说，它最有意思的地方不是“多了个控制入口”，而是让我第一次觉得，家里的智能家居系统不只是会执行规则，而是真的开始有点像“会协助你”的助手。
还没有评论，来说两句吧...