Skip to content

Create airhound-handlers crate (DroneProcessor + ProximityTracker + output pipeline) #90

@dougborg

Description

@dougborg

Summary

Create the airhound-handlers crate as a lightweight std crate containing the two genuinely stateful processors and the category-driven output pipeline. This replaces the original 4-handler design.

Crate Structure

crates/airhound-handlers/
  Cargo.toml           # depends on airhound-core
  src/
    lib.rs
    drone.rs           # DroneProcessor (ODID state accumulation)
    proximity.rs       # ProximityTracker (multi-target RSSI tracking)
    pipeline.rs        # Category-driven output routing + dedup
    network_catalog.rs # BSSID dedup map + WiGLE CSV export
    gps.rs             # Shared GPS position
    persistence.rs     # NVS abstraction

Design Philosophy

The rule engine (airhound-core) handles all matching. This crate handles:

  1. Stateful processors that need to accumulate state over time:

  2. Category-driven output pipeline — simple dedup + routing:

    • Surveillance/Watchlist: MAC dedup with configurable cooldown → alerts
    • Network: BSSID dedup with infinite TTL → catalog + WiGLE CSV export
    • Drone/Proximity: forward to respective processors
  3. Shared infrastructure: GPS, NVS persistence

No EventHandler trait — just concrete structs with clear responsibilities.

Requirements

  • std crate (HashMap, String, etc.)
  • Depends on airhound-core for scan events, filter types, protocol types, proximity math
  • cargo test passes on host
  • Each component independently testable

Replaces

Metadata

Metadata

Assignees

No one assigned

    Labels

    phase-2-handlersCreate airhound-handlers crate (std)

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions