Yeelight on Bruce's 博客

让 Codex 用灯光叫我回来（二）：从多会话分区到 Micro 原生状态

Mon, 21 Sep 2026 00:00:00 +0800

在上篇里，我已经让 ROG 键盘和 Yeelight 挂灯跟着 Codex 的状态变色：工作时蓝色，需要我回答时橙色，完成后绿色，过一会儿再回到平时的彩色灯效。

这个想法来自 Codex Micro 的指示灯。我希望不用一直盯着聊天窗口，也能知道任务有没有结束、是不是在等我。

但真正用起来以后，我又想加一点东西：如果同时开着两个、三个对话，能不能让键盘分别显示它们的状态？如果 Codex 本身就能给 Micro 发送状态，能不能不再依赖 hooks？

于是，我和 Codex 又折腾了几轮。最直观的变化是桌面版真的出现了 Micro 的欢迎向导；最费时间的部分，却发生在它已经显示“已连接”之后。

封面是 AI 生成的概念插画，用来表达状态与灯光的连接关系，不是实机照片，也不作为灯效测试证据。下文的软件截图来自我的实际测试。

一块键盘，能不能看几个对话？

原来的整块变色很直接，不过只能给出一个汇总结果。我说的多个对话，包括主窗口里的任务，也包括 Codex 右侧打开的另一个对话。

最开始的想法很朴素：两个就左右分，三个就左中右，再多一些也可以继续分，但要有上限。每个区域显示一个任务的状态。

第一次测试时，颜色确实出来了，边界却不太对。后来按这台 G615LR 的实际键盘布局重新校准，去掉不适用的数字小键盘布局假设，三色分区才变得正常。空格这样的大键也需要单独考虑：一个物理按键只能显示一种颜色，不能因为它跨过两个区域，就把它当成两颗灯处理。

紧接着又遇到了一个问题：两个相邻任务都在工作，两个区域都是蓝色，看起来又连成了一片。

我们试过白色分隔键，也试过熄灯隔离带。我反馈过“三色正常，但同色区分隔不清”。后来我举了个例子：一个蓝区向左流动，另一个向上流动，会不会更容易区分？

这把问题从分区带到了动画。区域越多，每块越窄，灯光本身也越难读。能把颜色写进去，离“我扫一眼就能看懂”还有距离。

我想用官方动画，结果发现要分开看

流动效果做出来之后，我的感觉是卡。既然 G-Helper 的灯效看着很顺，能不能直接用它的方式？

这里需要把两种控制方式分开。

整块键盘的常亮、呼吸，可以给键盘发送模式命令，让设备自己运行效果。任意分区里的独立波浪，则需要更细的逐键控制。目前这条实现路径还没有验证出“每个任意分区都能独立调用固件波浪”的能力，所以不能把整板原生动画当成多区动画的现成替代。

软件逐帧发送也做过优化。一次短测里，旧逻辑的实际提交频率约为 6.20 次/秒，调整调度后约为 29.71 次/秒。不过这测到的是程序提交灯光数据的节奏，不是相机测出的 LED 刷新率，更不能代替我的肉眼反馈。

我后来更在意的是颜色是否清楚。任务提示不一定要一直动，尤其不能为了波浪把蓝色压得很暗。动画保留为探索方向，日常显示先回到容易辨认的常亮。

让桌面版真正认出 Micro

接下来，我提出了另一个要求：“我不想用钩子做这个。”

上篇的路线是读取 hooks 事件，再由 Hub 判断状态。这次尝试的是在 Windows 上提供一个兼容 Micro 通信的虚拟 HID 设备，让 Codex 桌面版本身发送灯光状态，再把它转给实际的 ROG 键盘和 Yeelight。

大致路径是：

Codex 桌面版
 ↓ Micro 灯光状态
虚拟 HID 设备与本地桥接程序
 ├→ ASUS HID → ROG 键盘
 └→ 本地 MIoT → Yeelight 氛围灯

起初 Windows 已经能看到设备，本地程序也能枚举到，Codex 却没有真正开始通信。继续检查后，发现还涉及桌面版筛选设备时使用的设备路径。调整虚拟设备的标识路径之后，欢迎向导终于弹了出来。

桌面版出现了 Micro 的欢迎向导。这里连接的是本项目的虚拟兼容设备，不代表我购买或接入了一台实体 Micro。

