不拆机不改系统：用HDMI-CEC与功耗信号让PS5联动全屋智能家居

你有没有遇到过这种傍晚：忙完一天，坐进沙发，打开游戏机，客厅灯却还亮着刺眼的吊灯，窗帘没拉，路灯直直照进来，音响还停在蓝牙配对模式，风扇呼呼地吹。于是你先扔下手柄去关灯、拉帘、切音源，等回到沙发上，游戏已经加载了一半。我第一次冒出做 AnyPS5 的念头，就是在这个场景里。当时我手头只有一台 PS5、一台普通电视、一个智能插座，外加一颗想偷懒的心。这个项目做下来，核心其实不是游戏，而是怎么让主机在不拆机、不改系统、不碰任何边缘操作的前提下，把“我正在干什么”这件事主动告诉全屋设备，然后由它们自动完成整个客厅的气氛切换。

如果你有 PS5，家里也攒了一些支持局域网或本地协议的智能家居设备，看这篇会比较合适。我会从为什么做、三条触发链路怎么选、事件怎么统一，到实测数据和踩坑过程都讲一遍。里面不会有任何需要动主机硬件的方案，也不会教你怎么去突破官方限制，因为这套系统压根不需要那类操作。

1. 家务活比游戏还多，于是我想让 PS5 自己“管理”客厅

先说痛点。一台游戏主机在客厅里，本质上是一个巨大的“状态源”：它开机、进游戏、放视频、切音乐，每一次状态变化都意味着用户的心流正在切换。但在默认情况下，这些状态几乎全部被困在 HDMI 线和主机自身里，和灯、窗帘、音响、空调完全隔离。

我最早的做法非常笨。买了一个红外遥控转发器，用手机 App 录下电视遥控器的信号，再编写所谓的“开机宏”。结果头一天就翻车了：红外转发需要对准设备，隔着茶几就失灵；而且主机进入休息模式之后，红外信号根本不会把它唤醒。后来我又试图靠“看功耗”来推断主机状态——这反而成了后面整个项目的重要起点。

所以做 AnyPS5 的第一原则就定下来了：不折腾主机本身，而是从它和客厅环境已经存在的接口里“偷”状态信号。HDMI-CEC 总线、局域网里的媒体广播、电源插座的实时功耗，这三样东西都不是什么改装方案，而是 PS5、电视和智能插座本来就会产出的数据。我要做的只是去读它们、翻译它们、再把结果变成一次联动。

1.1 我到底想要“联动”还是想要“改造”

联动的本质是：设备之间互相通知状态，再由自动化规则决定做什么。改造的本质是：让某台设备突破原有边界，去做它不能做的事情。AnyPS5 走的是前者。

这个区分非常重要。一旦想通了这一点，很多技术选型都变得好做了。比如那根 USB 转 HDMI-CEC 的适配器，它只是在总线上“旁听”，不会向主机发送任何指令；智能插座也不需要对 PS5 做任何改动，PS5 插上去照常用电，只是一个“电流采样点”；局域网里的状态监听更不用说了，纯粹是被动接收广播包。整个过程里，主机的系统、固件、保修状态全都不会受到影响，这是我最看重的地方。

1.2 项目做出来之后的体验长什么样

最终的效果是：我按一下手柄 PS 键开机，客厅顶灯在 3 秒内慢慢变暗，窗帘电机会自动拉到一半，音响切换成 HDMI 输入，低音炮通电，屏幕背后的那圈氛围灯带变成冷蓝色。如果我在深夜打开流媒体看剧，规则又会把灯光调成暖黄色、亮度压到 20%，窗帘全关，风扇转速降到最低。

这些听起来不复杂，真正难的是“识别得准”。主机开机了但只是进系统界面，和主机开始跑 3A 大作，对灯光的要求完全不同；手柄充电导致功耗升高，能不能别被误判成“游玩模式”？电视开机时 CEC 总线上一堆乱七八糟的信号，如何避免把主机“假唤醒”当成真实开机？这些才是 AnyPS5 这场实验里最有意思的部分。

