InfluxData Blog - Product

From Edge to Enterprise: How Litmus and InfluxDB Are Modernizing the Industrial Data Stack

Ben Corbett (InfluxData) — Mon, 20 Apr 2026 00:00:00 +0000

Today at Hannover Messe, InfluxData is announcing a strategic partnership with Litmus to address one of the most persistent challenges in industrial data: getting reliable, contextualized telemetry from the shop floor into production systems.

Litmus bridges the gap between OT systems and modern IT infrastructure, while InfluxDB serves as the industrial data hub, giving organizations both real-time operational visibility and enterprise-scale historical analysis in a unified architecture.

By integrating Litmus Edge with InfluxDB 3 Enterprise, teams can collect and contextualize data at the source, then write it into a time series engine built for high-resolution data. Litmus handles connectivity and data normalization at the edge. InfluxDB provides high-throughput ingestion, real-time querying, and cost-efficient long-term storage, deployable at the edge, in the enterprise layer, or both.

The result is a system that captures every signal, retains its context, and makes it immediately usable

The industrial data problem

Something has shifted in industrial sectors. Modernization is no longer a roadmap item, but it’s starting to hit real constraints. The pull: industrial AI initiatives, predictive maintenance, cross-site analytics, digital twins, offer attractive value propositions. The push: legacy data historians are buckling under the demands of modern industrial operations, and the cost of extension is becoming harder to justify.

OT environments are notoriously fragmented. PLCs, CNCs, SCADA systems, and sensors operate across different protocols, vendors, and network boundaries. Getting that data into a usable, consistent format still requires heavy integration, time, and cost.

Traditional Historians made progress on the industrial data problem, but they weren’t built for what comes next. They struggle to preserve context across systems, degrade under high-frequency ingest and query load, and make cross-site analysis slow and expensive. This forces teams into trade-offs between fidelity, scale, and cost.

That’s the core issue: the value of industrial data is in its resolution and context. Most systems weren’t designed to retain either at scale.

How Litmus and InfluxDB work together

To move forward, teams need an architecture built for how industrial data actually behaves: high-frequency, distributed, and context-dependent. Litmus Edge and InfluxDB 3 Enterprise provide that foundation by collecting and structuring data at the edge, then making it available centrally without losing resolution or context.

Here’s how that looks in practice:

250+ prebuilt industrial connectors. Out-of-the-box connectivity to industrial data sources, including legacy systems and proprietary protocols. No custom integration required.
Collect and contextualize at scale. Normalize and contextualize telemetry from the source, with unlimited cardinality that preserves full context without compromising query performance.
Centralized data, not silos. Bring telemetry from tools, teams, and sites into a single architecture, from single-site monitoring to cross-plant analytics, without a data consolidation project.
Buffered, store-and-forward data transfer. Buffer and transmit data from remote sites with intermittent connectivity, with no loss or manual recovery.
Retain more, spend less. Keeps high-resolution data accessible long-term with object storage, without driving up storage costs as you scale.

The edge: collect, contextualize, buffer

Litmus Edge acts as the intelligence layer between your machines and the rest of your data architecture. With 250+ native connectors spanning OPC-UA, Modbus, MQTT, FANUC, Siemens S7, and more, it connects directly to industrial sources (PLCs, CNCs, DCS, SCADA systems, sensors, and beyond) without custom integration.

But connectivity alone isn’t enough. Raw signals without context aren’t useful. Litmus Edge tags, enriches, and structures data at the point of collection so a temperature reading is tied to an asset, production line, facility, and product run. By the time it leaves the edge, it’s already queryable.

The industrial data hub: Centralize, scale, retain

InfluxDB 3 serves as the system of record for industrial time series data, whether deployed at the edge, centralized in the enterprise layer, or both.

At the site level, InfluxDB runs locally alongside Litmus Edge, ingesting full-resolution telemetry and serving low-latency queries for real-time operations. It operates autonomously, so if connectivity to the central hub is interrupted, data is buffered locally and automatically forwarded when the connection is restored. There’s no data loss or manual intervention.

At the enterprise level, a centralized InfluxDB cluster aggregates data from every site into a single query layer across assets, plants, and time horizons. This creates a consistent, high-resolution data layer that can be used across operations, analytics, and industrial AI.

The bridge to higher-level analytics

With high-resolution, contextualized data available across systems, teams can move beyond basic monitoring. Predictive maintenance, anomaly detection, and cross-site analytics all depend on full-fidelity data. Industrial AI at the edge depends on low-latency access to it. Without that foundation, these systems don’t operate reliably. That’s what this architecture enables.

Get started

Whether you’re starting a greenfield initiative or hitting the limits of your current industrial data infrastructure, we’d love to talk.

Reach out to connect to an expert or join the conversation in the InfluxData Community Forums where our team and broader community are active.

If you’re attending Hannover Messe, come find me at the Litmus booth (Stand A09 in Hall 16) and see the architecture running end-to-end.

From Edge to Cloud: How Litmus Edge and InfluxDB Unlock Industrial Intelligence at Hannover Messe

Ben Corbett (InfluxData) — Thu, 16 Apr 2026 06:00:00 +0000

If you’ve spent time in industrial environments, you know the problem isn’t a lack of data. It’s collecting it reliably, contextualizing it, and storing it at scale. Most stacks weren’t built to fight all three battles.

The industrial data problem

Industrial connectivity is no joke. OT environments are notoriously fragmented and siloed, spanning PLCs, CNCs, SCADA systems, and sensors, each speaking a different protocol, running on a different vendor’s stack, and operating in a network zone that was never designed to talk to anything outside the shop floor. Extracting value from that data has traditionally required heavy IT involvement, expensive integrations, and months of professional services work, and the traditional answer was usually a historian. Historians made progress on the access problem, giving individual sites a way to capture and store machine data. But standardizing that data across silos and contextualizing it across systems and plants is where they fall short. And unfortunately, that’s where most of the value lies.

Once data is collected and contextualized, the next problem is keeping it useful at scale. This is more than a storage problem. Sustaining high-frequency ingest of contextualized telemetry and querying that data fast enough to act on it is where most systems break. Historians were not designed for this. They sacrifice resolution, degrade under query load, and make cross-site, cross-system analysis slow and impractical. The value in industrial data is in the detail, and most platforms are architected to throw this detail away.

Collect, contextualize, and store—all at the edge

Litmus Edge acts as the intelligence layer between your machines and the rest of your data architecture. It connects natively to hundreds of industrial protocols, including OPC-UA, Modbus, MQTT, FANUC, Siemens S7, and many more, normalizing disparate machine data into a unified, consistent stream.

But connectivity alone isn’t enough. Raw machine signals mean little without context. Litmus Edge allows operations teams to tag, enrich, and structure data at the point of collection. A temperature reading becomes tied to a specific asset, production line, facility, and product run. By the time data leaves the edge, it is no longer just a number. It is a meaningful, queryable event.

Scale, query, retain: your industrial data hub

InfluxDB 3 becomes the system of record for your industrial time series data at the edge, in a centralized environment, or both.

