Lovelace Fundamentals.

Before building Lovelace dashboards.

Prerequisites from earlier pages:

Entities are in place. Dashboards display entities. Without sensors, switches, and other entities already integrated, the dashboard has nothing to show. The Getting Started and Integrations sub-sections cover that foundation.

Design principles understood. [Dashboard Design for Growers](/home-assistant/dashboards/design) covers the design decisions — the quick-check view, role-based access, information hierarchy, mobile-first layout. The platform mechanics on this page are what those decisions get implemented with.

Areas and naming consistent. Per [Organizing Home Assistant for a Farm](/home-assistant/agriculture/organizing). Dashboards reference entities by ID; readable IDs make readable dashboards.

The Lovelace mental model.

Lovelace organizes content in a hierarchy. Understanding it makes every other part of the platform easier.

Dashboard. The top level. A dashboard is a named collection of views. An installation can have multiple dashboards — "Overview," "Greenhouse 1," "Staff," "Admin" — each appearing as a separate item in the sidebar for users with access.

View. A page within a dashboard. A view has a title, an icon, and content. Dashboards with multiple views show the views as tabs across the top. A "Greenhouse 1" dashboard might have views for "Overview," "Details," "Irrigation," and "Lighting."

Section. A grouping within a view. Sections are a newer Lovelace feature that help organize cards on a view; they work especially well for the "sections" layout type. A view might have sections for each zone, or sections by topic (climate, irrigation, lighting).

Card. The fundamental unit. A card displays one or more entities, or provides a control, or shows information. The view is built from cards; the dashboard is built from views.

The hierarchy reads top-down: the user picks a dashboard from the sidebar, navigates views with tabs, scrolls through sections, and reads or interacts with individual cards. Good dashboards work at all four levels — the right dashboards exist, the right views exist within each, sections group related content, and cards display what the user needs.

The UI editor and YAML.

Home Assistant offers two ways to build and maintain Lovelace dashboards.

The UI editor (storage mode). The default. Dashboards edit-and-save through the Home Assistant UI. Changes persist in Home Assistant's internal storage. The editor provides visual tools — drag-and-drop card placement, form-based card configuration, preview. Most dashboards get built and maintained through the UI editor.

YAML mode. Dashboards defined by YAML files in the configuration directory. Changes require editing the YAML file and reloading. YAML mode is more precise, supports features the UI editor may not fully expose, and works naturally with version control. Some operations prefer YAML for production dashboards.

The mixed approach. Home Assistant supports both modes simultaneously. One dashboard can be UI-editable; another can be YAML-only. A common pattern: start in the UI editor, export the dashboard's YAML once it is stable, and move it to YAML mode for version control.

Raw configuration editor. Even for UI-mode dashboards, the raw YAML is accessible through "Edit dashboard" → (three-dot menu) → "Raw configuration editor." This gives YAML-level control without converting the whole dashboard to YAML mode. Useful for complex card configurations that the UI editor's forms struggle to express.

Version control for dashboards. Dashboards in YAML mode are plain files in the configuration directory; Git tracks them naturally. UI-mode dashboards live in Home Assistant's internal storage and are backed up with standard Home Assistant backups. For operations that want deep version control, YAML mode is the path.

Dashboard types and layouts.

Lovelace offers several layout options for how cards arrange themselves on a view.

Masonry layout. The original Lovelace layout. Cards flow into columns based on screen width, sized by their content. Responsive automatically — a wide screen gets more columns, a narrow screen gets fewer. Masonry is the default for most dashboards and works well for mixed card sizes.

Sidebar layout. A two-column layout with a wide main column and a narrower sidebar. Useful for dashboards where a persistent set of cards (alerts, navigation) should stay visible alongside the primary content.

Panel layout. A single card filling the entire view. Useful for dedicated displays — a wall-mounted tablet showing one big zone overview, or a kiosk-style screen showing a single map or floorplan. Panel views do not scroll; the one card owns the whole space.

Sections layout. A newer layout that gives explicit control over card placement within sections, with responsive breakpoints. Cards can be sized explicitly (one-column, two-column, full-width), and sections can be pinned to specific columns. More layout control than masonry at the cost of slightly more configuration work.

Which to pick. For most agricultural dashboards, masonry works well. Sections is worth learning for primary dashboards where specific layout control matters. Sidebar fits operations that want a persistent element alongside content. Panel is for dedicated single-card displays.

