OpenClaw + Home Assistant:语音控制你的智能家

前言

前面几篇文章里，我们把OpenClaw部署上了服务器、打通了外网访问、接进了QQ，它已经是一位随叫随到的私人助理。但如果你家里也有一堆智能设备，大概率体会过这种割裂感：米家的灯、涂鸦的插座、Aqara的传感器，各管各的App；智能音箱听得懂固定口令，稍微换个说法就装聋；想做个自动化，又被可视化编辑器里的条件框绕晕。

Home Assistant（下称HA）解决了设备统一接入的问题，它是全球最流行的开源家庭自动化平台，能把几百个品牌的设备拢进一个入口。但HA自带的理解能力有限，规则是死的，人是活的。本文要做的，就是把HA的设备控制能力和OpenClaw的大脑接在一起：你说人话，OpenClaw听懂，HA执行，家里的灯、空调、窗帘、电视从此归一句话管。

一、Home Assistant与OpenClaw联动思路

1.1 为什么是这两个组合

先明确分工：HA管手，OpenClaw管脑。HA擅长的是连接——Zigbee、Z-Wave、Matter、Wi-Fi设备统统接进来，提供统一的实体体系和稳定的服务调用接口；但它对自然语言的理解基本停留在关键词匹配。OpenClaw恰好相反：它没有蓝牙，碰不到你家的Zigbee网关，但它背后是大模型，能理解上下文、能推理、能调工具，还会记住你上周说过空调喜欢开26度。

两者一旦打通，智能家居就从"背口令"进化到"讲道理"：你不用记"打开灯光实体light.living_room_main"，只需要说客厅有点暗。

1.2 双向通道架构

联动只需要两条链路，全部走HTTP，不需要任何额外硬件：

下行（控制链路）：OpenClaw调用HA的REST API。HA对每个用户暴露标准的REST接口，用长期访问令牌做认证，开灯、调温、查状态都是一个HTTP请求。OpenClaw用自带的exec工具跑curl就能完成，无需安装任何插件。

上行（事件链路）：HA把发生的事告诉OpenClaw。OpenClaw网关原生支持webhook入口（hooks），开启后在网关上多出一个带令牌鉴权的HTTP地址；HA的自动化在触发时向这个地址POST一条消息，OpenClaw就会收到通知并按配置唤醒对应的agent处理。门磁响了、水浸传感器报警了，都是走这条路。

1.3 部署前提

动手前确认三件事：HA已经跑起来（树莓派、NAS虚拟机或小型主机均可，官网提供丰富的安装方式）；OpenClaw所在服务器能通过网络访问HA的8123端口（同局域网最简单，跨网就按之前文章讲的外网安全链路走）；两边都建议配上HTTPS或至少走内网，因为后面要用到令牌。

二、Webhook与API调用配置

2.1 HA侧：创建长期访问令牌

登录HA网页端，点左下角自己的用户头像进入个人资料页，切换到安全标签，拉到最底部的"长期访问令牌"，创建一个并命名（比如openclaw）。令牌只完整显示一次，立刻保存到密码管理器。这个令牌等同于你的账号权限，只放在OpenClaw服务器的环境变量或密钥文件里，不要写进任何会被同步、提交的文件。

在OpenClaw服务器上验证一下连通性：curl带上Authorization头请求HA的/api/根路径，返回JSON里包含"API running"即通。再请求一个实体状态试试，比如/api/states/sensor.living_room_temperature，能拿到当前温度，说明读权限正常。

2.2 下行控制：调服务就是发一个POST

HA里所有控制动作都叫服务调用，格式统一为POST /api/services/域/服务名。开灯就是light域的turn_on服务，请求体里写实体ID和参数；brightness_pct参数控制亮度百分比，color_temp_kelvin控制色温。开关用switch.turn_on和switch.turn_off，空调用climate.set_temperature传温度值，窗帘用cover.set_cover_position传开合百分比，电视和音箱走media_player域。

多设备一次搞定也没有问题：entity_id传一个数组，"关闭全部灯"就是light.turn_off不带entity_id——HA默认作用于该域全部实体。每次调用后HA会返回执行结果数组，OpenClaw据此向你确认"已执行"还是"某某设备不可用"。

2.3 上行事件：打开OpenClaw的webhook入口

OpenClaw网关支持hooks配置，在配置文件里开启：enabled设为true，设一个专用的token（注意官方文档明确要求不要复用网关主密钥），path设为/hooks这样的独立子路径，再在mappings里定义匹配规则——比如路径含homeassistant的消息，路由给main agent处理并投递到你的聊天通道。安全上有几条官方红线：令牌只走请求头（Bearer或x-openclaw-token），不接受URL参数；webhook内容一律视为不可信输入；agent侧建议收紧工具策略。

