5 Visualization Tools

Chapter	Topic
Overview	Introduction to IoT data visualization and the 5-Second Rule
Visualization Types	Selecting chart types for different IoT data patterns
Dashboard Design	Information hierarchy, audience design, and accessibility
Real-Time Visualization	Push vs. pull updates, decimation, and performance
Data Encoding & Codecs	Video and audio codecs for IoT media streams
Visualization Tools	Grafana, ThingsBoard, Node-RED, and custom development
Hands-On Labs	ESP32 dashboards with Chart.js and serial visualization

5.1 Learning Objectives

By the end of this chapter, you will be able to:

Evaluate and select appropriate visualization tools based on project requirements
Configure Grafana data sources for IoT time-series databases
Create effective dashboard panels using time-series, gauge, and geomap visualizations
Implement template variables for dynamic, reusable dashboards
Configure alerting rules with appropriate notification channels
Decide when to build custom dashboards vs. using off-the-shelf tools

In 60 Seconds

The dominant IoT visualization tools serve different deployment contexts: Grafana is the de facto standard for time-series monitoring dashboards with deep InfluxDB/TimescaleDB integration; ThingsBoard provides an end-to-end IoT platform with device management and rule engine built in; Node-RED enables rapid prototype dashboards through visual flow programming. The selection rule is straightforward – use Grafana for infrastructure monitoring, ThingsBoard for full IoT platform management, Node-RED for prototyping, and custom code only when none of these meet your specific visualization requirements.

5.2 Key Concepts

Grafana: An open-source analytics and monitoring platform that connects to time-series databases, relational databases, and cloud services via plugins to create IoT dashboards, alerting rules, and on-call escalations
ThingsBoard: An open-source IoT platform combining device management, rule engine, and visualization in one system, with built-in MQTT/HTTP/CoAP device connectivity and a drag-and-drop dashboard builder
Node-RED: A visual flow programming tool from IBM that wires together MQTT inputs, data transformations, and dashboard output widgets through a browser-based graphical interface – ideal for rapid IoT prototyping
Grafana Data Source Plugin: An extension connecting Grafana to a specific database or API (InfluxDB, TimescaleDB, MQTT, REST) by implementing a query interface that translates Grafana’s query model to the source’s native protocol
ThingsBoard Rule Engine: A visual chain of input nodes, filter nodes, and action nodes that process incoming device telemetry and trigger actions (email alerts, dashboard updates, actuator commands) based on configurable conditions
Dashboard Variables: Dynamic parameters in Grafana that allow dashboard users to filter displayed data (e.g., select device ID, time range, location) without modifying the underlying queries, enabling reuse across device fleet
Loki: A log aggregation system designed to work alongside Grafana and Prometheus, enabling correlation of IoT device log streams with time-series metrics in unified dashboards
Custom Dashboard (D3.js/Chart.js): A hand-coded visualization built with JavaScript charting libraries when commercial tools lack required visualization types, custom interaction patterns, or tight embedding requirements

5.3 Minimum Viable Understanding: Choosing Visualization Tools

Core Concept: Tool selection depends on your constraints - Grafana for time-series monitoring, ThingsBoard for full IoT platforms, Node-RED for rapid prototypes, and custom development for unique requirements.

Why It Matters: Choosing Grafana when you need a complete IoT platform means building device management from scratch. Choosing ThingsBoard when you only need charts means learning unnecessary complexity. Match the tool to the job.

Key Takeaway: Start with Grafana for monitoring dashboards (30 minutes to first dashboard). Graduate to ThingsBoard when you need device management. Use Node-RED for prototypes. Build custom only when off-the-shelf tools cannot meet requirements.

For Beginners: Data Visualization Tools

Data visualization tools turn raw IoT numbers into charts, graphs, and dashboards that humans can quickly understand. Think of a weather app that shows temperature as a colorful map instead of a spreadsheet of numbers. Tools like Grafana and D3.js let you create similar visual displays for any sensor data, making it easy to spot trends and problems.

5.4 Introduction

With hundreds of visualization tools available, choosing the right one for your IoT project requires understanding each tool’s strengths and trade-offs. This chapter covers the most popular options for IoT visualization: Grafana for time-series monitoring, ThingsBoard for complete IoT platforms, Node-RED for rapid prototyping, and custom development for unique requirements.

5.5 Tool Comparison Overview

Tool	Learning Curve	Time to Dashboard	Customization	Cost	Best Use Case
Grafana	Medium	30 minutes	Medium	Free/Paid	Time-series monitoring
InfluxDB + Chronograf	Medium	1 hour	Low	Free/Paid	InfluxDB deployments
ThingsBoard	High	2-4 hours	High	Free/Paid	Full IoT platform
Node-RED	Low	15 minutes	Low	Free	Prototypes, demos
Custom (D3.js)	Very High	Days/weeks	Very High	Dev time	Unique requirements

