Cards That Matter for Agriculture.

Before using these cards.

Prerequisites:

Platform comfort. [Lovelace Fundamentals](/home-assistant/dashboards/lovelace) covers the mechanics. Readers comfortable with the dashboard, view, section, card hierarchy and with the UI editor will find this page straightforward to apply.

Design principles understood. [Dashboard Design for Growers](/home-assistant/dashboards/design) covers the design decisions — what goes on the quick-check, how to structure role-based views, mobile-first constraints. The card choices on this page should serve those principles; cards that do not contribute to a clear design goal usually do not belong.

Entities named consistently. Per [Organizing Home Assistant for a Farm](/home-assistant/agriculture/organizing). Cards reference entities by ID; readable IDs make every card configuration clearer and every YAML dashboard easier to maintain.

Derived values available. VPD, DLI, dew point, and similar derived metrics need to exist as template sensors before dashboards can show them. Per [Template Sensors](/home-assistant/automations/templates).

The zone card pattern.

Every agricultural dashboard ends up with some form of zone card. An operation with multiple zones benefits when every zone's card follows the same pattern — the grower learns the layout once and can then read any zone at a glance.

What a zone card shows. The current conditions that define the zone's state. For most growing operations: temperature, humidity, VPD, light (PPFD or DLI so far today), soil moisture, and a status indicator showing whether the zone is nominal or has an active alert.

The standard layout. Zone name as the header. Primary metrics (temperature and humidity, the two most universally tracked) as large values near the top. Secondary metrics (VPD, light, soil) below. Status indicator (green/yellow/red) in a corner. All metrics with their units visible.

One card, one zone. Each zone gets its own card rather than cramming multiple zones into one card. The one-to-one mapping keeps zone cards compact and composable — the dashboard's zone layout is built from zone cards rather than being a single complex multi-zone visualization.

Building a zone card. Three common approaches:

- Entities card listing the zone's sensors. The simplest approach. A standard Entities card listing temperature, humidity, VPD, PPFD, soil moisture entities for the zone. Compact, standard, works everywhere. Not the most visually striking but highly reliable. - Vertical or horizontal stack of individual value cards. A Vertical Stack or Horizontal Stack composing several individual cards — a Sensor card for temperature, one for humidity, a Gauge for VPD. More visual control, slightly more configuration work. - Custom card (Mushroom, Button Card). HACS custom cards can create more visually distinctive zone cards. Works well for operations that have committed to a custom card framework. Adds dependency risk.

The zone card for the quick-check view. A compact zone card — probably just primary metrics (temperature, humidity, status) — works for the quick-check dashboard where space is at a premium. The detailed zone card with VPD gauges, soil moisture, and recent activity lives on the per-zone detail view or on the detailed analysis dashboard.

Navigating to zone detail. Most zone cards should be tappable — tapping drills into a zone detail view with full conditions, recent history, and controls. The navigation card pattern and `tap_action: navigate` support this.

Value-display card choices.

Cards that display a single value or a small set of values.

Tile card for primary metrics. The modern Tile card shows an icon, entity name, current value, and optional secondary information. It handles most "show this one value" use cases. Scales well across screen sizes; looks good in both light and dark themes.

Sensor card for graph-with-value. The Sensor card shows a value and a recent-history sparkline. Useful when the current value plus the recent trend matters — "current temperature is 78°F, trending up over the last hour."

Gauge card for target-zone visualization. The Gauge card shows a value with a dial indicator and configurable threshold ranges. Well-suited to metrics that have target ranges — VPD with its 0.8-1.2 kPa target band, humidity with its 60-75% target range, soil moisture with its 22-35% comfort zone. Color-coded segments (green for in-target, yellow for approaching out-of-target, red for out-of-target) make the gauge an at-a-glance state indicator.

Glance card for compact multi-value display. The Glance card shows a grid of entities with icons and values in a compact format. Useful for a "zone summary" showing 4-8 values in a small area. Less visually rich than Tile cards but more space-efficient.

Markdown card for formatted values. A Markdown card with templates can produce custom-formatted text — "Zone 1 is currently 78°F (target 75°F, +3°F)." More flexible than entity cards but requires Jinja2 templating.

Avoid cards that add motion without information. Animated gauges, rotating displays, carousels of values — these add visual noise without adding operational information. A static display that updates as data changes is usually better than a display that moves whether or not anything changed.

The VPD visualization.

VPD is one of the most useful metrics in a growing operation, and one where visualization matters. The target-range behavior is central: VPD that is correct is in a band, not at a point.

