What's the best tablet for a Home Assistant wall dashboard?

A cheap, always-on tablet you won't mind leaving mounted for years. An Amazon Fire HD 10 is the budget favorite; an older iPad works if you already have one. What matters is an 8–10 inch screen, the ability to stay powered and awake, and a flush wall mount — not the newest hardware.

How do I keep a Home Assistant tablet dashboard always on?

Use a kiosk browser like Fully Kiosk Browser, which handles fullscreen, wake-on-motion, and screen dimming, and keep the tablet on power. Point it at your Lovelace dashboard URL and it stays on that one screen.

What size should touch targets be on a wall-tablet dashboard?

Big enough to tap at a glance without aiming — the dashboard has to work for stress-typing fingers walking through the kitchen. The post covers the specific layout sizing and the audit pass that fixed 22 cards that were too small or broken.

Will leaving a tablet plugged in 24/7 damage the battery?

It can. A lithium cell held at 100% and warm for months tends to swell, which is a real fire risk and can crack the screen or pop the mount off the wall. The common fix is to put the charger on a smart plug and let Home Assistant charge-cycle it — top up below ~20% and cut off around 80% so the battery stays in its healthy middle band instead of pinned at full.

Do I need the paid Fully Kiosk license?

Fully Kiosk Browser is free for basic fullscreen kiosk use. The one-time Fully Plus license (about €7 per device) unlocks the REST API and Remote Administration, which is what the Home Assistant Fully Kiosk integration needs to expose the tablet's screen, brightness, and battery entities. If you want to drive the screen from automations, you'll want Plus.

How do I wake the tablet screen when someone walks up?

Two ways. Fully Kiosk has a built-in motion screensaver that uses the front camera. For more control, pair a normal Home Assistant motion or presence sensor with the Fully Kiosk integration's screen switch in an automation — motion on turns the screen on, and a short delay after motion clears turns it back off. The post includes the YAML.

Home Assistant Tablet Dashboard: Wall-Mount Layouts & Touch Targets

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.

Choosing a tablet for Home Assistant

The best tablet for a Home Assistant wall panel is a cheap, always-on one you won’t mind leaving mounted for years. I run a 10-inch Android tablet in fullscreen (Fully Kiosk Browser handles wake-on-motion and screen dimming). An Amazon Fire HD 10 is the budget favorite; an older iPad works if you already have one. What actually matters: a screen big enough to tap at a glance (8–10 inches), the ability to stay powered and awake, and a flush wall mount. Skip the newest hardware — a dashboard tablet spends its life on a single URL.

Which tablet? A quick comparison

None of these is “the best” — pick on price and how much you care about a clean Android build. Here’s how the four options people actually reach for stack up:

Tablet	Screen	Price tier	The one tradeoff
Amazon Fire HD 10	10.1”	Budget (~$100–150)	Cheapest by far, but Fire OS has no Play Store — you sideload the Fully Kiosk APK
Samsung Galaxy Tab A9+	~11”	Mid (~$180–220)	Full Android + Play Store, plus Samsung’s “Protect battery” caps charging at 85%
Older / refurb iPad	~9.7–10.2”	Reuse or mid	Best screen, but Fully Kiosk is Android-only — on iOS you fall back to Safari + Guided Access and lose the screen/brightness/motion entities
Lenovo Tab (M-series)	10–11”	Budget–mid	Clean stock Android for a bit more than a Fire; middling max brightness

For a set-and-forget Android panel, the Fire HD 10 wins on price and the Galaxy Tab wins on not fighting the OS. The detail that matters more than the badge is keeping it powered without cooking the battery — a section of its own below.

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. Uses type: panel to 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:account

The 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: 0

This 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 tall

The 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:

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.

Fully Kiosk Browser: the settings that actually matter

Fully Kiosk Browser (Android only) is what turns a tablet into a wall panel. It’s free for basic use; the REST API and motion features need the one-time Fully Plus license (about €7 per device). The settings that actually matter, roughly in priority order:

Start URL → your tablet dashboard, e.g. http://homeassistant.local:8123/lovelace-tablet/0?kiosk. This is the only page it ever loads.
Enable Fullscreen (Web Content Settings) → hides the Android status and navigation bars.
Kiosk Mode with a PIN → stops anyone swiping out of the dashboard without the code.
Start on Boot (Power Settings) → survives a power blip or reboot without you walking over to relaunch it.
Keep Screen On / screensaver timeout → controls whether the panel dims and how fast.
Motion Detection → uses the front camera to wake the screensaver when someone walks up.

Then wire it into HA. The Fully Kiosk Browser integration (needs the Plus license and Remote Administration enabled in the app) exposes the tablet as real entities:

switch.<tablet>_screen — turn the display on/off from an automation
number.<tablet>_screen_brightness — set brightness on a 0–255 scale
sensor.<tablet>_battery and binary_sensor.<tablet>_plugged_in — the two you’ll use for charge-cycling below