Decision tree for selecting IoT visualization tools based on requirements including time-to-deploy, customization needs, and infrastructure constraints — Flowchart diagram

5.6 Grafana

The industry standard for time-series visualization.

5.6.1 Key Features

Multi-source support: InfluxDB, Prometheus, PostgreSQL, MySQL, MQTT, and 100+ data source plugins (plus panel, app, and other plugin types)
Beautiful, responsive UI: Production-ready out of the box
Powerful query editor: Transformations and calculations
Built-in alerting: Multiple notification channels
Template variables: Dynamic dashboards without code
Annotations: Mark events on charts
User management: Roles and permissions

5.6.2 Strengths

Free and open source (OSS version)
Large community and extensive documentation
Enterprise features available (Grafana Cloud, on-prem Enterprise)
Rapid development - dashboard in minutes

5.6.3 Weaknesses

Focused on time-series (less suitable for non-temporal data)
Limited native mobile app
Complex queries require learning specific query languages

5.6.4 Best For

Time-series IoT monitoring, DevOps metrics, industrial dashboards

5.6.5 Typical Stack

Sensors -> MQTT -> Telegraf -> InfluxDB -> Grafana

5.7 InfluxDB + Chronograf

Native time-series database with integrated visualization.

5.7.1 Key Features

Chronograf UI designed specifically for InfluxDB
Flux query language for advanced transformations
Tight integration with InfluxDB’s TICK stack
Pre-built dashboard templates
Kapacitor integration for alerting

5.7.2 Strengths

Optimized performance for InfluxDB queries
Consistent experience across stack
Time-series specific features (retention, downsampling)

5.7.3 Weaknesses

Locked to InfluxDB (can’t easily use other sources)
Smaller community than Grafana
Less polished UI

5.7.4 Best For

InfluxDB-centric deployments, when you want a complete integrated stack

5.8 ThingsBoard

Open-source IoT platform with built-in dashboards.

5.8.1 Key Features

Full IoT platform: Device management, data collection, dashboards
Widget-based dashboard builder: Drag-and-drop interface
Rule engine: Alerts and automation
Multi-tenancy support: Serve multiple customers
Mobile app: iOS/Android
Integration APIs: HTTP, MQTT, CoAP

5.8.2 Strengths

All-in-one solution (no separate DB, broker, dashboard)
IoT-specific features (device provisioning, firmware updates)
Good for commercial IoT deployments

5.8.3 Weaknesses

Steeper learning curve
Resource intensive
Less flexible for custom data sources

5.8.4 Best For

Complete IoT platform deployments, commercial products, multi-tenant SaaS

5.9 Node-RED Dashboard

Low-code, flow-based dashboard creation.

5.9.1 Key Features

Drag-and-drop dashboard creation
Integrated with Node-RED flow editor
Widgets: gauges, charts, buttons, sliders, forms
Real-time updates via WebSocket
Rapid prototyping

5.9.2 Strengths

Fastest time to first dashboard
No coding required for basic dashboards
Great for demos and quick projects
Excellent for Raspberry Pi and edge devices

5.9.3 Weaknesses

Limited customization without coding
Not suitable for production-scale deployments
Basic UI compared to Grafana/ThingsBoard

5.9.4 Best For

Prototypes, demos, home automation, education, edge dashboards

Mid-Chapter Check: Tool Selection

5.10 Custom Development

Building dashboards from scratch using web frameworks.

5.10.1 Popular Libraries

D3.js: Maximum flexibility, steep learning curve
Plotly.js: Interactive charts, Python integration
Chart.js: Simple, lightweight, good documentation
Apache ECharts: Rich visualizations, good performance
React + Recharts/Victory: Component-based dashboards

5.10.2 Strengths

Complete control over appearance and functionality
Can integrate deeply into existing applications
Custom interactions and workflows
Unique requirements possible

5.10.3 Weaknesses

Significant development time
Ongoing maintenance burden
Need frontend development expertise
Building features that tools provide for free

5.10.4 Best For

Embedded in products, unique UX requirements, existing app integration

5.11 Building a Grafana Dashboard

Now that you understand the landscape of visualization tools, let’s dive into a practical walkthrough of creating a production-ready IoT dashboard with Grafana – the most widely adopted tool for time-series monitoring.

5.11.1 Step 1: Connecting Data Sources

Grafana supports over 100 data source plugins (and many more panel and app plugins). The most common data sources for IoT:

InfluxDB 2.x Connection (bucket and token authentication):

{
  "name": "IoT Sensors",
  "type": "influxdb",
  "url": "http://localhost:8086",
  "jsonData": {
    "version": "Flux",
    "organization": "my-org",
    "defaultBucket": "sensor_data"
  },
  "secureJsonData": {
    "token": "your_influxdb_api_token"
  }
}

