Every Wi-Fi router fills a room with radio waves. When a person walks, sits or even breathes, those waves bounce and bend in slightly different ways. For years, researchers have studied how to read those changes to tell whether someone is in a room, how they are moving and even how fast they breathe. RuView is an open-source project that brings this kind of Wi-Fi sensing to low-cost ESP32 boards.
The project describes itself as a Wi-Fi sensing platform. It reads Channel State Information, or CSI, from ESP32 sensors and uses signal processing and small models to detect presence, motion, breathing rate trends, heart rate trends and falls, with camera-free pose estimation as an experimental feature. It runs on local hardware and connects to home automation systems.
This article explains the idea in plain words, what you need to experiment with it, how an AI coding tool fits in and why it is important to read the limits as closely as the features.
What CSI is
When a Wi-Fi device receives a signal, it does not just get the data. It also measures how the signal arrived on many small frequency channels at once: how strong each one was and how its timing shifted. That detailed measurement is CSI. Normal devices use it to correct for interference and then throw it away.
The ESP32 can expose CSI to your own code. That makes it one of the cheapest ways to experiment with Wi-Fi sensing.
How sensing works in plain words
Imagine a still pond. Drop a stone and ripples spread out. A person moving in a room is the stone. The Wi-Fi signal is the pond. The ESP32 watches the ripples.
Presence and motion. When nobody is there, the CSI pattern stays fairly steady. When someone moves, it changes quickly. Measuring how much it varies gives a simple presence and motion signal.
Breathing and heart rate trends. A breathing chest moves a little, in a slow repeating rhythm. The project filters the signal to keep only slow rhythms in the breathing range and counts how often the signal crosses its middle line. It does the same in a faster range for heart rate. These are estimates, and the project labels device-reported vital signs as unvalidated.
Falls. A fall causes a sharp change. The project uses a threshold on how fast the signal changes, with checks to avoid repeat alarms.
Learned features. On top of the signal tricks, the project trains small neural networks on CSI data and publishes pretrained weights, so the system can learn patterns for a specific room.
What it connects to
RuView can publish its sensors to Home Assistant through MQTT and can act as a bridge to other smart home systems. It also includes a toolkit for AI agents: an MCP server, a mode for Claude Code and guarded agent runs that are read-only by default, with writes and hardware access requiring explicit permission.
What you need
At least one supported ESP32 board. The project's quick start mentions ESP32-S3 and ESP32-C6 options. More nodes around a room give richer data.
A Wi-Fi network that the boards can listen to.
A computer to run the server, the dashboard and the analysis tools. The project offers a Docker image with simulated data, which lets you explore the software before you buy any hardware.
Patience. Sensing depends on the room, the furniture, the router position and the people.
How a beginner could start
Run the Docker version with simulated data first. Learn the dashboard and the data flow without any hardware.
Flash one ESP32 node following the project's guide and watch the live CSI view. Walk in and out of the room and see how the signal changes. Sit still and see what stays.
Write down what you see. Note where the node is, where the router is and what time of day you test.
Only then try the features that need training or calibration.
Using an AI coding tool
The repository is large, with many documents and decision records. An AI coding agent is useful for finding your way. Ask it to summarise how CSI moves from the ESP32 to the server, which files handle presence detection and what each command in the toolkit does.
You can also ask an agent to help with simpler projects of your own. For example, a small sketch that reads CSI from one ESP32 and prints the amount of change each second, so you understand the raw signal before you rely on a large system. Or a script that logs presence events to a file so you can compare them with when you were really in the room.
The project's own toolkit includes a claim check that compares statements about accuracy with the evidence. That is a healthy idea to copy in your own notes.
Read the limits carefully
Wi-Fi sensing is an active research field, and it attracts excited summaries. The project itself is careful in places. It marks vital signs as unvalidated. It describes its pose estimation model as a first cut with low measured accuracy, below its own target. It notes that parts of its combined world model are still tested on synthetic data. Through-wall sensing is described as signal-dependent and limited in range.
Treat those notes as the real picture. A setup that works well in one room may work poorly in the next. Never use a hobby sensing system for medical decisions or as the only safety system for someone at risk of falling.
Privacy and ethics
Wi-Fi sensing works without a camera, which some people find more private. But it can still tell when someone is home, when they sleep and how they move, even through a wall. That is sensitive. Use it only in spaces you control, tell everyone in the home what it does, and never point it at neighbours or use it to monitor someone without their knowledge and consent.
Variations
Build a simple occupancy sensor for one room that turns lights off when the room is empty.
Combine Wi-Fi sensing with a low-cost mmWave radar sensor and compare the two.
Log a week of presence data and look for patterns in when rooms are used.
Use the agent toolkit to ask questions about your own sensor data in plain language.
The short version
RuView uses ESP32 boards to read Channel State Information from Wi-Fi and turns small changes in the signal into presence, motion, breathing and fall signals, with experimental pose estimation. Start with the simulated Docker setup, then one node, and learn the raw signal before you trust higher-level features. Read the project's own notes on accuracy, treat vital signs as unvalidated, respect privacy and use an AI coding tool to navigate the large codebase and write small test tools of your own.
Project resources: https://github.com/ruvnet/RuView