Responsive behavior. All layout types respond to screen size. A dashboard designed for mobile shows differently on desktop — more columns, more cards visible at once. Testing a dashboard on the target device (usually a phone) catches layout problems that the laptop-based design does not reveal.

Views.

A view is a page within a dashboard.

Navigation between views. Multi-view dashboards show views as tabs across the top. Users tap or click tabs to switch between them. Views can also be linked from each other through navigation cards.

View types. Each view can use one of the layout types — a dashboard can mix masonry, sections, and panel views as needed. A dashboard might have a masonry "Overview" view, a panel "Map" view, and a sections "Details" view.

Icons and titles. Views have titles (shown on the tab) and icons (Material Design Icons, selected from the icon picker in the UI editor). Good icons and titles make views navigable at a glance.

Badges. Views support badges — small summary indicators that appear at the top of the view. A badge might show "Active Alerts: 2" or "Current Season: Summer." Badges are underused but useful for making view-specific summary information stick to the top.

Subviews. Views can be marked as "subviews," which excludes them from the main tab navigation. Subviews are reached through navigation (tapping a card to drill down) rather than tab clicks. Useful for per-zone detail pages linked from an overview.

View visibility. Views can be shown or hidden per user. Some views might be admin-only; others might be visible to everyone. This works in combination with the dashboard-level permissions for role-based access.

Sections.

A section is a grouping within a view. Sections became a first-class Lovelace concept with the introduction of the sections layout.

Sections as visual groupings. Each section has a title and contains cards. The title is typically shown as a header bar; cards within the section appear below. Sections group related cards so the user sees them as a unit.

Section columns. In the sections layout, sections can span one or more columns. A narrow single-column section might hold a compact zone summary; a wide multi-column section might hold a full history graph.

Section icons and visibility. Sections support icons and per-user visibility, much like views. A "Maintenance" section might be visible only to the owner, not to production staff.

Section collapse. Some sections can be collapsible, letting users hide content they do not currently need. For dashboards with many sections, collapse-by-default can reduce visual load while keeping the content available.

Sections versus separate views. When content is closely related and should be scrollable together, sections within one view fit. When content is separate enough that tab navigation makes sense (different users, different topics, different time scales), separate views fit. Both are legitimate; the choice is a design decision.

Cards.

Cards are the fundamental units of Lovelace dashboards. Home Assistant ships with many card types; more are available through HACS (the Home Assistant Community Store).

Entity cards. The simplest cards, showing one or a few entities. "Entity" (single entity with state), "Entities" (list of multiple entities), "Glance" (compact grid of entity values), "Tile" (modern card with icon, name, and state) all serve variations on the same pattern.

Value-display cards. Cards optimized for displaying a number or status. "Sensor" for basic numeric display, "Gauge" for a dial-style indicator with thresholds, "Tile" or "Entity" for large-format number display. These serve dashboards where a quick glance at a value is the point.

Graph cards. Cards that show history. "History Graph" for multi-entity time-series graphs, "Statistics Graph" for aggregated statistical views (hourly means, daily minimums), "Mini Graph Card" (custom, via HACS) for compact inline graphs.

Control cards. Cards that provide interaction. "Button" for a simple action trigger, "Light" for lighting controls, "Thermostat" for climate control, "Media Player" for media, and various domain-specific cards.

Layout cards. Cards that organize other cards. "Horizontal Stack" arranges cards side by side; "Vertical Stack" arranges them top to bottom; "Grid" provides a grid layout within a card; "Conditional" shows or hides cards based on conditions. Layout cards let the designer compose complex arrangements from simpler cards.

Information cards. Cards that show information other than entity states. "Markdown" for formatted text, "Picture" for images, "Picture Entity" for images with entity overlays, "Iframe" for embedded web content. Markdown cards are especially useful for dashboard instructions, alerts, and annotations.

Custom cards (HACS). The community ecosystem provides many additional cards — "Button Card" (highly customizable buttons), "Apex Charts Card" (rich graphing), "Mushroom Cards" (a design system), "Card Mod" (CSS customization). Custom cards extend Lovelace's capability but add dependencies.