It ingests high-frequency telemetry at full resolution, serves low-latency queries for real-time operations, and scales to fleet-wide analysis across sites and time horizons without forcing tradeoffs between fidelity and cost. High cardinality isn’t a problem to design around. Long-term retention doesn’t require a cost penalty. The data stays detailed, queryable, and useful.

Scaling across lines, sites, and the enterprise

Scale changes what’s possible, but only if the data model scales with it. When every site collects and contextualizes data the same way, writing to a consistent schema, cross-site analysis becomes straightforward. Comparing performance across plants, identifying outliers, and correlating signals across a global fleet become simple queries instead of integration projects. That consistency is what the Litmus and InfluxDB architecture is designed to deliver.

Which production lines across all facilities are showing early indicators of equipment degradation?
How does energy consumption per unit compare across sites running similar processes?
Where are the outliers? And what can the top performers teach the rest of the network?

These are not hypothetical future capabilities. They are available today to any organization willing to invest in getting the data foundation right.

The bridge to higher-level analytics

InfluxDB doesn’t just store data well; it integrates cleanly with the ecosystem: the analytics, visualization, and AI/ML tooling your teams are already investing in. Grafana dashboards, anomaly detection workflows, and digital twin platforms connect through InfluxDB’s SQL-native interface and open APIs without custom pipelines or bespoke integration work.

For OT teams, that’s the point. The edge handles the hard part—protocol translation, normalization, enrichment. InfluxDB centralizes the results into a single, interoperable data layer that every team can query with the tools they already use.

The result is a data architecture that is genuinely interoperable; the plant floor and the enterprise layer are finally speaking the same language.

Extending into the cloud with AWS

There are several ways to deploy InfluxDB as your industrial data hub: on-premises, at the edge, or in the cloud. For teams who want to go straight to the cloud, AWS is a natural fit. In this reference architecture, Litmus Edge writes contextualized telemetry directly into Amazon Timestream for InfluxDB, creating a seamless path from the shop floor to cloud-scale analytics. This allows teams to centralize access, scale analytics, and integrate with the broader AWS ecosystem without rebuilding their infrastructure from scratch.

Once data is available in AWS, it opens up a broader set of capabilities. For example, as new data arrives, you can trigger serverless workflows with AWS Lambda, stream high-velocity data through Kinesis for downstream processing, or connect directly to SageMaker to train models on high-fidelity data, without reshaping or downsampling it first.

What we’re showing at Hannover Messe

At Hannover Messe, you’ll be able to see this architecture running end-to-end:

Litmus booth (Hall 16, Stand A09): The full Digital Factory demo, showing how data flows from industrial systems into Litmus and into InfluxDB 3 Enterprise in real-time.
InfluxData kiosk (within the Litmus booth): A deeper look at how InfluxDB handles high-frequency ingest, real-time querying, and efficient storage at massive scale.
AWS booth (Litmus kiosk): The cloud extension of the demo, highlighting replication into Amazon Timestream for InfluxDB and integration with AWS services.

The InfluxData team (including myself) will be on-site at the Litmus booth throughout the event to walk through the architecture and discuss real-world deployment patterns.

Post by Ben Corbett, InfluxData; Rajesh Gomatam, Ph.D. Principal Partner Solutions Architect - Manufacturing, AWS; and Benjamin Norman, Partner Solution Architect, Litmus

What’s New in InfluxDB 3 Explorer 1.7: Table Management, Data Import, Transforms, and More

Daniel Campbell (InfluxData) — Wed, 15 Apr 2026 05:30:00 +0000

InfluxDB 3 Explorer 1.7 is a step forward for anyone who wants to manage their time series data without constantly switching between the UI and a terminal. This release adds table-level schema management, the ability to import data from other InfluxDB instances, and a new Transform Data section to reshape your data, all within the Explorer UI.

Table management

Previously, if you wanted to see what tables existed inside a database, you had to query system tables or use the API. The new Manage Tables page changes that. You can get there from the sidebar or from the new actions menu on any database in the Manage Databases page. That actions menu gives you quick access to query a database, view its tables, or delete it.

The Manage Tables page lists every table in the selected database, along with its column count, type, and any configured Distinct Value or Last Value Caches. Use the toggle filters to show or hide system tables and deleted tables. Deleted tables show up with a “Pending Delete” badge when the Show Deleted Tables toggle is enabled, so you always have visibility into what’s been removed.

You can also create new tables directly from this page. The Create Table dialog lets you define the schema up front: name, fields with data types, optional tags, and a retention period. This is useful when you want to control your schema explicitly rather than relying on schema-on-write to infer types from the first arriving data points.

From any table’s action menu, you can jump straight to the Data Explorer with a pre-built query for that table.

Import from InfluxDB

The next few features I’ll discuss are enhancements that make it much easier to work with the InfluxDB 3 Processing Engine.

Moving data between InfluxDB instances used to mean writing scripts, dealing with export formats, and coordinating tokens across environments. The new Import from InfluxDB feature provides a guided workflow for migrating small-to-medium datasets from any existing InfluxDB v1, v2, or v3 instance (assuming v3 Schema compatibility) into your current InfluxDB 3 database.

You’ll find it under the Write Data section, on both the Dev Data and Production Data pages. The workflow walks you through selecting a target database (or creating a new one), connecting to a source InfluxDB instance, authenticating, and then choosing which databases and tables to import.

Before committing to the import, perform a dry run that shows you exactly what will be transferred, including the source and destination, the number of tables, the estimated row count, and how long it should take. Advanced options let you tune the batch size and concurrency if you need to balance import speed against resource usage.

Once you start the import, a live progress view shows you how far along things are, how many rows have been imported, and the current status of each table. When it finishes, a “Query this database” button takes you straight to the Data Explorer so you can verify everything landed correctly.

If you’re running an InfluxDB 1.x or 2.x instance and want to try InfluxDB 3 with your real data, this saves you from building a migration pipeline. Just point the import tool at your existing instance, pick the databases and time range you want, and the data flows over. It also works for consolidating data from multiple InfluxDB 3 instances into one place, or pulling production data into a dev environment for testing.

Transform data

The new Transform Data section in the sidebar gives you a visual interface for setting up data transformations that run automatically on ingestion via the Processing Engine. Under the hood, these are powered by the Basic Transformation Processing Engine plugin, but you don’t need to write any plugin configuration by hand. The UI handles that for you.

The way it works: when data is written to a source table, the transformation runs automatically and writes the results to a target database or table. You can set a short retention period on the source data (say, one day) so the raw data cleans itself up, and the transformed data lives on in the destination. There are four types of transformations available.

Rename Table

Rename Table lets you route data arriving in one table to another table. This is handy when you’re consuming data from a source you don’t control, and the table names don’t match your naming conventions.

Rename Columns

Rename Columns works similarly, but at the column level. You pick a source table and select which columns to rename. If you’re integrating data from different systems that use different naming conventions (for example, temp_f vs temperature_fahrenheit), this standardizes everything without touching the source.

Transform Values

