睡着关灯，起床开帘：RuView 与 Jev 的隐私友好家居方案

晚上，你躺下休息，房间里的灯慢慢暗下来；第二天起床，窗帘在你允许的时间打开；半夜起身喝水，亮起的只是脚边一盏柔和的夜灯。

这样的智能家居，需要知道一些生活状态，却未必需要持续拍摄卧室。围绕 RuView 的这条 X 帖子，我们想讨论一种更具体的方案：用无线感知提供线索，用 Jev 理解场景，再由家庭自动化程序执行住户允许的动作。

这是一份产品设计与接入思路。RuView 已有感知与集成代码，但下面的 RuView + Jev 联动并不是已经完成硬件验证的成品，也不是安装后即可获得的现成功能。

原帖演示与实际能力，要分开看

视频来自 @make_claude 的原帖，由本站提供播放并保留来源。画面展示节点、运动能量与人形骨架界面；它本身不证明感知准确率，也没有展示本文提出的 Jev 家居联动。

RuView 研究的是 Wi-Fi 信号在空间中的变化。CSI（无线信道状态信息）比“信号有几格”更细，可以为人员活动等推断提供输入；信号处理和专用模型负责把这些测量变成状态估计。项目仓库

这条路径依赖支持的设备和环境条件，普通笔记本网卡不能直接等同于完整 CSI 传感器。项目的自动模式在找不到硬件时还可能使用模拟数据，所以启动了仪表盘、看到了骨架或读数，都不能单独证明正在测量真实房间。用户指南

原帖中的演示可以帮助理解方向，不能替代设备配置、真实数据来源和现场误差记录。本文也不把帖文中的价格、准确度、健康监测或合规说法当成购买与部署依据。

分工：感知动作、理解场景、执行动作

日常说的“动作识别”，其实可以拆成三个问题：房间里发生了什么、这在当前生活场景里意味着什么、设备现在是否应该动作。

1. RuView 与传感器提供线索。 例如占用、运动变化和数据质量；具体能输出什么，要看实际硬件、模型和接入路径。
2. 程序整理时间与事实。 算好状态持续多久、数据是否过期、是否在允许时段，并读取住户偏好、灯光状态和手动操作记录。
3. Jev 在有限选项里判断场景。 例如从“准备入睡、仍在活动、夜间短暂起身、早晨开始活动、信息不足”中选择。它使用的是整理后的证据与背景，不负责从原始 Wi-Fi 信号直接计算人体动作。
4. 自动化程序决定是否执行。 只有通过权限、时段、数据质量和设备条件检查，才把允许的命令交给灯具或窗帘。

Jev 官方的 Choice、Score 和 Noul 用于对给定状态作结构化判断。其中 Choice 很适合从少量候选场景或处理方式中选择；输出仍需用真实家庭数据评估，模型给出的数值不能直接当成设备可靠性保证。Jev 官方介绍

这里的场景名称是我们设计的候选项，不是 RuView 已经提供的完整事件清单。已有 Home Assistant 集成也不能理解为首页所有能力都进入了同一发布路径。Home Assistant 集成说明

场景一：睡着以后，灯慢慢暗下来

设想住户事先开启了“睡眠自动化”，并设置了适用房间与时段。系统观察到房间持续有人、活动减少，再结合睡眠模式、最近是否手动调亮灯等背景，判断是否适合进入休息场景。

“长时间不动”只是一条线索，不等于已经睡着。 躺着看书、刷手机、伴侣仍醒着，都可能让直接关灯变得讨厌。想进一步区分人在床上还是坐在椅子上，可以按需要增加床垫压力、床边按钮等输入；这些是额外设备和方案选择，不是默认存在的 RuView 能力。

一个可尝试的动作顺序是：先渐暗，保留短暂取消机会，再关闭指定灯具。住户手动开灯后，程序暂停本轮自动关灯，避免人与系统反复“抢开关”。数据不足或多人状态冲突时，保持当前灯光。

