Redesigning My Home Assistant Dashboard: Building a Cleaner Room-Based Interface

A Home Assistant dashboard is never really finished. As the smart home grows, more devices, sensors and integrations become available, and sooner or later those additions also start finding their way onto the dashboard. What initially starts as a clean interface can gradually turn into a collection of cards, buttons, values and controls that all work perfectly well individually, but together make the dashboard increasingly difficult to scan.

That was exactly the situation that led me to redesign my Home Assistant dashboard. There was nothing fundamentally wrong with the old dashboard and technically it did what it was supposed to do, but over time I had added more lights, climate controls, media players, cameras, energy information and various other sensors. Simply continuing to add more cards was no longer the direction I wanted to take.

Instead of starting over completely, I decided to rethink how the information should be presented. The main dashboard should give me a quick overview of the house, while detailed controls should only become visible when I actually need them. This eventually resulted in a room-based design using compact custom:button-card cards, state-aware icons and dedicated popups containing the actual controls.

In preparation of the new design, I started already in building cards that shows me relevant information only. The visibility settings hides them when they’re not relevant. When it’s not raining or there is no rain forecasted, the card is hidden. Not even a message of “no rain expected”. Show me only data that is relevant. For the low batteries, I don’t need a view with all battery levels, just show me the device names where battery level is lower than x (i.e. 30%), because they need attention.

Good examples I posted about it:

• Low battery card: https://rutg3r.com/why-i-dont-use-the-home-assistant-maintenance-dashboard-for-battery-monitoring/
• Rain card: https://rutg3r.com/smart-rain-alert-in-home-assistant-buienradar-bubble-card/

Let me show you quickly how my old dashboard views looked like. And you only see half of its views:

From a device dashboard to a room dashboard

One of the easiest traps when building a Home Assistant dashboard is designing it around entities. Home Assistant itself is naturally entity-oriented, so it is tempting to create a card for a light, another one for the television, another for a speaker, another for the thermostat and yet another for temperature or humidity. That works well when the installation is small, but it does not scale particularly well.

A single room can easily contain several lights, one or more media players, climate equipment, temperature and humidity sensors, blinds and various other smart devices. Showing all of these individually means that the dashboard gradually becomes an inventory of everything connected to Home Assistant.

During this redesign I started approaching the dashboard from a different perspective. Instead of asking which entities should be displayed, I started asking a much simpler question: what do I actually need to know about this room when looking at the main dashboard?

That question changed the structure considerably. The room itself became the primary object on the dashboard, while the individual devices became secondary. The dashboard therefore no longer needs to expose every control at the same time. It only needs to tell me what is happening and provide an easy way to get to the detailed controls.