The VPD gauge. A Gauge card configured with the target range highlighted in green, the acceptable range in yellow, and the out-of-target range in red. The needle's position within the gauge communicates both the current value and how close to out-of-target the zone is.

VPD with target context. For operations where the crop's target VPD varies by growth stage, a markdown card below the gauge can show current target: "Current target: 0.8-1.2 kPa (Flowering stage)." The context helps the grower interpret the gauge at a glance.

VPD history. A History Graph card showing VPD over the last 24 hours reveals patterns — daytime VPD targets being hit, nighttime VPD drifting high, the ramp through sunrise. On the detailed analysis view, VPD history alongside temperature and humidity history tells a coherent story.

Leaf VPD versus air VPD on the same gauge. Operations tracking both can show them on stacked gauges or a single dual-value display. The difference between leaf VPD and air VPD is itself meaningful (a large gap suggests active transpiration, a small gap suggests stressed plants).

The DLI visualization.

DLI is an accumulating value through the day, which makes it different from point-in-time metrics. Visualization should show both the current accumulated value and the progress toward target.

The DLI progress gauge. A Gauge card configured with the daily target as the maximum, and the accumulated DLI as the current value. The gauge fills as the day progresses. Color coding highlights whether the zone is on pace — green when on-schedule for hitting the target by end-of-photoperiod, yellow when falling behind, red when significantly behind.

DLI with target line on history graph. A History Graph of cumulative DLI through the day, with a horizontal line indicating the target. The graph shows the accumulated trajectory; the target line shows where the day needs to finish. Seasonal shifts show up over time — winter days that end well short of target, summer days that easily exceed it.

DLI remaining to target. A derived template sensor showing "DLI remaining" — the target minus the current accumulated — displayed as a large number. Useful for supplemental-lighting decisions: "2.3 mol/m²/d remaining; will need supplemental this afternoon."

Multi-zone DLI comparison. Operations with multiple zones often want a comparative view showing each zone's DLI progress side by side. A Horizontal Stack of compact gauges, one per zone, gives this at a glance.

Control card patterns.

Cards that let the grower take action.

Button cards for action triggers. A standard Button card calls a service when tapped. "Start Irrigation Cycle," "Run Daily Summary," "Acknowledge All Alerts." Each action gets its own button with a clear label and optional icon.

Toggle cards for automation enable/disable. A standard Entity or Tile card for an automation's entity, or an input_boolean that an automation checks as a condition. Tapping toggles the state. "Irrigation Automation: On" becomes "Irrigation Automation: Off" with a tap.

Input cards for setpoints. Number selectors for adjusting inputnumber helpers. Slider, spinner, or text-field form depending on the inputnumber's configuration. Lets the grower adjust target temperature, VPD target, DLI target without editing YAML or automation configuration.

Climate cards for climate-integrated systems. The built-in Climate card handles thermostats and climate entities with setpoint adjustment, mode selection, and current state display. For operations where climate integrations present as climate entities, this card is the expected interface.

Irrigation control patterns. A common composition: a button to start a cycle, a sensor showing current flow (or last cycle flow), an entity showing last cycle timestamp, and a counter showing cycles today. Grouped in a card, this becomes the "irrigation control" card for a zone.

Manual override patterns. Controls that temporarily suspend automation ("Maintenance Mode for Zone 1 — 30 minutes") with automatic expiration. Implemented through input_boolean + an automation that auto-clears. The card shows the current override state and time remaining.

Dangerous actions need friction. Actions that could damage the crop if triggered accidentally — "Disable all irrigation," "Turn off main lights during dark period" — should have confirmation prompts or multi-step interaction. A dashboard that makes accidents easy is a dashboard that will produce accidents.

History graph configuration.

The History Graph card and its variants are the primary tool for seeing patterns over time.

Time range matters. The last 24 hours is usually the right default for most zone metrics. Long enough to see a full day cycle; short enough that detail is preserved. The Statistics Graph card (for longer periods) uses aggregated data and handles 7-day or 30-day views better.

Group related entities. A single History Graph showing temperature, humidity, and VPD for one zone tells a coherent story. Three separate graphs for the same data are harder to correlate. Grouping should be purposeful — entities that inform each other belong together.

Consistent axis ranges where useful. For entities that have natural ranges (humidity 0-100, VPD 0-2, etc.), configuring explicit Y-axis ranges produces consistent visualizations across zones. Graphs with autoscaled axes for each zone can show visually similar patterns that are actually different in magnitude.

