Solo ProjectCompleted

PulseGrid

Real-time industrial telemetry that runs with hardware or without it.

ArduinoNode.jsExpressMongoDBMongooseReactViteTailwind CSSSocket.ioFirebase Authentication

Problem Statement

Industrial equipment needs continuous monitoring of conditions such as temperature and pressure, and without a unified live view, threshold breaches are noticed late. Hardware-based projects are also hard to demonstrate online, because a cloud server has no physical device plugged into it.

Proposed Solution

PulseGrid combines an Arduino sensor layer with a MERN web dashboard. A Hybrid Detection Engine checks whether a physical Arduino is connected over USB, and if none is found it switches to a mathematically generated simulator. Both sources feed the same real-time pipeline into MongoDB and the React dashboard, so the system works identically with or without hardware.

Key Features

Express API with health check and device lookup, backed by MongoDB through Mongoose.
Device model with status, mode, and configurable threshold settings, plus a seed script for a default monitored device.
Anomaly-only telemetry log that stores threshold breaches instead of every raw reading, keeping storage small.
React and Tailwind dashboard shell with a custom industrial theme.
In development: Hybrid Detection Engine that uses a connected Arduino over serial and falls back to a data simulator when none is present.
In development: live streaming of temperature and pressure to the dashboard through Socket.io, with Firebase Authentication.

System Architecture Flow

Arduino sensor node over USB serial, or the built-in simulator -> Hybrid Detection Engine (Node.js) -> Real-time pipeline (Socket.io, in development) -> MongoDB (devices and anomaly logs) -> React dashboard, with Firebase Authentication for access

Engineering Challenges

Hardware-dependent software cannot be demonstrated on a cloud host with no device attached, so the design uses hardware detection with a simulator fallback that feeds the identical pipeline.
Storing every sensor reading would grow the database quickly, so only threshold breaches are logged as telemetry events.
Monitoring rules should not be hardcoded, so device thresholds live in the database schema and are loaded through seed data.

Lessons Learned

Designing IoT data models around limited storage and high event volume.
Building one pipeline that serves both real hardware and simulated data, so the same code path is tested either way.
Building a hardware and software system in stages, starting with the backend core before the real-time layer.

Results

In progress and not deployed yet. The backend core, device and telemetry schemas, and dashboard shell are implemented.