InfluxDB 2.x uses buckets and API tokens instead of databases and username/password authentication. If you are using InfluxDB 1.x, replace version, organization, and defaultBucket with database, user, and password fields. The Flux examples later in this chapter assume InfluxDB 2.x.

MQTT Connection (via plugin):

{
  "name": "MQTT Broker",
  "type": "mqtt",
  "url": "mqtt://broker.example.com:1883",
  "topics": [
    "sensors/temperature/#",
    "sensors/humidity/#"
  ]
}

PostgreSQL Connection (for device metadata):

{
  "name": "Device DB",
  "type": "postgres",
  "host": "localhost:5432",
  "database": "iot_devices",
  "user": "grafana"
}

Putting Numbers to It

Grafana Query Performance for 10,000 Sensors at 1-Minute Intervals

Given a fleet of 10,000 sensors reporting every 60 seconds:

Data Ingestion Rate: Total data points per day: \[R_{\text{ingest}} = 10{,}000 \times \frac{60 \times 24}{1} = 14.4 \text{ million points/day}\]

InfluxDB Storage (Float64): Daily storage with 8 bytes per point: \[S_{\text{daily}} = 14.4 \times 10^6 \times 8 = 115.2 \text{ MB/day} \approx 42 \text{ GB/year}\]

Query Window Optimization: Dashboards showing 24-hour window with 5-minute aggregation: \[N_{\text{display}} = \frac{24 \times 60}{5} = 288 \text{ points per series}\]

Compression ratio (60 raw points → 1 aggregated): \[\text{Data Reduction} = \frac{60}{1} = 60\times \text{ fewer points transmitted}\]

Alert Evaluation Cost: Checking 10,000 sensors every 60 seconds: \[\text{Checks/hour} = 10{,}000 \times 60 = 600{,}000 \text{ evaluations/hour}\]

Template Variable Query: Dropdown populating 50 locations from 10,000 sensors: \[T_{\text{query}} \approx 20 \text{ ms (indexed DISTINCT on location field)}\]

Network Bandwidth (dashboard with 10 panels, 288 points each, 5-second refresh): \[B_{\text{dashboard}} = \frac{10 \times 288 \times 12 \text{ bytes}}{5 \text{ s}} = 6.9 \text{ KB/s per viewer}\]

Real-world insight: With 5-minute aggregation, a 24-hour dashboard queries 288 points instead of 1,440 raw points—5× faster rendering while preserving trend visibility. This is why Grafana defaults to $__interval for automatic downsampling.

5.11.2 Step 2: Panel Types

Each panel type serves specific visualization needs.

Time Series Panel: The default for time-based data.

Query:

SELECT mean("temperature")
FROM "sensors"
WHERE $timeFilter
GROUP BY time($__interval), "location"

Options: Multiple Y-axes, thresholds, fill opacity, line width

Use: Temperature trends across multiple rooms

Stat Panel: Single value with optional sparkline.

Query:

SELECT last("occupancy")
FROM "sensors"
WHERE location = 'lobby'

Options: Color thresholds, unit formatting, trend direction

Use: Current building occupancy with change indicator

Gauge Panel: Visual indicator of current value vs. range.

Query:

SELECT mean("battery")
FROM "devices"
WHERE $timeFilter

Options: Min/max, thresholds (green/yellow/red), angle

Use: Average battery level across device fleet

Table Panel: Tabular data with sorting and formatting.

Query:

SELECT device_id, last(temperature), last(battery)
FROM "sensors"
GROUP BY device_id

Options: Column overrides, cell formatting, sorting

Use: Device inventory with current status

Geomap Panel: Geographic visualization.

Query: Must return latitude, longitude, and value

Options: Basemap selection, marker styles, heatmap layers

Use: Vehicle fleet locations with status colors

5.11.3 Step 3: Variables and Templating

Variables make dashboards dynamic and reusable.

Location Variable (dropdown selector):

-- Query to populate variable
SELECT DISTINCT("location") FROM "sensors"

Use in panel query:

SELECT mean("temperature")
FROM "sensors"
WHERE location = '$location' AND $timeFilter

Time Range Variable:

-- Grafana provides $__timeFilter automatically
SELECT mean("value")
FROM "sensors"
WHERE $timeFilter
GROUP BY time($__interval)

Device Variable (multi-select):

-- Allow selecting multiple devices
SELECT DISTINCT("device_id") FROM "sensors"

Dashboard now adapts to user selections without creating separate dashboards for each location or device.

5.11.4 Step 4: Alerting

Grafana alerting evaluates conditions and sends notifications.

Alert Rule Example (High Temperature):

