There’s a 10-inch tablet mounted on the wall in our kitchen, and the only thing it does is run a fullscreen browser pointed at a Home Assistant dashboard. My partner doesn’t open the HA app on her phone — she taps the tablet on her way through the kitchen. That’s the actual usability bar I’m building for: the dashboard has to be glance-able, immediately tappable, and forgiving of stress-typing fingers.
After two iterations and one full audit pass that fixed 22 broken cards, I have a setup that works. This post is the layout philosophy, the YAML structure, and the specific mistakes I made the first time around.
Three dashboards, one set of entities
I run three separate Lovelace dashboards from the same HA install:
home.yaml— desktop / wide tablet primary dashboard. Five views (Home, Cameras, Media, Automations, System).mobile.yaml— phone-optimized variant of the home view. Larger tap targets, fewer cards visible at once.tablet.yaml— wall-mounted Fire HD variant. Usestype: panelto fill the screen, organized for at-a-glance reading from across the room.
Each dashboard is its own YAML file under lovelace/, registered in configuration.yaml as a separate dashboard resource. They share the same backing entities — input_select.home_mode, sensor.solar_power_kw, person.charles, etc. — so a state change anywhere shows up everywhere.
The YAML-mode-only restriction matters: HA’s UI editor for Lovelace is great for prototyping but eventually you want diff-able config in git. I prototype in the UI, copy the generated YAML out, paste it into the appropriate dashboard file, then resource-edit the dashboard back to YAML mode.
The home view, top down
The desktop home view is the most-used surface and the one I’ll walk through. It’s structured top-down by importance:
title: Home Overview
views:
- title: Home
path: home
icon: mdi:home
cards:
# Row 1: Weather + at-a-glance status
- type: weather-forecast
entity: weather.home
show_forecast: false
# Row 2: Solar production
- type: horizontal-stack
cards:
- type: gauge
entity: sensor.my_home_solar_power
name: Solar Now
min: 0
max: 10000
unit: W
severity:
green: 3000
yellow: 1000
red: 0
- type: entity
entity: sensor.solar_energy_daily
name: Today
icon: mdi:solar-power
- type: entity
entity: sensor.solar_energy_monthly
name: This Month
icon: mdi:calendar-month
# Row 3: Mode + Alarm
- type: horizontal-stack
cards:
- type: entity
entity: input_select.home_mode
name: Mode
icon: mdi:home-variant
- type: entity
entity: alarm_control_panel.alarmo
name: Alarm
icon: mdi:shield-home
# Row 4: People
- type: horizontal-stack
cards:
- type: entity
entity: person.me
name: Me
icon: mdi:account
- type: entity
entity: person.partner
name: Partner
icon: mdi:account
- type: entity
entity: person.kid
name: Kid
icon: mdi:accountThe ordering is deliberate: weather first because it’s the thing I most often want to know, solar second because watching the gauge ramp up in the morning is satisfying, mode/alarm third because they’re the most likely to need a tap, people fourth because seeing where everyone is at a glance is useful but rarely actionable.
After those four rows comes a quick-actions strip (good morning / goodnight scripts, all-off, leaving home), then a security row (door contacts, lock states), then lights and devices grouped by room.
The gauge severity colors are not just decorative
Look at the solar gauge:
- type: gauge
entity: sensor.my_home_solar_power
min: 0
max: 10000
unit: W
severity:
green: 3000
yellow: 1000
red: 0This sets thresholds: <1000 W is red, 1000-3000 W is yellow, >3000 W is green. Not because low solar is “bad” — the panels do what physics allows — but because the colors tell me at a glance whether it’s worth running discretionary loads (the dryer, the dishwasher, the EV) right now. Green = run them. Yellow = maybe wait. Red = wait.
That’s the difference between a dashboard that’s information and a dashboard that’s a decision aid. The gauge color is a recommendation, not just a reading.
The dashboard audit nobody warned me I’d need
About 18 months in, I did an audit of every card on every dashboard. Twenty-two cards in total — referencing entities by ID. Of those:
- 15 worked
- 4 referenced entities by the wrong ID — usually because I’d renamed the underlying automation but never updated the dashboard
- 3 referenced entities that didn’t exist — because the integration providing them had been uninstalled, or because I’d never installed the integration in the first place
The “wrong ID” cases are the most insidious. They don’t error visibly — they just render a card with unavailable or unknown state, which looks indistinguishable from “the integration isn’t talking right now.” I’d been looking at a unavailable System Monitor CPU card for months without realizing the System Monitor integration wasn’t installed at all.
The fix was tedious but mechanical: walk every card, click on it, see what entity it references, check that entity exists in the entity registry, fix the ID or remove the card. About two hours of work for the full audit.
What I’d do now: any time I rename an automation or remove an integration, immediately grep the Lovelace YAMLs for the old entity ID and fix anything I find. It’s a 30-second check that saves the audit pain later.
grep -r "automation.welcome_home_light" /config/lovelace/The wall-tablet variant: type: panel
The wall-mounted tablet uses a different layout strategy entirely. The desktop dashboard is column-of-cards; the tablet uses type: panel to put a single composed card filling the whole screen:
title: Tablet Dashboard
views:
- title: Home
path: home
type: panel
cards:
- type: grid
columns: 3
square: false
cards:
# 9 large tiles, 3 wide, 3 tallThe grid has nine tiles arranged 3x3. Each tile is a single piece of information, sized so it’s readable from across the kitchen — eight feet away or so. The tiles are:
| Top-left: Weather + outside temp | Top-middle: Mode (Home/Away/Sleep) | Top-right: Alarm state | | Mid-left: Solar gauge (large) | Mid-middle: Indoor temp | Mid-right: Outdoor cameras (one preview) | | Bot-left: Garage state | Bot-middle: Front door state | Bot-right: People (3 chips stacked) |
Each tile is a single card. No nested horizontal-stacks within a tile, because nesting reduces tap target size and increases visual complexity. The font sizes are bumped up via theme overrides so each tile’s primary number is readable at a glance.
The tablet’s browser is in fullscreen kiosk mode. There’s no navigation; this is the only view. To get to anything else, you’d unlock the tablet and use it as a normal tablet — but for “is the alarm armed” / “what’s the solar producing” / “where is everyone” questions, the kiosk view is enough.
The mobile dashboard’s discipline
The mobile dashboard is a different kind of constraint: it has to fit a phone screen, and the user is one-handed. Two rules I follow strictly:
No more than two cards per horizontal stack. Three cards in a row works on desktop; on a phone it makes each card too narrow to read or tap.
Tap targets ≥ 44pt. Apple’s Human Interface Guidelines minimum touch target is 44 points; iOS Safari renders Lovelace’s default cards just under that, depending on the card type. I bump up sizes via theme.
The mobile-specific tweaks live in a separate theme file (themes/midnight-mobile.yaml) that the mobile dashboard pulls in. Things like:
- Bigger primary text (1.4rem vs 1.1rem default)
- Bigger secondary text (1rem vs 0.875rem)
- Larger card padding (16px vs 8px)
Theme application is a per-dashboard setting, so the same base entities render differently on each surface.
Two things I got wrong twice
Trying to put history graphs in the kitchen-tablet view. A history graph at low res from across the kitchen is just noise. I had a “today’s solar production” line graph as a tile for about a month before I replaced it with a gauge + a daily-total tile. The graph is useful from arm’s length on a desktop dashboard. From eight feet away, you need a single number.
Mixing different card types in a horizontal-stack. A type: gauge next to a type: entity next to a type: button looks ugly because each has a different default height and they don’t align. Two solutions: pick one card type per row, or use type: grid instead of type: horizontal-stack. Grid forces a uniform cell size; horizontal-stack lets each card be its natural size. For glance-able layouts, grid is almost always what you want.
Theme: dark and quiet
I run a custom dark theme called midnight (predictably). The relevant values:
midnight:
primary-color: '#3b82f6' # blue accents
primary-background-color: '#0f172a'
card-background-color: '#1e293b'
primary-text-color: '#f8fafc'
secondary-text-color: '#94a3b8'
divider-color: '#334155'Two design rules I follow:
Backgrounds darker than cards, cards darker than text. Each layer steps up the lightness. Eyes lock onto the highest-contrast element, which should be the data. The card chrome and background should fade.
Color is for state, not decoration. Every color choice in the theme means something. Red = warning. Yellow = pay attention. Green = good. Blue = neutral information. The rest is grayscale. If everything is colorful, nothing is.
This matters more on the wall tablet, which is on 24/7 in a partially-dark kitchen, than on the desktop or phone variants. A bright theme on the wall tablet is fatiguing.
What I’d build next
Two ideas I keep noodling on:
A “context” view that auto-rotates. Cycle the wall tablet between three or four views automatically: solar/energy in the morning, security/cameras at night, weather/forecast all day, family schedule when there are events. Browser-driven via a small JS snippet, not anything Lovelace does natively. Haven’t built it yet because the static layout is good enough most of the time.
Per-room mini-dashboards. Tiny panels on the wall in each room with the lights for that room, a temperature reading, and one room-specific control (the bedroom’s white-noise machine, the office’s standing-desk position memory). That’s a hardware project as much as a dashboard project — would need cheap e-paper displays in each room, all driven from the same HA install. Currently in the “would be nice but lower priority than other things” pile.
For now: three dashboards, one set of entities, theme that’s quiet, audit pass once a year. That’s the whole UI strategy.