My Home Assistant instance has 13 dashboards and 751 entities. It has zero custom themes installed, and the two dashboards I open most often use only cards that ship with Home Assistant. That was not a principled decision. I kept meaning to install a theme, and the built-in cards kept being good enough.
Most dashboard articles start at Mushroom and button-card. This one is the step before that: what you can get out of the box, and where the stock cards actually stop.
Dashboard 1 — the solar overview
This is the one on the wall tablet. Three columns, one job each: what the roof is doing right now, what the battery is doing, and whether the hot water is being heated from surplus or from the grid.
Everything on it is a gauge card or a tile card. The numbers on a normal August afternoon: 4,761 W from the array, 1,196 W house consumption, battery at 95%, boiler at 71.3 °C, and 3,565 W of surplus with nowhere else to go.
The solar overview: gauge cards for PV output and house load, tiles for the daily totals.
The gauge card earns its place because of the severity bands. A number on its own tells you nothing until you already know the range — 4,761 W is meaningless unless you know the array peaks around 9 kW. The bands encode that knowledge into the card, so the tablet is readable from across the room without reading the number at all.
type: gauge
entity: sensor.pv_power
name: PV Leistung
unit_of_measurement: W
min: 0
max: 9000
severity:
green: 0
yellow: 5000
red: 7500The counterintuitive part is that green sits at the bottom. On a consumption gauge you want red at the top, and on a production gauge you arguably want the opposite. I kept the same direction on both so that a glance at the tablet reads consistently, and accepted that a full roof shows red. It is the only thing on the dashboard I would still call wrong.
The tile cards carry the daily totals — yield, self-consumption, consumption, lifetime production. Tiles are worth using over entity rows purely because they have room for an icon with a colour, which is what makes the difference between a list you read and a panel you scan.
Dashboard 2 — the numbers that are not sensors
The second dashboard shows self-sufficiency at 79.9%, a self-consumption rate of 65.8%, battery round-trip efficiency at 97.1%, and 803 full cycles. None of those come from a device. They are template sensors computed from the meters, and the dashboard is only displaying them.
The derived numbers — self-sufficiency, self-consumption rate and battery efficiency are template sensors, not device readings.
That is the part I would tell anyone rebuilding their energy view. The work is not in the cards. The work is deciding which derived numbers are worth watching, and those are rarely the ones an inverter exposes. My inverter reports instantaneous power perfectly well and has no idea what my self-sufficiency rate is.
I wrote up how those sensors are built in a separate post on self-consumption and autarky sensors, because the templates are the interesting half and they have nothing to do with dashboards.
Battery efficiency is the one I check most. 8,028 kWh charged against 7,795 kWh discharged over 803 cycles is a round-trip loss of about 3%, and if that number starts drifting it is the earliest signal I have that something is wearing out.
The layout rule that mattered
Both dashboards use the sections layout with a heading per column. Before that they were one long list of cards, and the difference is bigger than it sounds — a heading gives you somewhere to stop scanning. A dashboard with 20 cards and no headings gets read from the top every single time.
The other thing that helped was accepting that a dashboard is allowed to be incomplete. My solar view does not show the individual string voltages. They exist, I have alerts on them, and putting them on the overview would mean scanning past them a hundred times a week to notice them once.
Where the stock cards stop
Three places, in the order they annoy me.
There is no compact multi-entity tile. If you want six values in the space of two, you need a custom card. The built-in tile is one entity, and six tiles take six tiles' worth of room.
The gauge card cannot show history. It shows now. Getting a sparkline behind a current value is exactly what mini-graph-card exists for, and there is no stock equivalent.
And theming is all or nothing. Without a theme you get the default blue, and per-card colour control is limited to what the tile card exposes. This is the gap I have not closed, and it is why my dashboards look like Home Assistant rather than like something designed.
If you want to fix any of those, the two catalogues are the HACS Lovelace cards directory and the HACS themes directory. Both are ranked by GitHub stars and refreshed daily, which is a reasonable proxy for what is maintained.
What I would do differently
I would build the template sensors first and the dashboard second. I did it the other way round, and the result was a dashboard full of raw meter readings that I then had to redesign once the derived numbers existed.
I would also test on the phone earlier. Both of these were laid out on a 1440-wide browser window and they collapse to a single column on a phone, in an order I did not choose. That is still on the list.
Do I need HACS to build a good dashboard?
No. Both dashboards here use only built-in cards. HACS adds density, history-in-place and theming, which are real improvements — none of them are prerequisites for a dashboard that is useful.
What is the difference between a tile card and an entities card?
The entities card is a list of rows and is efficient for many values. The tile card is one entity with an icon, a colour and a tap action, and it is what you want when the dashboard is being scanned rather than read.
Why are my gauge colours in the wrong order?
The severity block sets thresholds by their lower bound, so green, yellow and red are the values at which each band starts. For a gauge where high numbers are good, you set green high and red at zero, which reads oddly in the YAML but renders correctly.