Transform Values lets you apply calculations or conversions to field values as they come in. You can do math operations, string transformations, unit conversions, or simple find-and-replace. If your sensors report temperature in Celsius but your dashboards expect Fahrenheit, this handles the conversion at ingestion time so your queries stay clean.

Filter Data

Filter Data lets you keep only the rows or columns that match specific conditions. You can filter by rows (e.g., only keep data where crop_type = 'carrots') or by columns (drop fields you don’t need). This is useful when you’re receiving more data than you actually want to store. For example, a third-party feed might send 50 fields when you only care about 5.

You can test each transformation before deployment, and once deployed, monitor its status (running, stopped, errors) from the Transform Data dashboard.

Downsample Data

Downsampling is a classic time series operation: take high-frequency data and roll it up into lower-frequency summaries to save storage and speed up queries over long time ranges. The new Downsample page, also under the Transform Data section, makes this easy to set up. You create a downsample trigger by specifying a source table, a target table, a schedule (how often the aggregation runs), a time window (how far back to look), an aggregation interval (the bucket size), and an aggregation function (avg, sum, min, max, etc.). You can also choose to include or exclude specific fields.

The Downsample Processing Engine plugin powers this feature.

Get started

All of these features are available now in InfluxDB 3 Explorer 1.7. For more on these Processing Engine capabilities, see InfluxDB 3 Processing Engine Updates.

If you’re running InfluxDB 3 Core or Enterprise, update to the latest version to try them out. To learn more, check out the InfluxDB 3 Explorer documentation.

To update InfluxDB 3 Explorer, pull the latest Docker image: docker pull influxdata/influxdb3-ui

Less Friction, More Control: Here's What Shipped in Q1

Ryan Nelson (InfluxData) — Wed, 08 Apr 2026 08:00:00 +0000

Our Q1 momentum has been focused on a simple goal: making InfluxDB easier to operate, easier to scale, and faster to put to work.

Across Telegraf, InfluxDB 3, and our managed offerings, these updates reduce friction in how teams collect, process, and scale time series workloads.

Telegraf Controller enters beta

Telegraf is already a powerful way to collect metrics, logs, and events across environments. At scale, the challenge shifts from collection to control. Telegraf Enterprise is designed to solve that problem.

At the center is Telegraf Controller, a control plane that gives teams centralized configuration management and fleet-wide health visibility. The beta includes major capabilities such as API authentication, API token management, user account management, multi-user support, role-based access control, global settings management, and expanded plugin support in the visual config builder.

Feedback from early users is shaping the road to general availability, with enterprise licensing, enforcement, audit logging, and federated identity management next on the roadmap. Sign up to join the beta.

InfluxDB 3.9 adds more operational control

Last week’s release of InfluxDB 3.9 is focused on making the platform easier to run at scale, with improvements aimed at predictability, visibility, and day-to-day management. The release expands CLI and automation support for headless environments, improves resource and lifecycle management, and adds clearer visibility into access control and product identity across Core and Enterprise deployments. These are the changes that matter in production: fewer rough edges, stronger operational clarity, and better control as workloads grow.

InfluxDB 3.9 Enterprise also includes a new beta performance preview for non-production environments. This optional preview includes optimized single-series queries, reduced CPU and memory spikes under load, support for wider and sparser schemas, and early automatic distinct value caches to reduce metadata query latency. These features are not yet recommended for production, but they give customers an early look at capabilities planned for future releases and a chance to help shape what comes next.

Processing Engine updates make InfluxDB 3 easier to operationalize

The Processing Engine remains one of the most powerful parts of InfluxDB 3 because it allows teams to run logic directly at the database. Users can transform data on ingest, run scheduled jobs, or serve HTTP requests without adding external services or layering on more pipeline complexity.

This quarter, we continued to expand both the engine itself and the plugin ecosystem around it. The latest plugins make it easier to get data into InfluxDB 3 from more sources:

The Import Plugin provides a simpler path for bringing data from InfluxDB v1, v2, or v3 into InfluxDB 3 Core and Enterprise, with support for dry runs, progress tracking, pause and resume, conflict handling, and flexible filtering.
New MQTT, Kafka, and AMQP subscription plugins help users ingest streaming data directly from external message brokers.
The new OPC UA Plugin gives industrial teams a more direct path to data from PLCs, SCADA systems, and other OPC UA-enabled equipment.

We also made important improvements to the Processing Engine itself:

New synchronous write controls give plugin authors more flexibility over durability and throughput.
Batch write support improves efficiency for high-volume workloads.
Asynchronous request handling keeps status checks and control operations responsive during long-running jobs.

Together, these updates make the Processing Engine a more practical way to build and operate real-time data pipelines directly inside InfluxDB 3. Check out our docs to learn more.

Better visibility for Cloud Dedicated customers

As teams run production workloads on Cloud Dedicated, understanding how the system is being used becomes just as important as performance itself.

This quarter, we introduced:

Query History (GA) for troubleshooting, performance analysis, and deeper insight into query activity.
S3 API dashboards (Tier 1 and Tier 2), including monthly usage visibility.

These updates give teams better visibility into system behavior, usage patterns, and a faster path to understanding activity across the environment. Detailed docs here.

InfluxDB Enterprise 1.12.3 delivers efficiency gains for v1 environments

For teams needing more performance and running large-scale v1 Enterprise environments, InfluxDB Enterprise 1.12.3 is now available with substantial improvements in efficiency and reliability:

100x faster retention enforcement for high-cardinality datasets
30% lower CPU usage during compaction
5x faster backups with configurable compression
3x less disk I/O during cold shard compactions

These improvements make Enterprise v1 clusters more efficient, more predictable under load, and more cost-effective to operate. Read the release notes.

Amazon Timestream for InfluxDB adds a new scale tier and simple upgrade path

InfluxDB 3 on Amazon Timestream for InfluxDB now supports clusters of up to 15 nodes, giving customers a new scale tier for more demanding real-time workloads.

This expanded tier improves query concurrency, increases ingestion throughput, and provides stronger workload isolation across ingestion, queries, and compaction. For teams running high-velocity, high-resolution data in production, that means more headroom to scale without compromising real-time performance.

Customers can also seamlessly migrate from InfluxDB 3 Core to InfluxDB 3 Enterprise, making it easier to move into this higher-performance tier without a manual architectural overhaul or data loss. The new 15-node option is available for InfluxDB 3 Enterprise in all AWS regions where Amazon Timestream for InfluxDB is offered. Read more here.

Looking ahead

Taken together, these updates are about helping teams do more with less friction: move data faster, operate with more confidence, and scale time series workloads without losing control. As operational data becomes more central to modern systems, we are continuing to invest in the infrastructure that turns that data into action across edge, cloud, and distributed environments.

New Plugins, Faster Writes, and Easier Configuration: What’s New with the InfluxDB 3 Processing Engine

Gary Fowler (InfluxData) — Tue, 07 Apr 2026 08:00:00 +0000

The Processing Engine is one of the most powerful features in InfluxDB 3. It lets you run Python code at the database—transforming data on ingest, running scheduled jobs, or serving HTTP requests—without spinning up external services or building middleware. You define the logic, attach it to a trigger, and the database handles the rest.