Hours-to-show settings. The `hourstoshow` attribute controls the time window. `24` is typical; `72` shows three days; `168` shows a week. Longer windows reduce detail; shorter windows do not show patterns that only emerge over longer periods.

Refresh interval. History graphs refresh periodically. For real-time monitoring, shorter intervals (30 seconds) give immediate feedback; for analysis-oriented graphs, longer intervals (5 minutes) reduce load without meaningfully changing the displayed information.

Statistics Graph for longer periods. For weekly or monthly trends, the Statistics Graph aggregates into hourly or daily averages, minimums, and maximums. Shows trends that raw history graphs cannot at that time scale. A weekly average-max-min graph of temperature reveals the shape of the week more clearly than 168 hours of point readings.

Graph performance. A dashboard with many history graphs can be slow to load. Each graph queries historical data; each query takes a moment. For dashboards with time-range-heavy displays, minimize the graph count or consider moving long-period analysis to [Grafana](/home-assistant/dashboards/grafana) where the tooling is purpose-built.

Layout card patterns.

Cards that organize other cards.

Horizontal Stack for side-by-side layout. Useful when two related cards should appear next to each other — two zone cards, two buttons, two gauges. Stacks respect the container's width and may wrap on narrow screens.

Vertical Stack for stacked content. Useful for composing related cards into a single column — a zone overview with header, values, controls. Vertical Stacks are the building block of most multi-element compositions.

Grid card for fixed layouts. The Grid card creates a fixed-column layout. Useful for "four zones in a 2x2 grid" displays. More visual structure than stacks at the cost of less flexibility on narrow screens.

Conditional card for visibility rules. A Conditional card shows or hides its contents based on entity states. "Show this alert card only when an alert is active." "Show this maintenance note only during maintenance mode." Useful for cards that should not always be visible but should stand out when they are.

Entity Filter card for dynamic lists. Shows entities matching filter criteria. "All sensors in state unavailable" produces a card listing any failed sensors. Useful for diagnostic views.

Section as a layout mechanism. In the sections layout, sections themselves replace many uses of stacks — cards in a section naturally group together with a header and consistent styling. Stacks within sections are still useful for fine-grained layout.

Custom cards worth adding.

HACS provides many custom cards. Most agricultural operations need a small number of them; adding too many creates dependency and maintenance burden. The ones that come up often enough to be worth the trade-off:

Mini Graph Card. Small inline graphs that fit where a full History Graph does not. Useful for sparkline-style inline trends on zone cards. Well-maintained, widely used.

Button Card. Highly customizable buttons — visual styling, state-dependent appearance, tap and hold actions. For operations that want distinctive action controls, this card is powerful. More configuration complexity than the standard Button card.

Apex Charts Card. Rich graphing with more control than the built-in graph cards. Supports stacked areas, custom colors, annotations. Useful when the built-in cards do not give enough visualization control.

Mushroom Cards. A design system of cards (mushroom-entity, mushroom-title, etc.) that produce a consistent visual style. Operations that want a polished dashboard appearance benefit from picking a card family like this.

Card Mod. Not a card itself — a utility that lets other cards accept CSS styling overrides. Enables visual customization that the standard cards do not expose. Powerful; can produce inconsistent dashboards if used carelessly.

Auto-entities. A card that dynamically builds a list of entities matching criteria. Useful for "show me every zone's VPD" when the set of zones evolves and manual listing would be tedious.

Plotly Graph Card. Another advanced graphing card with Plotly.js underneath. Deep customization; steep learning curve. Worth it for operations that need specific visualizations the simpler cards cannot produce.

The rule for custom cards. Each one is a dependency. A primary dashboard with zero custom cards is maximally reliable; each custom card slightly increases the risk of breakage on a Home Assistant update. Use custom cards where they add significant value, not where a standard card would suffice.

Card patterns that do not fit agriculture.

Some card types common in smart-home dashboards do not serve agricultural operations well.

Floorplan cards. Visual layouts showing a home floorplan with overlaid sensor values. Beautiful for a house; less useful for a greenhouse where the layout is typically much simpler and the primary view is numeric. Floorplan cards can work for large operations with complex spatial layouts; they do not work for most agricultural use cases.

Weather cards tuned for residential use. The built-in Weather card shows a consumer-oriented forecast. For agriculture, the specific data that matters (forecast minimums for frost protection, precipitation amount, wind speed for spray decisions) is different from what the consumer card surfaces. A markdown card with templated weather values often serves better.

Media player cards. Home Assistant's media cards are well-designed for home audio/video systems. Agricultural operations usually have no use for them.

