Technical write-up

Sensor & dashboard architecture

The public dashboard and sensor telemetry flow through one deliberately boring, deliberately secure design. Details that would map the private network are omitted on purpose.

Web / Mobile Frontend
  • responsive
  • dark / light
  • no secrets client-side
Secure API / Service Layer
  • request validation
  • rate limiting
  • event logging
Authentication & Access
  • issued codes
  • usage limits
  • audit & expiry
Automation / Orchestration
  • schedules
  • rules
  • event triggers
Service Boundaries
  • least privilege
  • safe fields
  • failure isolation
Dashboard Storage
  • time-series
  • preferences
  • logs & metrics
Sensor Ingestion
  • temperature
  • status
  • events
Analytics / AI
  • anomaly detection
  • forecasting
  • recommendations

How a reading gets to your screen

Sensors sign their reports and push them to an ingest endpoint that validates, rate-limits, and stores them as time-series data. The public dashboard never talks to a device: it asks the API layer, which serves a cached, sanitized summary — no device identifiers, no internal addresses, no credentials anywhere near the browser.

How protected capabilities stay separate

Public telemetry is read-only and restricted to a small sanitized schema. Authenticated content and design demonstrations live behind a separate session boundary, so the public dashboard cannot invoke private capabilities.

Security posture

  • Public responses validated against an explicit safe-field allow-list
  • Rate limiting at both the edge (nginx) and the application
  • Secrets live in server-side environment files owned by root — never in the repo, never in the client
  • Events logged without sensitive payloads
  • Public responses stripped to safe fields; private admin interfaces stay behind owner-only 2FA login