In development Personal product Active project

Raspberry Pi Network Auditor

A Raspberry Pi-based network auditor focused on device inventory, traffic summaries, changes over time and careful explanation. It is intentionally framed as personal defensive tooling, not an offensive-security product.

  • Raspberry Pi
  • Python
  • Network telemetry
  • Time-series analysis
  • Anomaly detection
  • Data visualisation
Concept illustration — no private project data shown.

01 · Problem

What needed solving

A home network can accumulate many devices while providing very little useful context about what is connected, what normal activity looks like and what has changed.

Use a bounded home-infrastructure problem to explore observability, time-series reasoning and explainable anomaly signals without collecting unnecessary content.

02 · Constraints

The difficult parts

  • Collect enough metadata to explain behaviour without retaining private payload content.
  • Separate a change worth reviewing from an unsupported claim that a device is malicious.
  • Keep credentials, device identifiers and household activity out of public screenshots and logs.

03 · Approach

How the work was structured

  1. Start with inventory, connection summaries and change detection rather than packet-content inspection.
  2. Treat anomaly scores as prompts for investigation, not security verdicts.
  3. Keep analysis local and design public demonstrations around synthetic device names and traffic patterns.

04 · Validation

What can be claimed now

The project and its privacy boundary are user-confirmed. Exact capture tools, current modules and model behaviour are not yet documented publicly, so the case study makes no narrower implementation claims.

The auditor is an active personal project and a learning environment for local observability. It is not presented as a certified security system or a finished public product.

05 · Learning

What the project clarified

  • Privacy starts with deciding what not to collect.
  • An anomaly is evidence of change, not proof of intent.
  • A defensive tool is more useful when every signal can be traced back to understandable metadata.

Next

Planned follow-through

  • Document the implemented collection and retention boundaries.
  • Create a synthetic demonstration network for screenshots and regression tests.
  • Add clearer explanations for new devices and unusual time windows.