Since launching the Processing Engine, we’ve been building out both the engine itself and the ecosystem of plugins that run on it. Today, we want to walk you through some exciting recent additions: new plugins for data ingestion, import, and validation; some general improvements to the engine; and a better configuration experience using InfluxDB 3 Explorer.

A quick refresher: Processing Engine plugins

If you’re already familiar with the Processing Engine, feel free to skip ahead. For those newer to the concept, here’s the short version.

A plugin is a Python script that runs inside InfluxDB 3 in response to a trigger. There are three trigger types: data writes (react to incoming data as it’s written), scheduled events (run on a timer or cron expression), and HTTP requests (expose a custom API endpoint). Plugins have direct access to the database: they can query and write without having to egress and ingress the data to a different machine or location. Plugins can also talk to other systems, letting you utilize data from other places or systems.

You can write your own plugins from scratch to solve problems specific to your environment. That’s the whole point of embedding Python in the database: your logic, your rules, running right next to your data.

But we also know that not everyone wants to start from a blank page. That’s why we maintain an official plugin library with production-ready plugins for common time series tasks, such as downsampling, anomaly detection, forecasting, state change monitoring, and sending notifications to Slack, email, or SMS.

These official plugins are designed to work in two ways. You can install them and use them as-is, configuring them through trigger arguments or TOML files to fit your setup. Or you can treat them as templates: fork one, customize the logic, and build something tailored to your exact workflow. Either way, they’re meant to get you moving faster.

One more thing worth mentioning: if you’re thinking about building a custom plugin but aren’t sure where to start, AI tools like Claude can be very effective. Point Claude to the Processing Engine documentation and the plugin library repo for examples, describe what you want your plugin to do, and let it generate a first draft. We’ve seen simple plugins created in a single shot, from description to working code, and even more complex plugins come together quickly when the AI has good examples to work from. It’s a great way to get past the blank-page problem and into something you can iterate on.

New plugins: data ingestion, import, and validation

We’ve recently added several new plugins to the library that address some of the most common requests we’ve been hearing from the community. These are available now in beta—they’re fully functional, but we want to see them tested across more environments before we call them production-ready. Give them a try and let us know how they work for you.

InfluxDB Import Plugin

If you’re running an older version of InfluxDB and want to bring your data into InfluxDB 3, the new Import Plugin makes that significantly easier. It supports importing from InfluxDB v1, v2, or v3 instances over HTTP, with features you’d expect from a serious import tool: automatic data sampling for optimal batch sizing, pause/resume for long-running imports, progress tracking, tag/field conflict detection and resolution, configurable time ranges and table filtering, and a dry run mode so you can preview what an import will look like before committing to it.

The plugin runs as an HTTP trigger, so you control the entire import lifecycle (start, pause, resume, cancel, check status) through simple HTTP requests. That means you can kick off a large import, pause it during peak hours, and pick it up later from exactly where it left off. For small or medium-sized InfluxDB databases, some might even use this as a migration tool to move to InfluxDB 3.

Data subscription plugins: MQTT, Kafka, and AMQP

These three plugins let new InfluxDB 3 users start getting data into InfluxDB 3 fast and without coding. They let you subscribe to external message brokers and begin automatically ingesting that data into InfluxDB 3.

The MQTT Subscriber Plugin connects to an MQTT broker, subscribes to topics you specify, and transforms incoming messages into time series data. It supports JSON, Line Protocol, and custom text formats with regex parsing, and uses persistent sessions to ensure reliable message delivery between executions.

The Kafka Subscriber Plugin does the same for Kafka topics. It uses consumer groups for reliable delivery, supports configurable offset commit policies (commit on success for data integrity, or commit always for maximum throughput), and handles JSON, Line Protocol, and text formats.

The AMQP Subscriber Plugin rounds out the trio with support for RabbitMQ and other AMQP-compatible brokers. Like the others, it supports multiple message formats, flexible acknowledgment policies, and comprehensive error tracking.

OPC UA Plugin

For industrial environments, the new OPC UA Plugin connects directly to PLCs, SCADA systems, and other OPC UA-enabled equipment. It polls node values on a schedule and writes them into InfluxDB 3 with automatic data type detection. You can list specific nodes for precise control, or use browse mode to auto-discover devices and variables across large deployments. The plugin maintains a persistent connection between polling intervals and supports quality filtering, namespace URI resolution, and TLS security.

Now, you might be thinking: “I’m already using Telegraf to interface with my streaming data services or OPC UA, why do I need these?” If Telegraf is working well for you, that’s great; there’s no need to change what isn’t broken. But if you’re newer to InfluxDB and aren’t yet a Telegraf user, these plugins give you another way to quickly get data flowing into InfluxDB 3 without adding another component to your stack.

All three plugins share a consistent configuration model: you can set them up with CLI arguments for simple cases or TOML configuration files for more complex mapping scenarios. They all include built-in error tracking (logging parse failures to dedicated exception tables) and write statistics so you can monitor ingestion health over time.

Schema Validator Plugin

One of the benefits of InfluxDB is that you don’t have to pre-define a schema. Data gets written as it is received. But for some use cases our customers have, they do want to constrain incoming data to conform to a specific schema.

The Schema Validator Plugin addresses that challenge, ensuring only clean, well-structured data makes it into your production tables. You define a JSON schema that specifies allowed measurements, required and optional tags and fields, data types, and allowed values. The plugin sits on a WAL flush trigger and validates every incoming row against your schema. Rows that pass get written to your target database or table; rows that fail get rejected (and optionally logged so you can see what’s being filtered out).

A typical pattern is to write raw data into a single database or table, let the validator check it, and have clean data land in a separate database or table. It’s a straightforward way to build a reliable data pipeline without external tooling.

Processing Engine general improvements

Alongside the new plugins, we’ve made several improvements to the Processing Engine itself that give plugin authors more control over write behavior, throughput, and concurrency.

Synchronous writes with durability control. New synchronous write functions let you choose between two modes: wait for the write to persist to the WAL before returning (for cases where you need to query the data immediately after writing), or return immediately for maximum throughput. This means you can treat bulk telemetry data as a fast path while ensuring that coordination states, such as job checkpoints or configuration flags, are immediately durable and queryable.

Batch writes. If your plugin writes thousands of points, the overhead isn’t in the data itself; it’s in the repeated write calls. The new batch write capability lets you group many records into a single write operation, which can dramatically improve throughput and make memory usage more predictable.

Asynchronous request handling. Request-based triggers now support concurrent execution. Previously, request handlers processed one request at a time, which meant a slow request would block everything behind it. With asynchronous mode enabled, the engine can handle multiple requests concurrently, so status checks, control commands, and other lightweight requests stay responsive even while a heavy operation is running.

These improvements work together in practice. The Import Plugin, for example, uses batch writes with fast-path durability for bulk data transfer, synchronous durable writes for checkpoints and state, and async request handling to keep its pause/resume/status endpoints responsive during long-running imports.

Easier plugin configuration in Explorer

We’ve also been improving InfluxDB 3 Explorer to make configuring plugins simpler, especially for the plugins in the library.

