InfluxData Blog - Suyash Joshi

When Your Plant Talks Back: Conversational AI with InfluxDB 3

Suyash Joshi (InfluxData) — Tue, 10 Mar 2026 08:00:00 +0000

No one wants to stare at a plant and guess if it needs water. It’s much easier if the plant can say, “I’m thirsty.” A few years ago, we built Plant Buddy using InfluxDB Cloud 2.0. The linked article is still a great guide for cloud-first IoT prototyping as it shows how quickly you can connect devices, store time series data, and build dashboards in the cloud with the previous version of InfluxDB.

But this time, the goal was different. Instead of sending soil moisture data to the cloud, the entire system runs locally using the latest InfluxDB 3 Core, similar to a modern industrial setup powered by LLM for a natural conversational interaction.

The architecture: the “factory” at home

In real factories, raw PLC data is captured at the edge, often using MQTT and a local database. That same architecture now powers PlantBuddy v3 with the following setup.

Edge Device (ESP32 / Arduino): Works like a small PLC. It reads soil moisture and publishes the plant’s state to the network without knowing anything about the database.
Soil Moisture Sensor (Analog): Outputs an analog signal based on soil moisture. The microcontroller converts it to digital using its built-in ADC.
Message Bus (Mosquitto MQTT): Handles publish/subscribe communication. The Arduino publishes data to the broker (running locally), and Telegraf subscribes to forward data to the database.
Database (InfluxDB 3 Core): Runs locally in Docker as a high-performance time series database storing all sensor readings.
User Interface (Claude + MCP): Enables natural language queries. Instead of writing SQL, questions about plant health can be asked conversationally.

1. Collecting & Sending Data from the Edge

To make this scalable, I treat the sensor data like an industrial payload. It’s not just a number; it’s a structured JSON object containing the ID, raw metrics, and a pre-calculated status flag.

The Arduino Payload

{ 
"id": "pothos_01",    // Device identifier (like a PLC tag) 
"raw": 715,  		// Raw ADC value (0-1023) 
"pct": 19,  		// Calculated moisture percentage 
"stat": "DRY_ALERT"   // Pre-computed status 
}

Why compute status at the edge? In factories, PLCs make local decisions (e.g., stop motor, trigger alarm). Here, the Arduino determines “DRY_ALERT” so the database can trigger alerts without recalculating thresholds.

2. The Ingest Pipeline

Below are two approaches to send plant data to InfluxDB. In this project, I went with MQTT and Telegraf, which are more standard for an industrial setup.

Telegraf acts as the gateway, subscribing to the MQTT broker and translating the JSON into InfluxDB Line Protocol. This configuration is identical to what you’d see in a manufacturing plant monitoring vibration sensors.

# telegraf.conf - Complete Working Example
[agent]
  interval = "10s"
  flush_interval = "10s"

[[inputs.mqtt_consumer]]
  servers = ["tcp://127.0.0.1:1883"]
  topics = ["home/livingroom/plant/moisture"]
  data_format = "json"

  # Tags become indexed dimensions (fast filtering)
  tag_keys = ["id", "stat"]

  # Fields become measured values
  json_string_fields = ["raw", "pct"]

[[outputs.influxdb_v2]]
  urls = ["http://127.0.0.1:8181"]
  token = "$INFLUX_TOKEN"
  organization = "my-org"
  bucket = "plant_data"

Note: If Telegraf runs in Docker, use host.docker.internal:8181 to reach the database.

3. Time Series Database: InfluxDB 3 (Docker Container)

InfluxDB 3 Core runs locally in Docker as the time series database. It stores soil moisture readings and enables real-time analytics, all without depending on external cloud connectivity.

# Create persistent storage 
mkdir -p ~/influxdb3-data

# Run InfluxDB 3 Core with proper configuration
docker run --rm -p 8181:8181 \
  -v $PWD/data:/var/lib/influxdb3/data \
  -v $PWD/plugins:/var/lib/influxdb3/plugins \
  influxdb:3-core influxdb3 serve \
    --node-id=my-node-0 \
    --object-store=file \
    --data-dir=/var/lib/influxdb3/data \
    --plugin-dir=/var/lib/influxdb3/plugins

4. The “AI” Interface: InfluxDB MCP & Claude

Instead of writing SQL queries or building dashboards, the system connects an LLM to InfluxDB through the Model Context Protocol (MCP). I’ve written another blog post on how to connect InfluxDB 3 to MCP, which you can find here.

Now the question isn’t: “What’s the SQL query for average soil moisture over the last 24 hours?”

It becomes: “Has the plant been dry today?”

The LLM generates the correct SQL under the hood. If needed, the generated query can be inspected. This makes time series analytics accessible through conversation.

claude_desktop_config.json

{
  "mcpServers": {
    "influxdb": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "--interactive",
        "--add-host=host.docker.internal:host-gateway",
        "--env",
        "INFLUX_DB_PRODUCT_TYPE",
        "--env",
        "INFLUX_DB_INSTANCE_URL",
        "--env",
        "INFLUX_DB_TOKEN",
        "influxdata/influxdb3-mcp-server"
      ],
      "env": {
        "INFLUX_DB_PRODUCT_TYPE": "core",
        "INFLUX_DB_INSTANCE_URL": "http://host.docker.internal:8181",
        "INFLUX_DB_TOKEN": "YOUR_RESOURCE_TOKEN"
      }
    }
  }
}

The Result:

What’s next

In the next post, we will upgrade this Plant Buddy project to do more than passively monitor. New features will include:

A water pump, motor, and small display.
Automatic watering when the plant enters DRY_ALERT.
An extended system with light and temperature sensors to determine how placement of the potted plant affects its health, especially during trips when no one is home.

Try to build one yourself with InfluxDB 3! We would love to hear your questions/comments in our community forum, Slack, or Discord.

The "Now" Problem: Why BESS Operations Demand Last Value Caching

Suyash Joshi (InfluxData) — Thu, 26 Feb 2026 08:00:00 +0000

Battery Energy Storage Systems (BESS) represent one of the most unforgiving environments for real-time data. Unlike a passive asset, a battery is a complex electrochemical system where safety and revenue are determined by split-second decisions. In this context, “average” latency can become a serious problem. Performance depends entirely on one key question:

“What is happening right now?”

For grid operators, Energy Management Systems (EMS), and trading desks, this is the most critical question. To answer it, operations teams rely on dashboards that answer:

Safety & Health: What is the current State of Health (SoH) of my BESS operations? Is the site healthy, or are there active thermal alarms?
Bottlenecks: What is limiting performance right now? (Is it a Power Conversion System [PCS] derate, a specific rack, or a container-level issue?)
Revenue: What is the precise State of Charge (SoC) available for immediate dispatch?

