ruview

RuView é uma plataforma open-source de sensing por WiFi que lê Informaçãode Estado do Canal (CSI) de sensores ESP32 de baixo custo e converte reflexos de rádio em dados espaciais e fisiológicos — sem câmeras, wearables ou serviços em nuvem. Roteadores WiFi comuns irradiam ondas radioelétricas por um espaço; pessoas se movendo, respirando ou paradas perturbam essas ondas, e o RuView mede essas perturbações. O que reporta, segundo o README: presença e ocupação (incluindo detecção através de paredes, contagem, rastreamento de entrada/saída), taxa de respiração sem contato (bandpass 0,1–0,5 Hz no fase envoltória, 6–30 BPM) e frequência cardíaca (bandpass 0,8–2,0 Hz, 40–120 BPM), classificação de movimento e atividade, detecção de quedas com limiar de aceleração de fase mais debounce e cooldown (sob 200 ms). Também reivindica contagem multi-pessoa via normalização adaptativa P95, sensing através de paredes até ~5 m dependendo do sinal, fingerprinting RF ambiental, staging de sono com triagem de apneia e estimativa de pose de 17 pontos a partir de CSI. Opções de hardware variam de gratuito a ~US$140. Um nó ESP32-S3 único custa cerca de US$9; uma mesh multi-nó cerca de US$54; a configuração recomendada adiciona um Cognitum Seed para armazenamento persistente de vetores, busca kNN, atestaçãocriptográfica e proxy MCP. Um nó ESP32-C6 (US$6–10) visa sensing de pesquisa Wi-Fi 6 e 802.15.4, com sincronismo ESP-NOW de 99,56% e captura HE-LTF no IDF 5.5.2, embora o README afirme que TWT e operação de ~5 µA ainda precisam de validação hardware. Placas de rede Intel 5300 e Atheros AR9580 para pesquisa, além de programas beta Qualcomm e vendor-adapter, também são listados. Notebooks comuns fornecem RSSI apenas para presença grosseira; a imagem Docker roda em dados simulados. O software é distribuído como crates Rust 1.85+, imagens Docker multi-arquitetura e pacotes PyPI (ruview e wifi-densepose, mesma wheel PyO3 abi3-py310 de ~250 KB para Linux, macOS e Windows). A integração com Home Assistant é feita via editor MQTT com 21 entidades por nó (sinais brutos mais estados inferidos como someone-sleeping, possible-distress, fall-risk-elevated, bathroom-occupied) e três Blueprints iniciais; Apple Home usa bridge HAP-1.1 detectável, e Google Home e Alexa funcionam via mesmo bridge HA ou endpoint Matter. HOMECORE fornece estado local, histórico, automações, plugins Wasm assinados, hooks de voz e suporte HomeKit. Um catálogo edge de 105 módulos é carregado de um registry. Um metaharness npm separado, @ruvnet/ruview, oferece doctor, guidance, agentes de codificação read-only, claim-check, verificação determinística e servidor MCP. O README é incomumente sincero sobre as limitações do modelo, e isso importa para avaliação. O encoder pré-treinado no Hugging Face reporta 82,3% de acurácia temporal-triplet hold-out, acima de 66,4% raw — a figura anterior de "100% presença" foi medida em gravação single-class e foi retratada. Sua build 4-bit cabe em 8 KB. O modelo MM-Fi de pose separado reporta 82,69% torso-PCK@20 single-model (83,59% com ensemble de três modelos mais test-time augmentation), comparado pelo projeto contra MultiFormer (72,25%) e CSI2Pose (68,41%). Em contraste, o modelo pose_v1 comprometido para on-device é descrito como primeira tentativa com PCK@20 = 3,0%, muito abaixo da meta própria de 35% ADR, com path de runtime ainda stub confidence=0. O header do model.safetensors publicado é NUL-padded e rejeitado pelo loader safetensors de referência (issue #1522); os arquivos model-q*.bin quantizados ainda carecem de leitor compatível. Acurácia do unified RF world model é afirmada como sintética até validação com dados reais. Ferramentas de verificação reivindicadas incluem replay determinístico de pipeline (python archive/v1/data/proof/verify.py) que hadéeia output contra SHA-256 publicado, chain de testemunhas Ed25519 e 1.463 testes passando reportados. Em resumo, RuView é um framework de sensing edge substancial com ampla integração smart-home e documentação extensa, mas usuários potenciais devem tratar as reivindicações de pose on-device em produção como não comprovadas e confiar nos próprios alertas do projeto, ADRs benchmarkeados e scripts reprodutíveis ao julgar a acurácia.