Until now, configuring a plugin meant passing all the right parameters as startup arguments to the Python script or specifying them in a TOML file. That works, but it requires you to know exactly which parameters a plugin expects—which means reading the documentation first.

We’re adding dedicated UI configuration forms for some of the plugins in Explorer. Instead of assembling a string of key-value pairs, you’ll see a form with all the available options laid out, along with descriptions and example values. Required fields are clearly marked, and the form handles the formatting for you. It’s the same configuration under the hood, just a much more approachable way to get there.

This is especially helpful for plugins with more involved configuration, like the data subscription plugins. where you’re specifying broker connections, authentication, message format mappings, and field type definitions. The form-based approach removes the guesswork and lets you get a plugin running without bouncing back and forth between the docs and your terminal. So far, we have built a specific configuration for the Import, Basic Transformation, and Downsampling plugins.

This is what it looks like for the Import plugin:

This is what the Basic Transformation and Downsample configuration looks like:

Look for these to become available in Explorer in the next couple of months.

What’s next

We are continuing to improve the Processing Engine and the Plugin Library. We have an OPC UA plugin about ready for you to try, as well as some additional anomaly detection and forecasting plugins. And, we are building UI configuration for the data subscription plugins mentioned above to make them even easier to configure.

Try them out

All new plugins are now available in beta in the InfluxDB 3 Plugin Library. They require InfluxDB 3 v3.8.2 or later. Install them from the CLI using the gh: prefix, or browse and install them directly from InfluxDB 3 Explorer’s Plugin Library.

We’re releasing these as a beta because we want your feedback. We’ve tested them thoroughly internally, but real-world environments are always more diverse and more demanding than any test suite. If you run into issues, have ideas for improvements, or build something cool on top of these plugins, we’d love to hear from you: drop into the InfluxData Discord, post on the Community Forums, or open an issue on GitHub.

What’s New in InfluxDB 3.9: More Operational Control and a New Performance Preview

Peter Barnett (InfluxData) — Thu, 02 Apr 2026 12:00:00 +0000

We’ve spent the last few months listening to how teams are running InfluxDB 3 in the wild. The feedback was clear: as you scale, you need less “guesswork” and more control. Today’s release of InfluxDB 3.9 is our answer to that.

As more teams move InfluxDB 3 into production, our focus has shifted toward the operational experience: how you manage the database at scale, how you ensure it remains secure, and how you provide a seamless experience for users. This release is packed with a host of quality-of-life improvements and a beta of the key features we have planned for upcoming releases.

Whether you’re using the open source InfluxDB 3 Core for recent data and local workloads or scaling with InfluxDB 3 Enterprise for the full clustering and security suite, these 3.9 updates are designed to make your stack more predictable.

Operational maturity and system transparency

In 3.9, we’ve focused on making the database more predictable and transparent for operators. We have organized these refinements into three key areas:

Advanced CLI & Automation: We’ve expanded the CLI to better support complex, headless environments. This includes new flags for non-interactive automation and data validation, alongside support for unique host overrides to target specific node types in a cluster. We’ve also improved how Parquet query outputs are piped, making it easier to integrate InfluxDB into automated data pipelines.
System Reliability & Resource Management: We’ve refined how the database handles resources and large-scale schemas. To better support complex data, we’ve increased the default string field limit to 1MB. We’ve also hardened the database lifecycle; administrative controls are now more rigorous, and we’ve ensured that background resources, such as triggers, are cleanly decommissioned whenever a database is removed.
Visibility & Under-the-Hood Infrastructure: We’ve upgraded our core infrastructure to improve both security and operational clarity. This includes upgrading DataFusion and the bundled Python for more efficient query execution and plugin security. Additionally, the system now provides better visibility into access control and product identity, updating metrics, headers, and metadata access to clearly distinguish between Core and Enterprise builds across your stack.

Collectively, these refinements remove the subtle points of friction that can accumulate as a system scales in production. By hardening resource management and streamlining automation, we’re ensuring that InfluxDB 3 remains a predictable, “set-it-and-forget-it” core for your infrastructure.

Now in beta: A new performance preview

Behind the scenes, we’ve been working on performance updates to InfluxDB 3. These improvements support large-scale time series workloads without sacrificing predictability or operational simplicity. This work lays the foundation for what’s coming in 3.10 and 3.11, specifically focusing on smoothing behavior under load and expanding the range of schemas InfluxDB 3 can handle.

Because performance in time series is highly dependent on specific workloads and cardinality, we are introducing these updates as a beta in InfluxDB 3 Enterprise. The beta is intended for testing in staging or development environments only. It allows you to explore and provide feedback on:

Optimized single-series queries: Targeting reduced latency when fetching single-series data over long time windows.
Resource smoothing: Testing reduced CPU and memory spikes during heavy compaction or ingestion bursts.
Wide-and-sparse table support: For handling schemas ranging from extreme column counts to ultra-sparse data tables (or any combination).
Automatic distinct value caches: Early-stage, auto-creation of caches designed to reduce friction and eliminate metadata query latency.

These updates are available as an optional, flag-gated preview in InfluxDB 3.9 Enterprise. They are not recommended for production workloads. We encourage Enterprise users to test these capabilities against their specific use cases to help us refine the features for GA. InfluxDB 3 Core will also support many of these new features in the coming releases.

For instructions on how to enable these preview flags and to view the full technical requirements, visit our official Enterprise documentation.

Download InfluxDB 3.9: Available now via our downloads page or latest Docker images.
Join the beta: If you are an InfluxDB 3 Enterprise Trial user, reach out to me in our Discord or Community Slack to learn how to enable these beta features.

Telegraf Enterprise Beta is Now Available: Centralized Control for Telegraf at Scale

Scott Anderson (InfluxData) — Thu, 26 Mar 2026 07:30:00 +0000

Telegraf is incredibly good at what it does: collecting metrics, logs, and events from just about anywhere and sending them wherever you need. But once Telegraf becomes part of your production telemetry pipeline, spread across environments, teams, regions, and edge locations, the hard part isn’t installing agents; it’s operating them.

Configs drift. “Temporary” overrides linger. Rolling out changes across hundreds (or thousands) of agents becomes a careful, manual process. And when something breaks, the first question is rarely about the data—it’s about the fleet:

which configuration is running where, and is every agent healthy?

That’s the problem Telegraf Enterprise is built to solve.

Today, we’re opening the Telegraf Enterprise beta to the broader Telegraf community so you can help us validate the product where it matters most: at scale.

What is Telegraf Enterprise?

Telegraf Enterprise is a commercial offering for organizations running Telegraf at scale and needing centralized management, governance, and support. It brings together two key components:

Telegraf Controller: A control plane (UI + API) that centralizes Telegraf configuration management and fleet health visibility.
Telegraf Enterprise Support: Official support for Telegraf Controller and official Telegraf plugins, designed for teams that need dependable response times and expert guidance.

It’s built for real-world, large-scale agent deployments, where Telegraf isn’t a tool you occasionally touch, but a platform you rely on.

Meet Telegraf Controller: your Telegraf control plane

