Summary

Managing Battery Energy Storage Systems (BESS) and distributed energy resources (DERs) is fundamentally a data problem: each site generates continuous time-series telemetry from BMS, PCS, EMS, and SCADA systems, and operators need a unified, time-aligned view across all of them. The TIG stack (Telegraf → InfluxDB → Grafana), alongside InfluxDB 3’s Processing Engine, gives you that unified view by collecting, storeing, querying, and visualizing data with a single source of truth, detecting anomalies as it works.

For IT and OT engineers managing Battery Energy Storage Systems (BESS) and other distributed energy resources (DER), data is a challenge. 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.

BESS graphic

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.

FAQ

What is the biggest data challenge in operating a BESS (Battery Energy Storage System)?
Telemetry volume and fragmentation—a single BESS site streams real-time data from BMS, PCS, SCADA, and EMS simultaneously, and each of those systems only answers part of the operational picture. The challenge is building a unified, time-aligned view across all of them, which gets more difficult once you're managing multiple sites instead of one. At full resolution, that same data also needs to be retained long-term for degradation tracking and predictive maintenance.

What's the difference between BMS, PCS, EMS, and SCADA in a BESS?
Each system answers a different operational question: BMS tells you if the batteries are safe and healthy, PCS tells you whether you can currently deliver or absorb power, EMS decides when to charge or discharge, and SCADA reports what's happening on site right now. They work fine individually, but none of them gives you the fleet-wide, time-aligned picture on their own.

Why use Telegraf instead of writing custom data collectors for BESS signals?
Because Telegraf ships with plugins for the protocols BESS equipment already speaks — Modbus, OPC-UA, MQTT, SNMP, HTTP — so you can onboard a new signal without writing a bespoke collector for it. It also supports store-and-forward buffering at the edge, which matters when a site's network connection to the central platform is unreliable. On top of that, it normalizes everything into a consistent metric format before the data ever reaches InfluxDB, which keeps downstream queries and dashboards simpler.

How do you do real-time anomaly detection on BESS data without building a Kafka or Flink pipeline?
By running the detection logic inside the database itself, using InfluxDB 3's Processing Engine, instead of exporting data to a separate stream-processing cluster or Python application server. The engine can evaluate thresholds—like temperature exceeding 80°C or vibration drift—as data arrives, which removes the latency, operational overhead, and added attack surface of a separate processing layer. The same engine also handles related jobs like downsampling and alerting in place.

Can InfluxDB 3 scale from a single BESS site to a full fleet?
Yes. You can run a single InfluxDB 3 Core instance for one site or scale up to a multi-node Enterprise cluster as your fleet grows, without changing the underlying data model or query approach. This lets the same architecture and dashboards extend from site-level asset health monitoring to fleet-wide coordinated operations and incident response.

Is a push-based stack like TIG still a good fit for BESS/IoT telemetry compared to pull-based tools like Prometheus?
For BESS and IoT telemetry specifically, push-based collection has lower latency and tends to fit better, since pull-based collection requires your targets to be reachable, stable, and willing to serve HTTP. Telegraf pushes metrics from the edge as they're generated, which suits BESS sites where IoT devices may be intermittently connected and unreachable for a central system to poll on demand.