Fleet Dashboard

The Fleet Dashboard is a full-stack monitoring platform designed to provide real-time visibility into distributed MPPT solar charge controllers. It combines on-site telemetry ingestion, intelligent diagnostics, IC2 cloud integration, and a browser-based dashboard to give operators a clear, actionable view of their solar fleet health.

MPPT Telemetry is retrieved on the device using python and ModbusSerialClient and HTTP/POSTed to an ingestioin server.

IC2 (Peplink In Control API) Integration via Rest/API

jaxnconsultingmarkedupdashboard

Project Overview

This project was built to solve a common problem in remote solar deployments: how to reliably monitor many MPPT controllers across multiple locations without expensive, heavyweight tooling.

  • Backend: Node.js + Express, CSV-based registry, IC2 API integration, diagnostic engine
  • Frontend: HTML/JS dashboard with Leaflet map, device table, and status views
  • Hosting: cPanel / Passenger on shared hosting
  • Focus: Operational visibility, reliability, and low operational overhead

The Problem

Managing a distributed fleet of MPPT solar charge controllers is challenging when devices are deployed across remote or hard-to-reach locations. Operators need to know:

  • Which devices are online and healthy
  • Which sites are underperforming or at risk
  • When batteries are in danger (over-voltage, under-voltage, temperature issues)
  • Whether solar input is sufficient or if there are wiring/shading issues
  • How to correlate on-site telemetry with cloud device metadata and locations

Most off-the-shelf tools are either too generic, too expensive, or not tailored to the specific combination of MPPT telemetry and IC2 device data. This project fills that gap with a focused, purpose-built solution.


The Solution

The Fleet Dashboard backend ingests telemetry from MPPT controllers, stores the latest state per device, logs historical data, merges it with IC2 cloud metadata and locations, and exposes a clean API for the frontend dashboard. The frontend renders a real-time view of the fleet with maps, tables, and diagnostic status.

Key Capabilities

  • Telemetry ingestion from MPPT controllers via a simple HTTP endpoint
  • Local registry of devices using per-device CSV files
  • History logging to a central CSV for long-term analysis
  • IC2 integration to pull device metadata and last-known locations
  • Diagnostic engine to evaluate PV, battery, load, temperature, and charging state
  • System voltage detection (12V / 24V / 48V) from telemetry
  • Web dashboard with map, device table, and status indicators

Architecture

High-Level Flow

MPPT Devices → POST /ingest → Backend Registry → Fleet Dashboard UI
          ↓
          History CSV
          ↓
          IC2 Cloud API
          ↓
          Merged Device Mapping API

Backend Components

  • app.js – Express server, routes, static hosting, Passenger-aware startup
  • registry.js – Device registry, telemetry storage, diagnostics, IC2 merge logic
  • ic2-client.js – IC2 API wrapper for devices and locations
  • alert-engine.js – Active alert evaluation based on telemetry and status
  • debug.js – Toggleable debug logging for development and production tracing

Frontend Components

  • index.html – Main dashboard shell
  • JavaScript modules – Fetch APIs, render device table, bind map interactions
  • Leaflet map – Visualizes device locations and status
  • Responsive layout – Usable on desktop and tablet

Backend Details

Telemetry Ingestion

MPPT controllers send JSON payloads to a dedicated ingestion endpoint:

POST /ingest
{
  "deviceId": "123",
  "timestamp": "2026-05-05T15:30:00Z",
  "pvVoltage": 18.2,
  "pvCurrent": 5.1,
  "pvPower": 92.8,
  "battVoltage": 12.8,
  "battCurrent": 4.3,
  "battPower": 55.0,
  "loadVoltage": 12.7,
  "loadCurrent": 1.2,
  "loadPower": 15.2
}

The backend:

  • Updates a per-device CSV file with the latest telemetry
  • Appends a row to storage/history.csv for long-term analysis
  • Logs the request and source IP for traceability

Device Registry

Each device is represented by a single-row CSV file under /devices:

  • devices/device_<id>.csv – latest telemetry, timestamp, status, and derived fields

The registry module can:

  • Return all devices and their latest telemetry
  • Update a device’s status
  • Merge registry data with IC2 metadata and locations

Diagnostics Engine

The diagnostics logic evaluates:

  • PV voltage – reverse polarity, low input, near or above hardware limits
  • Battery voltage – low, critical, high, and dangerous thresholds (scaled for 12/24/48V)
  • Load output – overcurrent and short-circuit conditions
  • Temperature – controller and battery temperature warnings
  • Charging state – MPPT not charging despite available solar, fault states
  • Telemetry age – stale data detection

System voltage (12V / 24V / 48V) is auto-detected from battery voltage and under-voltage warning registers, ensuring thresholds are applied correctly per system.

IC2 Integration

The backend calls IC2 APIs to retrieve:

  • Device metadata (ID, name, group, status, expiry)
  • Last-known locations (coordinates, points)

It then:

  • Normalizes device identifiers
  • Maps IC2 devices to local registry entries
  • Combines IC2 status, location, and local telemetry
  • Produces a merged dataset for the frontend via /device-mapping

Frontend Details

Dashboard Views

The dashboard provides:

  • Device table – ID, group, status, MPPT status, last sync, system voltage
  • Map view – Leaflet-based map with markers for each device
  • Diagnostic indicators – warnings and critical alerts per device

Interactions:

  • Clicking a table row centers the map on the selected device
  • Clicking a map marker highlights the corresponding device in the table

BASE Path Awareness

Because the application is hosted under a subdirectory (e.g., /fleet-dashboard), the backend injects a window.BASE variable into the HTML. The frontend uses this to construct all API URLs, making the deployment flexible and portable.


Business Value

This project demonstrates how a focused, well-architected solution can deliver real operational value:

  • Operational visibility – Clear, real-time view of fleet health
  • Reduced site visits – Diagnose issues remotely before rolling a truck
  • Faster troubleshooting – Pinpoint PV, battery, load, or configuration issues quickly
  • Extensible foundation – Easy to extend with new devices, alerts, or analytics

Technologies Used

  • Node.js, Express
  • CSV-based storage for registry and history
  • IC2 Cloud API
  • Leaflet.js for mapping
  • HTML5, CSS, JavaScript
  • cPanel / Passenger for hosting

My Role

I led the architecture, design, and implementation of the entire solution:

  • System architecture and data flow design
  • Backend engineering (ingestion, registry, diagnostics, IC2 integration)
  • Frontend engineering (dashboard UI, map integration, API wiring)
  • Deployment on cPanel / Passenger
  • Documentation and production hardening

Next Steps & Extensions

  • Authentication and role-based access control
  • Rate limiting and API keys for ingestion
  • WebSocket or SSE for live updates
  • Historical charts and trend analysis
  • Multi-tenant support for different fleets or clients

Interested in Something Similar?

If you’re looking to build a telemetry platform, operational dashboard, or integrate field devices with cloud systems, I help design and deliver solutions like this end-to-end—from architecture through deployment.

Let’s talk about your fleet, your data, and what visibility would change for you.