Home Dashboard — AI-Assisted Smart-Home Integration

Problem

A wall-mounted iPad mini 2 in a household, running iOS 12.5.8 — the last version Apple ever shipped for that device — and a kitchen wall that called for something more useful than family photos. The home already had the parts: a Fibaro Home Center 3 controller running the lights, gates, and scenes; four IP cameras of mixed make and authentication (Dahua, Sony); an Engenius router with a connected-device list; a shared Google family calendar. Each part worked on its own. None of them composed into a single screen.

What was needed was an always-on glance dashboard: today's calendar, live camera tiles, gate controls, the day's weather, and a simple presence panel showing who was home based on phone-MAC detection on the LAN. It had to render correctly on the wall-mounted iPad mini 2, and it had to be reachable from a laptop and an iPad simultaneously without going through the cloud.

This is the kind of household integration project that a smart-home installer would price at €5,000–10,000 in the Estonian market, and most homeowners would either pay it or live without. The question was whether AI-assisted development crosses the threshold where a homeowner can build their own version in a working week.

AI Approach

The starting point was a design link — an Anthropic-hosted HTML/JSX mock of the dashboard layout. The first prompt was literally "Fetch this design file, read its readme, and implement the relevant aspects of the design." Everything downstream followed from that mock.

The build used Claude Code running on Sonnet, with the operator as architect and the model as implementer.

Stack chosen during the build:

• —Vite + React + TypeScript for the kiosk frontend
• —A small Node.js camera proxy (scripts/cam-proxy.mjs) to mediate camera authentication and reduce LAN polling
• —Direct HTTP fetch against the Fibaro HC3 API on the local network (basic auth, self-signed cert)
• —Google Calendar via the public iCal feed — chosen over OAuth because read-only is sufficient and the integration cost is zero
• —Engenius router scraped for its connected-device list to derive presence
• —The Vite legacy plugin targeting the iPad mini 2's old WebKit; without it, modern JavaScript syntax (optional chaining, nullish coalescing) silently breaks the page
• —A single home-dash@%i.service systemd unit on Ubuntu, serving the built bundle and the camera proxy from one Node process

What was not automated:

• —Identifying the right MAC addresses for family devices. iOS rotates a per-network "Private Address" by default, and the first MAC supplied was a rotating one — detection only stabilised after the device was set to a fixed MAC for the home network.
• —Network-side configuration: signing into the router admin, enabling the right device-list endpoint.
• —Mounting the iPad and pointing it at the kiosk URL.

These items required physical access and account credentials. AI accelerates the parts where typing is the cost; it does not accelerate finding the right MAC address or signing into a router.

Human Effort

Active engagement totalled approximately 25 hours, spread across 6.6 calendar days from April 28 to May 5, 2026. Wall-clock duration was 158 hours, but the project ran intermittently — most of those hours were idle time during the working week.

Session distribution:

51 user prompts. Only 4 contained gotcha keywords (error / wrong / fix / fail), meaning the iteration density was low — most prompts moved the build forward, only a handful corrected mistakes. This is unusually clean for a project with this much network-side complexity.

Traditional Benchmark

A custom kiosk dashboard integrating four heterogeneous IP cameras with mixed authentication, a smart-home controller, a shared calendar, presence detection, and a target device running iOS 12.5.8 is a non-trivial small-installer or independent-developer project.

Mid-range planning value: ~100 hours, ~€7,000.

Acceleration Factor

The 4x effort acceleration is moderate by Kodulabor standards — the Revalia Homes website case ran at 27x. The reason is structural: code generation was not the bottleneck on this build. Network and hardware were.

The cost acceleration is dramatic, and that is the headline number for a homeowner. €120 in API spend for a dashboard that would have cost several thousand euros from an installer, even allowing for the household's own time, changes the calculus on whether the project is worth doing at all.

Quality Assessment

The dashboard is in production. It runs as home-dash@<user>.service on a Ubuntu Surface laptop in the home, was active and confirmed working at the close of the session, and survived a real test — cameras and gates working as expected, family calendar showing real events, presence panel detecting family devices on the LAN.

What met production standards:

• —Camera polling coalesces rapid-fire requests; the IPC units do not get hammered
• —iOS 12.5.8 compatibility verified against the production bundle (no ?. in the shipped JavaScript)
• —Systemd unit is parameterised by user (@%i.service) and survives reboots
• —Thumbnails refresh smoothly without the original blink-on-reload bug
• —Both viewports (laptop and iPad mini 2) render correctly after multi-round layout work

What an installer would do better:

• —A professional installer would use a wired tablet rather than Wi-Fi for the wall-mount, eliminating MAC-address rotation entirely
• —Camera digest authentication would be configured at the camera firmware level instead of in a Node proxy
• —The systemd unit would be replaced with a managed kiosk runtime (e.g., a dedicated Linux distribution like screenly or balenaCloud)

