How to create dashboards in Home Assistant

A Home Assistant dashboard is an interface made up of views and cards to monitor and control our home.

The next step in any systems engineering project is building the presentation layer. We need a graphical user interface (GUI) that allows us to visualize sensor data and actuate relays without interacting with the admin console.

For years this layer was known as Lovelace; in the current documentation and interface it is simply referred to as Dashboards. Let’s see how to organize useful panels without turning them into a sensor warehouse.

How a dashboard is organized

Unlike older home automation systems that generated static web pages, the Home Assistant interface is a highly reactive single-page web application (SPA), built on web components (historically based on the LitElement library).

When an entity changes state, the interface receives the update via WebSockets without reloading the page.

To organize this visual information, Home Assistant uses three main levels:

1. Dashboards: This is the highest level. You can have several completely independent Dashboards. For example, a general one for the family, a technical one with server performance charts only for the admin, and a simplified Dashboard optimized for a tablet mounted on the living room wall.
2. Views: Within each Dashboard, we organize information into views. They can separate the house by room or category and use section, panel, sidebar, or masonry layouts.
3. Cards: This is the fundamental visual component. A card is a widget that represents the state of one or more Entities and allows interaction.

The problem with the auto-generated dashboard

By default, when we install Home Assistant for the first time, the system generates a Dashboard of the “Automatic” type.

The behavior of this panel is very simple: every time Home Assistant discovers a new device (a light bulb, a Tuya sensor, or a Zigbee router), it creates a default card and throws it onto the Dashboard.

The first step to creating our own interface is Taking control of the panel. By clicking the top right menu and selecting “Edit Dashboard”, Home Assistant will warn us that it will stop adding items automatically. From that moment on, we are fully responsible for the interface code.

Designing for the end user

A technical Dashboard for us should not be the same as a family Dashboard. The former can have RSSI charts, consumption, server temperature, MQTT broker status, and a hundred diagnostic entities. The latter should have four clear buttons and little possibility of breaking anything.

For a wall-mounted tablet, we typically want per-room views and large controls. For a phone, we want quick access: main lights, alarm, climate, and occupancy. For administration, we want everything else, even if it looks much less tidy.

YAML or graphical interface

Home Assistant provides a visual editor where we can add and arrange elements. Panels created from the interface are stored in Home Assistant’s internal storage, not as a YAML file that we need to edit.

Each card has a structured configuration that we can view and edit as YAML from the code editor. We can also create entire dashboards in YAML mode, but it is a separate and explicit option, not the internal working of all panels.

Let’s look at the anatomy of a basic card (button type) written in YAML:

type: button
entity: light.luz_techo_salon
name: Main Lamp
icon: mdi:ceiling-light
show_state: true

• type: Defines the rendering component that the frontend will use.
• entity: This is the exact entity_id from our database (what we saw in the previous article).
• name and icon: Override the default name and icon (using the Material Design Icons - mdi library) of the entity.

How to organize the layout: stacks, grids, and sections

One of the biggest challenges when designing a Dashboard is positioning the elements. Home Assistant adapts cards to the screen width, and modern Sections type views allow organizing them into sections and grids from the editor.

We can also group cards using containers that don’t directly display entities:

1. Horizontal Stack (horizontal-stack): Forces child cards to sit side by side, dividing the available width equally.
2. Vertical Stack (vertical-stack): Groups several cards into a single indivisible block from top to bottom.
3. Grid (grid): Allows setting a fixed number of columns and forces cards to fit into that matrix.

Example of a composite layout

Let’s imagine we want to create a block for the Living Room Climate that contains: a main thermostat and, right below, two horizontally aligned buttons to turn the air conditioner on and off.

The underlying code we would generate through the graphical interface would be a nesting of Stacks:

type: vertical-stack
cards:
  - type: thermostat
    entity: climate.termostato_salon
  - type: horizontal-stack
    cards:
      - type: button
        entity: switch.ac_encendido
        name: Turn On AC
      - type: button
        entity: switch.ac_apagado
        name: Turn Off AC

Community cards: Mushroom

Home Assistant’s native cards are functional, but at a pure design level (UI/UX) they feel a bit clunky and outdated.

Once you master the concepts of Stacks and Views, the natural next step for any advanced user is to install card collections developed by the community via HACS (which we already installed in the previous article).

One of the most popular collections for creating compact and comfortable interfaces on mobile is Mushroom Cards. Mushroom replaces default buttons with rounded cards, with integrated sliders for light brightness or temperature, and exquisite control over icon colors based on the entity’s state.