Once the tablet is an entity in HA, the panel stops being a dumb screen and becomes something automations can drive.

Kiosk mode inside Lovelace: hiding the header and sidebar

Fullscreen in Fully hides Android’s chrome, but Home Assistant still draws its own top header and left sidebar. To strip those, install the kiosk-mode plugin (maykar/kiosk-mode) from HACS → Frontend. Two ways to use it.

Per dashboard, add a block to that dashboard’s YAML:

kiosk_mode:
  hide_header: true
  hide_sidebar: true

Or skip the config and append a query string to the Start URL:

?kiosk — hide both header and sidebar
?hide_header — header only
?hide_sidebar — sidebar only

You can also scope it to just the tablet’s user account so your phone and desktop keep normal navigation. Browser-level fullscreen plus Lovelace-level kiosk mode is what makes the wall panel read as an appliance instead of a web page.

Waking the screen on motion

Fully’s built-in motion screensaver works, but pairing a normal HA motion sensor (a Zigbee/Z-Wave PIR or a presence sensor) with the Fully screen switch is more reliable and lets you add a night rule. With the Fully Kiosk integration you can do exactly that:

automation:
  - alias: "Wake wall tablet on kitchen motion"
    trigger:
      - platform: state
        entity_id: binary_sensor.kitchen_motion
        to: "on"
    action:
      - service: switch.turn_on
        target:
          entity_id: switch.kitchen_tablet_screen

  - alias: "Blank wall tablet 2 min after motion clears"
    trigger:
      - platform: state
        entity_id: binary_sensor.kitchen_motion
        to: "off"
        for:
          minutes: 2
    action:
      - service: switch.turn_off
        target:
          entity_id: switch.kitchen_tablet_screen

  - alias: "Dim wall tablet at night"
    trigger:
      - platform: time
        at: "22:00:00"
    action:
      - service: number.set_value
        target:
          entity_id: number.kitchen_tablet_screen_brightness
        data:
          value: 20   # 0–255 scale — low, but not fully off

Swap binary_sensor.kitchen_motion for whatever sensor already covers the room. Blanking the screen when the kitchen is empty also keeps the panel out of the equation for burn-in and heat.

Keeping it powered without cooking the battery

“Keep it powered” is the easy part; keeping it powered without wrecking the battery is the part people learn the hard way. A tablet held at 100% on the charger 24/7 runs warm, and over months the lithium cell can swell — a genuine fire risk, not just a dead tablet. Left long enough, a swollen battery can crack the screen or lift the tablet off its mount.

The fix most wall-tablet builders use is to stop babysitting the charger and let HA cycle it. Put the charger on a smart plug and drive it off the Fully battery sensor:

automation:
  - alias: "Tablet charger - start below 20%"
    trigger:
      - platform: numeric_state
        entity_id: sensor.kitchen_tablet_battery
        below: 20
    action:
      - service: switch.turn_on
        target:
          entity_id: switch.tablet_charger

  - alias: "Tablet charger - stop above 80%"
    trigger:
      - platform: numeric_state
        entity_id: sensor.kitchen_tablet_battery
        above: 80
    action:
      - service: switch.turn_off
        target:
          entity_id: switch.tablet_charger

That keeps the cell in the 20–80% band lithium batteries are happiest in instead of pinned at full and hot. Some tablets ship a built-in cap you can lean on instead — Samsung’s “Protect battery” holds charging at 85% — but the smart-plug approach is model-agnostic and works on a Fire tablet too. If you ever see the back of the tablet bulging or a corner of the screen lifting, stop charging it and replace the battery. That’s the failure mode this whole section exists to prevent.

Mounting and routing the cable

A “flush wall mount” can mean a few different builds, and they mostly differ in how much drywall you’re willing to open:

Surface mount — a commercial tablet wall dock or a 3D-printed bracket (there are printable mounts for the Fire HD 10, Galaxy Tab, and iPad on the usual model sites). Nothing goes inside the wall; the cable runs down to a nearby outlet, often hidden in cord channel.
Recessed / in-wall — cut a low-voltage back box behind the tablet so it sits flush and the cable disappears into the wall. Cleanest look, most work.

For the cable itself, a right-angle USB-C connector keeps the plug from standing proud of the wall, and running it to an in-wall receptacle or a recessed USB outlet behind the mount means nothing shows. Keep that charger on the smart plug from the previous section so it stays HA-controlled once it’s buried in the wall.

Lock it down: a dedicated non-admin user

A wall tablet is the one HA session anyone in the house — or a guest — can walk up to and poke. Don’t log it in as your admin account. Create a dedicated non-administrative user (Settings → People → Users → Add user, leave Administrator off) and sign the tablet in as that. It can see and operate the dashboard but can’t reach Settings, add integrations, or read admin-only entities.

Pair that with the Fully Kiosk PIN from the setup section so nobody can swipe out of the dashboard to the tablet’s home screen either. Two cheap layers — a limited HA user and a kiosk PIN — and the panel is safe to leave reachable in a hallway.

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.