配置生效后，HA里发生的事就能这样进来：门磁传感器触发门打开事件，HA自动化动作调用一个RESTful请求，把"时间、设备、事件"POST到OpenClaw网关的/hooks地址，OpenClaw的agent被唤醒，判断要不要通知你。凌晨两点开大门是异常，立刻QQ提醒；中午开阳台门晾衣服，安安静静不吱声——判断逻辑由大模型拿捏，这正是比纯规则自动化强的地方。

2.4 反向补充：HA的webhook触发器

HA自己也支持webhook触发器：在自动化里选Webhooks触发器，会生成一个/api/webhook/自定义ID的地址，无需认证即可触发该自动化。它的用途是让外部系统或手机快捷指令轻松触发HA内部动作。在我们的架构里它不是主链路，但有个巧用：把它作为OpenClaw执行复杂场景的"简化接口"——HA侧把"离家模式"封装成一个webhook入口，OpenClaw只需GET一下这个地址，场景照常执行，双方解耦。

三、自然语言控制家电

3.1 给OpenClaw写一份设备说明书

大模型要调对服务，得先知道你家有哪些实体。最简单的做法是在OpenClaw工作区写一个设备清单文件，把常用实体ID、所属房间、支持的服务和参数范围列清楚，再在工作区说明里告诉agent：凡涉及家电控制的请求，先查这份清单，再组装curl调用HA接口，最后把执行结果用一句话汇报。

清单不需要穷尽所有实体，日常高频的十几个就够；HA的开发者工具页面可以一键复制每个实体的ID。重要的是把语义写进去：客厅主灯实体是light.living_room_main，色温范围2700K到6500K，主人说的暖光就是下限——这些注释是让"人话"和"参数"对上号的关键。

3.2 从人话到指令的完整链路

现在在QQ里对机器人说：客厅有点暗，我想看会儿书。OpenClaw拆解意图：调亮客厅主灯到阅读亮度，顺便把色温调到偏白；它组装两个服务调用，主灯brightness_pct提到80、色温4000K，落地灯保持关闭；请求发出，HA执行，回执成功；机器人回复"客厅灯已调亮到80%，色温偏白，适合阅读"。整个过程两三秒，你没碰任何开关。

再比如有点冷这种完全没提设备的表达：OpenClaw先查室内温度传感器确认现状，发现19度，再看你设备清单里的偏好记录——空调制热24度，于是直接下发climate.set_temperature，并告诉你"室温19度，空调已开到24度制热，十几分钟能暖和起来"。理解、查询、决策、执行、汇报，一条链走完，这是关键词匹配永远做不到的。

3.3 多步任务一句话下发

设备清单之上，再让OpenClaw学会调用HA侧封装好的脚本，就能一句话触发一整套动作。比如HA里写一个movie_night脚本：关主灯、氛围灯调到10%暖光、电视开机、音量设为15、空调24度静音风。你在QQ里说"我要看电影"，OpenClaw调用script.movie_night，五个动作原子化完成。复杂编排沉淀在HA脚本里保证可靠性，自然语言入口留在OpenClaw保证灵活性，这是最省心的分层。

四、场景自动化设置

4.1 三层自动化体系

搭好链路后，家里的自动化建议分三层，各干各的强项：第一层是HA原生自动化，传感器直驱，本地毫秒级执行，负责"必须立刻响应"的事——人体传感器联动夜灯、水浸传感器直接关水阀，断网也要能用；第二层是OpenClaw定时任务，负责按时间表巡检、汇总、推送；第三层是两者协同，HA上报事件、OpenClaw带着上下文做判断再反向下发指令，负责"需要动脑子"的场景。

4.2 场景与脚本的封装原则

在HA里用scene（场景）定义设备的目标状态组合，比如"回家模式"是玄关灯亮、客厅灯亮40%、空调24度、窗帘打开；用script（脚本）定义带顺序和条件的动作序列。原则是状态用scene、动作用script，并把OpenClaw常用的都封装好、在设备清单里登记。这样大模型每次只需调用一个入口，出错率最低，HA侧调整场景细节也不用改OpenClaw的任何配置。

4.3 协同场景实例：有人开门

拿一个完整例子走一遍第三层：门磁触发"大门打开"，HA自动化先执行本地规则——晚上十点后开门就亮玄关灯，这步不依赖任何外部服务；同时自动化把事件POST到OpenClaw的hooks地址。OpenClaw被唤醒后做判断：查你今天有没有说过出门、看现在家里还有没有人在（人体传感器状态）、结合时段决定这是家人回家还是异常开启。正常就什么都不做，异常就在QQ里连发提醒并附上当时的门口摄像头快照。规则处理速度和智能判断质量，两头都占。

