WiFi Human Detection: How CSI Sensing Finds Presence Without Cameras

What WiFi human detection actually detects

A WiFi link sends radio waves through a room. Walls, furniture, appliances, and bodies reflect and absorb parts of that signal. CSI records fine-grained changes across subcarriers, so a person walking, breathing, sitting down, or blocking a path can create a measurable pattern. The system does not literally see a person; it detects changes in a radio channel and infers a state from those changes.

That distinction matters for searchers comparing WiFi human detection GitHub projects. A presence detector may answer occupied versus empty. A motion detector may answer moving versus still. A tracking or pose system tries to infer richer geometry, often with stricter hardware, calibration, and training data requirements.

• Presence detection: estimates whether a room or zone is occupied.
• Motion detection: reacts to channel changes caused by movement.
• Human recognition: tries to classify activity, posture, or person-related patterns.
• RuView display: presents confidence, limitations, and links to the sensing stack rather than replacing validation.

CSI versus RSSI for human detection

Many simple WiFi experiments start with RSSI because it is easy to read. RSSI is useful for broad signal strength changes, but it compresses too much detail for robust human detection. CSI provides a richer picture of how each subcarrier changes over time, which is why most serious WiFi sensing research and ESP32 CSI projects focus on CSI capture.

The tradeoff is complexity. CSI requires compatible hardware, careful packet collection, preprocessing, labels, and repeatable test conditions. A RuView-style result panel should therefore report confidence and context instead of pretending that one CSI trace is a universal person detector.

A validation workflow before you trust results

A useful WiFi human detection test begins before model training. Collect empty-room baselines, still-person sessions, walking sessions, door and fan disturbances, and moved-router sessions. Keep the train and test recordings separated by day, placement, and people whenever possible. If every test comes from the same afternoon, the model may learn the room rather than human presence.

For public demos, the most important metric is often false positives. A system that detects a person when a fan moves, a door swings, or a router changes channel can look impressive in a short video but fail in ordinary use.

• Record empty-room sessions before and after each experiment.
• Test at least one changed placement, one unseen day, and one unseen person.
• Log packet rate, channel, board, firmware, room geometry, and label method.
• Show confidence and unknown states instead of forcing every sample into a human/no-human answer.

Where ESP32 and GitHub projects fit

ESP32-based CSI projects are useful because they make WiFi sensing experiments accessible without research-grade NICs. They are usually best treated as acquisition and prototyping tools first. Before choosing a model, confirm that the repository can capture stable CSI on your board, export raw data, and reproduce a small baseline in your room.

GitHub stars and demo GIFs are weaker evidence than a documented hardware path. Prefer projects that name the exact ESP32 board or WiFi card, explain firmware versions, include sample captures, and describe negative tests. If a project claims through-wall detection or detailed human tracking, look for independent room splits and failure-case discussion.

How this topic differs from other RuView resources

This page is about the search intent behind WiFi human detection: what it can infer, how to validate it, and how not to overclaim. The ESP32 CSI guide focuses on hardware capture. The dataset guide focuses on labels and benchmarks. The open source guide helps choose GitHub stacks. The RuView motion-capture guide covers pose-style interpretation and WiFi DensePose ideas.

Keeping those pages separate prevents keyword cannibalization. Searchers who want the official RuView repository should land on the GitHub guide. Searchers who ask whether WiFi can detect people need this more cautious explanation first.

• Use the ESP32 CSI guide when the blocker is hardware capture.
• Use the dataset guide when the blocker is labels and benchmark design.
• Use the motion-capture guide when the blocker is pose-like interpretation.
• Use this page when the blocker is presence detection reliability and validation.

Responsible limits for camera-free sensing

Camera-free does not mean risk-free. WiFi human detection can reveal occupancy, habits, and movement patterns. Any real deployment should explain what is collected, where processing happens, how long data is retained, and when the system is uncertain. For home automation, research demos, or accessibility experiments, local processing and visible consent are safer defaults.

Avoid using WiFi sensing as a sole safety, health, security, or emergency decision system. Treat it as one signal among several unless the exact environment has been rigorously validated and monitored for drift.

• Do not claim medical monitoring or emergency reliability from a general demo.
• Show uncertainty when the room or hardware no longer matches training data.
• Prefer local processing and minimal retention for occupancy-related signals.
• Document failure cases as part of the product experience, not only in a paper appendix.

Sources and technical references

WiFi Human Detection FAQ