ruvnet/RuView：WiFi 感知研究，先分清离线基准与真实硬件能力

原研究日期：2026-09-13；2026-10-13 核对修订。项目：ruvnet/RuView，MIT，处于 Beta 开发阶段。

WiFi 多径信号受人体活动影响，由 ESP32 节点采集并转成空间状态 — 图 1：WiFi 感知测量的是信号变化，不是拍摄透视照片。

这是什么

RuView 把 WiFi 的信道状态信息（CSI）当传感输入，研究存在、运动、生命体征和姿态估计，并连接本地自动化与 Agent。

比喻：不是给路由器装 X 光机，而是听房间里的“无线回声”怎么变，再用算法估计空间状态。可能受墙体、距离、频率、天线与布点影响；不是透视照片，也不是一块低价 ESP32 就能可靠完成医疗监护或替代摄像头的成品保证。

README 宣传低至 9 美元的节点，属于项目报价口径，不含多节点、主机、供电、校准与维护成本。普通路由器也不一定向软件提供所需 CSI。

为什么值得关注

感知与自动化连起来：采集、特征、模型、MQTT/MCP 有可研究的工程路径。
明确区分几种模型状态：离线数据集模型、早期设备模型和旧架构不是一回事。
有公开基准记录和源代码，可以核查数字的条件，不能只看 README 大标题。
可以不采集日常视频，减少一类数据暴露；活动、作息和生命体征推断仍是隐私信息。

删去“GitHub 前 0.01%”“工业级产品”“毫米波一定更准”等缺少一致证据的排名和结论。stars、forks 与模块数量不能证明感知有效性。

它怎么转：四层逻辑

触发层

优先用于获知情同意的科研、低风险房间占用实验、智能家居原型。老人监护、婴儿呼吸、病房告警等是高风险设想，不能仅凭模块名视为已验证用途。

核心层

ESP32 捕获 CSI，经特征提取和推理生成状态事件 — 图 2：从 CSI 到语义状态，中间仍要经过特征提取与推理。

采集：支持的 ESP32/CSI 硬件与固件提供无线测量，不能靠 Docker 凭空得到真实 CSI。
处理：幅度、相位、滤波与时间窗口产生特征；频段对应的生理范围不是实际测量准确率。
推理：按具体模型输出存在、活动或关键点，输出需带模型与数据来源。
事件：MQTT / Home Assistant 或 MCP 消费状态，分类名称不等于已经验证真实事件。
证明与存储：项目有 Ed25519 witness 记录等设计。数字签名不是数据加密，也不证明传感值真实或授权充分。
扩展研究：融合相机深度、mmWave 等路线不再是“纯 WiFi、全程无图像”路线。

输出层

Home Assistant 文档列每节点 21 个实体、3 个起步 Blueprint，并描述 Matter/HAP 等桥接。它们是集成与接口清单，不是 21 项独立可靠感知能力，也不是五大生态均经本文一键验证。

卡点层

硬件与固件匹配、信号质量、采样时序、房间校准、多人干扰、训练分布变化，以及演示数据被误认成实测。先辨认每个页面的数据源，再看漂亮的骨架或曲线。

它能做什么：HA 实体如何看

someone-sleeping、possible-distress、fall-risk-elevated 等是项目定义的推断状态名，不是睡眠分期、急症诊断或跌倒风险的医学结论。不能仅因面板出现数值，就认为它测到了可靠心率或呼吸。

关键能力指标

原稿数字	核对后应如何理解
MM-Fi 82.69%	项目报告的 torso-PCK@20、random_split 离线姿态成绩，不是家庭 ESP32 的准确率，更不是医学灵敏度
早期 cog PCK@20 3.0%	项目日志中 pose_v1 的特定留出集结果，与上行的数据、模型和评估设置不同，不能只用二者比值描述“工程精度下降”
encoder 82.3%	held-out temporal-triplet 指标，不能直接叫“存在检测准确率”
Pi 5 8.4ms	基准日志的 health 冷启动调用，含合成前向，不等于端到端人体姿态延迟
8KB 模型	某个量化 encoder 的大小，不代表全部姿态模型、运行时及固件都只有 8KB
<200ms 跌倒、约 5m 穿墙、节能 20-30%	不作为本文实证指标；缺少本次独立验证及明确应用条件