name: High Temperature Alert
condition:
  - query: A
    reducer: last
    evaluator:
      type: gt
      params: [30]
interval: 60s
for: 5m
annotations:
  description: "Temperature in {{ $labels.location }} is {{ $value }}C"
notifications:
  - slack-channel
  - email-oncall

Notification Channels:

Email
Slack
PagerDuty
Webhook (custom integrations)
Microsoft Teams
Telegram

Alert States:

OK: Condition is false
Pending: Condition true but not for duration (“for” period)
Alerting: Condition true for duration, notifications sent
No Data: Query returns no data
Error: Query failed

Grafana dashboard architecture showing data sources connected through queries to panels with alerting and templating components — Flowchart diagram

5.12 Interactive Tool Selection Calculator

Use this calculator to get a personalized tool recommendation based on your project constraints. Adjust the inputs to match your situation and see how each tool scores.

Show code

viewof timeline = Inputs.select(["< 1 day", "1 week", "1-3 months", "> 3 months"], {label: "Project Timeline", value: "1 week"})
viewof scale = Inputs.range([1, 100000], {label: "Number of Devices", step: 1, value: 100})
viewof budget = Inputs.select(["$0", "< $100/mo", "$100-500/mo", "> $500/mo"], {label: "Monthly Budget", value: "< $100/mo"})
viewof teamSkill = Inputs.select(["No coding", "Basic (HTML/CSS)", "Intermediate (JS/Python)", "Advanced (React/D3)"], {label: "Team Skill Level", value: "Intermediate (JS/Python)"})

Show code

toolScores = {
  // Score each tool 0-100 based on constraints
  // Order: [Node-RED, Grafana, ThingsBoard, Custom Dev]
  const timeMap = {"< 1 day": [95,60,20,5], "1 week": [80,90,50,20], "1-3 months": [40,85,90,60], "> 3 months": [20,70,95,95]};
  const t = timeMap[timeline];

  const scaleScore = scale <= 50 ? [90,80,70,60] :
                     scale <= 500 ? [60,90,85,75] :
                     scale <= 5000 ? [20,90,90,85] :
                     [5,85,90,90];

  const budgetMap = {"$0": [95,90,80,70], "< $100/mo": [95,90,85,75], "$100-500/mo": [80,95,90,85], "> $500/mo": [60,90,95,95]};
  const b = budgetMap[budget];

  const skillMap = {"No coding": [90,75,40,5], "Basic (HTML/CSS)": [85,80,55,15], "Intermediate (JS/Python)": [70,90,80,60], "Advanced (React/D3)": [50,85,85,95]};
  const s = skillMap[teamSkill];

  return [
    {tool: "Node-RED", score: Math.round((t[0] + scaleScore[0] + b[0] + s[0]) / 4), color: "#16A085"},
    {tool: "Grafana", score: Math.round((t[1] + scaleScore[1] + b[1] + s[1]) / 4), color: "#3498DB"},
    {tool: "ThingsBoard", score: Math.round((t[2] + scaleScore[2] + b[2] + s[2]) / 4), color: "#E67E22"},
    {tool: "Custom Dev", score: Math.round((t[3] + scaleScore[3] + b[3] + s[3]) / 4), color: "#9B59B6"}
  ].sort((a, b) => b.score - a.score);
}

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1.5rem; border-radius: 8px; font-family: Arial, sans-serif;">
  <h4 style="color: #2C3E50; margin-top: 0;">Tool Recommendation</h4>
  <p style="color: #2C3E50;"><strong>Best match:</strong> ${toolScores[0].tool} (Score: ${toolScores[0].score}/100)</p>
  ${toolScores.map(t => html`<div style="margin: 8px 0;">
    <div style="display: flex; justify-content: space-between; margin-bottom: 2px;">
      <span style="color: #2C3E50; font-weight: bold;">${t.tool}</span>
      <span style="color: #2C3E50;">${t.score}/100</span>
    </div>
    <div style="background: #ddd; border-radius: 4px; height: 24px; overflow: hidden;">
      <div style="background: ${t.color}; width: ${t.score}%; height: 100%; border-radius: 4px; transition: width 0.3s;"></div>
    </div>
  </div>`)}
  <p style="color: #7F8C8D; font-size: 0.85em; margin-bottom: 0;">Scores based on timeline, scale (${scale.toLocaleString()} devices), budget, and team skills. Adjust the inputs above to explore different scenarios.</p>