2. 三条触发链路：不碰主机、不改系统也能拿到状态信号

为什么需要三条链路，而不是一条？因为没有任何单一来源能同时满足“响应快”“判得准”“覆盖全”三个要求。我把它们分成了三条线，各管一段：

2.1 HDMI-CEC 总线：最快的开关机信号来源

HDMI-CEC 本质上是一条跑在 HDMI 线里的低速控制总线。电视、游戏机、回音壁、机顶盒挂在同一条总线上，互相之间可以用标准指令通知“我开机了”“我切换到某个输入源了”“我收到播放键了”。

我在 Linux 小主机上插了一根 USB 转 HDMI-CEC 适配器，把它接到电视的另一个 HDMI 口上。这样适配器就像总线上的一个“吃瓜参会者”，能听到 PS5 发出来的开机关机广播，但不需要串接在主机和电视之间。PS5 开机时会发送 source on 一类的指令，关机或进入休息模式时也有明确的电源状态消息，这些标准指令非常干净。

这一链路唯一的麻烦在于电视。某些电视在自身开机时，会向总线广播一轮非常热闹的“设备上下线消息”，如果没有做去抖处理，中枢很容易把这些消息当成 PS5 开机。所以我在消费 CEC 事件时加了一条铁律：只有 “PS5 这个逻辑地址的设备，自己发出的电源状态变更” 才算有效事件，电视和其他播放设备的消息一律忽略。

2.2 局域网媒体广播：知道它正在播什么

PS5 在播放流媒体视频或音乐时，局域网里会出现符合 UPnP/DLNA 标准的媒体设备广播。简单来说，就是主机在告诉网络里的其他设备：“我支持媒体渲染，我正在播放某个资源，我是这个 IP 地址。”

我的中枢脚本会在局域网里监听这些广播数据，然后把来源设备的 MAC 地址和 IP 与 PS5 的固定地址做比对。一旦发现确实是 PS5 在播媒体，就更新当前状态为“媒体模式”。最大的坑是家里还有 NAS、智能电视、蓝牙音箱这些同样喜欢广播 UPnP 的设备，不做白名单的话，NAS 自己播放一部电影也会把我的客厅灯变成暖黄色。

关于这条链路，有一个现实情况要说明：不是所有 PS5 上的应用都会稳定地广播设备状态，有些游戏内的串流功能、某些第三方播放器可能不发广播。所以我把这条链路定位成“锦上添花”，用来区分游玩和看片，而不是作为开关机的唯一依据。

2.3 智能插座功耗轮廓：最独立的长周期判据

第三个链路是物理世界里最稳的判据。我在 PS5 的电源线上装了一个带功率计的智能插座，每隔 2 秒读一次实时功耗。按我的实测数据，不同状态的功耗范围大致是这样的：

• 待机/休息模式：约 1 到 3W
• 系统主界面：约 60 到 80W
• 观看流媒体：约 40 到 50W
• 运行高负载游戏：约 160 到 200W

因为功耗不会说谎，所以它成了最后的裁定者。流程是这样的：CEC 已经告诉我主机开机了，媒体广播告诉我说“好像在看视频”，但我不完全确定，于是把最近 60 秒的平均功耗拿出来比一比。如果功率明显超过游戏阈值，那就判定为“游玩模式”；如果功率不高，就保持“媒体模式”。

但这条链路有一个天生的延迟问题。功率变化不是瞬时的，高负载游戏一开始往往有很长的加载画面，功耗可能只在 80W 左右徘徊，需要观察一段时间才能确认。所以我从不拿单次读数做判断，而是用一个带时间窗口的平滑算法，积满 60 秒的读数再做模式裁决。

2.4 为什么我不选改造主机的路线

