Zero-UI Home Automation Framework (2025)

Project Name

Zero-UI Home Automation

Objective

Design and operate a family-centric, on-prem home automation system that functions invisibly in the background.
The house should respond to presence, time, and physics, not dashboards or apps.

The system must:

• Be local-first and resilient to cloud outages
• Favor deterministic behavior over cleverness
• Require no daily interaction from non-technical users
• Allow advanced introspection and tuning by a power user without exposing complexity to the family

Core Philosophy

“Less Is More”

• Every automation must justify its existence
• Physical controls always remain authoritative
• If the system fails, it should fail quietly and predictably

“Physics Over Apps”

• Doors opening, motion, sunlight, power flow, and occupancy drive behavior
• No dependency on phone presence, fragile cloud triggers, or manual toggles

“Zero-UI for Family, Full Control for Operator”

• Family interacts via:
  • Physical switches
  • Apple Home (single UI surface)
• Operator interacts via:
  • Home Assistant
  • Logs, metrics, and code

High-Level Architecture

Layered Design Model

Operator Portal & Subdomains (2026)

Portal

• Technology: Next.js 14 (App Router) in Docker
• Role: Operator-only landing page with links to services and rendered docs
• URL: https://teamlewis.co

Subdomain Map

• https://docs.teamlewis.co → Operator docs (same container, middleware rewrites to /docs)
• https://ai.teamlewis.co → Open WebUI (private AI)
• https://ha.teamlewis.co → Home Assistant (host network)
• https://cam.teamlewis.co → NVR (Frigate/Scrypted) [planned]

Ingress

• Reverse proxy: Nginx Proxy Manager (Docker)
• Router: forward WAN 80/443 → NPM (no 3000 pinholes)
• TLS: Let’s Encrypt, Force SSL, HTTP/2, HSTS
• Container networking: services attach to nginx-proxy_default; NPM forwards by container name

Exposure Policy

• Family UI remains Apple Home
• Portal is operator-only; links to operator surfaces
• Private services avoid host port mappings; exposed exclusively via NPM

Technology Stack (Authoritative)

Core Platform

• Home Assistant (Container)
  • Runs on local server
  • Acts as the single source of truth for automation logic
  • No reliance on vendor clouds for real-time behavior

Messaging / Event Bus

• MQTT (Mosquitto)
  • Central “post office” for sensors, vehicles, and energy systems
  • Enables loose coupling between components

Data Storage

• PostgreSQL
  • Home Assistant recorder database
  • Long-term stability and performance
• InfluxDB
  • High-volume time-series data (solar, power, energy trends)

Sensor Skeleton (Hardwired Revival)

Philosophy

Hardwired sensors are treated as first-class assets, not legacy baggage.

Advantages:

• Instant response
• Immune to Wi-Fi congestion
• Zero batteries
• Deterministic behavior

Hardware

• Konnected boards
  • Flashed with ESPHome
  • Native Home Assistant integration
  • No cloud dependency
  • Sub-second latency

Role in System

• Door state
• Motion detection
• Occupancy inference
• Primary triggers for lighting and security logic

Lighting (Reliability First)

Platform

• Lutron Caséta

Rules

• Physical switches must always function independently
• Automations may augment, never override
• Lighting logic must be explainable in one sentence

Example philosophy:

“Lights respond as if a thoughtful human were already home.”

Energy & Power Assets

Inputs

• Solar inverters (local polling via Modbus TCP)
• Whole-home generator
• Utility power state
• Sense energy monitoring

Goals

• Understand real-time energy availability
• Enable future load-aware decisions (HVAC, EV charging)
• Maintain historical insight without UI clutter

Design Rule

Energy systems inform behavior — they do not spam notifications.

Mobility (Vehicles)

Assets

• Tesla
• Rivian

Integration Model

• Local server acts as a secure proxy
• Vehicle state exposed read-only to Apple Home where appropriate
• Authentication and token handling abstracted away from family users

Constraints

• Vehicles are not real-time critical
• Automations must tolerate API failures gracefully

Vision & AI (Eyes, Not Surveillance Theater)

Cameras

• Transition to Reolink PoE (local, wired, deterministic)

Processing

• Scrypted
  • Bridges cameras into Apple Home
  • Enables HomeKit Secure Video (HKSV)
• Frigate NVR
  • Local AI detection
  • Person / package / vehicle filtering
• Optional hardware acceleration:
  • Google Coral TPU

Design Goal

Reduce notification fatigue to near zero.

“If the system is unsure, it stays quiet.”

User Interaction Model

Family Experience

• No dashboards
• No maintenance
• No alerts unless truly actionable
• Apple Home is the only visible app

Operator Experience

• Full access to:
  • Home Assistant
  • YAML
  • Docker
  • Metrics and logs
• Changes tested incrementally and reversibly

Automation Design Rules (Non-Negotiable)

1. Physical controls win
2. Automations must be reversible
3. No automation without a failure mode
4. Silence is preferred over false positives
5. Every rule must be explainable to a non-technical adult

Cloud Policy

Long-Term Vision

The system should feel like:

• A well-designed commercial building
• A calm, aware environment
• Something you notice only when it’s missing

The success metric is not feature count, but:

“Nobody thinks about the house — it just behaves.”

Explicit Non-Goals

• Voice-command dependency
• Feature-driven dashboards
• Notification-heavy automations
• “Smart home demos”
• Cloud-only integrations

Intended Audience of This Document

• Human operator
• AI coding assistant
• Future maintainers

This document defines intent and constraints, not implementation steps. All future code, configuration, and automation must align with this framework.