Security cards. Alarm panel cards, door lock cards, camera feed cards — most agricultural operations do not need these, though cameras for monitoring crops or inputs are increasingly common. When cameras are used (pest monitoring, Frigate integration), their cards are specific-purpose rather than part of the standard dashboard.

Lighting cards for consumer lighting. Built-in Light cards work for smart bulbs and similar. Agricultural supplemental lighting often uses contactors and controllers that present as switches rather than lights; the Switch or Button card is often the better fit.

Common failure modes.

Specific card-configuration problems from real operations.

The zone cards that looked different from each other. Each zone's card was hand-configured; small differences accumulated; the grower had to relearn each zone's layout. Fix: build one zone card as a template, replicate with entity swaps; or use a custom card system (Button Card, Mushroom) that produces consistent visual style from shared configuration.

The gauge that showed the wrong target range. A VPD gauge configured with the target range for lettuce was deployed on a tomato operation. The gauge always showed "out of target" because the ranges did not apply. Fix: crop-specific gauge configuration; or use input_number helpers for thresholds so they can be adjusted without editing card YAML.

The history graph that auto-scaled. A temperature graph with autoscaling showed a tight Y-axis range for a stable day, making minor variations look dramatic. The grower misjudged the stability. Fix: explicit Y-axis ranges for metrics with natural bounds; consider the information the graph should communicate, not just the data it contains.

The button that fired on tap and on drag. A standard Button card configured without confirmation fired whenever the card was touched. The grower triggered irrigation three times accidentally while scrolling the dashboard. Fix: `hold_action` for destructive commands; confirmation prompts; or place dangerous buttons on a separate admin view rather than the primary dashboard.

The custom card that rendered differently on different devices. A card that looked fine on the owner's phone looked broken on the iPad mounted in the greenhouse. Fix: test on every target device; prefer standard cards where cross-device consistency matters.

The conditional card whose condition was wrong. A maintenance-mode card used a Jinja2 template that had a subtle bug; the card never showed during actual maintenance. Fix: test conditional logic in Developer Tools before deploying; inspect the rendered dashboard in each target state.

The dashboard that broke on a custom card update. An auto-updated HACS card changed its YAML syntax; existing dashboards using the old syntax broke silently on load. Fix: pin custom cards to specific versions for production dashboards; test updates before applying; avoid auto-update on custom cards for critical dashboards.

The markdown card with a template error. A template in a markdown card had a syntax error; the card showed "Template error" instead of the intended summary. Fix: test templates in Developer Tools before deploying; for critical summary information, have a fallback or alert when templates fail.

The Entities card with dozens of entities. A zone card grew to show fifteen entities in an Entities card; readability suffered. Fix: prioritize — show the top 4-6 metrics on the overview; put secondary metrics on drill-in detail views; use Glance cards for compact displays when many values need to be visible.

The gauge card with no units. The gauge showed "1.05" with no unit indicator; the grower had to remember whether the gauge was VPD (kPa) or humidity ratio or something else. Fix: always configure units; name cards clearly; use icon choices that suggest the metric type.

What not to do.

Patterns to avoid.

Don't use a different card type for each metric on the same card. Consistency within a zone card means the grower's eye can scan. Mixing Tile, Sensor, Gauge, Entity cards randomly within a zone card produces visual chaos.

Don't use gauges for every metric. Gauges are expensive visually — they take space and draw attention. Reserve them for metrics where target-range visualization matters. Temperature does not usually need a gauge; VPD often does.

Don't use history graphs as the primary display for current values. Graphs show trends; current values show state. If the grower wants to know what temperature it is right now, a Tile card with the number is faster than reading it off the right edge of a graph.

Don't overload a single card. A Vertical Stack with ten nested cards becomes hard to read and slow to render. Break complex compositions into multiple cards or sections.

Don't skip units or context. "78" without a unit is less useful than "78°F." "1.05" without context is less useful than "VPD 1.05 kPa (target 0.8-1.2)." Every value should carry enough context to be interpreted on its own.

Don't rely on color alone for state. Growers include people with color-vision variation. A card that shows "red = bad, green = good" through color only is less accessible than a card that uses both color and a text or icon indicator.

Don't use the flashiest card when the simplest one works. A standard Tile card displaying a number is often the right answer. Custom-card visuals are a choice; they are not always an upgrade.

Don't copy card YAML between dashboards without understanding it. A complex card configuration from a community forum post may depend on specific entities, specific template sensors, or specific custom cards. Copy-paste without understanding produces broken cards at best and wrong displays at worst.