其实在项目早期，身边也有朋友建议走“改机”路线，说这样可以拿到更精细的系统状态数据。我坚决否掉了。原因很简单：第一，任何突破官方限制的方案都会让保修瞬间失效，后续系统一更新可能就变砖；第二，主机系统非常封闭，改动之后稳定性完全没有保障，我想要的是一套能长年累月跑下去的客厅自动化，不是折腾几天就重装一次的玩具；第三，只靠公开的 HDMI-CEC、UPnP 和功耗数据，已经能覆盖 95% 的使用场景，为一个灯光联动去冒这么大风险，完全不值。

这套原则也是 AnyPS5 这个名字的由来：它想让你的 PS5 变成“任意设备都能协作的家庭中枢”，而不是“任意折腾主机的破解工具”。

3. 事件翻译层：把原始信号变成一套统一格式的“省心事件”

三条链路拿到的原始数据长得完全不一样：CEC 是一串十六进制指令，局域网广播是 XML 格式的协议描述，功耗则是一串数字。直接拿它们去触发自动化，逻辑会乱成一锅粥。所以我在中间加了一个“翻译层”，把原始信号全部归一化成一套自己的事件模型。

3.1 先把所有信号抽象成四种事件

整个系统只有四种对外事件：主机上线、主机下线、游玩模式、媒体模式。上线下线由 CEC 主判、功耗辅助确认；游玩和媒体模式由功耗主判、网络广播辅助修正。每种事件都带一个置信度字段，方便自动化规则决定是立即响应还是再等等。

最终的内部事件格式大概长这样：

{ "source": "ps5-powermeter", "event": "mode.playing", "confidence": 0.92, "ts": "2025-11-16T20:33:12+08:00", "detail": { "avg_watts": 172, "sample_count": 30, "duration_sec": 640 } }

所有下游设备只认这四类事件，不关心它们是从哪条链路来的。这意味着以后哪怕我不再使用智能插座，换成读取另一套协议的数据，下游规则也完全不用改。

3.2 事件去抖与置信度：别被一瞬间的信号骗了

刚开始联调时，我犯过一个很经典的错误：收到 CEC 开机消息就立刻执行“开灯、拉帘、切音响”。结果电视开机、回音壁唤醒、HDMI 握手，全都在一瞬间给中枢发来一堆无关消息，灯光像抽搐一样闪了好几次。

后来我给每条链路加了去抖逻辑：CEC 事件必须满足“逻辑地址指向 PS5 且 500ms 内没有重复冲突消息”；功耗事件必须满足“持续 60 秒超过阈值”；媒体广播必须满足“来源 MAC 在白名单内且在线状态稳定 3 秒”。任何事件只有当置信度超过 0.8 才会真正对外广播。这个设计之后，误触发率从每天十几次降到了几乎为零。

3.3 消息总线：让全屋设备都来订阅，而不是挨个去控

统一事件有了，下一步是分发。我没有用云平台，而是在局域网内跑了一个 MQTT 消息总线，所有设备订阅对应主题。主机状态事件发布到anyps5/state，自动化引擎订阅这个主题来做场景判断；Web 面板也订阅它，用来实时显示状态；甚至我手机上的一个自动化小组件也能订阅它，在锁屏看到 PS5 正在跑哪个模式。

MQTT 的好处是主题结构天然适合这类事件流。每个事件带retain标志，新设备上线后立刻能拉到当前最新状态，不用重新等待一次事件发生。

3.4 一条规则是怎么把“正在打游戏”变成“灯变暗”的

自动化引擎我最初用现成的流式规则工具做，后来嫌太重，直接用 Python 写了一个极简状态机。核心逻辑就几句话：

def on_ps5_event(evt): if evt.event == "mode.playing" and evt.confidence > 0.8: scene.set("game") light.brightness(30) light.color_temp(2700) curtain.move(50) speaker.input("hdmi") subwoofer.power(True) elif evt.event == "mode.media" and evt.confidence > 0.8: scene.set("movie") light.brightness(20) light.color_temp(3200) curtain.close_all() fan.speed(1)

这里的关键是“场景”这个概念。我不去控制单个设备，而是先定义一个场景，再告诉场景里每个设备该做什么。AnyPS5 的自动化层只负责“判断现在处于什么场景”，设备层只管“按场景要求执行动作”，职责分得很清，排查问题的时候能迅速定位是判断错了还是执行错了。