The challenge: the “latest value” bottleneck

“Current state” dashboards create a punishing workload for standard time series databases. A single utility-scale site might generate 50,000+ distinct signals (high cardinality) from cells, inverters, and meters. To display a “Live View,” the database must repeatedly scan recent data on disk to find the most recent timestamp for every single one of those signals.

At the site level, this is difficult. At fleet scale with more assets, more concurrent users, and millions of streams, this “scan-for-latest” pattern becomes a crippling bottleneck.

The solution: Last Value Cache

InfluxDB 3 solves this architectural conflict with its built-in Last Value Cache (LVC). Instead of scanning historical data to compute the current state, LVC automatically caches the most recent values (or the last N values) in memory for your critical signals. This ensures that “current state” queries remain sub-millisecond (< 10ms) and consistent, regardless of write throughput or fleet size, bridging the gap between historical analysis and real-time situational awareness.

How to use InfluxDB’s Last Value Cache (LVC) in memory for BESS operations

1. Define Your “Hot” Signals

Don’t cache everything. Pick the specific high-leverage fields that power your “Current State” dashboards and safety alerts, for example:

Safety: Cell Temperature (temp_c), Voltage (volts), Alarm Severity (alarm_level)
Performance: State of Charge (soc), State of Health (soh), Inverter Mode (inv_state)
Ops: Comms Heartbeat (last_seen), Charge/Discharge Limits (p_limit_kw)

2. Design Your Keys

Choose the columns that define how operators slice the system. These will become your cache keys.

Best Practice: Match your dashboard filters. If your dashboard filters by site_id → container_id → rack_id, those are your keys.

Cardinality Note: Keep keys efficient. While InfluxDB 3 handles high cardinality exceptionally well, unnecessary keys (like a unique transaction_id per second) waste memory. Stick to asset identifiers.

3. Shape the Cache Behavior

Configure the cache to match your visualization needs:

count:
- Set to 1 for Gauges, Status Lights, and “Single Value” tiles.
- Set to 3–10 for “Sparklines” (mini-charts) where operators need to see the immediate trend (e.g., “Is voltage diving or stable?”).
ttl (time-to-live): Define when data becomes “stale.” If a sensor stops reporting, how long should the dashboard show the last value before switching to “Offline/Unknown”? (e.g., 30s for safety, 1h for capacity).

4. Create the Cache

Create the Last Value Cache using the UI explorer, HTTP API or the CLI.

influxdb3 create last_cache \
  --database bess_db \
  --table bess_telemetry \
  --token AUTH_TOKEN \
  --key-columns site_id,rack_id \
  --value-columns soc,temp_max,alarm_state \
  --count 5 \
  --ttl 30s \
  bess_ops_lvc

Key arguments:

Database name: bess_db
Table name: bess_telemetry
Cache name: bess_ops_lvc
Key columns: site_id, rack_id (field keys to cache)
Value columns: soc, temp_max, alarm_state (field values to cache)
Count: 5 (the number of values to cache per unique key column combination, range 1-10)
TTL: 30s (time duration until data becomes stale)
Token: InfluxDB 3 authentication token

5. The “Warm Cache” Advantage

Unlike a standard cache that starts empty, LVC in InfluxDB 3 is “warm” by default.

On creation: It instantly backfills from existing data on disk.
On restart: It automatically reloads the state.

Why it matters: Ops teams never see “blank” dashboards after a maintenance window. The system is ready the moment it comes back online.

6. Querying the Cache

Use standard SQL and last_cache() function that replaces complex analytical queries with a simple lookup.

influxdb3 create last_cache \
  --database bess_db \
  --table bess_telemetry \
  --token AUTH_TOKEN \
  --key-columns site_id,rack_id \
  --value-columns soc,temp_max,alarm_state \
  --count 5 \
  --ttl 30s \
  bess_ops_lvc

7. Architecture: Built for Scale Using InfluxDB 3 Enterprise

Last Value Cache can help separate heavy “writing” from “reading” workloads:

Dedicated Ingest Nodes: Handle the massive flood of 1Hz sensor data.
Dedicated Query Nodes: Host the LVC in memory to serve dashboards instantly.

influxdb3 create last_cache \
  --database bess_db \
  --table bess_telemetry \
  --token AUTH_TOKEN \
  --node-spec "nodes:query-01,query-02" \
  --key-columns site_id,rack_id \
  --value-columns soc,temp_max,alarm_state \
  --count 5 \
  --ttl 30s \
  bess_ops_lvc

The benefit: Heavy write loads (e.g., a fleet-wide firmware update logging millions of events) will never slow down the control room’s live view.

The value of LVC

In BESS operations, latency isn’t just a delay; it’s a risk. InfluxDB 3’s Last Value Cache eliminates that risk by serving the “current state” of your entire fleet instantly from memory, removing the need for complex external caching.

When you’re ready to start building, download InfluxDB 3 Enterprise, or contact us to talk about running a proof of concept.

From Legacy Data Historians to a Modern, Open Industrial Data Stack

Suyash Joshi (InfluxData) — Thu, 12 Feb 2026 08:00:00 +0000

We recently sat down with founder and principal consultant at recultiv8, Coenraad Pretorius, who drew on his years of data engineering experience in the manufacturing and energy sectors to share key industrial IoT insights. In this article, I list the top takeaways; you can also watch the full webinar recording here.

The challenge with traditional data historians

Industrial systems generate large volumes of time series data from machines, sensors, and control systems. Historically, this data has been managed using proprietary data historian platforms.

These systems often lead to the following challenges:

Complexity: Traditional stacks involve many tightly coupled components: SCADA systems, OPC servers, historians, data extraction tools, and analytics layers. Each layer requires specialized skills, making systems difficult to debug, extend, or modernize.
High cost: Per-tag licensing, annual maintenance fees, and specialized training significantly increase the total cost of ownership, particularly as systems scale.
Slow time to insight: Extracting and analyzing data often takes days or weeks, delaying decisions and limiting optimization opportunities.
The analytics gap: Traditional historians prioritize data storage, not data analysis. Common pain points include proprietary query languages, reliance on Excel exports, overloaded BI integrations, and additional licensing for advanced features. As a result, time to action is measured in days or weeks rather than hours, which is an unacceptable delay for modern industrial operations.

Data Historian Technical Architecture

A modern, open architecture: edge + cloud