At the heart of Telegraf Enterprise is Telegraf Controller, which centralizes two things teams struggle with most at scale:

Configuration Management That Doesn’t Collapse Under Growth

Telegraf Controller helps you create and manage configurations to support consistency across environments while still allowing necessary variation. Core capabilities include:

Centralized configuration creation and editing
Templates and parameterization to reuse configs safely
Label-based organization (so fleets don’t devolve into a long list of “agent-123”)
Bulk operations for fleet-wide changes
Environment variable and parameter management
Plugin metadata visibility to simplify config authoring and maintenance

Fleet-Wide Health Visibility

Telegraf Controller gives you a single view into the overall status of your agent deployments, so you can understand:

Which agents are reporting as expected
Where health issues are clustering
What changed recently, and what might be correlated

In other words, you don’t just manage Telegraf. You operate it.

Designed to fit your telemetry stack

Telegraf Enterprise is designed to work with the way teams actually deploy Telegraf.

It does not require InfluxDB. You can use the Telegraf Controller regardless of where your telemetry data is going.
Configuration delivery follows a pull-based model, where agents fetch configuration over HTTP. This keeps change management predictable and compatible with locked-down environments.
It’s built to support hundreds to thousands of agents, with production-grade storage options and a modern UI + API architecture for automation.

Why we’re running this beta

This beta is open to any Telegraf user who wants to test-drive Telegraf Controller.

The focus of the beta is simple:

Test Telegraf Controller at scale: We want to validate how well Telegraf Controller holds up when you connect real fleets—hundreds or thousands of agents—with real operational behaviors.
Gather feedback from the community: We’re intentionally inviting community input early, while we’re still shaping the GA experience. What workflows are missing? What’s confusing? What would make this tool indispensable in your environment?

At this stage, your feedback directly influences what Telegraf Enterprise becomes.

Enterprise support that matches production expectations

Operating telemetry pipelines is a production responsibility, and when Telegraf is part of that pipeline, you need support that understands the stakes.

Telegraf Enterprise includes support designed for teams that need:

Clear expectations for response and escalation
Coverage for Telegraf Controller and official Telegraf plugins
Help diagnosing issues and reducing operational risk as fleets grow

This is especially valuable when Telegraf is deployed across multiple teams, environments, or customer sites, where operational consistency matters as much as collection capability.

Who is Telegraf Enterprise for?

Telegraf Enterprise is built for organizations that manage Telegraf fleets at a meaningful scale, including:

Platform engineering and SRE teams
DevOps organizations operating across multi-cloud / hybrid / edge
Managed service providers delivering telemetry as a service
Compliance-sensitive teams that need standardized configurations and governance

If you’re running a small number of agents and are comfortable managing configs manually, you may not need Telegraf Enterprise today. But if Telegraf is everywhere—and your team is responsible for keeping it reliable—centralized control quickly becomes less “nice to have” and more “how did we operate without this?”

Packaging: free and enterprise options

Telegraf Controller

A free tier is available for teams that want centralized configuration management and visibility with pre-defined limits.

Telegraf Enterprise

For teams operating Telegraf as critical infrastructure, Telegraf Enterprise includes the Telegraf Controller packaged with enterprise support.

The key difference: the Telegraf Enterprise is built for scale and operational reliability, with support and capabilities aligned to production fleet management.

Getting started with Telegraf Controller

Telegraf Enterprise is designed for teams operating Telegraf as a core part of production telemetry pipelines. If Telegraf is already how you collect metrics, logs, and events across your infrastructure, Telegraf Controller is the missing piece that helps you operate that collection layer like a platform—not a pile of configs.

To join the beta, click here to opt in. Please share your feedback in-app with the feedback button or our slack channel #telegraf-enterprise-beta.

Join the beta, push it hard, share your use case, and what makes your workflow easier!

A New Scale Tier for Time Series on Amazon Timestream for InfluxDB

Pat Walsh (InfluxData) — Mon, 16 Mar 2026 08:00:00 +0000

When we first announced the availability of InfluxDB 3 Core and Enterprise on Amazon Timestream for InfluxDB last year, we set a new standard for managed time series on AWS. We gave developers a simple way to harness high performance at scale while removing the burden of infrastructure management.

But as our customers have taught us, “at scale” is a moving target. Across Industrial IoT, physical AI, and real-time observability, data is growing in both volume and resolution. When you move from minute-by-minute polling to sub-millisecond, high-fidelity telemetry, the pressure on the underlying database compounds. To stay ahead of that curve, developers need a platform that scales as fast as their workloads.

Today, we’re delivering that by expanding InfluxDB 3 on Amazon Timestream for InfluxDB to support expanding clusters up to 15 nodes. We’re also introducing a seamless migration path from InfluxDB 3 Core to InfluxDB 3 Enterprise, allowing teams to unlock this massive performance tier without friction, risk of a manual architectural overhaul, or any data loss.

Scaling for the mission-critical

At InfluxData, we’re seeing time series expand from infrastructure monitoring to the foundation for autonomous systems. In high-stakes environments like power grid management or autonomous vehicle navigation, increased latency is a significant operational risk rather than just a performance metric.

Previously, AWS Timestream’s support of InfluxDB 3 was focused on smaller, highly efficient configurations. By expanding to 15 nodes, we are providing major upgrades across three important areas:

Query concurrency: More nodes mean more hands on deck to process complex, concurrent queries. Large teams can now run heavy analytical workloads without impacting real-time dashboards or critical alerts.
Massive throughput: With a larger cluster, you can ingest millions of data points per second across hundreds of millions of unique series, maintaining real-time query performance.
Workload isolation and optimization: These expanded clusters enable true functional isolation between ingestion, queries, and compaction. This allows granular performance tuning optimized for your most demanding workloads.

Architected for enterprise demand

This new 15-node option is available for InfluxDB 3 Enterprise and is designed for organizations that require high availability, enhanced security, and the power to maintain high ingestion and real-time query performance across high-resolution, high-velocity datasets. InfluxDB 3 Core will continue to operate in single-node deployments.

By leveraging AWS infrastructure, you can spin up these expanded clusters in minutes directly from the AWS Console. With our new seamless migration capabilities, you can transition your existing Core workloads to Enterprise clusters with a single click. This ensures that as your data grows (from a few local sensors to a global fleet of devices), your database never becomes the bottleneck, and your team never has to worry about the downtime typically associated with a migration. These larger clusters are available today in all AWS regions where Amazon Timestream for InfluxDB is available, ensuring you can deploy and optimize mission-critical time series infrastructure wherever your data lives.

The foundation for physical AI

Our partnership with AWS is about meeting developers where they build. By integrating with services like AWS Lambda, SageMaker, and Kinesis, we’ve simplified the path from high-volume streams into Physical AI. This is the frontier where intelligence moves from the digital realm into the physical world.

Time series is the heartbeat of this transition, fueling a two-part lifecycle:

Training: Using massive volumes of historical data to establish baselines and “normal” patterns.
Inference: Streaming real-time data against those models to trigger automated, deterministic actions.