4. 场景引擎与 Web 面板：让联动从实验变成日常

有了统一事件，只能算做好了“感知”。要让家里人愿意用，不觉得这套系统碍事，还需要一个稳定的场景引擎和一个随时能查看状态的控制面板。

4.1 场景引擎的设计：同一件事，早晚动作不同

同一个“游玩模式”，下午和晚上应该有不同的执行结果。下午阳光充足，窗帘不需要动，灯也不用开；晚上则要把亮度压低、色温调暖。我把场景引擎设计成“规则 + 条件判断”，所有场景都带有时间段、当前亮度传感器数值这些上下文标签。

举例来说，我家的“游戏模式”有两个版本：白天版只做一件事，把音响切到 HDMI 并打开低音炮；夜间版则会拉窗帘、把客厅灯光压暗、开启屏幕背后灯带。选择哪个版本，由事件里携带的时间和光感数据共同决定。自动化引擎会先把事件存起来，再结合上下文条件统一计算，而不是收到消息就无条件执行。

4.2 一个极简 Web 面板：状态一眼可见

我不喜欢一开 PS5 还要打开手机 App 调一堆参数，所以中枢上跑了一个极简的本地 Web 页面。页面只有三个区域：顶部是 PS5 当前状态（在线、离线、游玩中、媒体播放中）和最近一次状态变化的时间；中间是当前所有联动场景的执行记录，可以看到每条规则是命中还是跳过以及命中的原因；底部是一个临时开关，用来手动冻结某个场景，比如“今夜不拉窗帘”。

后端就是一个轻量 Python Web 应用，通过 WebSocket 和 MQTT 总线直接相连，任何状态更新可以实时推到浏览器。这样我不需要任何云服务，所有数据都留在局域网里。整个面板是给家里人用的，所以我不追求复杂功能，稳定、直观、不卡顿才是第一位。

4.3 网络层必须做对的几件事

这套系统极其依赖局域网，网络配置做不对，后面全是在踩坑。

第一件事，给 PS5、电视、中枢主机、智能插座设置 DHCP 静态绑定或者直接在路由器上绑死 MAC 和 IP。因为媒体广播白名单判断依赖 IP，IP 一变，系统就会把 PS5 当成陌生设备，什么都触发不了。

第二件事，交换机的 IGMP Snooping 要开启。多个房间的设备在订阅同一条多播媒体广播时，如果交换机的组播处理能力不行，会出现部分设备能收到消息、部分设备收不到的情况，排查起来极其折磨人。

第三件事，绝对不要把控制端口暴露到公网。AnyPS5 的家庭自动化功能只需要在局域网使用，远程我宁可单独做一套带认证的加密隧道方案，也不愿意把 MQTT 这种明文协议直接挂在公网上。省事的代价往往就是安全隐患。

5. 一周实测：延迟数据、误触现场和排障过程

空谈架构没有说服力，我专门统计了连续七天的实测数据。项目跑下来，每天平均触发联动 14 次，其中开关机联动 8 次，游玩/媒体模式切换 6 次。整体正确率在 96% 左右，剩下几次误触，全都能追到很具体的场景。这些场景非常有代表性，值得写出来。

5.1 各链路的实测延迟与可靠性

成功率没有到 100% 的原因都出在边界情况。下面三个坑，是我这一周里印象最深的翻车现场。

5.2 坑一：手柄充电让功耗判断“演戏”

有一天我明显感觉不对：人坐在沙发上什么也没干，系统却从“系统界面”切到了“游玩模式”。查事件日志发现，原来是手柄插着 USB 线在主机上充电，同时我刚好打开了系统设置里的一个高占用界面，功耗短时间冲到 140W 以上，越过了游戏阈值。

