Edge Dashboard Overview

Introduction

The Pyvorin Edge Dashboard is a web-based interface that lets you visualise sensor data, monitor pipeline health, configure privacy rules, and inspect cloud sync status, all from a browser. Because the Edge Agent exposes a built-in HTTP health server, the dashboard can run locally on the Pi, on a separate machine on the same network, or even as a hosted web application that polls multiple gateways.

This article explains how to access the dashboard, what each view displays, and how to point the dashboard at your gateway's health endpoint.

How the Dashboard Works

Unlike monolithic IoT platforms that require you to push data to their servers, the Pyvorin Edge Dashboard is a thin client. It makes HTTP GET requests to your agent's /health and /metrics endpoints, renders the JSON responses as charts and tables, and optionally queries the SQLite database directly for historical data. Your data never needs to leave your network unless you explicitly enable cloud sync.

The dashboard is typically served as a static site (HTML, CSS, JavaScript) from:

• A lightweight HTTP server running on the Pi itself (e.g., nginx or Python's http.server).
• A separate laptop or desktop on the same LAN.
• A hosted version at https://app.pyvorin.com that connects to your Pi via local tunnel or VPN.

Accessing the Dashboard

Option 1: Local Dashboard on the Pi

If you installed the dashboard package alongside the edge runtime, you can start it directly:

# Activate the environment
source ~/pyvorin-edge/.venv/bin/activate

# Start the dashboard (serves on port 3000 by default)
pyv-edge-dashboard --agent-url http://localhost:8080 --port 3000
  

Then open a browser on any device on the same network and navigate to:

http://your-pi-ip:3000
  

Option 2: Static Files on a Separate Machine

Download the dashboard static build and serve it with any web server:

# On your laptop
curl -O https://cdn.pyvorin.com/edge-dashboard/latest.tar.gz
tar -xzf latest.tar.gz
cd edge-dashboard

# Edit config.js to point at your Pi
# export const AGENT_BASE_URL = "http://192.168.1.45:8080";

# Serve with Python's built-in server
python3 -m http.server 8000
  

Open http://localhost:8000 in your browser.

Option 3: curl (No Dashboard UI)

If you prefer command-line monitoring, you can consume the raw JSON directly:

# Live health status
curl -s http://192.168.1.45:8080/health | python3 -m json.tool

# Raw metrics
curl -s http://192.168.1.45:8080/metrics | python3 -m json.tool
  

Dashboard Views

The dashboard is organised into views, each accessible from the left navigation panel. Below is what each view shows and how the data is sourced.

Overview

The landing page presents a high-level summary of your gateway.

• System Health Card. CPU, RAM, disk, and temperature gauges populated from /metrics. Thresholds are colour-coded: green below 60%, orange 60-80%, red above 80%.
• Agent Status Card. Running state, number of buffers, total readings processed, and events triggered from /health.
• Cloud Sync Card. Queue depth, last flush time, messages sent today, and endpoint URL from /health.cloud.
• Privacy Status Card. Whether the firewall is enabled, how many rules are active, and which sensor patterns are redacted or hashed from /health.privacy.

Sensors

This view lists every device configured in [sensors.devices].

• Device Table. Name, ingest type, sensor type, unit, and adapter status (connected or error).
• Live Values. The most recent reading per device, refreshed every poll interval.
• Historical Chart. A time-series line chart showing the last N readings from the SQLite store. The dashboard queries /api/readings?sensor_name=... if the agent exposes a read API, or it queries the database file directly if running on the Pi.

Pipeline

Shows the data flow from ingestion through buffering, rule evaluation, and storage.

• Pipeline Diagram. A visual flowchart: Sensors → Ingest Adapters → Ring Buffers → Privacy Filter → SQLite Store → Cloud Queue.
• Window Statistics. Per-device buffer utilisation (count / capacity) and oldest reading age.
• Rule Evaluation Log. Recent rule firings with timestamps, severity, and matched condition expressions.

Privacy

Dedicated to the privacy firewall configuration and audit trail.

• Active Rules. A table of sensor_pattern, action, and hit count (how many readings have matched this rule since startup).
• Redaction Log. Recent readings that were dropped or masked, shown in a redacted form for audit purposes.
• Hash Mapping. For hash actions, a read-only table mapping original sensor names to their SHA-256 prefixes. This helps you correlate anonymised data back to physical devices when authorised.

Cloud

Monitors and controls cloud synchronisation.

• Queue Inspector. Live queue depth, oldest item age, and retry statistics from /health.cloud.
• Upload History. Batches sent, success/failure rates, and HTTP status codes.
• Endpoint Configuration. Read-only display of the current endpoint and API key mask (e.g., sk-...9a3f).
• Manual Flush Button. Triggers an immediate maybe_flush() call to force a sync attempt.

Benchmarks

Performance analytics for compiled kernels and pipeline latency.

• Pipeline Latency. Average milliseconds per reading processed, measured inside Pipeline.run().
• Kernel Performance. If you have compiled .so files, this view shows their load times and execution benchmarks against pure-Python equivalents.
• Resource Usage Over Time. A historical chart of CPU, RAM, and thermal trends, sampled from /metrics and stored in the dashboard's local cache.

Logs

A live tail of agent logs.

• Structured Log Viewer. Parses JSON log lines and displays them in a filterable table with columns for timestamp, level, logger, and message.
• Level Filters. Toggle visibility of DEBUG, INFO, WARNING, ERROR, and CRITICAL lines.
• Search. Full-text search across log messages.

If the agent is configured for text-format logs, the dashboard falls back to regex parsing.

Configuring the Pi Endpoint

The dashboard needs to know where your agent lives. This is configured once during setup.

Settings Panel

Click the gear icon in the top-right corner to open the settings panel. The following fields are available:

Example: Multi-Gateway Setup

If you have multiple Pyvorin Edge gateways, you can configure the dashboard to switch between them:

// dashboard-config.js
export const GATEWAYS = [
  { name: "Factory Floor A", url: "http://192.168.1.45:8080" },
  { name: "Factory Floor B", url: "http://192.168.1.46:8080" },
  { name: "Server Room", url: "http://192.168.1.47:8080" },
];
  

CORS and Network Considerations

The agent's health server sends CORS headers by default:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, OPTIONS
Access-Control-Allow-Headers: Content-Type
  

This allows the dashboard to run on a different origin (e.g., http://localhost:8000 talking to http://192.168.1.45:8080). In production, you may want to restrict Access-Control-Allow-Origin to your dashboard's domain by placing a reverse proxy like nginx between the dashboard and the agent.

Example: nginx Reverse Proxy

server {
    listen 80;
    server_name edge-dashboard.local;

    location / {
        root /var/www/edge-dashboard;
        try_files $uri $uri/ /index.html;
    }

    location /api/agent/ {
        proxy_pass http://192.168.1.45:8080/;
        proxy_set_header Host $host;
    }
}
  

Security Best Practices

• Do not expose port 8080 to the public internet. The health server has no authentication. Use a VPN, SSH tunnel, or private network.
• Use HTTPS when possible. If you terminate TLS at nginx or a load balancer, the agent itself does not need to handle certificates.
• Restrict CORS in production. Replace * with your dashboard's exact origin.
• Monitor dashboard access. If running the dashboard on the Pi, consider using fail2ban or iptables to limit connection sources.

Summary

The Pyvorin Edge Dashboard turns raw JSON health endpoints into actionable visualisations. Configure the agent URL in the settings panel, explore the Sensors, Pipeline, Privacy, Cloud, Benchmarks, and Logs views, and remember to keep your health endpoint behind a firewall or reverse proxy in production. For headless deployments, the same data is available via curl and can be integrated into existing monitoring stacks like Prometheus or Grafana.