To address these limitations, Coenraad presented a modern architecture built around InfluxDB 3, open source tooling, and cloud analytics. The core idea is a clear separation of responsibilities that leads to improved performance, security, cost efficiency, and scalability while keeping systems simpler and easier to operate.

Edge systems handle real-time ingestion, short-term storage, and operational dashboards close to the data source.
Cloud systems handle long-term storage, historical analysis, and advanced analytics without impacting operational performance.

Modern IIoT Technical Architecture

Example from Coenraad’s case study

Typical deployment setup

Four OPC UA servers
10k+ tags
Windows-based servers
Telegraf running as Windows service

Configuration approach

Split config files (agent, inputs, outputs)
Custom Starlark processor for schema management
Environment variables for cloud credentials

Result: Rapid implementation of the modern data stack using open source solution resulted in saving $70k (once off) and $5 (annually).

Why this approach works

This modern stack delivers several practical benefits:

Simpler systems built with familiar tools like SQL and Python that most developers are familiar with.
Faster dashboards move from multi-second load times to near instant response as detailed in this blog post.
Lower costs are incurred by replacing proprietary licensing with open source and consumption-based services.
Flexible data pipelines use Telegraf to ingest data from industrial protocols such as OPC UA, MQTT, and Modbus into InfluxDB Core with optional streaming to the cloud.

Recap

The difference is fairly cut and dry: traditional data historians often limit agility and slow down insights, while modern industrial data stacks focus on speed, openness, and maintainability by separating edge operations from cloud analytics and using familiar, developer-friendly tools. For industrial and IIoT teams, modernizing the data pipeline is now foundational. To learn more, read the Teréga case study and connect with our community in the InfluxDB forums.

Building with the InfluxDB 3 MCP Server & Claude

Suyash Joshi (InfluxData) — Fri, 30 Jan 2026 08:00:00 +0000

InfluxDB 3 Model Context Protocol (MCP) server lets you manage and query InfluxDB 3 (Core, Enterprise, Dedicated, Serverless, Clustered) using natural language through popular LLM tools like Claude Desktop, ChatGPT Desktop, and other MCP-compatible agents.

The setup is straightforward. In this article, we will focus on setting up InfluxDB 3 Enterprise using Docker with Claude Desktop.

Prerequisites

Install InfluxDB 3 Enterprise using Docker (if you’re a new user, try out our free trial) on your machine by running the installer script:

curl -O https://www.influxdata.com/d/install_influxdb3.sh && sh install_influxdb3.sh enterprise

InfluxDB 3 Explorer UI will also make it easier to manage InfluxDB operations, so it’s recommended that you install it (using Docker) during initial setup or afterwards.

1. Create an InfluxDB 3 token for MCP server

The easiest way to create a scoped token is within InfluxDB 3 Explorer UI.

Open Explorer at http://localhost:8888.
Go to Manage Tokens.
Create a Database (resource) token with read (and optional write) permissions for the databases you want your LLM to access.
Copy the token string and store it securely; the MCP server will use it as INFLUX_DB_TOKEN.

Alternatively, you can run the following command inside a Docker container to create the token.

docker exec -it YOUR_CONTAINER_ID influxdb3 create token \
  --permission "db:DATABASE1,DATABASE2:read,write" \
  --name "Read-write on DATABASE1, DATABASE2" \
  --token YOUR_ADMIN_TOKEN \
  --expiry 1y

Security Tip: Use resource tokens with the minimum required permissions and an expiration date, rather than providing a full admin token to the LLM MCP.

2. Configure the Claude Desktop MCP server (Docker) for InfluxDB 3 Enterprise

The InfluxDB 3 MCP server runs as a separate service and can be started using either Node.js or Docker. We will use Docker, as it’s already running InfluxDB 3 and Explorer UI.

Open Claude Desktop.
Navigate to Settings → Developers → Edit Config
Open the Claude Desktop configuration file, add the following to the existing file, save, and restart Claude Desktop.

{
  "mcpServers": {
    "influxdb": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "--interactive",
        "--add-host=host.docker.internal:host-gateway",
        "--env",
        "INFLUX_DB_PRODUCT_TYPE",
        "--env",
        "INFLUX_DB_INSTANCE_URL",
        "--env",
        "INFLUX_DB_TOKEN",
        "influxdata/influxdb3-mcp-server"
      ],
      "env": {
        "INFLUX_DB_PRODUCT_TYPE": "enterprise",
        "INFLUX_DB_INSTANCE_URL": "http://host.docker.internal:8181",
        "INFLUX_DB_TOKEN": "YOUR_RESOURCE_TOKEN"
      }
    }
  }
}

3. Use Claude with InfluxDB via MCP

Once restarted, verify that Claude can access the InfluxDB 3 MCP server by chatting with it.

Finally, you can interact with the database however you’d like, such as performing operations, getting analytics, etc., using natural language. Try the following prompts:

“List all the databases and permissions you have access to.”
“Show me the schema for the sensor_data table.”
“Analyze bitcoin sample data price in the last 30 days.” You can also see the actual SQL query that gets executed.

Connecting other LLMs

In this article we used Claude Desktop, but the InfluxDB 3 MCP server itself is generic. Any LLM agent that supports the Model Context Protocol can be used. For example, ChatGPT Desktop. In a follow-up article, we’ll cover how to run the MCP server and an LLM locally using other tools. We would love to hear your comments/questions, etc., on our community website, Slack, or Discord.

Optimizing BESS Operations: Real-Time Monitoring & Predictive Maintenance with InfluxDB 3

Suyash Joshi (InfluxData) — Tue, 13 Jan 2026 08:00:00 +0000

For IT and OT engineers managing Battery Energy Storage Systems (BESS) and other distributed energy resources (DER), the challenge isn’t just dealing with energy. It’s a data problem, or managing the massive stream of real-time telemetry these systems generate. For example, a BESS site produces a constant stream of time-series data from BMS, PCS, SCADA, EMS, and more, and operating it means ingesting, correlating, and acting on that data in real time. And this challenge changes with scope. At a single site, telemetry drives asset health and safe operation—from cell temperatures to inverter vibration. At fleet scale, the same data supports coordinated operations and incident response across sites. When retained at full resolution, it also enables historical analysis for degradation tracking, predictive maintenance, and long-term optimization.

Data flows from Operational Technology (OT) signals to Information Technology (IT) systems. Most BESS operators already run a slew of disparate systems:

BMS answers: Are the batteries safe and healthy?
PCS answers: Can I deliver or absorb power?
EMS answers: When should I charge or discharge?
SCADA answers: What’s happening right now on site?