Conceptually, the new structure looks like the one below. On the left a few light scene buttons that triggers automation (basically nothing changed here except the design_. Selecting a room opens the second layer, where the detailed controls are located.

Living room card:

• Yellow bulb: at least one light is on
• Blue blinds icon: blind is full down
• Purple TV: TV is on.
• Temperature and Humidity in the Living

Building the new room cards

The room cards are built with custom:button-card. Rather than assigning the card to a particular device, each card represents an entire room. The Living card, for example, starts with the following configuration:

There are a couple of important decisions hidden in this relatively small piece of YAML. The card is named Living and uses a room-related icon rather than the icon of a particular device. More importantly, tapping the card does not toggle anything. Instead, the entire card acts as a navigation target and opens:

Controls:

• Lights: The left bulb icon will toggle the light only. The slider is clickable for dimming or just toggle as well. The right hand percentage is opening the “more-info”.
• Sound Bar, which is located below the TV, with some TuneIn radio presents
• Blinds
• Climate/HVAC, in this case the floor heating, it’s on 24/7 on heating or cooling.

This means I don’t have to remember that only a particular icon or small button opens the room controls. If I want to interact with the Living room, I simply press the Living card.

The same principle is used throughout the redesigned dashboard. A room card provides information first and navigation second. Actual device control is moved into the room popup.

Keeping the overview compact

I wanted the room cards to contain enough information to be useful without becoming miniature dashboards themselves. During the redesign I settled on a height of 160 pixels, 16-pixel rounded corners and enough padding to keep the contents visually separated.

Using var(--card-background-color) rather than a hardcoded background color also allows the card to remain consistent with the active Home Assistant theme. My dashboard uses the Noctis theme, so maintaining that consistency is important, especially as the same room-card design is gradually applied throughout the dashboard.

The 160-pixel height turned out to provide a good balance. There is enough room for the room name, icon, several state indicators and environmental information, but not enough room to tempt me into adding every possible control.

Using CSS Grid to create a predictable layout

A major part of the redesign involved the internal layout of the room cards. custom:button-card provides a lot of flexibility, but that flexibility can also make alignment frustrating if the structure is not properly defined. I therefore use CSS Grid to explicitly determine where the different elements should appear.

One of the layouts developed during the redesign uses the following structure:

     

The first row contains the main room icon and room name. The middle section is available for state-aware information about devices in the room, followed by a subtle divider. The bottom section is reserved for environmental information such as temperature and humidity.

Defining these areas explicitly made the card considerably easier to maintain. Instead of positioning elements with individual margins and offsets until everything happens to look correct, every component has a defined place within the card.

The first column reserves a fixed amount of space for the room icon, the middle column expands to use the available space, and the final column can contain active-state information. Once this structure is correct, aligning the individual elements becomes much more predictable.

Showing information instead of controls

Temperature and humidity are good examples of information that belongs directly on the room card. When I look at the dashboard and see the temperature of a room, I normally don’t need to interact with anything. I simply want to know the value. The same applies to humidity and several other environmental measurements.

This eventually led to one of the main rules behind the redesign: status belongs on the overview, while controls belong in the popup.

There will always be exceptions, but this rule provides a very useful starting point. A temperature value is status information. A light icon showing that lights are currently switched on is status information. A media icon indicating that something is playing is also status information. A volume slider, playback controls or thermostat adjustment, on the other hand, are controls and generally do not need to occupy space on the main dashboard.

Separating those two types of information makes the dashboard significantly easier to understand.

Replacing unnecessary text with state-aware icons

Another part of the redesign involved removing text that was technically useful but not necessarily useful enough to justify the space it occupied. For example, an earlier version of a room card could display something similar to:

This tells me that one of three lights is currently switched on, but in everyday use I rarely need to know the exact ratio. What I normally want to know is simply whether any lights have been left on.

A state-aware light icon can communicate that information much faster. When all lights are off, the icon remains subdued. When one or more lights are switched on, the icon can turn yellow. The same principle can be used for media players, televisions, climate systems and other devices.

This also gives color a clear purpose. Rather than adding several colors simply to make the dashboard look more interesting, color is now primarily used to communicate a state change. A yellow bulb means something. A highlighted media icon means something. When nothing is active, the card becomes visually quieter.

That makes active states much easier to notice.

The Living room as one of the main examples

The Living room became one of the main cards used while developing and refining the new layout. Its basic configuration starts with.

The Living room contains more than just lighting, which makes it a good test case for this design. Media is also an important part of the room.

The important decision here was not to turn the Living room card into a television remote or media controller. These devices can contribute state information to the room overview, but the detailed controls do not need to be visible all the time.

This allows the Living card to remain relatively simple even though there are several controllable devices behind it.

Applying the same design to Office Rutger

Once the Living card was working the way I wanted, I started applying the same design principles to other rooms. Office Rutger is a good example because it contains a different collection of devices but can still use the same basic interface.

The card starts with:

The popup:

The Office contains an air-conditioning entity:

Optional the advanced settings hidden in a dropdown, with fan speed and wing options, that are not all present in the default climate/hvac card.

and its own media player:

These are completely different devices from those that might be important in another room, but that does not mean the room card needs a completely different design. The information displayed within the card can change while the overall structure remains consistent.

That consistency is important. If the room name, state indicators, temperature information and navigation behave differently on every card, the dashboard quickly becomes harder to use. Keeping the visual hierarchy consistent means I can understand a room card almost immediately without having to think about how that particular card works.

Moving the detailed controls into popups

The popup is what makes the simplified overview possible. Instead of trying to fit buttons, sliders, media controls, climate controls and other interactive elements into the 160-pixel room card, those components can live inside a much larger room-specific interface.

The popup itself uses subtle visual containers so that individual sections remain recognizable without creating a collection of heavy cards. One of the styles used during the redesign is:

The background is only slightly different from its surroundings and the border is intentionally subtle. Combined with the 20-pixel rounded corners, this gives the popup sections enough visual separation without making the interface feel crowded.

This approach also works well with a dark dashboard. Instead of relying on strongly contrasting backgrounds, the hierarchy is created with small differences in transparency, borders and spacing.

Integrating media controls into the room interface

Media controls were another area that benefited from the new room-based approach. Previously, it is easy to think of media players as something that should live on a dedicated media page. The redesign made me reconsider that assumption. If a media player is primarily used in a particular part of the house, having its controls available from the appropriate room popup often makes much more sense.

The first row provides space for the title and status, the second row displays the source and the third row contains the actual controls. Using another grid here keeps the media component organized while allowing it to visually match the rest of the redesigned interface.

During the later stages of the redesign I also moved the Living media player into the Kitchen / Diner popup. Although that sounds like a relatively minor interface change, it illustrates an important point: controls should be placed where they make sense to the person using the dashboard, rather than being dictated entirely by an entity’s technical name or original location.

Home Assistant thinks in domains, devices and entities. People generally think in rooms and activities. The dashboard is the layer that needs to translate between those two worlds.

Solving the alignment problems

Not everything worked immediately. One of the more stubborn problems during the redesign involved alignment. Some custom elements continued appearing too close to the center of the card even though the overall grid looked as if it should position them further to the left.

This is one of the challenges when working with more complex custom:button-card configurations. The visible position of an element can be influenced by the CSS Grid itself, the grid area assigned to the element, the width of the corresponding column, justify-self, align-self and even styling inside a custom field.

Rather than assuming that an element will naturally appear at the left side of its grid area, explicitly defining the alignment produced much more predictable results. The same approach can be applied to room names and custom fields.

Another lesson from this process was that fixing the grid itself is usually preferable to compensating for a bad layout with increasingly complicated margins. A negative margin may make one card look correct, but the problem can return as soon as another card contains a longer room name or is displayed at a slightly different width. A properly defined grid is much easier to reuse.

Sometimes redesigning means removing things

One of the more useful lessons from this project was that improving a dashboard does not necessarily mean adding more functionality. In several cases the interface improved because I removed something.

During the iterations, information such as the 1/3 lights text was removed. Some icons were moved, other icons disappeared from the top-right section, the media icon was changed and several alignment choices were simplified. Each individual change was small, but together they made the cards considerably calmer and easier to scan.

When building a Home Assistant dashboard, it is very easy to ask, “What else can I display here?” Home Assistant provides so much information that there is almost always another useful value or state available. During this redesign I increasingly started asking the opposite question: does this information really need to be visible here?

That question has probably had a greater impact on the final design than any individual CSS setting.

A room card should not become another dashboard

Once a room card starts looking good, there is another temptation: adding just one more feature. Perhaps playback controls could fit underneath the media icon. Maybe the thermostat controls could be squeezed into the bottom corner. Perhaps each individual light could have its own button.

That would eventually recreate the original problem inside a smaller card.

For this reason, I now consider a room card to have three primary responsibilities. It identifies the room, shows the most important current states and provides access to the room popup. Everything beyond that has to justify why it needs to occupy space on the overview.

A volume slider does not. Playback buttons generally do not. Detailed thermostat adjustments do not. Those controls remain available, but one level deeper in the interface.

Designing the inactive state is just as important

Another aspect that became clearer during this redesign is the importance of the dashboard’s inactive state. A smart-home dashboard spends a large amount of time showing rooms in which nothing particularly interesting is happening. Lights are off, media players are idle and climate systems may not be actively heating or cooling.

If every icon remains bright and every card displays several lines of information regardless of the current state, it becomes difficult to notice when something actually changes. The redesigned room cards therefore work best when inactive states remain relatively subdued.

When a light switches on, the bulb indicator can become yellow. When media starts playing, the corresponding icon can become more prominent. When everything is inactive, the room card visually settles down again.

This means that color and emphasis become useful information rather than permanent decoration.

Turning the design into a reusable system

The Living and Office Rutger cards were useful while developing the layout, but the real benefit comes from being able to reuse the same design throughout the dashboard. Once the alignment, spacing, icon sizes and visual hierarchy have been solved, there is little reason to solve those problems again for every room.

The state indicators and entities can then be changed according to what is actually present in that room. A bedroom may need different status information from the Living room, and the Office may need an air-conditioning indicator that is irrelevant elsewhere, but the underlying interface remains familiar.

This is ultimately what I wanted from the redesign: not just a collection of nicer cards, but a small design system for the Home Assistant dashboard.

The design rules I settled on

After going through several iterations, a few rules emerged that I intend to follow while converting the remaining dashboard cards. The main dashboard should remain an overview rather than becoming a control panel for every entity. Rooms should be the primary navigation model because that reflects how the house is actually used. Detailed controls such as sliders, media controls and climate adjustments should generally live inside popups.

Icons work well for states that can be understood immediately, while color should communicate something rather than simply decorate the card. The cards themselves should remain structurally consistent even when the devices behind them are different. With custom:button-card, alignment should be explicitly defined instead of relying too heavily on automatic positioning.

Most importantly, information should earn its place on the overview. The fact that Home Assistant has a value available does not automatically mean that value needs to be displayed.

The difference between the old and new approach

The interesting thing about this redesign is that the underlying Home Assistant installation has not suddenly become less complex. All of the entities, integrations and devices still exist. What changed is how much of that complexity is exposed at once.

Instead of flattening everything onto a single dashboard, the interface now has layers. The first layer is optimized for quickly understanding the state of the house, while the second is optimized for interaction.

The dashboard that us running on the main tablets around the house have access to the main screen, the rooms and a handfull other views. Other tablets are having their own dashboard only, just specific for that room.

New main view:

The same view, but with hidden cards:

 

The Weather warning under the Clock is only visible when there is a warning active (code Yellow, Amber or Red). The border colors accordingly, with the warning inside the card.

• The custom Alarm panel is not visible when it’s disarmed and is controlled by scenes and automations.
• The Rain Expected card with the Precipitation card only shows up when raid in there (was visible in the first card as well)
• The “Low Batteries” I mentioned earlier only shows up when at least one device (sensor, mobile phone, car battery, cleaning robot battery, etc) has a value lower than 30%.

That relatively simple distinction makes a surprisingly large difference.

Quick illustration about the Low Batteries part in the top right corner:

 

And it’s design is reused in the other standalone room dashboards as well:

Dryroom/Mudroom: The medicine one is a reminder (every other day) that it needs to be given today to one of the dogs):