Open quality items at session close:

• —Family Calendar event spacing is too tight on iPad layout
• —Open button on a confirmation modal misaligns with the checkmark at narrow widths
• —Camera thumbnail refresh feels slightly slow under real-world latency

These are cosmetic. Functional correctness is solid.

Gotchas & Limitations

Every project has friction. Documenting it honestly is the point of this framework.

1. iPad mini 2 / iOS 12.5.8 compatibility. The wall-mount device is running an OS Apple stopped supporting in 2019. Modern JavaScript syntax silently breaks the page. The Vite legacy plugin solved most of it, but verifying the production bundle did not contain optional chaining required explicit grep checks against the built artefact. This is the kind of constraint that generic "build me a dashboard" requests will miss; it had to be stated up front.

2. Camera authentication mismatch. One of the Dahua-style camera units expected basic auth on snapshot URLs but digest auth on some other endpoints. The first integration attempts produced 502 Bad Gateway from the camera proxy. Fix required switching the proxy to use undici with explicit digest support and a per-camera auth-mode config. Mixed authentication across cameras of different makes is the rule, not the exception, in any real household.

3. Layout for two viewports. Designs work on a laptop and break on the iPad, or vice versa. Several iterations: "on laptop all is good, but on iPad cameras thumbs are cut" → "on laptop weather panel is cut at the bottom now, on iPad weather panel is good but there are no cam thumbs". The eventual fix widened the centre column and trimmed the top status row.

4. iPhone Private Wi-Fi Address rotation. iOS rotates a per-network "Private Address" by default. The first MAC for presence detection was a rotating one and stopped matching after a day. Detection only stabilised after the device was set to a fixed MAC. This is documented in iOS settings but is far from obvious — a user-facing presence feature has to either explain it or work around it.

5. Ubuntu deploy: pnpm not found. The Surface laptop had npm but not pnpm. The deploy plan assumed pnpm parity with the development Mac. A small thing to fix, but the kind of small thing that costs fifteen minutes when it should cost zero.

6. Empty page on iPad on first load. Initial Vite dev server bound only to 127.0.0.1. The iPad on the same LAN could not reach it. Required --host 0.0.0.0 to expose the dev server on the network. Obvious in hindsight; not obvious the first time.

Replicability Score

3 out of 5.

The pattern — Vite + React kiosk → smart-home API → camera proxy → systemd service on Linux — is widely applicable. Any household with a smart-home controller, IP cameras, a calendar, and a wall-mountable display can adopt this architecture. Many do not, because the integration work is exactly the kind of thing that gets quoted in thousands of euros.

The score is 3 rather than 4 because this specific build depends on:

• —A Fibaro HC3 controller (premium smart-home hardware; not common)
• —A specific mix of IP cameras with their own authentication quirks
• —An Engenius router exposing its connected-device list
• —A wall-mounted iPad mini 2 specifically — the iOS 12.5.8 constraint shaped multiple decisions

A reader with different smart-home hardware would adopt the architecture but rewrite most of the integrations. A reader with the same hardware mix would replicate the build in roughly the same time. A reader with a modern tablet (no iOS 12 constraint) would have a noticeably easier time.

Verdict

This project demonstrates a category Revalia Homes did not: AI-assisted integration work, where most of the value is in connecting heterogeneous existing systems rather than producing new application logic. Code generation accelerated the React UI and the camera proxy, but the real wins were elsewhere — Claude Code held the protocol details (digest auth quirks, iCal parsing, HC3 endpoint shapes, iOS 12 polyfill strategy) so the operator could focus on the network-side work that no AI can do remotely.

The 4x effort acceleration is honest and consistent with similar integration projects. The ceiling on AI acceleration is set by the LAN-side work — finding the right MAC address, signing into the router, mounting hardware — and that work was a larger fraction of this project than of, say, a website build. For an experienced developer, the value of AI here is reduced typing on the integration glue, not magical insight about the home network.

The cost story is the more interesting one. €120 in API costs versus several thousand euros for an installer changes whether a household builds the dashboard at all. Most don't, because the cost-of-bespoke is too high. With AI assistance, the bar drops far enough that personal-scale integration projects become a normal weekend activity for technically inclined homeowners.

For someone considering a similar build: the architecture transfers cleanly (Vite kiosk + Node proxy + systemd), the tooling is now mainstream (Claude Code for the build, Vercel-or-similar tutorials for deploy), and the iOS 12 / iPad mini 2 constraint is the largest single source of friction — plan for it explicitly, or buy a newer tablet. Either choice is fine; pretending the constraint isn't there is what wastes time.

Kitchen-table AI integration is no longer hypothetical. It runs as a systemd service on a Linux laptop, refreshes every two seconds, and shows the household who is home.

This case study was produced using the Kodulabor Assessment Framework. Raw data sourced from Claude Code session logs. Methodology and findings published openly at kodulabor.ai.

Data Appendix