Individually, these systems work well. The problem starts when you need a unified, time-aligned view across all of them, especially across multiple sites. InfluxDB sits at the center as a shared time series platform, consolidating telemetry from all sources and serving it to operations, analytics, and automation workflows.

One popular architecture: TIG (Telegraf → InfluxDB → Grafana)

A typical pattern for BESS telemetry is the TIG stack, because it cleanly separates collection, storage/query, and visualization and scales from a single site to a fleet.

Telegraf (Collection + Normalization)

Telegraf acts as a lightweight collection agent at the edge or in your DMZ, with plugins for common OT and IoT protocols (Modbus, OPC-UA, MQTT, SNMP, HTTP). Use it when you want: Fast onboarding of new signals without writing custom collectors Store-and-forward style buffering patterns at the edge (architecture-dependent) A consistent metric format before data hits your central platform

InfluxDB 3 (The Time Series Database)

InfluxDB is where BESS telemetry becomes operationally usable, offering:

High-speed ingestion so you don’t drop high-frequency telemetry during bursts (faults, transients, dispatch changes).
High-cardinality modeling so you can tag by site/rack/module/cell/inverter.
SQL support so IT/data teams can query using familiar tools and patterns (and integrate with BI/analytics stacks).
Low-latency “hot path” reads using Last Value Cache and Distinct Value Cache for dashboards that need current state now (SoC, alarms, inverter status, thermal conditions).
Scalable: Deploy a single InfluxDB 3 Core or multiple-node Enterprise cluster as per your needs.

Grafana (or Power BI/Apache, SuperSet, etc.)

Grafana turns fast queries into multi-panel dashboards commonly used for:

Live SoC/power/dispatch tracking
Temperature gradients and thermal risk monitoring
Voltage spreads, imbalance indicators, and fault timelines
Per-site and fleet rollups with consistent tags

Real-time data processing: anomaly detection for predictive maintenance

Traditionally, predictive maintenance required a complex pipeline: extracting data to a separate Python application server, running analysis, and writing results back. This adds latency, maintenance overhead, and security risks.

InfluxDB 3 Core & Enterprise brings the data processing to where the data lives.

Using the Processing Engine and ready-made plugins, you can perform stream processing within the database infrastructure.

Real-Time Detection: As shown in the “Anomaly Detector” toggle in our demo, the system can identify thresholds (e.g., Temp > 80°C or Vibration Drift) in real-time as data arrives.
Simplified Architecture: You eliminate the need for an external Python application server or complex stream-processing clusters (such as Kafka or Flink) to detect spikes.
Operational Plugins: Beyond anomaly detection, plugins handle tasks like downsampling (converting 10 ms raw data into one-minute averages for long-term storage) and alerting without leaving the platform.

Overview

BESS operations depend on fast, reliable, and time-aligned telemetry. InfluxDB 3 provides a single platform to support real-time monitoring, anomaly detection, and forecasting at fleet scale without adding unnecessary complexity to your data pipeline. If you’re building or operating real-time BESS data systems, you may find our customer case study on ju:niz energy helpful. As always, we’d love to hear your questions/comments or see what you have built on Slack, Discord, and our Community Forum.

Performing Real-Time Anomaly Detection with InfluxDB 3: An In-Depth Guide

Suyash Joshi (InfluxData) — Fri, 02 Jan 2026 08:00:00 +0000

If you’re working with sensors, machines, or embedded systems, your primary goal is simple: no unplanned downtime and smooth operations. This means detecting errors and taking action as soon as possible, ideally preventing them through predictive maintenance before they become critical issues.

This is where anomaly detection becomes essential. In this blog, we will take a deep dive into anomaly detection using two ready-to-use Python plugins for real-world IoT use cases. We will be leveraging the Python Processing Engine within InfluxDB 3 Core or Enterprise. This means you can detect outliers, level shifts, and unusual patterns without ever leaving your database, simplifying your streaming data process and pipeline right where the data lives.

Understanding the anomaly detection landscape

Before diving into the plugins, let’s look at where these approaches fit in the broader anomaly detection ecosystem.

The Three Approaches to Anomaly Detection

For most industrial IoT, infrastructure monitoring, and operational scenarios, proven statistical and classical ML methods are not just “good enough,” they’re often the better choice because they’re reliable, battle-tested in production for decades, explainable (engineers understand why alerts were fired), and they deploy and receive alerts right away without training ML models, etc.

How to use MAD and ADTK plugins in InfluxDB 3

1. Start InfluxDB 3 with the Processing Engine Enabled

Choose a directory for plugins and start the server with it:

influxdb3 serve \
  --plugin-dir ~/.influxdb3/plugins \
  # other flags...

2. Install Python Dependencies into the Processing Engine

# For notifications (optional)
influxdb3 install package httpx twilio

# For ADTK plugin
influxdb3 install package adtk
influxdb3 install package pandas

# For MAD plugin
influxdb3 install package requests

3. Add Plugins to the Plugin Directory

Clone the influxdb3_plugins GitHub repository and copy the plugin files you need. For example, copy them into your PLUGIN_DIR or use them directly from GitHub.

4. Access and Configure Plugins From the Plugin Library

Use InfluxDB Explorer or by following the steps below in your local console.

MAD plugin for real-time spike detection

The MAD-Based Anomaly Detection Plugin provides real-time anomaly detection for time series data in InfluxDB 3 using Median Absolute Deviation (MAD), which is a pure statistical approach.

Example use case: Get instant alerts when temperature suddenly spikes above the normal range.

Step 1: Set up notification handler (separate plugin for alerting purpose)

influxdb3 create trigger \

 --database sensors \

 --plugin-filename gh:influxdata/notifier/notifier_plugin.py \

 --trigger-spec "request:notify" \

 notification_trigger \

 --token YOUR_TOKEN

influxdb3 enable trigger --database sensors notification_trigger --token YOUR_TOKEN

Step 2: Create MAD detector (runs on every write)

influxdb3 create trigger \

  --database sensors \

  --plugin-filename gh:influxdata/mad_check/mad_check_plugin.py \

  --trigger-spec "all_tables" \

  --trigger-arguments \

    'measurement=environment,\

     mad_thresholds=temperature:2.5:20:5,\

\     senders=slack,\

     slack_webhook_url=https://hooks.slack.com/services/YOUR/WEBHOOK/URL,\

     influxdb3_auth_token=YOUR_TOKEN' \

  temperature_spike_detector \

  --token YOUR_TOKEN

influxdb3 enable trigger --database sensors temperature_spike_detector --token YOUR_TOKEN

What this does:

temperature:2.5:20:5 = monitor temperature field, flag if 2.5× MAD away from median, use 20-point window, alert after 5 consecutive anomalies
Triggers on every write for instant detection