</div>`

5.13 Tool Selection Decision Guide

With an understanding of what each tool offers, the next step is matching a tool to your specific project. Use this framework to select the right tool:

5.13.1 Start with Requirements

What data sources do you have?
- Time-series databases -> Grafana
- Need complete IoT platform -> ThingsBoard
- Simple prototype -> Node-RED
Who are the users?
- Technical operations -> Grafana
- Business stakeholders -> Custom or ThingsBoard
- Quick demo -> Node-RED
What’s your timeline?
- Need it today -> Node-RED
- Have a week -> Grafana
- Building a product -> ThingsBoard or Custom
What’s your budget?
- Zero budget -> All have free tiers
- Enterprise features needed -> Grafana Enterprise, ThingsBoard PE
- Custom development -> Factor in ongoing maintenance

5.13.2 Migration Path

Most IoT projects follow this progression:

Prototype (Week 1): Node-RED Dashboard for proof-of-concept
Development (Month 1-3): Grafana for operational monitoring
Production (Month 3+): Grafana + custom panels, or ThingsBoard for full platform
Scale (Year 1+): Custom development for unique requirements, Grafana for monitoring

5.14 Best Practices for Tool Usage

5.14.1 Grafana Best Practices

Use template variables for reusable dashboards
Create hierarchical dashboards: Overview -> Category -> Detail
Use folders to organize by team or function
Set up alert rules with appropriate “for” durations to avoid flapping
Use dashboard playlists for NOC displays

5.14.2 ThingsBoard Best Practices

Design rule chains carefully - they can become complex
Use dashboard states for multi-screen workflows
Leverage entity views for multi-tenant deployments
Plan your data model (devices, attributes, telemetry) early

5.14.3 Node-RED Best Practices

Keep flows simple and modular
Use link nodes to connect flows without spaghetti
Back up flows regularly (export to JSON)
Don’t use for production-scale deployments

Match: Visualization Tools and Use Cases

Order: Tool Selection Decision Process

Common Pitfalls

1. Using Grafana for device management and actuator control

Grafana is a read-only visualization and alerting tool – it cannot manage device configuration, send commands to actuators, or store device metadata. Teams that use Grafana for monitoring and then discover they need device management must add a separate IoT platform (ThingsBoard, AWS IoT, Azure IoT Hub). Start with a full IoT platform if device lifecycle management is in scope.

2. Building all dashboards in Node-RED for production use

Node-RED’s dashboard module is designed for prototyping and internal tools, not for production deployments serving many concurrent users. It runs single-threaded, has limited styling control, and lacks enterprise features like row-level security and SSO integration. Use Node-RED to prove concepts quickly, then migrate production dashboards to Grafana or ThingsBoard.

3. Connecting Grafana directly to raw time-series tables without aggregation

Grafana queries on raw sensor tables with billions of rows cause full table scans on every dashboard load. Always connect Grafana to pre-computed continuous aggregates (hourly/daily rollups) for historical charts, and use the raw table only for the most recent time window. Without this architecture, dashboard performance degrades catastrophically as data volume grows.

Worked Example: Migrating from Node-RED Prototype to Production Grafana

Scenario: A smart agriculture startup built a proof-of-concept dashboard in Node-RED (2 hours, 15 sensors, 1 farm). After successful pilot, they need production-ready monitoring for 50 farms × 500 sensors = 25,000 data streams.

Phase 1: Node-RED Prototype (Week 1)

// Node-RED flow (drag-and-drop, no code)
[MQTT Input] → [Parse JSON] → [Gauge Widget] → [Dashboard]

// Advantages:
// - Built in 2 hours
// - Perfect for investor demo
// - Showed concept works

// Limitations discovered:
// - Cannot handle 25,000 sensors (UI lags)
// - No user management (1 dashboard for everyone)
// - No alerting to Slack/PagerDuty
// - No historical query (only real-time)

Phase 2: Production Grafana Deployment (Month 2-3)

Step 1: Infrastructure Setup

# docker-compose.yml
version: '3'
services:
  influxdb:
    image: influxdb:2.7
    volumes:
      - influxdb-data:/var/lib/influxdb2
    environment:
      - DOCKER_INFLUXDB_INIT_MODE=setup
      - DOCKER_INFLUXDB_INIT_USERNAME=admin
      - DOCKER_INFLUXDB_INIT_PASSWORD=${INFLUX_PASSWORD}
      - DOCKER_INFLUXDB_INIT_ORG=SmartAg
      - DOCKER_INFLUXDB_INIT_BUCKET=sensor_data
      - DOCKER_INFLUXDB_INIT_ADMIN_TOKEN=${INFLUX_TOKEN}

  telegraf:
    image: telegraf:1.28
    volumes:
      - ./telegraf.conf:/etc/telegraf/telegraf.conf
    depends_on:
      - influxdb

  grafana:
    image: grafana/grafana:10.2
    ports:
      - "3000:3000"
    volumes:
      - grafana-data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_PASSWORD}
      - GF_USERS_ALLOW_SIGN_UP=false
    depends_on:
      - influxdb

Step 2: Data Pipeline (Telegraf)

# telegraf.conf - Subscribe to MQTT, write to InfluxDB
[[inputs.mqtt_consumer]]
  servers = ["tcp://mqtt.farm.com:1883"]
  topics = ["sensors/#"]
  data_format = "json"

[[outputs.influxdb_v2]]
  urls = ["http://influxdb:8086"]
  token = "$INFLUX_TOKEN"
  organization = "SmartAg"
  bucket = "sensor_data"

Step 3: Grafana Data Source Configuration

{
  "name": "Farm Sensors",
  "type": "influxdb",
  "url": "http://influxdb:8086",
  "jsonData": {
    "version": "Flux",
    "organization": "SmartAg",
    "defaultBucket": "sensor_data"
  },
  "secureJsonData": {
    "token": "$INFLUX_TOKEN"
  }
}

Step 4: Dashboard Design (Multi-Level)

Level 1: Fleet Overview (All 50 Farms)

// Flux query for farm summary
from(bucket: "sensor_data")
  |> range(start: -1h)
  |> filter(fn: (r) => r["_measurement"] == "soil_moisture")
  |> group(columns: ["farm_id"])
  |> mean()
  |> map(fn: (r) => ({
      farm_id: r.farm_id,
      avg_moisture: r._value,
      status: if r._value < 20.0 then "Critical"
              else if r._value < 40.0 then "Warning"
              else "OK"
    }))

Panel Config: Stat panel with color thresholds - Green: >40% (OK) - Yellow: 20-40% (Warning) - Red: <20% (Critical)

Level 2: Single Farm Dashboard (500 Sensors)

// Variable: $farm_id (dropdown populated by query)
from(bucket: "sensor_data")
  |> range(start: -24h)
  |> filter(fn: (r) => r["farm_id"] == "$farm_id")
  |> filter(fn: (r) => r["_measurement"] == "soil_moisture")
  |> aggregateWindow(every: 15m, fn: mean)

Panel Config: Time-series panel with multiple series

Level 3: Sensor Drill-Down (Individual Sensor History)

// Variable: $sensor_id (clicked from Level 2)
from(bucket: "sensor_data")
  |> range(start: -7d)
  |> filter(fn: (r) => r["sensor_id"] == "$sensor_id")
  |> filter(fn: (r) => r["_measurement"] =~ /soil_moisture|temperature|humidity/)
  |> aggregateWindow(every: 1h, fn: mean)

Step 5: Alerting Rules

# Grafana alert: Low soil moisture
apiVersion: 1
groups:
  - name: agriculture_alerts
    interval: 5m
    rules:
      - uid: low_moisture_alert
        title: Low Soil Moisture
        condition: A
        data:
          - refId: A
            queryType: flux
            model:
              query: |
                from(bucket: "sensor_data")
                  |> range(start: -10m)
                  |> filter(fn: (r) => r["_measurement"] == "soil_moisture")
                  |> mean()
        for: 15m  # Must be low for 15 minutes
        annotations:
          description: "Farm {{ $labels.farm_id }} sensor {{ $labels.sensor_id }} moisture: {{ $values.A }}%"
        labels:
          severity: critical
        notificationSettings:
          - uid: slack_channel
          - uid: pagerduty

Step 6: User Management (Multi-Tenancy)

Grafana organizations are managed through the HTTP API (not direct database access):

# Create organization per customer
curl -X POST http://admin:admin@localhost:3000/api/orgs \
  -H "Content-Type: application/json" \
  -d '{"name": "Farm_A"}'

curl -X POST http://admin:admin@localhost:3000/api/orgs \
  -H "Content-Type: application/json" \
  -d '{"name": "Farm_B"}'

# Add user to organization with a role
curl -X POST http://admin:admin@localhost:3000/api/orgs/1/users \
  -H "Content-Type: application/json" \
  -d '{"loginOrEmail": "farmer_a@example.com", "role": "Viewer"}'

curl -X POST http://admin:admin@localhost:3000/api/orgs/1/users \
  -H "Content-Type: application/json" \
  -d '{"loginOrEmail": "manager_a@example.com", "role": "Editor"}'

# Dashboard permissions: Farm_A users see only Farm_A data
# (set via folder permissions in the Grafana UI or API)

Never modify Grafana’s internal SQLite/PostgreSQL database directly. Use the Grafana HTTP API for all organization, user, and permission management.

Results Comparison:

Metric	Node-RED Prototype	Production Grafana
Development time	2 hours	3 weeks
Sensors supported	15	25,000+
Concurrent users	1	500+ (with load balancer)
Historical queries	None	90 days (compressed)
Alerting	None	Slack, PagerDuty, Email
User management	None	Org-based multi-tenancy
Uptime	60% (crashes)	99.9% (HA setup)
Cost per month	$0 (self-hosted)	$150 (InfluxDB Cloud)

Key Lesson: Node-RED excels at rapid prototyping (2 hours to demo), but Grafana’s enterprise features (scaling, alerting, multi-tenancy) are essential for production. Use Node-RED to validate concepts, then migrate to Grafana for deployment.

Migration Checklist:

Node-RED prototype successfully demos concept
Scale requirements exceed Node-RED capabilities (>1,000 data streams)
Multi-user access required (operations, management, customers)
Professional alerting needed (PagerDuty, Slack integration)
Budget approved for infrastructure ($100-500/month)
Team trained on Grafana Flux queries (2-day learning curve)

Decision Framework: Choosing Visualization Tools for Your IoT Project

Decision Stage	Question	If YES →	If NO →
1. Timeframe	Need dashboard working in <1 day?	Node-RED	Proceed to 2
2. Scale	<100 devices?	Node-RED or Grafana	Proceed to 3
3. Data Source	Using InfluxDB/Prometheus/time-series DB?	Grafana	Proceed to 4
4. Multi-Tenancy	Need per-customer dashboards?	ThingsBoard or Custom	Proceed to 5
5. Budget	$0 budget (self-hosted only)?	Grafana OSS	Proceed to 6
6. Custom UX	Need unique branding/UX?	Custom (React + Plotly)	Grafana Enterprise

Tool Selection Matrix:

Tool	Best For	Worst For	Learning Curve	Typical Use Case
Node-RED	Prototypes, demos, edge dashboards	Production scale (>1,000 streams)	1 hour	Proof-of-concept, hackathons
Grafana OSS	Time-series monitoring, DevOps	Complex business logic	4 hours	Operations monitoring
Grafana Enterprise	Enterprise IoT, multi-org	Small projects (overkill)	8 hours	SaaS IoT platform
ThingsBoard CE	Full IoT platform, device management	Just visualization	16 hours	Smart city, industrial IoT
Custom (D3/Plotly)	Unique UX requirements	Standard dashboards	80+ hours	Embedded in product

Cost Comparison (100 devices, 3 users):

Tool	Self-Hosted	Cloud Managed	Annual Cost
Node-RED	Free	N/A	$0
Grafana OSS	Free	Grafana Cloud: $49/mo	$588
ThingsBoard CE	Free	ThingsBoard Cloud: $100/mo	$1,200
Custom Dev	Free	AWS hosting: $50/mo	$15,000 (dev time)

Migration Path (Real-World Progression):

Phase 1: Prototype (Week 1) → Node-RED (2 hours to first dashboard)

Phase 2: Pilot (Month 1-3) → Grafana OSS + InfluxDB (handles 10-100 devices)

Phase 3: Production (Month 6-12) → Grafana Enterprise or ThingsBoard (multi-tenancy, alerting)

Phase 4: Scale (Year 2+) → Custom dashboards embedded in product (unique UX)

Checklist:

Timeframe matches tool complexity (Node-RED for speed, Custom for perfection)
Budget approved (Cloud fees + development time)
Team skills match tool (Flux queries, JavaScript, etc.)
Scalability validated (test with 10× expected load)
Maintenance plan (who updates dashboards when requirements change?)

Common Mistake: Choosing Tools Based on Features, Not Constraints

The Mistake: A startup selects ThingsBoard for their IoT dashboard because it has “the most features” (device management, rule engine, widgets), ignoring that their team has zero Java experience and their 2-week deadline makes the 16-hour learning curve impossible.

Why It Happens:

Feature comparison spreadsheets (more checkmarks = better tool?)
Ignoring learning curve and implementation time
Not considering team skills (JavaScript vs Java vs Flux queries)
Underestimating “time to first dashboard” metric

Real-World Impact:

Scenario: Smart agriculture startup, 2 developers, 2-week deadline for investor demo.

Wrong Choice: ThingsBoard

Week 1: Installing, configuring, reading docs (learning curve)
Week 2: Still struggling with rule engine, no working dashboard
Demo day: Show incomplete prototype, lose investor confidence
Result: Project delayed 6 weeks, lost funding opportunity

Right Choice: Node-RED

Day 1 (2 hours): Working dashboard with 5 sensors
Day 2-3: Polish UI, add features
Day 4-10: Integrate remaining sensors, test
Demo day: Polished, working prototype
Result: Funding secured, migrate to Grafana in Month 2

Decision Matrix: Constraints Over Features:

Your Constraint	Tool Choice	Reasoning
Timeline: <1 week	Node-RED	Fastest time-to-demo
Team: No web dev experience	Grafana	Point-and-click UI
Budget: $0	Grafana OSS or Node-RED	Self-hosted, free
Scale: >10,000 devices	Grafana Enterprise or Custom	Only options that scale
Unique UX required	Custom development	Off-the-shelf won’t match brand

Example Bad Decisions:

Bad Decision 1: Choosing ThingsBoard for a 10-device home automation project - Why Bad: 99% of features unused, massive overkill - Should Use: Node-RED (perfect fit for small scale)

Bad Decision 2: Choosing Node-RED for 5,000-device industrial monitoring - Why Bad: Won’t scale, no user management, no enterprise alerting - Should Use: Grafana Enterprise (built for scale)

Bad Decision 3: Building custom dashboard for standard time-series monitoring - Why Bad: 200+ dev hours to replicate what Grafana does out-of-box - Should Use: Grafana (solves 95% of requirements in 4 hours)

The Fix: Constraint-Based Selection:

Step 1: List YOUR Constraints

Timeline: 2 weeks
Team Skills: JavaScript (yes), Java (no), Python (yes)
Budget: $0 for first 3 months
Scale: 50 devices now, 500 in 6 months
Features Needed: Time-series charts, alerting to Slack
Features Nice-to-Have: Device management, mobile app

Step 2: Filter Tools by Constraints

Node-RED: ✓ Timeline, ✓ JavaScript, ✓ Budget, ✗ Scale (500)
Grafana: ✓ Timeline, ✓ JavaScript, ✓ Budget, ✓ Scale, ✓ Alerting
ThingsBoard: ✗ Timeline (16h learn), ✗ Java, ✓ Budget, ✓ Scale
Custom: ✗ Timeline (weeks), ✓ JavaScript, ✓ Budget, ? Scale

Step 3: Winner = Grafana

Meets all constraints
Handles future scale (500 devices)
Team already knows JavaScript (for custom panels if needed)

Checklist to Avoid This Mistake:

Listed all project constraints (timeline, budget, team skills, scale)
Filtered tools by constraints BEFORE comparing features
Calculated “time to first dashboard” for each tool
Validated team has skills for chosen tool
Tested chosen tool with representative data (not just toy example)
Considered migration path (can we grow with this tool?)

Rule of Thumb: If your constraints eliminate a tool, its features don’t matter. Choose based on what you CAN do, not what the tool CAN do.

Concept Relationships

Visualization tools connect to several related concepts:

Foundational: Visualization Types - Chart types supported by each tool
Parallel: Dashboard Design - Design principles applied within tools
Infrastructure: Time-Series Databases - Data sources for Grafana and ThingsBoard
Practice: Hands-On Labs - Building dashboards with Chart.js and ESP32

Contrast with: Off-the-shelf tools (Grafana, ThingsBoard, quick setup) vs. custom development (D3.js, Plotly, maximum flexibility but higher complexity)

5.15 What’s Next

If you want to…	Read this
Build real-time dashboards with Grafana using live sensor data	Hands-On Labs
Understand real-time rendering techniques for high-frequency data	Real-Time Visualization
Design effective information hierarchies for operator dashboards	Dashboard Design Principles
Understand time-series databases that power Grafana dashboards	Time-Series Databases
Explore stream processing that feeds live dashboard data sources	Stream Processing Fundamentals

5.1 Learning Objectives

5.2 Key Concepts

5.3 Minimum Viable Understanding: Choosing Visualization Tools

5.4 Introduction

5.5 Tool Comparison Overview

5.6 Grafana

5.6.1 Key Features

5.6.2 Strengths

5.6.3 Weaknesses

5.6.4 Best For

5.6.5 Typical Stack

5.7 InfluxDB + Chronograf

5.7.1 Key Features

5.7.2 Strengths

5.7.3 Weaknesses

5.7.4 Best For

5.8 ThingsBoard

5.8.1 Key Features

5.8.2 Strengths

5.8.3 Weaknesses

5.8.4 Best For

5.9 Node-RED Dashboard

5.9.1 Key Features

5.9.2 Strengths

5.9.3 Weaknesses

5.9.4 Best For

5.10 Custom Development

5.10.1 Popular Libraries

5.10.2 Strengths

5.10.3 Weaknesses

5.10.4 Best For

5.11 Building a Grafana Dashboard

5.11.1 Step 1: Connecting Data Sources

5.11.2 Step 2: Panel Types

5.11.3 Step 3: Variables and Templating

5.11.4 Step 4: Alerting

5.12 Interactive Tool Selection Calculator

5.13 Tool Selection Decision Guide

5.13.1 Start with Requirements

5.13.2 Migration Path

5.14 Best Practices for Tool Usage

5.14.1 Grafana Best Practices

5.14.2 ThingsBoard Best Practices

5.14.3 Node-RED Best Practices

Common Pitfalls

Concept Relationships

See Also

5.15 What’s Next