这个误判暴露了一个问题：只看平均功耗不够，还要看功耗的波动形态。真正跑游戏时，功耗波形是持续走高的，而且会有比较明显的波动；而手柄充电叠加系统菜单，功耗虽然高但曲线太平了。我在功耗判断里加了一个“波动方差”参数，只有当平均功耗超过 130W 并且最近 30 个样本的波动方差超过某阈值，才判定为游玩模式。改完之后，这种场景就再也没有误触发过。

5.3 坑二：电视开机触发了 CEC 假警报

客厅里谁先开机是有讲究的。某次家里老人打开电视看新闻，结果我的客厅灯瞬间暗了下来，音响也自动切到 HDMI。排查后发现，电视开机时 HDMI-CEC 总线会先经历一轮设备枚举，某些电视会向总线广播一条“全设备电源状态请求”，PS5 收到后自动应答，这应答消息被我误读成了“PS5 开机”。

修复方式是做逻辑地址过滤和来源验证。CEC 总线上的每条消息都带有发送方的逻辑地址，电视机通常固定是某个地址，PS5 是另一个地址。我只处理来自 PS5 逻辑地址的主动电源变更消息，对电视发起的请求和枚举类消息一律忽略。同时，还要等主机在总线上连续应答两次以上才确认状态，避免单次握手信号造成假警。

5.4 坑三：NAS 上的流媒体加入了“观影模式”

有一次凌晨，客厅灯光突然自己变暖，窗帘也缓缓合上。我看了一眼时间，心想坏了，是不是哪里误触发了。查看日志发现，中枢收到了一条 UPnP 媒体广播，来源 IP 指向我家的 NAS，但 NAS 本身没有装任何媒体服务，怎么会广播？

实际情况是，家里某个电视盒子在向 NAS 里的媒体库请求缩略图时，触发了 NAS 上媒体服务模块的广播行为。这种广播并不是 PS5 发出的，但是因为之前白名单过滤不够严格，被放进了系统。后来我在白名单里明确写入了 PS5 唯一的 MAC 地址和 IP，并且把广播消息里的设备型号标识也加入校验，彻底杜绝了其他设备“蹭状态”的问题。想让联动不被莫名其妙触发，白名单过滤永远不能图省事只做一半。

6. 复刻这套系统需要什么：物料清单与实施次序

如果你也想在家里搭一套，我把整个物料清单和实施顺序整理出来，照着一步步来会比较顺。

6.1 物料清单

总预算主要花在 CEC 适配器和小主机上，如果家里正好有闲置旧笔记本，实际成本可以压得很低。

6.2 建议从哪一步开始

别一开始就三条链路全上。我最推荐的顺序是：先接智能插座功耗链路，用 48 小时记录 PS5 各状态下的功耗区间，顺便把消息总线和 Web 面板搭起来；这一步其实已经能实现最基础的“开机亮灯”了。然后再加 HDMI-CEC 链路，解决“响应不够快”的问题；最后再上局域网媒体广播，去优化“游戏和看片灯光氛围不一样”这种细节。

每加一条链路，都要单独观察 24 小时再接入自动化规则，否则一旦出现问题，你会分不清是链路误判、规则冲突还是设备执行失败。控制变量的思路，在这个项目里比什么都重要。

6.3 我最后的一点点体会

All in all——不，我不是想说“总而言之”。我在这个项目里学到的真正教训其实是：一台看起来完全封闭的游戏主机，通过它身边那些已经存在的标准协议，完全可以变成一整个家庭自动化系统的核心感知源。你不必去突破任何限制，只需要学会从正确的位置读取信息。

这套系统跑到现在最打动我的瞬间，不是我一开始设想的“灯光自动变暗”这种酷炫效果，而是有天晚上家人走进客厅，发现灯已经调到了合适的亮度，音响也处于正确的输入源，淡淡说了一句“还挺懂事的”。那一刻我知道，AnyPS5 已经从一次好奇的实验，变成了真正融入日常的东西。项目本身没有什么高深技术，但把这些原生能力组装起来，让家里每个人都觉得“它就该这样”，这大概就是自己做家庭自动化最爽的地方。