Step 3: Write test data

# Establish normal baseline (22°C)

for i in {1..25}; do

  influxdb3 write --database sensors --token YOUR_TOKEN \

    "environment,room=factory temperature=22.$((RANDOM % 5))"

done

# Simulate equipment failure (sudden spike to 45°C+)

for temp in 46 47 48 49 50; do

  influxdb3 write --database sensors --token YOUR_TOKEN \

    "environment,room=factory temperature=${temp}.0"

done

Expected result: You should see an “anomaly detected” alert in InfluxDB 3 Logs and also in the Slack channel after the fifth spike: “MAD count alert: Field temperature in environment outlier for 5 consecutive points”.

ADTK plugin for detecting sustained instability

This plugin is built on top of the popular time series machine learning library, Anomaly Detection Toolkit (ADTK).

Example use case: Detect when temperature becomes erratic/unstable (e.g., sensor malfunction causing wild swings).

Step 1: Create ADTK detector (scheduled every 30 seconds)

influxdb3 create trigger \

  --database sensors \

  --plugin-filename gh:influxdata/stateless_adtk_detector/adtk_anomaly_detection_plugin.py \

  --trigger-spec "every:30s" \

  --trigger-arguments \

    "measurement=environment,\

     field=temperature,\

     detectors=VolatilityShiftAD,\

     detector_params=eyJWb2xhdGlsaXR5U2hpZnRBRCI6IHsid2luZG93IjogMTV9fQo=,\

     window=600s,\

     senders=slack,\

     slack_webhook_url=https://hooks.slack.com/services/YOUR/WEBHOOK/URL,\

     influxdb3_auth_token=YOUR_TOKEN" \

  temperature_stability_detector \

  --token YOUR_TOKEN

influxdb3 enable trigger --database sensors temperature_stability_detector --token YOUR_TOKEN

What this does: * Checks every 30 seconds (scheduled trigger) * Analyzes last 10 minutes of data (window=600s) * Detects when variance shifts (stable → erratic)

Step 2: Write Test Data

# Stable readings (±2°C variation)

for i in {1..15}; do

  influxdb3 write --database sensors --token YOUR_TOKEN \

    "environment,room=factory temperature=$((20 + RANDOM % 5)).5"

done

# Erratic readings (wild swings indicating sensor malfunction)

for temp in 5.2 35.8 8.5 40.3 12.1 38.7 7.9 42.4 6.6 44.3; do

  influxdb3 write --database sensors --token YOUR_TOKEN \

    "environment,room=factory temperature=${temp}"

done

Expected result: Within 30 seconds, you should get a Slack alert → “Volatility shift detected in environment.temperature.”

Why use these plugins together?

MAD catches acute problems such as immediate dangers, hazards, etc.
ADTK catches chronic problems such as sensor degradation over time.

Next steps

Customize this ready-to-use Anomaly Detection Plugin for your use case:

MAD Plugin Documentation (adjust MAD multiplier (k) for sensitivity)
ADTK Plugin Documentation (change ADTK window size for different time horizons)

You now have a production-ready anomaly detection system running in your database with no separate infrastructure. We invite you to clone/form the plugins in the GitHub repository, publish your own plugins for others to use, and share your questions and projects with our web community on our Slack and Discord channels.

Master the Basics of InfluxDB 3 with These Two Free Courses

Suyash Joshi (InfluxData) — Fri, 05 Dec 2025 08:00:00 +0000

If you’ve been wanting to build your skills with InfluxDB 3, InfluxDB University now has two new free courses that make learning simple, clear, and hands-on. Each course includes short videos and interactive quizzes to help you learn at your own pace.

Both courses go beyond the basics and walk you step-by-step through real examples so you can start using InfluxDB 3 Core & Enterprise along with the Processing Engine with confidence.

Course: InfluxDB 3 Core & Enterprise Essentials

This fundamentals course helps you understand the architecture and features of both InfluxDB 3 Core and Enterprise. You’ll learn:

The structure and key differences between the two editions
How to install and use InfluxDB 3 with the CLI and UI Explorer
How the InfluxDB 3 data model works
How to write and query time series data using SQL
How caching improves performance
An introduction to the Processing Engine

Course: Processing Engine Essentials

The Processing Engine is one of the most powerful features of InfluxDB 3, allowing you to run Python directly in the database. This course shows you how to use it effectively, including:

The basics of how the Processing Engine works
Different trigger types and when to use them
Step-by-step guides for WAL Flush, Schedule and HTTP triggers
How to create a custom Python plugin
How to use community and InfluxData built plugins with the UI Explorer
How the Processing Engine APIs fit into real workflows

Bonus: earn shareable badges

When you finish each course, you’ll receive a verified badge you can add to your LinkedIn profile or portfolio. It’s a simple way to show that you understand the latest version of InfluxDB and its key features.

Start learning for free today

InfluxDB University is completely free; just sign up and begin. These new courses are the easiest way to get hands-on with InfluxDB 3 and its Processing Engine, with clear explanations and guided examples.

If you have any questions or feedback, we’re always happy to help. You can reach the team at university@influxdata.com.

Happy learning!

Smart Home Monitoring with InfluxDB 3, Google Nest, and Grafana

Suyash Joshi (InfluxData) — Tue, 25 Nov 2025 08:00:00 +0000

Your smart home devices generate vast amounts of scattered data—this tutorial shows you how to centralize it into a unified platform using InfluxDB 3 and Grafana. You’ll not only track your home’s vital signs but also learn professional software development concepts, such as time series database design and building resilient data pipelines, applicable to various monitoring and analytics systems. Before we begin, ensure you have:

Basic familiarity with Python and API concepts
Administrative access to your router (for bandwidth monitoring)
At least one smart device (Nest thermostat, smart meter, etc.)
A computer or Raspberry Pi to run InfluxDB 3, Grafana, and Python programs

Understanding what you’re working with

Time series data differs fundamentally from traditional relational data. Instead of focusing on relationships between entities, we’re capturing how values change over time. Each data point consists of:

Timestamp: When the measurement was taken
Measurement: What we’re measuring (temperature, power, bandwidth)
Tags: Metadata that helps us categorize data (device_id, location, type)
Fields: The actual values measured

This structure makes InfluxDB handy for IoT data because it’s optimized for write-heavy workloads with time-based queries. We define this in a syntax called “line protocol,” and it looks like this:

weather,location=london,season=summer temperature=30 1465839830100400200

Understanding this syntax:

“weather” is the name of your database table, also known as a measurement.

