In this guide
Node-RED gives you a dashboard in an afternoon. Then your evaluator asks for user logins, per-device history going back months, email alerts, and a second tenant's devices kept separate — and you realize you are building an IoT platform, not a project. ThingsBoard is the open-source IoT platform that already is one: device management, time-series storage, rule chains, dashboards, and multi-tenancy, ready to run.
This guide covers ThingsBoard's architecture, getting it running, connecting devices over MQTT, building dashboards that demo well, the rule-chain engine for alerts, and how it compares to lighter alternatives.
What ThingsBoard is
ThingsBoard is an open-source IoT platform for device management, data collection, processing, and visualization. The mental model:
- Devices connect (MQTT, HTTP, CoAP) and push telemetry (time-stamped readings) and attributes (rarely-changing properties like firmware version).
- Dashboards visualize telemetry: time-series charts, gauges, maps, tables.
- Rule chains process incoming data: filter, transform, trigger alarms, send notifications.
- Tenants and customers isolate groups of devices and users — the multi-tenancy story Node-RED does not have.
For a final-year project, ThingsBoard turns "sensors publishing MQTT" into a system with logins, history, and alerts in days rather than months. The community edition is free and self-hosted; there is also a managed cloud with a free tier.
Getting it running
ThingsBoard runs as a Java application with a database (PostgreSQL recommended). For students, the practical paths:
- Docker on a VPS or lab server — the documented compose setup gets you running quickly and is the easiest to back up and move.
- Managed cloud free tier — zero server administration; fine for projects that do not need a local deployment story.
- Raspberry Pi — possible for tiny deployments, but the Pi is underpowered for ThingsBoard plus a database under any real load; fine for a demo, not for stress-testing.
Whichever path: the first login uses default credentials that you must change immediately, and if the instance is reachable beyond your local network, put it behind HTTPS before connecting real devices.
Note: ThingsBoard is heavier than it looks. Give it real RAM (the documented minimums are minimums, not suggestions) or you will debug mysterious slowness that is just memory pressure.
Connecting a device over MQTT
Each device in ThingsBoard gets an auto-generated access token. The device publishes telemetry as JSON to a fixed topic structure:
- Telemetry: publish
{"temperature": 27.4, "humidity": 61}to the telemetry topic with the device token as the MQTT username. - Attributes: publish to the attributes topic for semi-static data (firmware version, location label).
- Commands: the platform publishes to a per-device RPC/command topic that the device subscribes to.
The ESP32-side pattern with PubSubClient is the same publish loop you already know — the only ThingsBoard-specific parts are the topic names and the token-as-username. Keep payloads as flat JSON with numeric values; ThingsBoard's charts and rule chains expect numeric values, not strings.
Provisioning tip: create devices in the UI first (or via the REST API for fleets), copy each token into the device firmware or a config file. Never commit tokens to a public repository — a leaked token lets anyone publish fake telemetry as your device.
Dashboards that demo well
ThingsBoard's dashboard builder is widget-based: add an entity (your device), pick widgets, bind them to telemetry keys. The widgets that carry student demos:
- Time-series charts — the workhorse; show the sensor history that proves the system ran, not just that it runs now.
- Gauges and digital cards — current values at a glance.
- Maps — for devices with GPS attributes; a moving asset on a map demos beautifully.
- Alarm widgets — show active alarms from the rule chain; ties the whole story together.
- Control widgets — buttons/sliders wired to RPC commands for actuation.
Dashboard states and layouts let you build one view per audience: an overview for the evaluator, a detailed view for debugging. Keep the demo dashboard to the story — five widgets that show cause and effect beat thirty widgets of raw data.
Rule chains: alerts without a backend
The rule engine processes every incoming message through a visual chain of nodes: filters ("temperature > 40"), transformations ("add a severity field"), and actions ("create alarm," "send email," "publish to another topic").
The pattern every project needs: threshold → alarm → notification → clear. A temperature rule creates an alarm when readings exceed the limit, sends an email, and clears the alarm when readings return to normal. Build this once and you have demonstrated event processing, alerting, and state management with zero backend code.
A second useful chain: data validation at ingestion — drop or flag out-of-range values before they pollute history and charts. Sensor glitches happen; your platform should handle them.
ThingsBoard vs the alternatives
| ThingsBoard | Node-RED dashboard | Custom web app | |
|---|---|---|---|
| Setup effort | Medium (server + DB) | Low | High |
| Multi-device management | Built in | Manual | You build it |
| History & alarms | Built in | Add storage yourself | You build it |
| Multi-tenancy/users | Built in | No | You build it |
| Flexibility | Platform conventions | Total freedom | Total freedom |
Choose ThingsBoard when the project needs to look and behave like a deployed IoT system: multiple devices, history, users, alarms. Choose Node-RED when you need maximum flow-level control and the deployment is small. Build custom only when the brief explicitly demands it.
Tenants, customers, and users: the multi-user story
This is ThingsBoard's structural advantage over lighter dashboards: the hierarchy of tenants, customers, and users.
- A tenant owns devices, dashboards, and rule chains — think of it as one organization. Your project is a tenant.
- Customers subdivide a tenant: customer A sees only their devices and dashboards. For a student project, customers map naturally to demo scenarios — two separate greenhouse installations, or the evaluator's view versus your debug view.
- Users belong to tenants or customers, with roles controlling what they can see and do.
For a final-year project, this hierarchy demos beautifully: create a customer account for the evaluator with a curated dashboard showing only the headline devices, while your admin account keeps the full debugging view. It demonstrates access control — a genuine deployment concern — with zero code.
Practical notes: plan the hierarchy before creating dozens of devices (moving devices between customers later is tedious), use the REST API for bulk device creation rather than clicking through the UI fifty times, and remember the community edition supports this fully — multi-tenancy is not a paid-only feature.
Common mistakes checklist
- Under-provisioned server. Mysterious slowness is usually just insufficient RAM.
- Default credentials left in place. Change them before exposing anything.
- String payloads instead of numbers. Charts and rule comparisons need numeric telemetry.
- Tokens in public repos. Treat device tokens like passwords.
- No data validation in rule chains. One glitching sensor poisons every chart.
- Dashboard sprawl. Curate the demo view; hide the debugging widgets.
- No backup of the database. History is the project's evidence — back it up.
Where to go from here
- Docker student projects beginner guide — run ThingsBoard in containers for clean deployment, easy backups, and a reproducible setup.
- MQTT protocol explained with practical examples — the protocol your devices use to reach the platform.
- More platform builds in the IoT & Embedded branch hub.