Zero-UI
← Back to docs/Integrations Policy – Zero-UI Home Automation (2025)

Integrations Policy – Zero-UI Home Automation (2025)

Purpose

This document defines which integrations are allowed, preferred, tolerated, deprecated, or banned in the Zero-UI Home Automation system.

It exists to:

  • Prevent architectural drift
  • Stop accidental cloud creep
  • Give AI coding tools clear guardrails
  • Ensure long-term stability and family trust

This file is authoritative.
If an integration conflicts with this document, the integration is wrong.


Integration Classification System

Each integration is classified into one of five tiers:

Tier Name Meaning
A Core Foundational, required, must be rock-solid
B Preferred Strongly recommended, well-aligned
C Tolerated Acceptable with constraints
D Deprecated Allowed temporarily; do not expand
E Banned Must not be introduced

Tier A β€” Core Integrations (Non-Negotiable)

These integrations form the spine of the system.

Home Assistant (Docker)

  • Role: Central logic engine
  • Cloud: ❌ Not required
  • Notes:
    • All automations must ultimately live here
    • No parallel automation logic elsewhere

Lutron CasΓ©ta

  • Category: Lighting
  • Cloud: ❌ Not required for real-time
  • Why Tier A:
    • Instant response
    • Physical control supremacy
    • Extremely high reliability

Rules:

  • Physical switches always work
  • Automations may assist, never override

Konnected + ESPHome

  • Category: Hardwired sensors
  • Cloud: ❌ None
  • Why Tier A:
    • Hardwired, deterministic
    • Sub-second latency
    • Battery-free

Rules:

  • ESPHome only (no legacy firmware)
  • Sensors are authoritative inputs

MQTT (Mosquitto)

  • Category: Messaging
  • Cloud: ❌ None
  • Why Tier A:
    • Decouples systems
    • Enables clean failure isolation

Rules:

  • No hidden point-to-point dependencies
  • Topics must be readable and documented

These align extremely well with project goals.

PostgreSQL (HA Recorder)

  • Category: Storage
  • Cloud: ❌ None
  • Reason: Stability, performance, long-term maintainability

InfluxDB

  • Category: Time-series metrics
  • Cloud: ❌ None
  • Reason: Energy and solar history without UI slowdown

  • Category: Vision
  • Cloud: ❌ Optional / disabled
  • Reason:
    • Wired reliability
    • Local access
    • Works cleanly with NVRs

Scrypted

  • Category: Camera bridge
  • Cloud: ❌ None
  • Reason:
    • Best-in-class Apple Home camera support
    • Enables HKSV without cloud dependence

Frigate NVR

  • Category: Vision / AI
  • Cloud: ❌ None
  • Reason:
    • Local AI detection
    • Reduces notification noise

Nginx Proxy Manager (Reverse Proxy)

  • Category: Ingress
  • Cloud: ❌ None
  • Reason:
    • Central TLS and access control
    • Clean subdomain routing by container name
    • Eliminates host-port exposure

Rules:

  • Router forwards 80/443 only to NPM
  • Services join nginx-proxy_default network
  • Force SSL, enable HTTP/2 and HSTS

Tier C β€” Tolerated Integrations (Use Carefully)

These are acceptable only within strict boundaries.

Apple Home / HomeKit

  • Category: UI
  • Cloud: ❌ Not required
  • Allowed Use:
    • Family-facing control surface
    • Basic scene exposure
  • Disallowed Use:
    • Core automation logic
    • Complex conditional rules

Sense Energy Monitor

  • Category: Energy monitoring
  • Cloud: βœ… Required
  • Constraints:
    • Read-only
    • No real-time automations
    • No notifications except true anomalies

Tesla (Fleet API)

  • Category: Vehicle
  • Cloud: βœ… Required
  • Constraints:
    • State visibility only
    • Automations must tolerate auth/API failure
    • No mission-critical behavior

Rivian

  • Category: Vehicle
  • Cloud: βœ… Required
  • Constraints:
    • Best-effort integration only
    • Monitoring > control
    • Must degrade silently

Open WebUI (Private AI UI)

  • Category: Operator UI / AI
  • Cloud: ❌ None
  • Constraints:
    • Operator-only access via ai.teamlewis.co
    • No host port mapping; exposed only through NPM
    • No family-facing features; aligns with β€œAI reduces noise” principle

Tier D β€” Deprecated Integrations (Do Not Expand)

These may exist temporarily but must not be extended or relied upon.

Wyze Cameras

  • Category: Vision
  • Cloud: βœ… Required
  • Status: Deprecated
  • Reason:
    • Cloud dependency
    • Inconsistent latency
    • Poor local-first alignment

Policy:

  • Do not build new automations on Wyze events
  • Phase out in favor of Reolink PoE

Samsung SmartThings

  • Category: Automation platform
  • Status: Deprecated
  • Reason:
    • Cloud-first
    • Parallel logic creates confusion

Policy:

  • No new devices added
  • No automations maintained
  • Remove once parity is achieved

Tier E β€” Banned Integrations (Never Introduce)

These conflict fundamentally with Zero-UI goals.

Cloud-Only Automation Engines

Examples:

  • IFTTT
  • Vendor-hosted rule engines

Reason:

  • Latency
  • Opacity
  • Fragility

Voice-Only Control Systems

Examples:

  • Alexa-only routines
  • Google Assistant-only workflows

Reason:

  • Non-deterministic
  • Not family-inclusive
  • Poor failure characteristics

Battery-Only Sensors (as Primary Inputs)

Reason:

  • Latency
  • Maintenance burden
  • Failure-prone

Exception:

  • Allowed only as secondary/contextual signals

Notification-Centric Integrations

Reason:

  • Increase cognitive load
  • Encourage micromanagement

Integration Evaluation Checklist (For Humans & AI)

Before adding any integration, it must answer YES to all:

  1. Can the house still function if this integration is offline?
  2. Does it reduce effort or cognitive load?
  3. Does it respect physical controls?
  4. Does it fail quietly?
  5. Does it avoid creating new dashboards for the family?

If any answer is NO, the integration is rejected or sandboxed.


Summary Principle

Integrations exist to disappear, not to be admired.

The best integration is the one nobody talks about after installation.

This document is authoritative. All future integrations must comply or be rejected.