“location=london,season=summer” are key-value pairs or ‘tag sets’ separated by a comma that provide metadata.

“temperature=30” is the fieldset, which is the actual data set.

“1465839830100400200” is optional; it’s actually the timestamp 2016-06-13T17:43:50.1004002Z in RFC3339 format. If you don’t provide a timestamp, InfluxDB will use your server’s local nanosecond timestamp in UTC.

Setting up InfluxDB 3

We’ll use InfluxDB 3 Enterprise’s free at-home license, which will only require you to provide your email. It includes 2 CPUs and is for personal use only. You will need to check your inbox and verify the link to activate the at-home license.

# Pull image from Docker for InfluxDB 3 Enterprise
docker pull influxdb:3-enterprise

# Run InfluxDB 3 Enterprise with proper configuration
docker run -d \
  --name influxdb3-enterprise \
  -p 8181:8181 \
  -v $PWD/data:/var/lib/influxdb3/data \
  -v $PWD/plugins:/var/lib/influxdb3/plugins \
  -e INFLUXDB3_ENTERPRISE_LICENSE_EMAIL=you@example.com \
  influxdb:3-enterprise \
    influxdb3 serve \
      --node-id=node0 \
      --cluster-id=cluster0 \
      --object-store=file \
      --data-dir=/var/lib/influxdb3/data \
      --host=0.0.0.0 \
      --port=8181

Building a robust data collector

We’ll focus on creating a single comprehensive data collector that covers all the patterns you’ll need for any IoT integration. This example uses a Nest thermostat, but the principles apply to any smart device or API. We’ll build a collector that polls the Google Nest API and writes to InfluxDB 3 Enterprise using the v3 Python client.

Create a database and optionally set a retention period.
```
influxdb3 create database home-data
```
Nest API setup. To collect data from your Nest thermostat, you need API access. To do this:

Go to Google Cloud Console.
Create a new project.
Save your Project ID.
Visit Device Access Console and follow the console instructions.
Create a project, link it to your Google Cloud project, and download OAuth credentials.
Create a Python program “get_nest_token.py” as follows:

# get_nest_token.py
import requests
import webbrowser
from urllib.parse import urlencode

CLIENT_ID = "your-client-id-here"
CLIENT_SECRET = "your-client-secret-here"

# Generate authorization URL
auth_url = f"https://accounts.google.com/o/oauth2/v2/auth?{urlencode({
    'client_id': CLIENT_ID,
    'redirect_uri': 'http://localhost',
    'response_type': 'code',
    'scope': 'https://www.googleapis.com/auth/sdm.service',
    'access_type': 'offline'
})}"

print(f"Visit: {auth_url}")
webbrowser.open(auth_url)

# Get authorization code from redirect URL
auth_code = input("Enter the code from the redirect URL: ")

# Exchange for tokens
token_response = requests.post('https://oauth2.googleapis.com/token', data={
    'client_id': CLIENT_ID,
    'client_secret': CLIENT_SECRET,
    'code': auth_code,
    'grant_type': 'authorization_code',
    'redirect_uri': 'http://localhost'
})

tokens = token_response.json()

print(f"Access Token: {tokens['access_token']}")
print(f"Refresh Token: {tokens['refresh_token']}")

Building the data collector

Create a .env file and save it locally.

NEST_ACCESS_TOKEN=your_access_token_here
GOOGLE_CLOUD_PROJECT_ID=your_project_id
INFLUXDB_HOST=http://localhost:8181
INFLUXDB_TOKEN=your_influxdb_token
INFLUXDB_DATABASE=home-data

Install the Python dependencies.

pip install influxdb3-python requests python-dotenv

Create a new Python program that will act as a data collector and write to InfluxDB 3 “nest_collector.py.”

# nest_collector.py
import os
import time
import logging
from datetime import datetime, timezone
from functools import wraps
import requests
from influxdb_client_3 import InfluxDBClient3
from dotenv import load_dotenv

load_dotenv()

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s - %(levelname)s - %(message)s"

)

def retry_on_failure(max_retries=3, delay=5):
    def decorator(func):
        @wraps(func)
        def wrapper(*args, **kwargs):
            for attempt in range(max_retries):
                try:
                    return func(*args, **kwargs)
                except Exception as e:
                    if attempt == max_retries - 1:
                        logging.error(f"{func.__name__} failed: {e}")
                        raise
                    logging.warning(f"Retry {attempt + 1}: {e}")
                    time.sleep(delay)
        return wrapper
    return decorator

class NestCollector:
    def __init__(self):
        self.access_token = os.getenv("NEST_ACCESS_TOKEN")
        self.project_id = os.getenv("GOOGLE_CLOUD_PROJECT_ID")

        if not self.access_token or not self.project_id:
            raise ValueError("Missing NEST_ACCESS_TOKEN or GOOGLE_CLOUD_PROJECT_ID in .env file")

        # Initialize InfluxDB 3 client
        self.client = InfluxDBClient3(
            host=os.getenv("INFLUXDB_HOST", "http://localhost:8181"),
            token=os.getenv("INFLUXDB_TOKEN"),
            database=os.getenv("INFLUXDB_DATABASE", "home-data"),
        )

        # Test connection
        try:
            list(self.client.query("SELECT 1", language="sql"))
            logging.info("InfluxDB connection successful")
        except Exception as e:
            logging.error(f"InfluxDB connection failed: {e}")
            raise

    @retry_on_failure(max_retries=3, delay=5)
    def get_thermostat_data(self):
        """Fetch data from Nest API"""
        url = f"https://smartdevicemanagement.googleapis.com/v1/enterprises/{self.project_id}/devices"
        headers = {
            "Authorization": f"Bearer {self.access_token}",
            "Content-Type": "application/json"
        }

        response = requests.get(url, headers=headers, timeout=30)
        response.raise_for_status()

        devices = response.json().get("devices", [])
        data_points = []        

        for device in devices:
            if "THERMOSTAT" not in device.get("type", ""):
                continue                `

            traits = device.get("traits", {})
            device_id = device.get("name", "").split("/")[-1]            `

            # Extract measurements
            temp_trait = traits.get("sdm.devices.traits.Temperature", {})
            humidity_trait = traits.get("sdm.devices.traits.Humidity", {})
            hvac_trait = traits.get("sdm.devices.traits.ThermostatHvac", {})
            setpoint_trait = traits.get("sdm.devices.traits.ThermostatTemperatureSetpoint", {})
            info_trait = traits.get("sdm.devices.traits.Info", {})            `

            try:
                temp_celsius = float(temp_trait.get("ambientTemperatureCelsius", 0))
                humidity = float(humidity_trait.get("ambientHumidityPercent", 0))
            except (TypeError, ValueError):
                continue

            # Build data point for InfluxDB
            point = {
                "measurement": "nest_thermostat",
                "tags": {
                    "device_id": device_id,
                    "room": info_trait.get("customName", "main"),
                    "device_type": "thermostat"
                },
                "fields": {
                    "temperature_celsius": temp_celsius,
                    "temperature_fahrenheit": temp_celsius * 9/5 + 32,
                    "humidity_percent": humidity,
                    "hvac_status": hvac_trait.get("status", "OFF"),
                    "hvac_mode": hvac_trait.get("mode", "UNKNOWN")
                },
                "time": int(datetime.now(timezone.utc).timestamp())
            }

            # Add setpoint temperatures if available
            if "heatCelsius" in setpoint_trait:
                heat_c = float(setpoint_trait["heatCelsius"])
                point["fields"]["heat_setpoint_celsius"] = heat_c
                point["fields"]["heat_setpoint_fahrenheit"] = heat_c * 9/5 + 32                `

