InfluxData

One of the things we love most about building an open source platform is seeing what the community creates with it, and independent developer Anton Havekes recently built something we just had to share. Anton put together Influx Dashboard, a native iOS app that connects to your InfluxDB instance and brings your time series data straight to your phone. We’re genuinely thrilled to see this kind of work come out of the community. A quick note before we dive in: this is entirely Anton’s project, built and published by him. InfluxData has no commercial relationship or financial stake in the app. We’re sharing it simply because we think it’s a great piece of community work and because surfacing what people build on InfluxDB is something we’ll always make time for. So, thank you, Anton, for the awesome work you’ve done! Here’s how it works. What is Influx Dashboard? Influx Dashboard is a mobile-first visualization tool for InfluxDB. It supports InfluxDB versions 1, 2, and 3—including Core, En

Material Event filed 2026-05-18

The need for real-time telemetry in aerospace Every second of a flight test produces a torrent of telemetry from engines, sensors, and control systems. Aerospace teams have captured this data for decades to verify performance and maintain safety, yet analysis often happens long after the mission ends. Engineers wait for downloads, conversions, and compliance checks before they can interpret results. That delay turns telemetry into a historical record instead of a feedback loop. As flight programs shorten development cycles and expand digital testing, teams need to see and act on telemetry as it arrives. Real-time visibility turns raw packets into insight and enables faster, more confident decisions mid-test. What is IRIG 106? IRIG 106 forms the backbone of flight-test telemetry. Established by the Range Commanders Council, it defines how data is formatted, synchronized, and recorded to ensure interoperability across recorders, ground stations, and analysis tools. Its purpose is to crea

A battery is a complex electrochemical system where safety and revenue are decided in milliseconds. Cell temperatures, voltages, and state of charge change in real-time; dispatch decisions and thermal alarms must fire in real-time. Anything in between—your data pipeline, your historian, your alerting layer—has to disappear into the background. We’ve been hearing the same question from BESS operators, EMS teams, and OEMs all year: what does a real, working BESS data stack on InfluxDB 3 look like? So we shipped one. Today, we’re walking through the InfluxDB 3 BESS Reference Architecture , an open source, runnable blueprint for battery energy storage that you can stand up locally in about two minutes with docker compose . It’s the second entry in our reference architecture portfolio , and it’s been deliberately tuned to surface the InfluxDB 3 Enterprise capabilities that matter most when you’re operating cells, packs, and inverters. Why BESS is a special case for time series Most BESS ope

Material Event filed 2026-05-07

Quarterly Report filed 2026-05-07

InfluxDB 3 Explorer 1.8 is all about writing data and keeping it under control. You can now subscribe to MQTT, Kafka, and AMQP streams directly from Explorer, generate custom sample datasets, stream live sample data continuously into your database, and validate your line protocol and preview the resulting schema before you write it. You can now also view and edit retention periods on both databases and individual tables. Data Subscriptions: stream from MQTT, Kafka, and AMQP InfluxDB 3 Explorer now includes a Data Subscriptions page (powered by the MQTT , Kafka , and AMQP subscriber plugins) that lets you wire a streaming source directly into a database. Pick a provider, fill in configuration details, and Explorer installs and activates the right Processing Engine plugin behind the scenes. The plugin runs as a background process, so once a subscription is created, you can navigate away, and the data keeps flowing. The MQTT configuration contains: a subscription name, target database, br

Time series autoregression is a powerful statistical technique that uses past values of a variable to predict its future values. This approach is particularly valuable for forecasting applications where historical patterns can inform future trends. In this hands-on tutorial, you’ll learn how to implement autoregressive (AR) models using Python and see how InfluxDB can enhance your time series analysis workflow. Understanding time series autoregression Autoregression models represent one of the fundamental approaches to time series forecasting, based on the principle that past behavior can predict future outcomes. The “auto” in autoregression means the variable is regressed on itself—essentially, we’re using the variable’s own historical values as predictors. This concept is intuitive: yesterday’s temperature influences today’s temperature and last month’s sales figures can indicate this month’s performance. An autoregressive model of order p, denoted as AR(p), uses the previous p obser

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 u

In this blog, we’re going to take a look at how you can set up a fully-functioning, robust data pipeline to centralize your data into an InfluxDB instance by collecting and sending messages with the MQTT protocol. We’ll start with a brief overview of the technologies and protocols used in the pipeline, then dive into how you can connect, configure, and test them to ensure your data pipeline is fully functional. It’s going to be a long post, so let’s jump right in. What is MQTT? MQTT is an industry-standard, lightweight protocol for moving messages through a network of devices. It functions by having a broker, or multiple brokers, receive messages from individual devices (publishing clients) across the network, and publish those messages to external systems (destination clients) that are connected and listening to the broker. By categorizing messages into “topics,” systems that subscribe to specific topics can opt to receive only messages they’re interested in. As a lightweight protocol

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 unfor