Choosing a card type. Most agricultural dashboards use a small set of card types repeatedly: tile or entity cards for current values, gauges or tile cards for key metrics like VPD and DLI, history graphs for trending, buttons for actions, markdown for headers and instructions. Starting simple and adding card types as needs emerge works better than starting with a zoo of card types.

Themes and styling.

Lovelace supports themes that change the visual appearance of dashboards.

Built-in themes. Home Assistant ships with a light theme and a dark theme. Users pick which in their profile. The dark theme is noticeably better for outdoor and low-light conditions; the light theme is better for office environments.

Community themes. Many themes are available through HACS — alternative color schemes, typography choices, sizing variants. Themes can be installed, enabled, and switched through the UI.

Custom themes. Themes are YAML files that override CSS variables. Operations that want a specific look can write their own theme. The CSS variable names and approach are documented in Home Assistant's theming reference.

Per-user theme selection. Each user can pick their preferred theme, independent of others. The owner might use a minimal theme; outdoor staff might prefer a high-contrast dark theme; an operations center display might use a large-text theme.

Card-level styling. Some cards support per-card style overrides. The custom "Card Mod" integration provides deeper CSS customization. For most dashboards, theme-level styling is enough; per-card styling is a path toward visual inconsistency unless used deliberately.

Font and icon considerations. Themes can change fonts; Lovelace uses Material Design Icons by default. Switching fonts to larger or higher-contrast options helps readability in specific conditions (outdoor use, older users, low-light environments).

Multiple dashboards.

A Home Assistant installation can have many dashboards, each serving a different purpose.

Creating a new dashboard. Settings → Dashboards → Add Dashboard. The new dashboard appears in the sidebar for users who have access.

Dashboard URL paths. Each dashboard has a URL path (like `/lovelace-greenhouse-1/` or `/lovelace-staff/`). URLs can be referenced directly, bookmarked, or opened from automations.

Dashboard icons. Each dashboard has an icon shown in the sidebar. Good icons make the sidebar easy to scan when the user has access to several dashboards.

Default dashboard per user. Each user has a default dashboard — the one shown when they open Home Assistant. Different users can have different defaults, supporting role-based access patterns.

Dashboard access control. Dashboards can be restricted to specific users. The admin dashboard might be visible only to admins; the staff dashboard visible to everyone. This is configured per-dashboard in its settings. [User Management and Security](/home-assistant/operations/security) covers the full access-control picture.

Dashboards are independent. Each dashboard has its own views, sections, cards, and configuration. Changes to one dashboard do not affect others. This independence is good for experimentation — a redesign of the quick-check view happens on a new dashboard, and the old one remains as a fallback until the new is trusted.

Testing and debugging dashboards.

Dashboards are configuration. Bugs in dashboards are real.

Preview during editing. The UI editor shows a live preview as cards are configured. Most issues are visible in the preview; a card that looks wrong in preview will look wrong in production.

Test on the target device. A dashboard edited on a laptop should be tested on the phone it will live on. Phone view is the use case for most agricultural dashboards; phone testing is not optional.

Test across user roles. A dashboard available to multiple users should be checked from each user's perspective. Hidden cards appear or disappear based on user permissions; the owner testing their own view sees everything, which hides visibility issues that staff would encounter.

Test with realistic data. A dashboard that looks good with nominal conditions may look wrong during an alert, during an unusual reading, or when an entity is unavailable. Where possible, test with simulated out-of-range conditions to see how the dashboard responds.

The "template error" warning. Cards with template errors (a template referencing a missing entity, a syntax error) show error indicators in the UI. These errors need fixing; they are not cosmetic. A persistently broken template can make the whole dashboard fail to render.

Browser developer tools. For custom cards and advanced debugging, browser developer tools (F12 in most browsers) show console errors, network activity, and the rendered HTML/CSS. Useful when a custom card is behaving oddly or a dashboard is loading slowly.

Reload without restart. Dashboard YAML changes can be applied through "Reload Lovelace" from Developer Tools, without a full Home Assistant restart. Quick iteration during development; faster than restarting for every change.

Common failure modes.

Specific Lovelace problems from real operations.

The dashboard that stopped rendering after an update. A custom card from HACS was not updated to the new Home Assistant version; the card produced a render error; the view containing it showed errors instead of content. Fix: test dashboards on staging before production updates; keep custom cards minimal on critical dashboards; know how to identify which card is the problem (check individual cards until the broken one is found).