这个时刻很有意思：最初只是受到它的指示灯启发，现在终于走到了桌面版原本为它准备的状态通道。

不过，“原生”这个词也容易把几件事混在一起。在这里，我说的是状态由 Codex 的 Micro 通道发出；接收和转译仍然靠本地桥接，键盘仍然是 ASUS 的设备。它不意味着 ROG 键盘变成了 Micro，也不意味着分区动画就由 ASUS 固件自动完成。

这条路线涉及虚拟驱动和本地证书信任，也不是拷贝一个脚本就结束的普通配置。我把它当作自己这台机器上的兼容性实验，而不是已经适合所有人安装的通用方案。

欢迎向导能打开，不代表所有功能都实现了

向导里的智能体按键很贴合我最初想要的体验：六个位置，各自显示状态。截图里的图例包括白色空闲、蓝色思考中、绿色已完成、琥珀色需要输入、红色错误，以及关闭表示未分配。

我目前接的是灯光状态。截图里介绍的命令键、旋钮、麦克风，以及点击按键切换任务，都不能因为欢迎向导出现了，就算成本项目的功能。桥接程序也不会替我点击批准按钮。

设置页同样需要这样看：它显示已连接，能看到亮度和自动调暗设置，是通信接入的证据。但虚拟设备报告的“电池 100%”只是兼容信息，不能当作笔记本电池读数。

测试时的设置页：亮度为 100%，自动调暗关闭。设置值正常，仍然不保证实际键盘颜色足够明显。

还有一个限制：这条实现接收的是六个原生槽位的灯光状态，不是读取所有聊天内容、任务标题或者百分比进度。它不能无上限地把所有打开的对话铺到键盘上，也不能承诺槽位始终对应屏幕上从左到右的窗口位置。

接通之后，我看到的却是一整块淡蓝白色

接入成功之后，实际效果仍让我不满意。我先反馈“整块蓝”，后来又觉得颜色很淡，基本看不清，甚至像白色。

这次没有继续只看日志里的“发送成功”。我们做了一轮独立的硬件测试：先整块红色，再左蓝右橙，最后左红中绿右蓝。我确认这三种都看到了。

这至少说明键盘能显示明显的颜色，也能接受分区数据。但它只验证了输出路径，不能证明真实聊天状态已经显示正确。接下来还得把状态选择、颜色映射和显示方式一起检查。

此前的显示会把原生槽位里的白色空闲状态也带进键盘，加上浅冰蓝和亮度变化，视觉上很容易变成一片偏白的光。后来的日常策略改得更直接：

白色和关闭的槽位不再挤占键盘上的活动区域。
只有一个有色状态时，用整块键盘显示。
多个有色状态时，再做分区。
工作蓝改成更饱和的蓝色，RGB 为 35, 105, 255，先用常亮保证可见。

原始槽位数据仍然保留，改变的是呈现方式。至于相邻同色区域，目前还不能说已经完美解决，尤其不能把两区、三区通过测试，推成所有分区数量都清楚可读。

后来我又提了一个更直接的改法：把分界处的一条按键都点亮，不要只在顶部放一个白色标记。调整后的实拍里，两个相邻绿区之间已经出现了纵向白色分隔键。键盘每一排的位置有错位，大键也不能切开，所以它是一串沿边界排列的亮键，不是一条连续的灯带。

最新原图：左侧蓝色，中部与右侧绿色，白色按键标出两个相邻绿区的边界。这次改动后的代码测试为 110 项通过，照片记录实际显示效果。

写这篇时，我又拍了两张新版分区的效果。第一张能看到左右蓝色、中间绿色；第二张多了一块黄橙色，从左到右是蓝、黄橙、绿、蓝。和之前那种整块偏白的观感相比，这两张照片里已经能直接辨认出不同的颜色区域。

新版分区实拍之二：四块区域同时显示。照片里的黄橙色会受拍摄曝光和白平衡影响；两张静态照片只记录颜色与空间分区，不证明动画帧率，也不单独证明每个区域的任务对应关系。

真正询问时也单独试过。我在一次真实询问里确认键盘和挂灯都变成了橙色。这个反馈比手动发送一个橙色测试命令更有意义，因为它走的是实际交互链路。

另一组分区近照：左侧黄橙色，右侧蓝色。不同状态可以同时留在键盘上。

这张全景把询问窗口、键盘上的黄橙色区域和挂灯两端的橙光拍在了一起。比起只看设置页，我更想保留这种实际使用时的画面。