`            if "coolCelsius" in setpoint_trait:
                cool_c = float(setpoint_trait["coolCelsius"])
                point["fields"]["cool_setpoint_celsius"] = cool_c
                point["fields"]["cool_setpoint_fahrenheit"] = cool_c * 9/5 + 32            `

            data_points.append(point)
            logging.info(f"Collected {device_id}: {temp_celsius:.1f}°C, {humidity:.0f}%")           
        return data_points

    def write_to_influx(self, points):
        """Write data to InfluxDB"""
        if not points:
            logging.warning("No data to write")
            return            `

        success_count = 0
        for point in points:

            try:
                self.client.write(record=point, write_precision="s")
                success_count += 1
            except Exception as e:
                logging.error(f"Write failed: {e}")

        logging.info(f"Wrote {success_count}/{len(points)} points")

    def run_cycle(self):
        """Run one collection cycle"""
        try:
            data = self.get_thermostat_data()
            self.write_to_influx(data)
        except Exception as e:
            logging.error(f"Cycle failed: {e}")

if __name__ == "__main__":
    collector = NestCollector()    `

    try:
        while True:
            collector.run_cycle()
            time.sleep(300)  # Run every 5 minutes
    except KeyboardInterrupt:
        logging.info("Stopped by user")

Installing and configuring Grafana

# Install Grafana using Docker
docker run -d \
  --name grafana \
  -p 3000:3000 \
  -v grafana-storage:/var/lib/grafana \
  -e "GF_SECURITY_ADMIN_PASSWORD=your-secure-password" 
  grafana/grafana:latest

Essential dashboard configuration

Make sure Grafana is up and running locally on port 3000.
- Log into Grafana using your username/password at localhost:3000
- Navigate to Connection —> Type ‘InfluxDB’ —> ‘Add new Data Source’
- Type: InfluxDB3 Enterprise Home
- Language : SQL
- Database: home-data
- URL: http://influxdb3-enterprise:8181 for connecting to InfluxDB 3 Enterprise
- Token: Paste the string value for INFLUXDB_TOKEN environment variable from your .env file & toggle Insecure Connection to “ON”
Create dashboards with two panels using the following SQL queries to monitor the data:

Current Temperature Panel

SELECT 

  temperature_fahrenheit,

  device_id

FROM nest_thermostat 

WHERE time >= now() - interval '5 minutes'

ORDER BY time DESC 

LIMIT 1

24-Hour Trend Panel

SELECT 

  date_trunc('minute', time) as time,

  AVG(temperature_fahrenheit) as avg_temp

FROM nest_thermostat 

WHERE time >= now() - interval '24 hours'

GROUP BY date_trunc('minute', time)

ORDER BY time

(Optional) Health Monitoring Script

Keep your systems healthy with simple checks by creating the script “health_check.py” as follows:

# health_check.py
import requests
from datetime import datetime

def check_health():
    services = {
        'InfluxDB': 'http://localhost:8181/health',
        'Grafana': 'http://localhost:3000/api/health'
    }

    print(f"\n=== Health Check - {datetime.now().strftime('%H:%M:%S')} ===")

    all_healthy = True
    for service, url in services.items():
        try:
            response = requests.get(url, timeout=5)
            healthy = response.status_code == 200
            status = "✅" if healthy else "❌"
            print(f"{service}: {status}")
            all_healthy = all_healthy and healthy
        except Exception:
            print(f"{service}: ❌ Connection failed")
            all_healthy = False

    print(f"Overall: {'✅ HEALTHY' if all_healthy else '❌ ISSUES'}\n")

if __name__ == "__main__":
    check_health()

Bringing it all together

What you’ve built here goes far beyond just monitoring your thermostat; you’ve implemented the foundational patterns that power modern observability systems at scale. The retry logic and circuit breakers you wrote to handle flaky IoT APIs are the same resilience patterns that keep Netflix running when services fail. At the same time, the time series data modeling and visualization pipeline you created mirrors the monitoring infrastructure used by major tech companies to track millions of metrics per second.

Most importantly, you now understand how to think about data as a stream of events over time rather than static records in tables, which is a mental shift that will serve you well whether you’re building application monitoring dashboards, analyzing business metrics, or working with any system that generates continuous data streams.

How to Visualize Time Series Data with InfluxDB 3 & Apache Superset

Suyash Joshi (InfluxData) — Thu, 06 Nov 2025 08:00:00 +0000

Introduction

Learn how to visualize time series data from InfluxDB 3 Core using popular open source Apache Superset. This tutorial walks you through setting up both systems with Docker, writing sample IoT data, and creating your first visualization. For more information about Apache Superset, this article may be helpful.

What you’ll build:

InfluxDB 3 (Core / Enterprise) instance with sample home sensor data
Apache Superset dashboard connected to InfluxDB 3
A simple temperature visualization powered by SQL

Prerequisites:

Docker Desktop running on your system (download)
Terminal/Command line access
Basic understanding of SQL

Part 1: Setting up InfluxDB 3

Step 1: Install InfluxDB 3 Core (optionally use InfluxDB 3 Enterprise)

Download and run the installation script:

curl -O https://www.influxdata.com/d/install_influxdb3.sh
sh install_influxdb3.sh

When prompted, select the Docker installation option. The script will handle pulling the InfluxDB 3 Docker image and setting up the CLI.

Step 2: Verify Installation

Check that InfluxDB 3 CLI is installed. Command should print the latest InfluxDB 3 version:

influxdb3 --version

Step 3: Start InfluxDB 3 Server