MM-Fi 论文原文的采集系统使用 TP-Link N750/Atheros CSI 工具、多天线与 5GHz/40MHz 配置，与单天线 ESP32 的输入条件不同。数据集成绩不能直接外推到任意家庭墙体、多人或实时部署。

还有一个文档与代码差异： README 的模型成熟度表仍写实时 cog 是 confidence=0 stub；但本次读取的 inference.rs 已有 safetensors 加载与真实前向路径，缺权重时才回退居中骨架。代码把 0.185 这个验证集 PCK@50 数值作为固定 confidence，而非逐帧置信预测。不能再断言“实时路径全部是 stub”，也不能据此声称端到端部署已经可靠。应同时核查权重、backend、输入和实际事件。

怎么升级：分三档

Docker 模拟数据演示与真实 ESP32 感知部署需要分开判断 — 图 3：能运行演示，不代表已经完成真实环境的硬件感知验证。

入门（零硬件演示）

当前 README要求 API token；原稿直接 run 的示例已不完整。下面只演示模拟数据入口，本文未运行：

docker pull ruvnet/wifi-densepose:latest
export RUVIEW_API_TOKEN="$(openssl rand -hex 32)"
docker run -p 127.0.0.1:3000:3000 -e RUVIEW_API_TOKEN ruvnet/wifi-densepose:latest
# http://localhost:3000；这是模拟演示，不是家中实测

镜像标签会变化，复现时应记录版本或 digest。删除未逐项核验发布身份的 pip install ruview / wifi-densepose 混用建议；同名包不能凭名称当成当前仓库的等价入口。

进阶（真实硬件）

按官方固件说明选择支持板型，核对 build、烧录地址与配置。先记录空房/有人场景，检查 CSI 来源、缺帧与误报，再尝试低风险的占用自动化。不承诺“30 分钟看到可靠心率”。

高手（模型与集成）

固定提交、权重和数据协议；使用独立时间段、人员、房间评估泛化；对误报漏报、退出条件与传感失效单独验收。MetaHarness 文档中的 doctor / guidance / claim-check 是检查工具，不是医学认证或现场效果证明。

场景迁移：三个方向

方向 1：有同意的家庭感知实验

研究占用或运动趋势，可与参考传感器对照。删除“婴儿呼吸暂停筛查可替代智能袜”“实验室级睡眠分期”的建议；本次没有临床证据或医疗器械适用证据。

方向 2：办公与商业空间原型

会议室占用与能耗联动值得试，但应告知采集目的、保留期限及访问人。没有测量基线不能承诺节能比例，也不能把酒店或病房视作无授权采集场景。

方向 3：Agent 的物理状态输入

本地语义状态通过 MQTT 进入 Home Assistant，通过 MCP 提供给 Agent 查询 — 图 4：自动化和 Agent 消费的是空间状态，感知误差仍要单独验证。

先用于“状态提示 → 人工确认”或可逆自动化。删除替代工业安全光栅、承担自动驾驶路侧安全感知的建议；研究原型不能直接接管人身安全联锁。

部署风险与收益

收益是无需日常视频也能研究空间状态，以及本地处理的可控性。风险是分布变化、多人分离、设备故障、健康数值误读及行为隐私泄露。接入云端家居或模型服务时还要重新核对数据流，不能宣传“隐私零妥协、绝不外流”。

项目元数据

维度	核对结果
仓库	ruvnet/RuView
许可	MIT
阶段	README 标记 Beta，硬件/API 持续变化
实现	Rust、TypeScript、Python、固件与多个可选模块，具体看对应路径
指标证据	项目日志与模型报告；不是本文独立复现或外部认证
动态数字	不保留过期 stars、forks、issues、仓库体积及全站排名

关键技术亮点

真正有用的是把“测到的信号、模型推断、接口输出、来源证明”分开，并允许核查局限。模块目录越丰富，越应逐项查输入硬件和验证状态；音频、相机或 mmWave 模块不能统称 WiFi 已实现能力。

一句话总结

RuView 的灵魂是“让无线信号变成可研究的空间状态”。值得研究，但别把演示、离线成绩和成熟监护产品画等号。

2026-10-13 资料核对说明： 实际浏览仓库，读取 README、姿态基准原始日志、inference.rs 与 MM-Fi 论文的采集/评估章节。本文未运行 Docker、烧录 ESP32、测呼吸/心率或复现任何基准；相关数字明确保留为项目报告，README 与实现差异亦已注明。