Home Assistant's built-in history does the job for the last few days, but it was not built for seasonal analysis, cross-zone comparison, or the long time-series queries that agricultural operations generate. Grafana plus InfluxDB was built for exactly that. Home Assistant streams its entity state history to InfluxDB; Grafana queries InfluxDB and produces rich interactive dashboards — seven-day temperature trends, month-over-month DLI comparisons, annual irrigation totals, per-zone season summaries. For operations running the graybox approach on capable hardware, adding Grafana and InfluxDB is natural; both run in Docker alongside Home Assistant with minimal additional resource load. This page covers why the pairing matters for agriculture, how it fits into the graybox philosophy, configuration patterns, the specific agricultural dashboards Grafana handles better than Lovelace, and the failure modes that affect production Grafana deployments. Lovelace remains the primary operational interface — the quick-check view, the controls, the at-a-glance state — but Grafana becomes the analysis tool for understanding how the operation is running over time.
Before adding Grafana.
Prerequisites and considerations.
Home Assistant running with enough spare capacity. Grafana and InfluxDB together add modest resource load — a few hundred megabytes of memory, some disk I/O for InfluxDB writes, a small fraction of CPU. On a repurposed business desktop with 16 GB of RAM and an SSD (the primary hardware recommendation per [Choosing Your Hardware](/home-assistant/hardware/choosing)), the overhead is unnoticeable. On a Raspberry Pi with 4 GB of RAM, it is meaningful; the graybox approach exists partly to make additions like this easy.
A Docker-based Home Assistant deployment, or separate VM. The graybox approach — covered in [Installing Home Assistant on Ubuntu with Docker](/home-assistant/installation/ha-docker) — naturally accommodates Grafana and InfluxDB as additional Docker services. Home Assistant OS installations can add InfluxDB as a supervisor add-on and can run Grafana as another add-on or in an external container. The specifics of how Grafana gets deployed depend on the installation method; the broad strokes are the same.
A clear sense of what long-term analysis is needed. Grafana is powerful but requires setup and configuration. For operations that never need anything beyond Home Assistant's built-in history, the investment may not pay off. For operations doing season-over-season comparison, compliance documentation, trend analysis, or cross-zone comparison, the investment is substantial.
Disk space for InfluxDB retention. InfluxDB stores every entity state change indefinitely by default. For an operation with hundreds of sensors updating every few minutes, this adds up — hundreds of megabytes per year, sometimes more. Disk space planning matters, and retention policies limit how far back data is kept.
What Grafana and InfluxDB do.
Two distinct tools working together.
InfluxDB. A time-series database. Purpose-built for storing numeric values with timestamps. Handles the ingest of constantly-updating sensor data efficiently, and supports queries over long time ranges with reasonable speed. InfluxDB is the storage layer; it does not display anything by itself.
Grafana. A dashboard and analytics platform. Queries data from InfluxDB (and many other sources) and renders it as graphs, tables, heat maps, and other visualizations. Grafana is the visualization layer; it does not store data.
Together. Home Assistant writes sensor state changes to InfluxDB continuously. Grafana queries InfluxDB on demand when the user loads a dashboard, producing the visualizations. The separation of storage and visualization lets each tool do its specialty; it also lets data flow in from other sources (not just Home Assistant) to unified dashboards.
Compared to Home Assistant's built-in history. Home Assistant stores recent state history in a small database (SQLite or MariaDB) optimized for short time windows and automation trigger use. The History Graph card works well for the last 24 hours; it handles longer periods less gracefully, and complex queries (zone comparisons, derived aggregations, year-over-year trends) are either clumsy or not possible. InfluxDB plus Grafana does those things well — at the cost of being an additional system to maintain.
The graybox fit.
The graybox approach to Home Assistant deployment — covered in [Choosing Your Hardware](/home-assistant/hardware/choosing) — anticipates adding capable services alongside Home Assistant rather than keeping the host dedicated to Home Assistant alone. InfluxDB and Grafana are natural additions.
Resource usage is small. For most agricultural operations, the combined overhead of InfluxDB and Grafana is well under 1 GB of memory and a small fraction of a CPU core. A capable graybox host has room for both alongside Home Assistant.
Networking is simple. On a single host, Home Assistant, InfluxDB, and Grafana all run in the same Docker network (or as add-ons on the same machine). Home Assistant writes to InfluxDB on a local port; Grafana reads from InfluxDB on a local port. No external networking required for the core data flow.
Backup strategy unifies. Backups can cover Home Assistant, InfluxDB, and Grafana together — one host, one backup strategy, as covered in [Backup and Recovery](/home-assistant/operations/backup).
The principle of one capable host doing many jobs. The graybox approach rejects the idea that each service needs its own hardware. One business-class desktop or laptop runs Home Assistant, InfluxDB, Grafana, probably a few other services (Frigate for computer vision, a backup tool, possibly a VPN endpoint), and has capacity to spare. Grafana adds capability without fragmentation.
The data flow.
How a sensor reading gets from a greenhouse to a Grafana dashboard.
1. The sensor. A temperature sensor reports a value. The reading arrives at Home Assistant through its integration — ESPHome, BLE, Zigbee, or whatever protocol is in use.
2. Home Assistant entity state change. Home Assistant updates the entity state. Automations, the built-in recorder, and the InfluxDB integration all see the state change.
3. Home Assistant's InfluxDB integration writes to InfluxDB. Configured in Home Assistant's configuration, the InfluxDB integration streams entity state changes to InfluxDB over the local network (or local Docker network).
4. InfluxDB stores the reading. The timestamp, the entity ID (as a tag), the value (as a field), and any additional metadata go into the time-series database. This happens continuously.
5. Grafana queries InfluxDB on demand. When a user loads a Grafana dashboard, Grafana issues queries to InfluxDB asking for specific data (this entity, this time range, this aggregation).
6. Grafana renders the visualization. The query results become the graphs, tables, and panels the user sees.
The data flow is one-way — Home Assistant writes to InfluxDB; Grafana reads from InfluxDB. Grafana never writes back to Home Assistant; it is purely an analytics layer.
Configuring Home Assistant to write to InfluxDB.
Home Assistant's InfluxDB integration handles the write side.
The integration. Added through Home Assistant's configuration — either through the UI's integrations menu or through YAML. Basic configuration specifies the InfluxDB host, port, database/bucket name, and authentication credentials.
Which entities to include. By default, the integration can be configured to include or exclude specific entities or entity domains. For most operations, including all sensor and binary_sensor entities is right — these are the values worth analyzing over time. Excluding noisy entities (signal strength, technical sensors that do not inform decisions) reduces storage without losing analytical value.
Performance tuning. The integration supports batching writes, adjusting precision, and controlling update frequency. For typical agricultural operations, defaults work well. High-frequency sensors (reading every second) can generate substantial write volume; reducing precision or increasing batch intervals lowers the load.
Authentication. InfluxDB 2.x uses token-based authentication; Home Assistant's integration accepts the token in its configuration. InfluxDB 1.x uses username/password. New installations should use InfluxDB 2.x; legacy installations on 1.x continue to work.
Setting up InfluxDB.
InfluxDB deployment options.
As a Docker service alongside Home Assistant. The typical graybox pattern. A Docker Compose entry for InfluxDB, with a volume for data persistence, runs alongside Home Assistant. The initial setup creates the first bucket, organization, and admin token.
As a Home Assistant OS add-on. Available through the add-on store. Easier initial setup on Home Assistant OS installations; slightly less flexible than a standalone Docker deployment.
On separate hardware. For operations with enough scale to warrant it — multiple Home Assistant instances writing to one InfluxDB, or an InfluxDB shared across non-Home-Assistant data sources — InfluxDB can run on its own host. Overkill for most agricultural operations.
Retention policies. InfluxDB supports retention policies that automatically expire old data. For operations that want indefinite history, no retention policy is set. For operations with disk-space constraints, a retention policy (say, three years of raw data) bounds storage growth.
Downsampling. InfluxDB supports downsampling — reducing older data to aggregated summaries while keeping recent data at full resolution. For an agricultural operation where "the exact value every five minutes three years ago" is less useful than "hourly averages three years ago," downsampling reduces storage while preserving the useful information.
Volume backups. InfluxDB's data volume needs to be part of the backup strategy. A graybox host with Docker volumes is backed up by backing up the host or the specific Docker volumes; InfluxDB is just one of those.
Setting up Grafana.
Grafana deployment options.
As a Docker service alongside Home Assistant and InfluxDB. The graybox pattern again. A Docker Compose entry, a data volume, and initial admin credentials. Grafana runs on a configurable port (default 3000) and is accessed through a browser.
As a Home Assistant OS add-on. Available through the community add-on store. Simple setup on Home Assistant OS.
Adding InfluxDB as a data source. Once Grafana is running, the first step is adding InfluxDB as a data source. Grafana provides a UI for this — paste the InfluxDB URL (typically `http://influxdb:8086` for local Docker) and the authentication token. Grafana tests the connection and saves the data source.
User and role configuration. Grafana supports multiple users with different roles — admin, editor, viewer. For operations where staff should see dashboards but not edit them, viewer roles are appropriate.
Organization. Grafana supports multiple organizations within one installation. For most agricultural operations, the default single organization is fine; the feature is more useful for multi-tenant deployments.
Backup. Grafana's dashboard configurations and settings live in its data volume. Backing up the volume protects against loss. Grafana also supports dashboard export (JSON files) for individual dashboard portability; these can be checked into Git.
Agricultural dashboards in Grafana.
The dashboards Grafana handles well that Lovelace handles less well.
Multi-day temperature and humidity trends. Seven days of every zone's temperature and humidity, overlaid or stacked, at hourly resolution. Reveals weekly patterns, diurnal cycles, and the effects of scheduled operations (irrigation, supplemental lighting) on microclimate.
Season-over-season comparison. This month last year versus this month this year. For operations that run continuously through seasons, the comparison reveals whether control improvements are working, whether the crop is responding differently, whether the weather is affecting things more or less than historical patterns.
Cross-zone comparison. All zones' VPDs on one graph. All zones' DLIs over the last 30 days. Reveals which zones are performing consistently, which are outliers, and whether specific zones have systematic differences from others.
DLI calendar heat maps. A 365-day grid showing DLI for each day, color-coded from low to high. At a glance, the operation's full year of light exposure becomes visible. Seasonal patterns, cloudy weeks, and outlier days all appear.
Cumulative metrics over long periods. Total irrigation water used per month. Total electricity consumed by supplemental lighting per season. Accumulated growing degree days through the growing period. Lovelace's counter displays show a current total; Grafana's cumulative graphs show how the total accumulated over time.
Statistical summaries. Monthly temperature averages, maximums, minimums, and standard deviations. Reveals the shape of a month beyond what a recent-hours graph shows.
Anomaly detection panels. Grafana supports alerting on query results. A panel that shows "VPD deviations more than 0.3 kPa from target, by hour, for the last week" highlights when control was working poorly.
Compliance reports. For operations with regulatory compliance requirements (cold chain documentation, food safety records), Grafana dashboards configured to show the required records at the required resolution produce audit-ready views. Exports to PDF or CSV support the documentation workflow.
Cross-source dashboards. Grafana can query data sources other than InfluxDB — weather data, external APIs, other databases. A dashboard that overlays local zone temperature with regional weather data, all on the same time axis, makes correlations visible.
Query basics.
How Grafana queries InfluxDB, in practical terms.
Flux and InfluxQL. InfluxDB 2.x supports two query languages: Flux (newer, more powerful) and InfluxQL (older, SQL-like). Most new installations use Flux. Grafana has UI-based query builders for both; manual query writing is possible for advanced cases.
The typical query shape. "Give me the value of entity X over time range Y, aggregated by interval Z." Grafana's UI translates this into the appropriate query language syntax automatically. Users not comfortable writing queries can build most dashboards through the UI.
Aggregation. Long time ranges require aggregation to be visualizable. An hourly aggregation (mean, max, min, or similar) of a sensor over seven days produces 168 data points rather than thousands, which renders cleanly and loads quickly.
Downsampling at query time. Grafana can apply downsampling in queries without requiring pre-computed aggregates in InfluxDB. For ad-hoc analysis, this is convenient. For frequently-displayed dashboards with long time ranges, pre-computing aggregates in InfluxDB produces faster dashboards.
Entity name references. Home Assistant entity IDs become tags in InfluxDB. Queries filter by entity ID to pick specific sensors. Patterns for selecting multiple related entities (all zones' temperatures, for example) use tag filters or regex patterns.
Dashboard configuration patterns.
How Grafana dashboards are typically organized.
Per-zone dashboards. One dashboard per zone, showing that zone's metrics at various time ranges. Natural for operations where each zone is a primary unit of attention.
Cross-zone comparison dashboards. One dashboard showing the same metric across all zones. Complementary to per-zone dashboards; both views are useful.
Time-range templates. A dashboard's time range is typically a variable — "last 24 hours," "last 7 days," "last 30 days." Users switch the time range from the dashboard header; all panels update to use the new range. One dashboard serves many time-range inquiries.
Variables for filtering. A dashboard can have variables for zone selection, crop stage, or other dimensions. Users pick values from dropdowns; panels filter accordingly. A single configurable dashboard replaces many hardcoded variants.
Alerts from Grafana. Grafana can alert on query results — "if VPD has been above target for more than 6 of the last 24 hours, notify." Useful for longer-horizon alerts that Home Assistant's automation-based alerts are less well-suited to.
Dashboard export and version control. Dashboard definitions export as JSON. Checking them into Git provides version control and portability; the same dashboard can deploy to multiple Grafana instances.
Common failure modes.
Specific Grafana/InfluxDB problems from real deployments.
The dashboard that was empty for the wrong reason. A Grafana panel showed "No data"; the grower thought the sensor was broken. Actually the time range on the dashboard was set to a period before the sensor existed. Fix: check time range first when a panel is empty; verify the sensor is writing to InfluxDB through InfluxDB's own data-inspection tools.
The InfluxDB that filled the disk. Retention was not configured; years of every-minute readings accumulated. The host's disk filled. InfluxDB stopped accepting writes; Home Assistant's InfluxDB integration started failing silently. Fix: set retention policies early; monitor disk usage; consider downsampling for long-term retention.
The dashboard that was slow. Complex queries over long time ranges without aggregation took 30 seconds to load. Users stopped opening the dashboard. Fix: aggregate in queries; use pre-computed downsampled data for long ranges; separate fast-loading operational dashboards from slow-loading analytical dashboards.
The Home Assistant InfluxDB integration that silently failed. InfluxDB's authentication token was rotated; Home Assistant's configuration was not updated. Home Assistant's integration logged errors but did not alert prominently; the grower did not notice until days of data were missing. Fix: monitor the InfluxDB integration's status; alert on write failures; consider running a periodic check that writes to InfluxDB have been happening.
The Grafana dashboard that showed wrong units. A query returned values in the sensor's raw units (e.g., °C), but the panel was configured to display "°F." The graph's Y-axis labeled the values incorrectly. Fix: verify units carefully in panel configuration; use template sensors that convert to the operation's preferred units if unit consistency matters.
The dashboard that broke when Grafana updated. A plugin used by the dashboard was abandoned by its author; a Grafana update removed compatibility. The dashboard panels using the plugin stopped rendering. Fix: minimize third-party plugin dependencies; test Grafana updates on a staging instance; have migration paths for abandoned plugins.
The InfluxDB 1.x installation that could not upgrade cleanly. An operation running InfluxDB 1.x for years accumulated queries, dashboards, and integrations coded for that version. Upgrading to 2.x required query migration (InfluxQL to Flux in some cases), integration re-authentication, and dashboard rebuilding. Fix: if running InfluxDB 1.x, plan the upgrade deliberately; document queries so they can be rewritten; prefer starting new installations on 2.x.
The Grafana admin password that got lost. Someone set the admin password during setup; the credentials were never documented. Later, when admin access was needed, nobody remembered the password. Fix: document credentials in the operation's password manager; use SSO (single sign-on) for multi-user installations where available.
The dashboard that referenced entities that no longer existed. Home Assistant entities were renamed or removed; the Grafana dashboard's queries referenced the old names. Panels started showing empty data. Fix: review dashboards after significant Home Assistant changes; use InfluxDB's entity inventory to find what is available; consider scripts that automatically update dashboard queries on entity renames.
The network issue that lost data. A brief network outage between Home Assistant and InfluxDB caused writes to fail during the outage; some data was lost. Fix: Home Assistant's InfluxDB integration can retry failed writes; consider local-buffering patterns for critical data; accept that brief network outages do produce small data gaps.
What not to do.
Patterns to avoid.
Don't try to make Grafana the primary operational interface. Grafana is for analysis. Lovelace remains the operational interface — the dashboard the grower checks thirty times a day. Using Grafana for quick-check purposes leads to slow-loading dashboards, over-complex visualizations, and a worse daily experience. Each tool has its job.
Don't skip retention planning. InfluxDB accumulates data forever by default. Without a plan, disk usage grows unbounded. Set retention policies. Monitor disk usage. Consider downsampling for long-term retention.
Don't overload dashboards with panels. A Grafana dashboard with forty panels is slow, hard to read, and rarely as useful as three focused dashboards. Break broad views into purposeful dashboards.
Don't forget about Grafana backups. Dashboards are configuration. Losing them loses work. Back up the Grafana data volume; export dashboards to JSON and keep them in Git for additional durability.
Don't configure Grafana to expose to the internet without security hardening. A Grafana instance accessible from the public internet needs strong authentication, ideally behind a VPN or reverse proxy with access controls. An unprotected Grafana is an attack vector. Refer to [Remote Access](/home-assistant/operations/remote-access) for secure external access patterns.
Don't hand-code complex Flux queries when the UI will do. Grafana's UI query builder produces correct queries for most use cases. Hand-written queries are for the cases the UI cannot express; most dashboards never need that.
Don't skip testing queries against small data ranges. A query developed on the last hour of data may produce different results on the last week. Test the query against the time ranges it will actually be used with before relying on it.
Don't assume InfluxDB's default configuration fits your operation. InfluxDB has many configuration options — memory allocation, write performance, query timeouts. The defaults work for small deployments; larger operations may need tuning. Read the documentation when performance issues appear.
Don't ignore Grafana plugin warnings. Grafana warns when plugins are outdated or have known issues. Pay attention; update plugins; remove plugins that are no longer maintained.