Run the following two commands to create a local directory for storing data (optionally, it can point to a remote object store) and then start the InfluxDB 3 database.

# Create a local directory for data
mkdir -p ~/influxdb3-data

# Start InfluxDB 3 Core with local file system storage
docker run -d \
  --name influxdb3 \
  -p 8181:8181 \
  --volume ~/influxdb3-data:/var/lib/influxdb3 \
  influxdb:3-core influxdb3 serve \
  --node-id my_node \
  --object-store file \
  --data-dir /var/lib/influxdb3

What this does:

-d runs in detached mode (background)
-p 8181:8181 exposes the default InfluxDB 3 port
--volume mounts local storage for data persistence
--object-store file uses local file system (can also use S3, GCS, or Azure Blob)

Step 4: Create an Authentication Token

Generate an admin token for database operations by executing the following docker command in the influxdb3 container:

docker exec -it influxdb3 influxdb3 create token --admin

Save the token somewhere safe!

Step 5: Create a Database

**docker exec -it influxdb3 influxdb3 create database home_sensors --token "PASTE_YOUR_TOKEN_STRING"

Part 2: Load sample data using CLI

Write Home Sensor Data (optionally stream or write your own data)

We’ll load sample line protocol data consisting of temperature, humidity, and CO readings from two rooms:

docker exec -it influxdb3 influxdb3 write \
  --database home_sensors \ 
  --token "PASTE_YOUR_TOKEN_STRING" \
  'home,room=Living\ Room temp=21.1,hum=35.9,co=0i 1741593600
home,room=Kitchen temp=21.0,hum=35.9,co=0i 1741593600
home,room=Living\ Room temp=21.4,hum=35.9,co=0i 1741597200
home,room=Kitchen temp=23.0,hum=36.2,co=0i 1741597200
home,room=Living\ Room temp=21.8,hum=36.0,co=0i 1741600800
home,room=Kitchen temp=22.7,hum=36.1,co=0i 1741600800
home,room=Living\ Room temp=22.2,hum=36.0,co=0i 1741604400
home,room=Kitchen temp=22.4,hum=36.0,co=0i 1741604400
home,room=Living\ Room temp=22.2,hum=35.9,co=0i 1741608000
home,room=Kitchen temp=22.5,hum=36.0,co=0i 1741608000
home,room=Living\ Room temp=22.4,hum=36.0,co=0i 1741611600
home,room=Kitchen temp=22.8,hum=36.5,co=1i 1741611600'

Understanding the data format (Line Protocol):

home - measurement name
room=Living\ Room - tag (indexed, for filtering)
temp=21.1,hum=35.9,co=0i - fields (actual data values)
1741593600 - timestamp (Unix epoch in seconds)

Other ways to write data:

Telegraf - You can run the popular open source tool Telegraf in another Docker container to collect system metrics in real-time automatically
InfluxDB Client SDKs v3 - Python, Go, JavaScript, Java, C#, Node, etc.
HTTP APIs - Direct write endpoint for custom integrations

For this tutorial, we’re using static data to keep it simple.

Step 6: Verify Data with CLI Query

Query the data using InfluxDB 3 CLI and SQL to confirm it loaded correctly:

docker exec -it influxdb3 influxdb3 query \
  --database home_sensors \
  "SELECT * FROM home ORDER BY time DESC LIMIT 10" \
  --token "PASTE_YOUR_TOKEN_STRING"

You should see the 10 most recent readings.

Try another query—average temperature by room:

docker exec -it influxdb3 influxdb3 query \
  --database home_sensors \
  "SELECT room, AVG(temp) as avg_temp FROM home GROUP BY room" \
  --token "PASTE_YOUR_TOKEN_STRING"

Part 3: Setting up Apache Superset

Step 1: Clone Superset and Add Flight SQL Support

# Clone the repository
git clone https://github.com/apache/superset.git
cd superset

Step 2: Add Apache FlightSQL Support

# Add flightsql-dbapi to the requirements file
echo "flightsql-dbapi" >> docker/requirements-local.txt
# Verify it was added
cat docker/requirements-local.txt

Step 3: Start Superset

Download/copy docker-compose-non-dev.yml. That takes care of setting up Superset locally.
Start Superset in Docker containers using Docker Compose.

# Pull images
docker-compose -f docker-compose-non-dev.yml pull

# Start superset services
docker-compose -f docker-compose-non-dev.yml up -d --no-deps superset

Wait 2-3 minutes for all services to start. Check status:

docker ps | grep superset

Make sure containers show a “healthy” status.

Step 4: Access Superset UI

Open your browser to:

http://localhost:8088

Username: admin
Password: admin

Optionally: Change the admin password after first login via Settings → List Users.

Part 4: Connect InfluxDB to Superset

Step 1: Add Database Connection

Click Settings (top right) → Database Connections
Click + Database button
Select Other from the dropdown

Step 2: Configure Connection

Display Name:

InfluxDB3

SQLAlchemy URI:

datafusion+flightsql://localhost:8181?database=home_sensors&token=YOUR_TOKEN_HERE

Replace YOUR_TOKEN_HERE with your actual token from earlier.

Important: Use datafusion+flightsql:// (not just flightsql://).

Step 3: Test Connection

Click Test Connection. You should see a “success” message. Click Connect to save.

Part 5: Query and visualize data

Open SQL Lab, write the SQL query and execute to see the data:

Lastly, don’t forget to save your dashboard for easier future reference.

Troubleshooting

Problem: “Could not load database driver”

Error: sqlalchemy.exc.NoSuchModuleError: Can't load plugin: sqlalchemy.dialects:flightsql

Solution: The flightsql-dbapi package wasn’t installed before starting Superset

# Stop containers
docker-compose down

# Ensure requirements file exists
echo "flightsql-dbapi" > ./docker/requirements-local.txt

# Restart

docker-compose -f docker-compose-non-dev.yml up -d

Problem: Connection Timeout

Causes: Wrong host/port, InfluxDB not running, or firewall blocking

Solutions:

Verify InfluxDB is running: docker ps | grep influxdb
Check port (default: 8181 for Core)
Use localhost, not 127.0.0.1 when both are in Docker

Problem: Wrong Protocol

Error: Connection fails with flightsql://

Solution: Use datafusion+flightsql:// (not just flightsql://)

Next steps

You now have a complete stack for collecting, storing, and visualizing time series data! You can customize your dashboard, add your own (real-time) data, and connect with InfluxDB 3 Enterprise (use the same steps as above, just make sure the Docker image is for the enterprise version). For more help and inspiration, check out the InfluxDB community forum, Slack, Reddit, and Discord community. Happy visualizing!