The dashboard that worked in the UI editor and crashed in the YAML. A manual YAML edit introduced a syntax error. The UI editor no longer opened the dashboard for editing; the dashboard itself failed to load. Fix: keep backups before YAML edits; use the "Raw configuration editor" inside the UI for individual edits rather than hand-editing YAML files; YAML mode requires discipline.

The card that showed the wrong entity after a rename. An entity was renamed (refactoring, integration change, cleanup). Dashboards referencing the old name showed "entity not available" or silently showed wrong data. Fix: keep an entity registry discipline; search dashboards (through raw configuration) for references when renaming; prefer selection through the UI picker over hand-typed entity IDs.

The template in a markdown card that produced misleading output. A Jinja2 template in a markdown card had a bug; the displayed text was confidently wrong. The grower acted on it. Fix: test template logic in Developer Tools → Template before deploying; verify complex templates produce expected output across real data ranges.

The dashboard that loaded slowly. Too many history graphs, too many real-time templates, or too many custom cards on one view produced a slow-loading dashboard. Growers stopped using it. Fix: profile the slow cards; reduce history graph count per view; use thumbnails with drill-downs to full graphs; ensure the Home Assistant server has sufficient resources.

The dashboard that did not adjust for unavailable entities. When a sensor was unavailable, its card showed "unavailable" in small text, easy to miss. The grower thought everything was fine. Fix: prominent visualization when entities are unavailable — colored card borders, a badge showing "sensors offline," an alert triggered by unavailability.

The dashboard whose custom card author abandoned it. A HACS card's author stopped maintaining it; Home Assistant updates eventually broke it. The dashboard depended on it. Fix: prefer standard cards for critical dashboards; when custom cards are used, pin to working versions and test on update; have a migration plan when a custom card becomes a dependency.

The dashboard that nobody's theme choice respected. One user set a dark theme; the dashboard forced a light-theme-looking style because of hardcoded card colors. Fix: use theme variables rather than hardcoded colors; test with both light and dark themes; respect the user's theme preference.

The sidebar overloaded with dashboards. The installation accumulated ten dashboards over time; the sidebar was unwieldy; users could not find the one they wanted. Fix: consolidate related dashboards into views of a single dashboard; archive dashboards that are no longer used; use sidebar organization features.

The view with too many cards. A single view had thirty cards; load time was slow, and the scroll was endless. Users stopped engaging with content below the fold. Fix: split into multiple views with tabs; use sections for grouping; apply the design principles from [Dashboard Design for Growers](/home-assistant/dashboards/design).

What not to do.

Patterns to avoid.

Don't design the dashboard in YAML without the UI editor. The UI editor is faster for most card configuration. Design in the UI, move to YAML only when YAML's specific benefits (version control, complex templates, shared configuration) are needed.

Don't overuse custom cards. Each custom card is a dependency. A dashboard with ten different custom cards has ten places where a Home Assistant update could cause trouble. Standard cards handle most needs; custom cards earn their place by doing something standard cards cannot.

Don't hardcode entity IDs when the picker works. UI-editor-selected entities update through Home Assistant's internal references; hand-typed entity IDs are strings that do not automatically update when entities change. For dashboards, the picker-based selection is more maintainable.

Don't skip testing on the phone. The phone is the agricultural use case. A dashboard that was never tested on a phone is a dashboard that will reveal its problems the first time someone tries to use it in the field.

Don't mix operational and admin content on one dashboard. Operational dashboards (quick-check, detail views) should not mix with admin content (automation lists, entity configuration, settings). The separation prevents accidental changes and keeps each dashboard focused.

Don't leave broken cards on dashboards. A card showing an error indicator is a visible sign that something is wrong. It should either be fixed, or removed, or replaced with a placeholder that explicitly says "diagnostic view — expected to show X." Broken cards left in place become visual noise and reduce trust in the dashboard.

Don't forget about users with limited access. Every dashboard design should consider what users with restricted access see. A card that is hidden for a role should not leave visual gaps that make the dashboard look broken; the layout should adapt.

Don't build dashboards without a plan for maintenance. As the operation evolves, dashboards evolve. Before building a dashboard, consider how it will get updated, who will update it, and how changes will be reviewed. Dashboards without maintenance plans drift into irrelevance.