Custom IoT & Hardware Dashboards

A solar panel array produces 50 data points per panel per minute — voltage, current, temperature, inverter state. A fleet of delivery vehicles sends GPS coordinates and engine diagnostics every 5 seconds. A factory floor has 200 sensors monitoring temperature, vibration, pressure, and flow rates continuously.

That data is valuable. It can predict equipment failures before they happen, catch efficiency problems in real time, and provide the documentation you need for regulatory compliance. Most companies collect it, dump it into a CSV somewhere, and review it manually a week later when a problem has already caused an expensive failure.

The Custom IoT & Hardware Dashboard processes that data in real time and puts it in front of the people who can act on it.

Why Relational Databases Break Under Telemetry Load

A standard PostgreSQL table is the right tool for user records, orders, and application state. It's the wrong tool for sensor data. The problem is the write pattern: IoT devices don't insert one row per day, they insert thousands of rows per second, continuously, forever.

At scale, this creates specific problems: write amplification as indexes are updated on every insert, bloated tables where 99% of the data is historical and rarely queried, and slow analytical queries because the query planner has to scan through gigabytes of time-ordered data without efficient time-based partitioning.

TimescaleDB is a PostgreSQL extension designed specifically for this workload. It automatically partitions your data into time-based "chunks" (daily or weekly, configurable), which means:

• Historical data queries scan only the relevant time partitions rather than the entire table
• Automated compression on older chunks reduces storage costs by 90-95%
• Continuous aggregates pre-compute common time-bucket queries (hourly averages, daily maximums) so dashboard queries return in milliseconds instead of seconds
• Full SQL compatibility — everything you know about PostgreSQL works

The database schema ships pre-configured for telemetry workloads. Device metadata, sensor definitions, reading tables, and continuous aggregate policies are already set up.

MQTT Ingestion With EMQX

MQTT is the standard protocol for IoT device communication. It's designed for constrained devices and unreliable networks — a sensor on a cellular connection can maintain a persistent MQTT connection even through brief signal drops, and messages are queued for delivery when the connection is restored.

EMQX is an enterprise MQTT broker that handles millions of concurrent device connections on commodity hardware. The platform ships with EMQX configured as a message broker with:

• Topic-based routing — devices publish to structured topics (devices/{id}/sensors/{type}) and the backend subscribes to all telemetry automatically
• Message persistence — unprocessed messages are retained in a queue if the backend processing service restarts
• Authentication — each device authenticates with a unique certificate, preventing unauthorized devices from injecting data
• Bridging to the Next.js API — EMQX's built-in webhook rules forward processed messages to the WebSocket server that powers the live dashboard

Live Dashboard at 60 Updates Per Second

The frontend uses a WebSocket connection to receive real-time data updates. The chart library is configured to handle continuous updates without re-rendering the entire chart on each frame — only the new data point is appended, and the time window slides forward.

Dashboard layouts are configurable per device type. A solar installation sees different default panels than a vehicle fleet — but all layouts use the same underlying component library, so custom views for new device types can be assembled without writing new chart code.

Features on the dashboard layer:

• Multi-device comparison — overlay the telemetry from multiple devices on the same chart to identify outliers
• Zoom and time range selection — click and drag to zoom into a specific time window, or select from presets (last hour, last 24h, last 7 days)
• Annotation markers — log maintenance events or configuration changes directly on the timeline to correlate with telemetry patterns
• Raw data export — download any time range as CSV for offline analysis or regulatory reporting

Alert Engine: Get Notified Before the Failure, Not After

Every IoT platform needs alerting, and most IoT platforms implement it poorly. Threshold-based alerts that fire every time a value briefly spikes (false positive noise) get ignored. Alerts that only fire when a value is continuously above threshold for N minutes (hysteresis) are much more actionable.

The alert engine supports:

• Simple threshold rules — value above or below X triggers immediately
• Hysteresis rules — value must be outside threshold for N consecutive readings
• Rate-of-change rules — value increasing or decreasing faster than X per minute
• Composite rules — multiple conditions on multiple sensors must all be true simultaneously

Alert destinations include Slack (with formatted message cards showing the device, sensor, value, and trend), SMS via Twilio, email via Resend, and outbound webhooks to any URL — useful for integrating with existing incident management systems like PagerDuty or Opsgenie.

Alert rules are managed through the admin interface — no code changes needed to adjust thresholds or add new alert destinations.