What makes our partnership with AWS unique is that we support both sides of this loop. With up to 15 nodes at your disposal, InfluxDB 3 has the headroom to act as a distributed inference engine, running predictive maintenance and anomaly detection against your data. This eliminates the latency tax of moving massive datasets between layers, ensuring that whether you are managing a robotic fleet or a smart grid, your autonomous systems can perceive and react with real-time precision.

What’s next?

The future of time series is about speed, precision, and scale. With today’s announcement, we’re handing you the keys to all three. By removing the barriers between single-node efficiency and enterprise-grade performance, we’re making it easier than ever to evolve your architecture as fast as your data grows.

We’re excited to see what the community builds with this new level of power. If you’re ready to scale your real-time workloads, head over to the AWS Console and start building.

How to Integrate Grafana with Home Assistant in 2026

Community (InfluxData) — Thu, 08 Jan 2026 08:00:00 +0000

This post covers how to get started with Home Assistant and Grafana, including setting up InfluxDB and Grafana with Docker, configuring InfluxDB to receive data from Home Assistant, and creating a Grafana dashboard to visualize your data. It provides a comprehensive guide for real-time monitoring and analysis of Home Assistant data.

In this tutorial, you’ll learn how to install and configure both InfluxDB and Grafana, and create a Grafana dashboard to visualize data from Home Assistant.

Want to know more about InfluxDB and Grafana before you get started?

Watch the webinar.

Definitions: Grafana, Home Assistant, InfluxDB

Home Assistant

Home Assistant is an open source home automation platform that enables control and monitoring of various devices using a web interface or mobile app. With support for diverse devices and protocols, it’s highly customizable, allowing users to integrate new devices and protocols through custom components.

Grafana

Grafana is a versatile open source analytics and monitoring platform that offers powerful data visualization capabilities. It supports various data sources, including popular databases, such as InfluxDB, Elasticsearch, Prometheus, MySQL, PostgreSQL, and more.

With its extensibility through plugins, Grafana allows users to easily incorporate new data sources for enhanced analytics and monitoring.

InfluxDB

InfluxDB is an open source time series database designed for storing and querying time series data. It supports a wide range of data types, including integers, floats, strings, booleans, and others. Additionally, InfluxDB provides the flexibility to incorporate new data types via plugins.

Home Assistant integrates with Grafana, an analytics and monitoring platform, to visualize and analyze data. This data can be collected and stored in InfluxDB, an open source time series database, which allows for efficient querying of timestamped data.

Together, these tools enable users to control and monitor their smart home devices through Home Assistant while visualizing and analyzing the data in real-time using Grafana and InfluxDB.

Prerequisites and versions

To follow this tutorial, you will need the following:

Home Assistant 2025.1+
Docker 24.0+
InfluxDB 3.x
Grafana 12

Step 1: Install InfluxDB 3 Core

Option A: Install via Docker

First, pull the InfluxDB 3 image using this command:

docker pull influxdb:3-core

Once the download is complete, run the InfluxDB container with the following command:

docker run -d\
	--name influxdb \
	–p 8086:8086 \
-v influxdb3_data:/var/lib/influxdb2 \
	-v influxdb3_config:/etc/influxdb2 \
-e DOCKER_INFLUXDB_INIT_MODE=setup \
     -e DOCKER_INFLUXDB_INIT_USERNAME=admin \
     -e DOCKER_INFLUXDB_INIT_PASSWORD=your_password \
     -e DOCKER_INFLUXDB_INIT_ORG=home_org \
     -e DOCKER_INFLUXDB_INIT_BUCKET=home_assistant \
     influxdb:3

This command starts InfluxDB on port 8086, configures an initial user, organization, and bucket, and stores data in Docker volumes so it survives container restarts.

Option B: Install Directly

First, you’ll need to install InfluxDB on your machine. You can find instructions for your specific operating system on the InfluxDB downloads page.

Step 2: Configure InfluxDB and Generate an API Token

After installing InfluxDB, you’ll need to configure it to accept data from Home Assistant. You can do this by creating a new InfluxDB database and user account.

Open your browser and navigate to http://localhost:8086.

If you used the environment variables in Step 1, you can log in with the username and password you specified. Otherwise, complete the initial setup process.

Next, generate an API Token by:

In the InfluxDB UI, click Load Data in the left sidebar
Click API Tokens
Click Generate API Token (All Access API Token)
Give it a description like “Home Assistant Token”
Grant Write permission to the home_assistant bucket
Click Generate

Lastly, copy and save the token, as you’ll need it for Home Assistant and Grafana configuration.

Step 3: Configure the InfluxDB integration in Home Assistant

Now, you’ll need to install the InfluxDB integration in Home Assistant. You can do this by navigating to the Home Assistant web interface, selecting Settings from the sidebar, and then selecting Integrations. From there, you can search for InfluxDB and follow the prompts to configure the integration. Next, open your Home Assistant configuration.yaml file and add the following influxdb configuration block:

 influxdb:
     api_version: 2
     ssl: false
     host: YOUR_INFLUXDB_IP
     port: 8086
     token: YOUR_API_TOKEN
     organization: home_org
     bucket: home_assistant
     tags:
       source: HomeAssistant
     tags_attributes:
       - friendly_name
     default_measurement: state
     exclude:
       entity_globs:
         - sensor.date*
         - sensor.time*
     include:
       domains:
         - sensor
         - binary_sensor
         - climate
         - light
         - switch

Then, restart Home Assistant to apply the changes.

For additional configuration options, see the Home Assistant InfluxDB integration documentation.

Verify Data is Flowing to InfluxDB

After restarting Home Assistant:

Return to the InfluxDB UI
Click the Data Explorer in the left sidebar
Select your home_assistant bucket
Within a few minutes, you should see measurements appearing

If you don’t see data, check the logs at Settings -> System -> Logs for connection errors.

Step 4: Install Grafana Using Docker

If you prefer to run Grafana in Docker rather than install it locally, follow these steps.

Install Docker

If you haven’t already, you’ll need to install Docker on your machine. You can find instructions for your specific OS on the Docker website.

Pull the Grafana Docker Image

Once Docker is installed, you can pull the Grafana Docker image by running the following command in your terminal:

docker pull grafana/grafana

This will download the latest version of the Grafana Docker image to your machine.

Run the Grafana Docker container

To start a new Grafana Docker container, run the following command in your terminal:

docker run -d -p 3000:3000 --name=grafana grafana/grafana

This will start a new container named grafana and map port 3000 on the container to port 3000 on your local machine.

Access the Grafana web interface

Once the container is running, you can access the Grafana web interface by navigating to http://localhost:3000 in your web browser.

Create a Grafana account and connect data sources

When you first access the Grafana web interface, you’ll be prompted to create a new user account. After creating your account, you can start configuring Grafana by adding a data source and creating dashboards, as described in the previous steps.

Configure Grafana

After installing Grafana, you’ll need to configure it to connect to the InfluxDB database. You can do this by following these steps:

Open the Grafana web interface by navigating to http://localhost:3000 in your web browser. Log in to Grafana using the default username admin and password admin.