RuView 本身已有睡眠相关的状态机实现。这个状态关闭也不代表已经醒来：源码会在检测不到人时立即关闭，或在活动持续增加 30 秒后关闭。若只需根据几个稳定阈值和持续时间处理，直接使用规则可能就够了；Jev 更适合处理“今天要读书”“伴侣还在工作”等文本偏好与例外。睡眠状态机代码

场景二：早上起床，再打开窗帘

开窗帘应当比“检测到一次运动”多几步判断。我们建议同时检查：是否进入住户允许的清晨时段、是否有持续活动、是否启用睡懒觉或遮光模式，以及是否有人仍需休息。

当前 Home Assistant 文档明确说明，bed_exit 尚未由感知服务发布，依赖它的起床蓝图也暂时不会触发；本文开帘流程需要另行接入可靠信号或用户确认。当前起床蓝图的限制

Jev 可以在这些条件下选择“建议开启早晨场景、继续等待、信息不足”。实际开帘幅度与速度由住户预设，程序再核对设备状态、控制范围和手动覆盖。遇到异常，保留原有状态，不连续重试发出动作。

多人卧室尤其需要谨慎：无线占用估计不应被直接当成“识别了某个家庭成员”。无法确认其他人是否仍在睡觉时，可以改为按钮确认或保留既有定时规则。判断“早晨开始活动”也不意味着系统已经验证了离床识别。

场景三：半夜起身，只亮夜灯

同样是活动增加，凌晨和早晨需要的响应不同。夜间模式下出现活动时，可以选择预先配置的低亮度路径灯，同时保持窗帘关闭；活动结束后再按规则延时熄灭。

若系统没有可靠的床区与房间定位，产品应称它为“夜间活动触发”，而不是宣称能准确识别“谁下床去了哪里”。这类简短、确定的灯光规则可以完全在本地运行；Jev 只在偏好、场景或例外需要判断时参与。

兼顾隐私，不等于没有隐私问题

不采集卧室影像，能够减少面孔、衣着和房间细节等视觉信息的暴露。但占用、睡眠线索和出入时间同样可能反映一个人的生活规律。没有摄像头，不意味着没有个人数据，也不能据此推断自动满足任何合规要求。

对于这份方案，我们建议把隐私做成住户能理解和控制的产品功能：

• 优先在家里处理。 原始无线测量留在本地；自动化使用当前所需的状态，默认不保存长期作息轨迹。需要排障时，再由住户选择限时记录。
• 只传判断所需的信息。 若选择托管 Jev API，可发送经过精简的事件和偏好，不附带姓名、地址或原始 CSI。即便如此，事件摘要仍可能透露生活状态，应让住户清楚知道哪些字段会离开家庭网络。
• 让共同居住者有选择。 提供访客模式、房间级开关和明显的暂停入口，让家人与访客知道感知何时开启、覆盖哪些区域。
• 把控制权留给人。 手动开关优先，自动化动作留有简短可读的记录，住户能看到触发依据并撤销相关场景。

这些是建议落实的设计要求，不代表 RuView 或 Jev 的现有安装已自动实现全部要求。若采用云端判断，断网时应继续保留本地规则与手动控制；不要把照明的基本可用性依赖在一次模型请求上。

如何把它做成能用的原型

可以从一个房间、一盏灯和一个清楚的场景开始。先确认硬件数据确实来自现场，再通过 MQTT 等接口接收现有事件，明确记录时间、来源、质量与缺失值。RuView 的桥接实现可作为理解事件转换的起点。MQTT 桥接代码

第一阶段只记录“系统本来想做什么”，请住户标记是否合适，暂不驱动设备。把简单规则与加入 Jev 后的建议放在相同回放上比较：不该关灯时关了多少次、被手动纠正多少次、反应是否太慢、数据缺失时是否选择等待，以及实际向外发送了什么。

达到事先约定的验收标准后，再开启可随时取消的渐暗灯光，最后扩展到窗帘等设备。评估目标应是减少打扰、保持控制权和减少不必要的数据，而不是让系统记录更多生活细节。

本文依据公开文档与代码撰写，核查日期为 2026 年 10 月 27 日。未连接传感硬件，未实测睡眠、离床或设备联动效果；文中的家庭自动化场景为建议方案。