IoT Dashboard Development for Connected Hardware
From device to MQTT broker to TimescaleDB, then Grafana or a custom Next.js dashboard
IoT dashboard development is building the software that turns device data into something people can see and act on: an MQTT broker, an ingestion service, time-series storage and dashboards with alerts. Electuni builds this layer for hardware teams who need to watch a device fleet, using Grafana for engineering views and Next.js when customers need a branded product UI.
Design → Prototype → Production
Key Facts: IoT Dashboard Development
- Messaging
- MQTT over TLS
- Brokers
- AWS IoT, Azure, EMQX, Mosquitto
- Storage
- TimescaleDB
- Dashboards
- Grafana or Next.js
- Views
- Fleet Health, OTA, History
- Access
- Auth & Multi-Tenant
What You Get
- Data architecture from device topic structure to stored tables
- MQTT broker setup with per-device credentials and topic access rules
- Ingestion service that validates and writes device messages to TimescaleDB
- TimescaleDB schema with hypertables, retention policies and continuous aggregates
- Grafana dashboards and alert rules for fleet health and device history
- Custom Next.js dashboard with user accounts, where a branded product UI is needed
- Deployment notes and source code in Git
How We Approach IoT Dashboard Development
A dashboard is only as good as the data path behind it. Devices publish to an MQTT broker over TLS, using a topic structure that encodes the tenant, device and message type, so access rules and routing stay simple. The broker can be a managed service such as AWS IoT Core or Azure IoT, or a self-hosted Mosquitto or EMQX instance when the team prefers to run its own infrastructure. An ingestion service subscribes to the relevant topics, validates each message against an expected schema, and writes it to the database, rejecting malformed data instead of storing it.
Device data is time-series data, and TimescaleDB stores it in PostgreSQL. Readings go into hypertables, which TimescaleDB partitions into time-based chunks automatically. Retention policies drop raw data after a set period, compression shrinks older chunks, and continuous aggregates keep hourly or daily summaries up to date, so a dashboard showing a year of history reads a small summary table instead of every raw sample. Device metadata, firmware versions and ownership live in ordinary relational tables alongside the measurements, joined with plain SQL.
Grafana is usually the fastest route to useful views: fleet health, last-seen times, signal strength, error counts, OTA rollout status and per-device history, with alert rules sending notifications when a device goes quiet or a value leaves its range. It suits engineering, support and operations teams. When the dashboard is part of the product your customers log into, a custom Next.js application gives full control over branding, user accounts, device claiming and multi-tenant access, while reading from the same TimescaleDB data.
Technical Constraints and Trade-offs
- Topic structure is hard to change once devices are in the field, so it is designed with tenancy, access rules and future message types in mind before the first firmware release.
- Raw high-rate data grows quickly. Retention, compression and aggregate resolution are agreed per data type, rather than keeping everything forever by default.
- Grafana is well suited to internal users but has limited branding and custom workflows. Customer-facing dashboards often outgrow it.
- Multi-tenant access must be enforced at every layer: broker topic permissions, database queries and the dashboard itself. Hiding data only in the UI is not access control.
- Devices reconnect, buffer and resend, so ingestion must handle duplicates and out-of-order timestamps without corrupting history.
- Managed brokers reduce operations work but tie the system to a cloud provider's pricing and limits. Self-hosted brokers need monitoring, updates and backups.
Fabrication and Assembly Handoff
- Git repository for the ingestion service, database migrations and any custom dashboard
- Topic and payload specification shared with the firmware team
- TimescaleDB schema, retention and aggregate policies as versioned migrations
- Exported Grafana dashboards and alert rules, ready to re-import
- Broker configuration, access rules and the procedure for issuing device credentials
- Deployment and backup notes for each environment
From a real project
Three-phase smart energy meter: metering IC to cloud
A complete three-phase smart energy meter taken from hardware architecture through firmware to the cloud backend that receives the data. An ATM90E36A metering front-end measures voltage, current, power, energy and harmonics, an ESP32-S3 runs the application, a Quectel EC200U cellular modem provides backhaul and a CC2652P Zigbee radio links neighbouring meters. The server side is an MQTT broker, time-series storage and dashboards, and the deliverables covered firmware through to data reaching the broker plus backend ingestion, storage and dashboards.
Read the project on our PCB division's site (opens in a new tab)How an Electuni Engagement Works
Step 1
Discovery
Requirements analysis and feasibility study.
Step 2
Architecture
System design, component selection, and risk assessment.
Step 3
Design
Schematic, layout, firmware, and mechanical CAD.
Step 4
Review
DFM/DFT checks and design review with stakeholders.
Step 5
Prototype
Board fabrication, assembly, and firmware bring-up.
Step 6
Handoff
Production files, BOM, and full documentation package.
Tools & Technologies
- MQTT
- AWS IoT Core
- Azure IoT
- EMQX / Mosquitto
- TimescaleDB
- Grafana
- Next.js
IoT Dashboard Development FAQ
Should I use Grafana or build a custom IoT dashboard?
Use Grafana when the users are your own engineers, support or operations staff and the priority is useful views and alerts quickly. Build a custom dashboard, for example in Next.js, when customers log in, when branding matters, or when the UI needs workflows such as device claiming, user management or billing. Many products use both on the same database.
Why use TimescaleDB for IoT data?
TimescaleDB is a PostgreSQL extension, so device readings, device metadata and user accounts live in one database queried with standard SQL. Hypertables partition data by time automatically, compression reduces storage for older data, retention policies remove what is no longer needed, and continuous aggregates keep summary tables current for fast long-range charts.
Which MQTT broker should we use?
AWS IoT Core and Azure IoT suit teams already on those clouds and wanting managed certificates and scaling. Mosquitto is a lightweight self-hosted option for smaller fleets. EMQX is a self-hosted or managed broker designed for larger deployments and clustering. The choice depends on fleet size, existing cloud use, and how much infrastructure the team wants to operate.
How do I show OTA update status across a fleet?
Each device reports its firmware version and update state, such as downloading, applied, rolled back or failed, to a status topic. The ingestion service records these events per device, and the dashboard shows rollout progress by version, lists devices that failed or rolled back, and links each one to its history so problems can be investigated.
How is multi-tenant access handled in an IoT dashboard?
Each device and user belongs to a tenant, and that ownership is enforced at every layer. Broker rules restrict each device to its own topics, database queries filter by tenant, for example with PostgreSQL row-level security, and the dashboard's authentication maps each user to their tenant and role. Grafana offers organisations and folder permissions for simpler cases.
Can you build the dashboard if another team wrote the firmware?
Yes, provided the device message format is documented or can be read from the firmware. The first step is a topic and payload specification both sides agree on. If the existing format makes storage or access control difficult, changes are proposed in a form the firmware team can adopt in its next release without breaking devices already deployed.