The one screen the whole family shares is the one nobody wanted

The screen nobody fights over

Every home lab eventually has a drawer of shame: the $25 monitor that came free with something, the first-gen Pi you swapped out two upgrades ago, an HDMI cable of unknown provenance. The individual parts are worthless; the combination is the most-watched screen in the house — if you put them together as a family dashboard. A writer at XDA did exactly that this week, wiring a forgotten monitor and a Raspberry Pi 4 into a shared screen for chores, meals, calendars, and photos. It’s the right idea, and it deserves a harder look than the parts list — because the hardware is the easy 10% of the project.

Why family dashboards die

Not from hardware failure. From update friction. A dashboard is a promise that the screen will keep telling the truth — today’s calendar, this week’s chores, tonight’s dinner. The moment changing any of that requires SSH, the countdown starts. Within a month, the dashboard is a photo frame; within three, it’s a black rectangle the family has learned to ignore.

So my rule: if updating the screen needs a terminal, it’s already dead. Design for that from the first boot and the project survives. Ignore it and you’ve built a very expensive clock.

This is also why “just build it as a web page and open a tab” fails. A tab is not an appliance: it closes, it updates, it logs out. The dashboard has to be the only thing the machine knows how to do.

The build is two decisions, not twenty

• Screen: the worst HDMI monitor you own. Not-touch is fine. Big text fixes more UX problems than touch does, and the remote control is everyone’s phone anyway.
• Brain: whatever Pi is in the drawer. A Pi 4 with 1GB ran the XDA build at ~50% memory — no mini PC needed. A lightweight OS (DietPi is a good default; it idles under a few hundred MB) leaves the whole machine for one Chromium window.

Do not buy a touchscreen for version one. Buy it for version three, after the family has told you what they actually reach for. My experience with kiosk builds is that the features you’re sure they’ll want get ignored and the boring ones — the clock, the calendar, tonight’s meal — carry the whole device.

Kiosk mode, and the Wayland trap

The dashboard tool I’d point at here is Home Screens: custom pages, a proper web portal for layout, and — crucially — a separate portal just for content edits. But the software is only half the kiosk. The other half is making the OS boot into a fullscreen browser and nothing else.

On a Pi, that means an autostart entry or a small systemd service that launches Chromium fullscreen, incognito, pointing at the dashboard URL. Something like:

[Unit]
Description=Dashboard kiosk
After=network-online.target

[Service]
User=kiosk
Environment=DISPLAY=:0 WAYLAND_DISPLAY=wayland-0
ExecStart=/usr/bin/chromium-browser --kiosk --incognito \
  --noerrdialogs --disable-infobars \
  http://localhost:3000
Restart=always
RestartSec=5

[Install]
WantedBy=graphical.target

Two lessons that will save you an evening. First, the XDA author’s build crashed on boot — UI up for two seconds, dead, restart, repeat — because the kiosk was launched into a session layer (Wayland) it wasn’t configured for. If you see a crash loop, suspect the session before the app: launch the browser the way the project’s own installer does, into the session the project documents. Second, Restart=always with a short backoff is not optional. A kiosk that shows a black screen after a browser crash until someone reboots it has failed the appliance test.

Two doors into the dashboard

Home Screens’ smartest design decision is that it has two doors. The builder portal (port 3000) is for the person who makes pages. The content portal (the same URL plus /remote) is for everyone else: chores, meal plans, users, photos, screen brightness, sleep and wake — all editable from a phone, none of it able to break the layout.

That separation of powers is what keeps the screen alive. The family gets a door with no sharp edges; you keep the dangerous one. It also gives you the feature nobody knows they need until it works: alerts on the big screen. A persistent or timed message when someone forgets a chore is nag-as-a-service — off your back, onto the furniture.

Feed it things that update themselves

A dashboard’s content pipeline splits into two kinds, and they age very differently:

• Self-updating: calendar (iCal links), weather, photo carousel via an API. These never rot.
• Hand-fed: chores, meals, lists. These rot in days unless the editing door is genuinely easy.

Maximise the first, make the second a one-tap phone job, and skip anything in between. A card that needs a weekly manual export will be the first thing the family notices is wrong.

Run it like a service, because it is one

This machine has the most public SLO in your house. Everyone can see when it’s down. So give it the boring production treatment:

• Auto-restart everything — the browser session at minimum, and a read-only-ish SD card setup so a power cut at 6am can’t corrupt it.
• Boot to dashboard after power loss — no login, no desktop, straight to the kiosk.
• Sleep on a schedule — dim or blank overnight via the content portal or DPMS; a 24/7 bright panel in a hallway is how projects get unplugged.
• One-line health check — if you already monitor services (and if you’re reading this blog, you do), curl -f http://pi:3000 from your uptime monitor tells you the dashboard is serving, which is 90% of “the screen is fine.”

The small-business version is the same build

Swap the family content for ops content and this is a reception screen or a warehouse status board: today’s schedule, a Grafana or Glance page, the on-call rotation, the shipment board. The rules carry over unchanged — worst screen you have, kiosk boots to one URL, auto-restart, and a content door a non-technical person can use without calling you. Every client site has a wall; most of them are showing a screensaver because nobody treated the wall screen as a service.

The best screen is the one already paid for

The economics of a junk-drawer dashboard are unbeatable: zero dollars, one evening, and the family’s shared context stops living in four different apps. The XDA piece is a good build log — read it for the DietPi and kiosk details. But the parts list isn’t the lesson. The lesson is that the screen survives on maintenance design: two doors, self-updating feeds, restart-on-failure, and a phone-sized path from “tonight’s dinner changed” to the wall. Build those in, and the cheapest screen in the house becomes the one nobody can live without.