Click on the Configuration icon in the sidebar and select Data Sources.
Click on the Add data source button and select InfluxDB. Enter the following information in the InfluxDB details section:
- URL: http://localhost:8086
- Query Language: SQL or InfluxQL
- Database: homeassistant
- User: homeassistant
- Password: yourpassword
- HTTP method: GET
Click on the Save & Test button to save the data source and test the connection to InfluxDB.

Create a Grafana dashboard

After configuring the InfluxDB data source in Grafana, you can create a new dashboard to visualize the Home Assistant data. To do this, follow these steps:

Click the Create icon in the sidebar, then select Dashboard.
Click on the Add new panel button and select Graph.
Click on Panel title.
In the Query tab, select the InfluxDB data source that you configured.
Enter your InfluxDB query in the Query editor. For example, you might enter a query like this to display the temperature from a temperature sensor:

SELECT mean("value") FROM "temperature" WHERE ("entity_id" = 'sensor.temperature') AND $timeFilter GROUP BY time($__interval)

This query selects the average temperature from the temperature measurement for the sensor.temperature entity in Home Assistant and groups the results by time interval.

Click on the Apply button to save the query and display the results.

Customize your panel as desired by selecting different visualization options, adding legends and annotations, etc.

Click on the Save icon in the toolbar to save the panel to your dashboard.

You can repeat these steps to add more panels to your dashboard, using different InfluxDB queries to display different data. Check InfluxDB’s Grafana documentation for more details.

Step 8: View Your Dashboard

After creating your Grafana dashboard, you can view it by navigating to http://localhost:3000/dashboards in your web browser and selecting the dashboard from the list. You should now see a visual representation of your Home Assistant data in Grafana!

Troubleshooting and FAQs

No data appears in InfluxDB after configuring Home Assistant

Check your Home Assistant logs (Settings > System > Logs). If the connection fails, you will see errors there. Ensure the token in configuration.yaml is correct and wrapped in quotes if it contains special characters.

Can I write to multiple InfluxDB databases or buckets from Home Assistant?

No. Home Assistant’s InfluxDB integration only supports writing to a single database or bucket. All your sensor data must be sent to a single location. If you need to separate data streams, you’ll need to use Home Assistant’s filtering options in configuration.yaml to exclude certain entities, or run multiple Home Assistant instances.

My Grafana can’t connect to InfluxDB even though both are running. What’s wrong?

This is often a Docker networking issue. If both services are running in Docker containers, they may not be able to reach each other via localhost.

Try using your host machine’s actual IP address (like 192.168.1.100:8086) instead of localhost:8086 in Grafana’s data source configuration. Also, verify that the port number matches; InfluxDB’s HTTP API uses port 8086 by default.

If you’re using Home Assistant add-ons, make sure you’re using the correct internal container names (like a0d7b954-influxdb:8086 instead of a0d7b954_influxdb:8086, note the hyphen vs underscore).

Can I use InfluxDB Cloud instead of running my own instance?

Yes. InfluxDB Cloud offers a fully-managed InfluxDB 3 service, and the setup is very similar. You’ll get a URL, organization, bucket, and API token from the InfluxDB Cloud console, then configure Home Assistant and Grafana to point at those cloud endpoints instead of a local instance.

This eliminates the need to manage Docker containers, backups, and updates yourself. However, you’ll need to consider data egress costs if you have high query volumes, and your Home Assistant data will be stored in the cloud rather than locally.

Can I migrate from InfluxDB 2.x to 3.x?

Yes, InfluxDB 3 maintains backward compatibility with the v2 write API. Your Home Assistant configuration will continue to work. For data migration, refer to the official InfluxDB migration documentation.

Next steps for Home Assistant and Grafana

Getting started with Home Assistant and Grafana requires installing InfluxDB and Grafana on your machine, configuring InfluxDB to accept data from Home Assistant, installing the InfluxDB integration in Home Assistant, configuring Grafana to connect to the InfluxDB database, and creating a Grafana dashboard to visualize your data. With these tools and techniques, you can easily monitor and analyze your Home Assistant data in real-time.

InfluxData Blog - Product

From Edge to Enterprise: How Litmus and InfluxDB Are Modernizing the Industrial Data Stack

The industrial data problem

How Litmus and InfluxDB work together

The edge: collect, contextualize, buffer

The industrial data hub: Centralize, scale, retain

The bridge to higher-level analytics

Get started

From Edge to Cloud: How Litmus Edge and InfluxDB Unlock Industrial Intelligence at Hannover Messe

The industrial data problem

Collect, contextualize, and store—all at the edge

Scale, query, retain: your industrial data hub

Scaling across lines, sites, and the enterprise

The bridge to higher-level analytics

Extending into the cloud with AWS

What we’re showing at Hannover Messe

What’s New in InfluxDB 3 Explorer 1.7: Table Management, Data Import, Transforms, and More

Table management

Import from InfluxDB

Transform data

Rename Table

Rename Columns

Transform Values

Filter Data

Downsample Data

Get started

Less Friction, More Control: Here's What Shipped in Q1

Telegraf Controller enters beta

InfluxDB 3.9 adds more operational control

Processing Engine updates make InfluxDB 3 easier to operationalize

Better visibility for Cloud Dedicated customers

InfluxDB Enterprise 1.12.3 delivers efficiency gains for v1 environments

Amazon Timestream for InfluxDB adds a new scale tier and simple upgrade path

Looking ahead

New Plugins, Faster Writes, and Easier Configuration: What’s New with the InfluxDB 3 Processing Engine

A quick refresher: Processing Engine plugins

New plugins: data ingestion, import, and validation

InfluxDB Import Plugin

Data subscription plugins: MQTT, Kafka, and AMQP

OPC UA Plugin

Schema Validator Plugin

Processing Engine general improvements

Easier plugin configuration in Explorer

What’s next

Try them out

What’s New in InfluxDB 3.9: More Operational Control and a New Performance Preview

Operational maturity and system transparency

Now in beta: A new performance preview

Get started and share your feedback:

Telegraf Enterprise Beta is Now Available: Centralized Control for Telegraf at Scale

What is Telegraf Enterprise?

Meet Telegraf Controller: your Telegraf control plane

Configuration Management That Doesn’t Collapse Under Growth

Fleet-Wide Health Visibility

Designed to fit your telemetry stack

Why we’re running this beta

Enterprise support that matches production expectations

Who is Telegraf Enterprise for?

Packaging: free and enterprise options

Telegraf Controller

Telegraf Enterprise

Getting started with Telegraf Controller

A New Scale Tier for Time Series on Amazon Timestream for InfluxDB

Scaling for the mission-critical

Architected for enterprise demand

The foundation for physical AI

What’s next?

How to Integrate Grafana with Home Assistant in 2026

Definitions: Grafana, Home Assistant, InfluxDB

Home Assistant

Grafana

InfluxDB

Prerequisites and versions

Step 1: Install InfluxDB 3 Core

Step 2: Configure InfluxDB and Generate an API Token

Step 3: Configure the InfluxDB integration in Home Assistant

Verify Data is Flowing to InfluxDB

Step 4: Install Grafana Using Docker

Install Docker

Pull the Grafana Docker Image