A dashboard is how the grower actually uses Home Assistant day to day. The sensors are reporting, the automations are running — but the grower interacts with the system through a dashboard. A well-designed dashboard shows the right information at the right level of detail, loads fast on a phone, and answers the grower's common questions at a glance. A poorly designed dashboard shows too much, too small, in the wrong order, and becomes a chore to use. This page covers building a useful first dashboard — the design principles that matter for growers, the specific steps through the interface, and the things not to rush into. By the end, the grower has a dashboard they will actually look at regularly, and the pattern to extend it as the system grows.
Before the first dashboard.
Prerequisites:
At least one sensor reporting data. Per [Your First Sensor](/home-assistant/getting-started/first-sensor). The dashboard has content only if there is data.
Understanding of areas and entities. Per [First Hour with Home Assistant](/home-assistant/getting-started/first-hour). The dashboard design uses these concepts throughout.
The mobile app installed. The dashboard will be used primarily from the phone. Testing the design on the phone during construction matters.
If the first sensor and first automation have not been done yet, come back to this page after. A dashboard without content is an empty exercise.
Design principles for a grower's dashboard.
Before clicking anything in the interface, a few principles worth holding.
Mobile-first. Most grower dashboard views happen on a phone — in the greenhouse, at the packhouse, in the field, from bed before sleep, from the couch when a notification arrives. The dashboard must work on a phone screen, in landscape or portrait, with dirty hands or gloves. Desktop dashboards look lovely on a monitor and reveal their shortcomings on a phone. Design for the phone; it looks fine on the monitor too.
Quick-check first. The top of the dashboard, the part visible without scrolling, should answer the grower's most frequent question: "is everything okay?" Temperature and humidity for active zones, pending alerts, the status of critical equipment. Detailed data goes below; the first screen tells the grower at a glance whether attention is needed.
Organized by area. Each growing zone, each packhouse, each cooler, each outbuilding is its own section. This matches how the grower thinks about the operation — by location. A flat list of all sensors is an engineer's view; a list organized by location is a grower's view.
Readable at arm's length. Fonts large enough to read without glasses, values prominent enough to see without squinting. A dashboard optimized for density (maximum data per screen) is unreadable in the field; a dashboard optimized for readability wastes screen space but actually gets used.
Alert states visible. When a sensor reads outside normal range, the dashboard should show that visually — color changes, placement changes, explicit alert indicators. Not hidden in a sub-menu. The grower scanning the dashboard should notice exceptions without reading every number.
Restraint. Fewer cards showing the most important information beats more cards showing all information. A dashboard with 20 well-chosen cards is more useful than one with 60 cards that the grower rarely scrolls through.
These principles guide the specific choices below. A grower who internalizes them designs their own dashboards well.
The default dashboard.
Home Assistant creates a default dashboard at install, called "Overview." It automatically places cards for discovered devices, recently-added entities, and common things. It is a reasonable starting point but not a good end state — the auto-generated layout is generic and does not reflect the specific operation's structure.
Two approaches:
Modify the default dashboard. Edit the Overview dashboard, remove cards that do not fit, add cards that do, reorganize into useful sections. The dashboard keeps the "Overview" name and serves as the main view.
Create a new dashboard. Leave the default dashboard alone (or disable it) and create a fresh dashboard designed deliberately. This is the cleaner approach for a serious design pass because nothing legacy constrains the design.
For a first dashboard, either works. The walkthrough below creates a new dashboard — the cleaner path.
Creating a new dashboard.
Settings → Dashboards → Add Dashboard.
Home Assistant prompts for a dashboard name and icon. Choose something descriptive — "Farm Overview," "Operations," "Greenhouse" — and pick an icon.
Select "New dashboard from scratch." The dashboard appears in the sidebar and is empty.
Click the new dashboard in the sidebar.
The empty dashboard appears. A prompt offers to take a tour or add the first card. The grower can explore through the tour or dive in.
Click the pencil icon (top-right) to enter edit mode.
In edit mode, cards can be added, moved, resized, and deleted. Clicking outside edit mode returns to the view state the grower sees day-to-day.
Building the first card.
The first card sets the pattern. The collective's recommendation for a first card: a quick-check tile showing the greenhouse's current temperature, humidity, and alert state, prominent and readable.
Click "Add Card."
Home Assistant shows a menu of available card types. Many are available. For a first dashboard focused on clarity:
Entities card. A simple list of entity states with values. Reliable, readable, works everywhere. The workhorse.
Gauge card. A visual gauge showing a single value within a range. Useful for at-a-glance status on critical measurements.
Glance card. Multiple entities shown compactly with icons and values. Good for quick-status summaries.
History graph card. A time-series graph of selected entities. Useful for trend context.
Sensor card. Like Entities but styled for sensor-specific presentation.
For a first card, try the Entities card. Add it.
Configure the Entities card.
Title: "Greenhouse Zone 1" (or whatever the zone is called).
Entities: Add the temperature and humidity sensors for that zone. Home Assistant autocompletes from the available entities.
Optionally add the battery level and signal strength entities for completeness, but these often clutter the main view; they can live on a detail sub-dashboard instead.
Save the card.
The card appears on the dashboard with the greenhouse's current readings. Resize the card if needed (drag the edges in edit mode).
Adding a second card: the history graph.
A single current-value card answers "what is happening now?" but not "what has been happening?" A history graph adds context.
Click "Add Card" → History graph card.
Configure:
Entities: the temperature sensor.
Hours to show: 24. A 24-hour window captures the daily cycle and makes recent trends visible.
Save.
The graph shows the temperature over the last 24 hours. A daily temperature curve typically shows a low near dawn, a peak in the afternoon, and a return toward the low overnight. Heating or cooling events, ventilation effects, and unusual patterns all become visible in the curve.
Add a similar graph for humidity — often paired with temperature because VPD depends on both. The [VPD-Based Control](/home-assistant/agriculture/vpd-control) page covers deriving VPD from the two.
Adding a gauge for at-a-glance status.
A gauge card turns a numeric reading into a visual state indicator. Useful for the "is it okay?" question at a glance.
Add Card → Gauge.
Entity: the temperature sensor.
Minimum: 50 (or whatever the sensible lower bound is for the operation).
Maximum: 100 (or whatever the sensible upper bound is).
Severity: configure the color breakpoints. For example: green up to 80°F, yellow 80 to 90°F, red above 90°F. This makes the gauge change color as the temperature enters different zones, giving the grower an at-a-glance color-coded status.
Save.
The gauge is now a visual status indicator for the zone. Scanning the dashboard, the grower sees "everything is green" or "one zone is yellow" without reading numbers.
Organizing by area.
If the operation has multiple zones, the dashboard quickly needs organization. Home Assistant supports several patterns.
Sections view (newer). Home Assistant's newer dashboard design uses "sections" — defined groupings of cards. Each section gets a header and its own group of cards. A typical grower's dashboard might have sections for "Greenhouse Zone 1," "Greenhouse Zone 2," "Propagation," "Cold Storage," "Field," and "System Status."
Multiple views (classic). Each "view" is a tab at the top of the dashboard. Tabs for "Overview," "Greenhouse," "Field," "System." Each tab has its own set of cards. Tapping a tab shows that view's cards.
Either pattern works. The sections view is typically better for mobile because scrolling through sections is more natural on a phone than tapping between tabs.
For a first dashboard with one or two zones, a single view with a few cards is fine. Multiple sections or views matter when the dashboard would otherwise become too long to scan.
Making it mobile-friendly.
A dashboard designed and tested only on a desktop often looks wrong on a phone. A few specific considerations.
Test on the phone during construction. Have the Home Assistant mobile app open alongside the desktop editor. After each card addition, check how the card looks in the app. Adjust immediately when something looks wrong.
Prefer card types that auto-adapt. Entities, Gauge, Glance, and History graph all render reasonably on phones by default. Some custom card types from the community look great on desktop and poor on mobile; check each one.
Avoid wide layouts that force horizontal scrolling. Phones do not scroll horizontally comfortably. Cards should flow vertically down the screen.
Keep fonts legible. The default font sizes are usually fine. Custom themes or card configurations that shrink fonts to pack in more data usually regret it later.
Limit total cards per view. Phones have limited screen real estate. Thirty cards on one view means a lot of scrolling. Five to ten cards per view, with multiple views or sections for different contexts, is more usable.
Consider a separate "quick check" view for mobile. The primary mobile view has only the most critical status; secondary views have more detail. The grower opens the app, sees the top of the quick-check view, and either is done or taps into detail.
Quick actions.
A dashboard can include buttons that trigger actions — running a script, calling a service, toggling an automation, sending a specific notification. For a first dashboard, a few worthwhile additions:
A "Run Backup" button. Calls the `backup.create` service or equivalent. Manual backup before a significant change.
A "Disable alerts" toggle. Some automations support being disabled from the dashboard. Useful during maintenance when the grower knows alerts will fire falsely.
A "Test notification" button. Calls the notification service with a test message. Confirms the notification path is working.
These go on a dedicated "Controls" section or view, below the monitoring content. Most dashboard interaction is reading, not clicking; actions are the exception.
Colors and themes.
Home Assistant supports themes that change colors, fonts, and overall appearance. For a first dashboard, the default theme works fine. Later, the grower can explore:
Dark mode. The Home Assistant interface has a dark mode toggle in user preferences. For field use in sunlight, dark mode can reduce screen glare; for general use, either works.
Custom themes. Community themes provide different color schemes and layouts. The Home Assistant Community Store (HACS) hosts many. Generally not worth exploring until the dashboard content is settled.
Per-user dashboards. Different users can have different default dashboards. Useful in multi-user operations where different people care about different views of the data.
What not to rush into.
A few common first-dashboard temptations that produce poor outcomes.
Installing every custom card. The HACS card catalog is enormous and many cards are genuinely impressive. Installing a dozen of them in the first hour produces a cluttered, inconsistent interface. Add custom cards when a specific need arises, not speculatively.
Overly clever layouts. Nested grids, conditional cards, complex layouts — all possible, all contribute to dashboard sprawl. Keep the first dashboard simple; add complexity when simple designs fail to serve specific needs.
Raw data dumps. A dashboard showing every available entity is exhausting. The question is always "what does the grower need to see?" — not "what data does the system have?" Show the former; the latter is available in Developer Tools when needed.
Optimization before observation. A dashboard built before knowing how the operation actually uses it is optimized for assumptions rather than reality. Build a basic dashboard, use it for a few weeks, then refine based on actual usage. The cards the grower never looks at can be removed; the information the grower keeps needing to check in Developer Tools can be promoted to the dashboard.
Elaborate aesthetic work. Colors, themes, custom card styling, animated elements — enjoyable to tweak but mostly cosmetic. Functionally, a boring-but-clear dashboard is better than a beautiful-but-cluttered one.
Looking forward.
This is a first dashboard. More depth lives in the Dashboards sub-section.
[Dashboard Design for Growers](/home-assistant/dashboards/design) covers design principles and the common grower-specific dashboard patterns.
[Lovelace Fundamentals](/home-assistant/dashboards/lovelace) covers the dashboard system's full capability, including YAML-based dashboards for more precise layout control.
[Cards That Matter for Agriculture](/home-assistant/dashboards/agricultural-cards) covers specific cards useful for agricultural deployments, including custom cards worth adding and historical graph configurations tuned for crop-cycle analysis.
[Grafana Integration](/home-assistant/dashboards/grafana) covers the pattern of feeding Home Assistant data to Grafana for deeper analytical dashboards alongside the operational Home Assistant dashboards.
For a first dashboard, the content covered here is enough. The grower has a usable interface, designed around their operation, readable on the phone.
What to do next.
The foundation is in place. Home Assistant is installed. Sensors report data. Automations act on the data. A dashboard makes it all visible. From here, the section's remaining content takes the grower deeper.
[Organizing Home Assistant for a Farm](/home-assistant/agriculture/organizing) is the natural next page — the patterns for naming, organizing, and structuring the system as it grows.
Agricultural Configuration pages (Climate Control, Irrigation, Lighting, VPD-Based Control, Multi-Zone Operations, Cold Chain Monitoring, Propagation) cover specific patterns for agricultural control.
Integration pages cover specific protocols and device types in depth — Bluetooth, Zigbee, LoRa, Modbus, MQTT, ESPHome, and more.
Automation pages cover automation logic in depth — Fundamentals, Templates, Scripts and Scenes, Advanced Patterns, the Agricultural Automation Cookbook.
No single path through the remaining content is the right one. Growers' needs differ, and the section's organization supports jumping to specific topics as they become relevant. The foundation built in Phase 1 through Phase 3 supports any direction the grower wants to go next.