完成以后，我还是想回到原来的彩色

另一个让我直接要求改回去的地方，是任务结束后的灯。

我问：“运作完的灯为什么关了，还是和以前一样比较好。”

如果把原生槽位的关闭状态直接照搬到整个桌面，任务结束可能就把灯关掉了。但我平时用的就是彩色灯效，希望任务提示只是暂时覆盖它，而不是接管之后再把它熄灭。

后来的修正恢复了本地的完成保持：收到绿色完成状态后，保持三分钟，再恢复平时的灯效。键盘恢复 G-Helper 保存的灯效，Yeelight 恢复配置的空闲灯效。

沿用上篇的彩虹灯效实拍，展示我想保留的日常效果，不单独证明三分钟倒计时与自动恢复的全过程。

这三分钟也不能挡住新任务。同一位置如果又变成蓝色、橙色或红色，就立即显示新状态；重复收到同一轮绿色不会不断延长倒计时。保持期间收到白色或关闭，也不应立刻把完成提示切掉。

这里还有一个边界：如果根本没有收到绿色，只是从蓝色变成关闭，就不能擅自判断“任务完成了”，再编出一段绿色提示。

这一轮修改后的本地测试记录是 109 项通过。它验证了程序行为，但截至这篇记录，我还没有把完整三分钟的双设备实机保持、恢复过程当作已经验收的结果。长时间使用、重启后的恢复，以及多个真实任务同时变化，仍然需要继续观察。

我现在更想要一盏看得懂的灯

这一轮从分区开始，绕到了逐帧动画、虚拟 HID 和 Micro 状态，最后又回到了很简单的要求：蓝色得看得清，需要我回答时要提醒，完成后别马上消失，也别把我原来的灯效弄没了。

Micro 给我的启发一直没有变。我喜欢的是把任务状态放到视线边缘，不用频繁切回聊天窗口。至于是不是每个区域都在滚动、有没有复制出向导里的全部功能，反而没那么着急。

目前的版本已经能继续沿着原生状态接入这条路走，也保留了后续校准和回退的余地。我会先让它在自己的桌面上稳定工作，再决定哪些效果值得留下。

毕竟我想要的是它在需要的时候叫我回来，而不是让我一直盯着灯，猜它现在到底是什么意思。

留两张整理后的桌面照片

最后，我也给两张照片做了 AI 美化，整理曝光和背景，留作这篇的视觉记录。前面的原图仍然保留。美化版可能重绘按键字符、屏幕文字和局部细节，不用于核对按键映射、灯光亮度或软件界面。

让 Codex 用灯光叫我回来：CodexLightHub 的 ROG 与 Yeelight 实机记录

Tue, 08 Sep 2026 00:00:00 +0800

Codex 在后台跑任务时，我不想一直盯着窗口。更需要提醒我的时刻，是它已经停下来，等我回答一个问题。既然桌上已经有 RGB 键盘和挂灯，能不能让这些灯直接表示任务状态？

这个想法来自 Codex Micro 的状态指示灯。它用颜色告诉我 Codex 正在工作、等待输入还是已经完成，我也想让整张桌面有同样直观的反馈。最后做出来的 CodexLightHub，是一个运行在 Windows 上的 Python 小程序。它接收 Codex 的生命周期事件，再把状态发给 ROG 笔记本灯光和 Yeelight 挂灯的后方氛围灯。

这篇记录整理到 1.0.6。ASUS 和 Yeelight 两条链路已经接通，EZ80 仍停在只读探测阶段。本文中的灯光照片均来自实际运行效果，连接图只用于解释程序结构。

先确定灯光应该告诉我什么

最早的设想很直接：工作时蓝色，需要我时橙色，完成时绿色。真正用起来以后，才发现颜色背后的判断比变色本身更难。

例如，Codex 发起权限检查时，可能由自动审核处理，根本没有弹窗让我操作。如果每次都变橙色，我就会不断被叫回来，最后开始忽略它。

1.0.6 把规则收紧到了下面这样：

状态	当前行为
工作中	满亮蓝色；ROG 使用硬件呼吸形成动态起伏，Yeelight 保持静态蓝色
真实询问	`request_user_input` 调用前变成满亮橙色，回答后恢复蓝色
自动审核或后台权限检查	保持蓝色，不触发橙色提醒
本轮完成	满亮绿色保持 180 秒，再恢复日常彩色灯效
收到中断事件	满亮红色短暂提示，默认保持 4 秒
空闲	ASUS 恢复 G-Helper 保存的灯效；Yeelight 按配置恢复彩虹