All Dashboard views and standalone dashboard using the badges as well, just for specific information like:

• Available updated in Home Assistant (without need to check “Settings”.
• When the Tesla leaves specific zones, we see the ETA (minutes left to home)
• If the tesla is plugged in with its battery percentage
• If the washer is running and time to finish
• If the dryer is on
• If there are cameras offline
• When the water level in the pond is lower than xx
• Room name where the Dreame robot is cleaning and it’s current task (washing pads, cleaning/mopping). etc.

Some examples of things that immediately got our attention when we look at any dashboard. If something important is going on, we got notified anyway on our mobile phones via the Pushbullet integration (not HA notifications).

Below screenshot is in edit mode, because some badges are not visible at this moment.

What’s next?

The Living and Office Rutger cards have provided the foundation for the rest of the dashboard. The next step is not another major redesign, but systematically applying the same design language to the remaining rooms and making sure each popup contains the entities and controls that make sense in that context.

This should also make future additions easier. If I add another smart device to a room, I no longer automatically need to find space for another visible card on the main dashboard. Instead, I can first decide whether its state is important enough to be represented on the room overview. If it isn’t, the device can simply become another control inside the popup.

That is a much more scalable approach for a Home Assistant installation that will inevitably continue to grow.

Another upcoming improvement is making the device icons in the room cards all the same color, which makes it not like a Christmas tree.

Conclusion

What started as a visual redesign ended up changing the way I think about the Home Assistant dashboard itself. The most important improvement was not a particular icon, CSS property or popup configuration, but the decision to separate overview information from detailed control.

The main dashboard now represents rooms and their important states rather than exposing individual entities everywhere. Detailed functionality is still immediately available, but it sits one level deeper inside the appropriate room popup. Using custom:button-card, CSS Grid, state-aware icons and room-specific popups provides enough flexibility to create a highly customized interface without forcing all of Home Assistant’s underlying complexity onto the screen at once.

There were plenty of small iterations along the way. Alignment needed adjustment, icons were moved or removed, text that initially seemed useful turned out to be unnecessary and media controls were moved to locations that made more sense in everyday use. Those iterations ultimately helped establish something more useful than a single good-looking card: a reusable design language that can now be applied across the entire dashboard.

The dashboard will undoubtedly continue to evolve, because that is simply what happens with Home Assistant. The difference is that I now have a much clearer framework for deciding where new information and controls should go.