4.4 OpenClaw定时巡检

再加一个cron定时任务，比如每天凌晨跑一次：调HA的API把全屋状态拉一遍，检查有没有"空调开着但家里没人""门没关严""某传感器掉线超过一天"这类异常，汇总进清晨简报。第二天早上你会在QQ里收到：昨夜空调运行9小时建议清理滤网、书房窗户传感器的电池只剩12%。家居健康，一目了然。

五、语音指令示例大全

5.1 灯光窗帘类

开客厅灯；把卧室灯调到30%；灯太刺眼了（自动压暗）；换个暖光；我要睡了，留个夜灯；把窗帘拉到一半；全屋关灯。这些指令不需要任何固定格式，怎么说都行，说"氛围搞浪漫一点"它会去调低亮度加暖色。

5.2 空调温度类

有点冷；有点热；空调调到26度；开除湿模式；风开小一点；一小时后把空调关了；我半小时后到家，先把空调打开。最后这条会触发一个定时：OpenClaw记下时间，到点再调服务，人还没进门家里已经凉快了。

5.3 影音设备类

我要看电影；电视声音太大了；关掉电视；放点轻音乐（路由到音箱播放常听歌单）；暂停一下。配合前文的脚本封装，一条指令背后是一整套设备状态切换。

5.4 场景与安防类

我出门了（离家模式：全屋关灯、空调调26度节能、扫地机开工）；我回来了（回家模式）；晚安（夜灯模式+关闭电视音箱+明早七点叫我）；家里都关好了吗（OpenClaw逐项查询并汇报：灯全关、空调开着、门已锁）。查询类的价值在于你不用自己挨个App翻。

5.5 组合与条件长句

这是最见功力的一类：我要睡了，空调定时两小时，客厅的灯都关掉，明早七点半叫我起床——一句话四个意图，OpenClaw拆开逐项执行并汇总回执。还有带条件的：如果一小时后家里没人就把空调关了，它会安排一个延迟检查任务，到点先查人体传感器再决定执不执行。智能的含义，就在这些不需要你操心细节的地方。

5.6 语音入口

以上指令在QQ里既可以打字也可以按住说话：语音经STT转写成文字进入同一套链路，开车到家楼下按一句话"我到家了"，进门就是亮着的玄关和舒服的温度。结合之前文章配置的TTS，机器人的回执还能以语音形式播回来，全程动口不动手。

六、实际家庭场景演示

6.1 清晨模式

OpenClaw的cron任务在早上六点半启动：先调HA把卧室灯从0%渐亮到60%模拟日出（HA支持transition过渡参数），拉开电动窗帘，空调按日程提前调温。十分钟后，你的QQ收到早安简报：今天天气与穿衣建议、室温与空气质量、夜间异常巡检结果、今天日历里的安排。起床这件事，从闹钟刺耳变成了服务到位。

6.2 出门与回家

出门前一句"我出门了"，离家脚本执行，OpenClaw回执"已切换离家模式：8盏灯关闭、空调26度节能、扫地机已启动、门已上锁"。下班路上说一声"半小时后到家"，到家前空调先开、电饭煲启动；进了门一句"我回来了"，灯光窗帘音乐各就各位。你甚至可以让OpenClaw结合日历自动判断——工作日下午六点后检测到你回家，就主动切回家模式，一个字都不用说。

6.3 夜间安防值守

夜里是HA上报、OpenClaw判断链路最忙碌的时段：门磁、水浸、烟感任一触发，事件即刻POST进hooks。大模型带着上下文判断轻重缓急——轻微的记入清晨简报，异常的立刻QQ连发提醒，附设备、时间和当时状态。全家熟睡时，这两个系统在替你值守。

6.4 一句话总结日常

用一周下来，你会发现交互方式彻底变了：以前是打开五个App各点各的，现在是对着一个聊天窗口说人话。家里的设备状态、发生了什么、为什么这么执行，OpenClaw都能答上来，因为它既是执行者也是记录者。智能家居第一次有了一个能对话的总管家，而不是一屋子各自为政的遥控器。

总结

回顾整套方案：HA用长期访问令牌开放REST API，OpenClaw用exec加curl就能完成全部下行控制；OpenClaw网关开启hooks入口，HA自动化把事件实时上报，上行链路同样一个HTTP搞定；设备清单文件让大模型知道每句人话对应哪些实体和参数；HA场景脚本负责可靠执行，OpenClaw负责理解和决策；最后用三层自动化体系把速度、可靠和智能各归其位。整个过程不需要新硬件、不需要写一行正式代码，一台服务器加一套HA，一个晚上就能搭出雏形。下一篇文章，我们聊聊怎么让这位管家更懂你：日程、习惯与长期记忆的养成。