蓝色：Codex 正在工作

橙色：等待我回答问题

绿色：这一轮已经完成

彩色：恢复平时的桌面灯效

这里的“完成”指当前一轮结束，不代表整个项目已经做完。红色也不能覆盖所有错误：当前安装器没有注册通用错误事件，Hub 只是保留了 Interrupt 的处理入口。

还有一个限制要单独说清楚。项目默认启用了 plan_stop_is_waiting，当收到带有 permission_mode=plan 的 Stop 时，会保守地显示等待状态。它是为部分计划确认界面补的启发式判断，不能证明屏幕上一定有弹窗。普通询问使用的是实际工具事件，这两条路径不能混为一谈。

一条很短的事件链

程序分成三层：Hook 接事件，Hub 判断状态，Adapter 控灯。

Codex lifecycle hooks
 │
codex-light-hook.cmd → hook.py
 │ UDP 127.0.0.1:17871
 ▼
Hub：按会话保存状态、去重、决定当前灯色
 ├── ASUS HID → ROG 键盘与机身灯光
 └── 本地 MIoT → Yeelight 后方氛围灯

hook.py 只挑出事件名、会话、轮次、工具名等少量字段，发送到本机回环地址后退出。提示词、工具参数、工具输出、回复正文和工作目录都不在转发白名单里。灯光程序也不输出允许或拒绝权限的决定。

硬件写入在 Hub 的工作线程里执行。挂灯连接慢了，或某个设备不可用，不应该让 Codex 的 Hook 一直等着。

同一时间开多个任务时，Hub 按下面的顺序选择灯色：

waiting > running > interrupted > completed > idle

因此，一个任务完成不会用绿色盖住另一个任务的橙色询问；只要还有任务在运行，整体也会优先显示蓝色。这意味着绿色的 3 分钟计时到了，不一定马上看到彩虹，还要看其他会话是否仍然活跃。

ROG：从没有设备的 REST 接口，走到 ASUS HID

这次使用的笔记本是 ROG Strix G16 G615LR，灯光由 G-Helper 0.279.0 管理。

最初的 Aura REST 探测没有枚举到设备，返回值是 5。我们随后试过 Windows Dynamic Lighting，又遇到了 PyWinRT 枚举接口的参数问题。但确认平时由 G-Helper 控灯后，主线就转向了它使用的 ASUS HID 通道。

G-Helper 的公开源码提供了实际设备控制实现。项目据此整理协议，再结合本机 G-Helper 日志确认目标设备，而不是只看到 ASUS 的厂商编号就发送数据。

本机核对到的参数是：

VID: 0B05
PID: 19B6
Aura collection: col04
Report length: 64 bytes

桥接层会同时检查 PID 白名单、配置中的允许列表、日志里的完整 HID 路径、报告长度和 Aura Probe 结果。检查不通过时，拒绝写入。

灯效写入沿用了三段报告的顺序：

5D-B3-00-{mode}-{R}-{G}-{B}-{speed}-...
5D-B5-00-00-00
5D-B4

上面是协议结构说明，不是可以直接复制发送的完整数据包。它也不代表所有 ASUS 设备都适用。当前配置默认只允许这次验证过的 19B6，换型号后应重新探测。

GHelperAuraBridge.py 提供 blue、waiting、complete、error 和 restore 命令。ASUS 的运行、等待和错误效果使用硬件呼吸模式，不需要 Python 持续计算每一帧亮度。四种任务状态都按 100% 亮度发送。

恢复灯效时，程序读取 G-Helper 保存的 aura_mode、aura_color 和 aura_speed，再发送对应模式。它不会修改 G-Helper 的配置。这恢复的是保存的日常设置，并不是对接管前任意瞬时灯光状态的完整快照。

Yeelight：55443 不通，仍然可以走本地 MIoT

挂灯是 Yeelight 显示器挂灯 2 Pro，设备型号为 yeelink.light.lamp42。这里控制的是背后的氛围灯。

最容易绕进去的地方，是把“Yeelight 设备”与“开放传统 Yeelight LAN Control”画上等号。本机测试中，传统局域网控制端口 55443 没有开放。这只能说明那条路径没有跑通，不能据此判定设备没有其他本地接口。

另一个障碍是登录。早期 python-miio/micloud 的密码登录在这次环境中失败，后面改用了 mihome-ctl 的米家扫码登录，取得设备的本地 IP 和 Token。这个工具用于完成设备信息获取；日常灯色切换由 CodexLightHub 的本地 MIoT 后端处理。

所以最终链路是：扫码取得凭据，然后通过本地 MIoT 控灯。它不需要每变一次颜色就重新扫码，也没有把米家账号密码写进 Hub。

在这盏灯上，氛围灯属性已经按下面的映射完成实机验证：

属性	SIID / PIID
开关	3 / 1
亮度	3 / 2
RGB 颜色	3 / 3
模式	3 / 4

颜色按 RGB 转成十进制值：

color = (r << 16) | (g << 8) | b

正常变色时，后端依次写入静态模式、颜色、亮度和开关。恢复日常灯效时则把模式放到最后写，因为写颜色可能让设备回到静态模式。此次验证中，最后写入 mode=1 可以恢复彩虹。

这里还有一个设备差异：ASUS 的蓝色运行和橙色等待灯效使用硬件呼吸，当前 Yeelight 后端则显示对应颜色的满亮静态灯效。两者表示同一个状态，动画并不完全一致。

Token 是设备控制密钥，只放在本地配置。文章没有附设备地址、Token、登录二维码或账号信息；如果分享工程，应使用 config.example.json，不能打包自己的运行配置。

真正费时间的是状态细节

Hook 显示完成，不等于灯光脚本执行了

Windows 包装命令曾是一个排查点。项目最后用 .cmd 包装器承接 Python 调用，避免在 Hook 字符串里反复嵌套引号。

安装器会备份并合并已有的 hooks.json，保留不属于本项目的处理器。最终版本还移除了本项目之前注册的 PermissionRequest 处理器，让自动审核不再触发橙色。

这套安装方式是在本机路径和 Codex 版本下跑通的。包装命令依赖路径格式，迁移到包含空格的用户目录时仍应检查，不能把一次成功当成所有 Windows 环境的保证。

“已完成”和“我已经看过”不是一回事

开发中一度参考 Codex Micro 的“完成且未读”思路，让绿色一直保持到下一次交互。用了一下，我又把需求改成了“过几分钟切回彩色”。

最后的配置是：

{
 "completed_hold_seconds": 180,
 "sticky_completed": false
}

新提示提交后立即回到蓝色，不必等计时结束。Hub 虽然保留了 MarkRead 和 Read 入口，但当前接入没有收到“用户已阅读回复”的事件，不能根据绿色是否消失判断我有没有看过结果。

橙色必须值得我回来

最后一次调整是把手工变橙色测试改成真正的询问弹窗测试。

先手工写入橙色，只能证明设备能接收颜色。真正调用 request_user_input、出现问题、回答后恢复蓝色，才能检查从 Codex 到设备的整条链路。开发记录里最终确认了“弹窗且橙色”，随后完成 1.0.6。

Hub 还处理了一个并行工具细节：已经在等我回答时，另一个工具先结束，不应把等待状态提前冲掉。只有匹配的询问结束，才应该回到运行状态。

目前完成到哪里

截至这次记录，已经完成 ASUS HID 写入、Yeelight 本地 MIoT 写入、双设备接入同一状态机、真实询问提醒，以及完成 3 分钟后的彩色恢复。最终开发记录报告 11 项自动测试通过，代码中的测试覆盖了状态变化、HID 构造与保护条件、MIoT 属性写入等部分。自动测试与实机变色是两类证据，不能互相替代。

EZ80 暂时只有只读 HID 探测器，没有写入灯光协议。当前项目也没有实现逐键显示多个任务、按某个键跳回会话，或者识别所有客户端弹窗。这些早期讨论过的想法，没有被写成已经完成的功能。

工程仍是围绕这台 G615LR 和这盏 lamp42 做的个人工具。设备断开、网络超时、G-Helper 与其他灯光控制器竞争，以及不同 Codex 版本的事件差异，都是后续使用时需要观察的地方。

对我来说，最有用的结果是：起伏的蓝色让我知道它还在工作，橙色提示有问题要回答，绿色短暂保留完成状态，然后桌面回到原来的彩色。这个小工具的价值，取决于这些提醒能不能对应真实情况。