99 lines
7.0 KiB
Markdown
99 lines
7.0 KiB
Markdown
# RuView HOMECORE vs Home Assistant — Performance & Capability Benchmark
|
||
|
||
**Measured:** 2026-05-31 · Windows 11, Docker Desktop 28.5.1 (WSL2 Linux engine) · single host.
|
||
**Reproduce:** `python aether-arena/staging/run_homecore_bench.py` and `python aether-arena/staging/run_ha_bench.py`.
|
||
|
||
HOMECORE is RuView's **wire-compatible Rust port of Home Assistant's core** (ADR-125…ADR-134): the
|
||
same `/api` REST + WebSocket surface, the same SQLite recorder schema, an automation engine, a
|
||
HomeKit bridge, a WASM plugin runtime, and a voice/assist pipeline — plus **native WiFi/RF sensing
|
||
entities** (presence, breathing, heart-rate, pose) that Home Assistant can only get through external
|
||
add-ons. Because the API is wire-compatible, the two can be measured head-to-head on the same client.
|
||
|
||
> **Read this honestly.** HOMECORE (`0.1.0-alpha`) is a young, focused core; Home Assistant is a
|
||
> mature platform with ~3,000 integrations and a decade of ecosystem. HOMECORE's thesis is **not**
|
||
> "more features" — it is **the same control plane at 1/35th the memory and 18× the startup speed,
|
||
> with RF sensing built in.** The numbers below quantify exactly that trade.
|
||
|
||
## Performance (measured)
|
||
|
||
| Metric | RuView HOMECORE `0.1.0-alpha` | Home Assistant `stable` | Advantage |
|
||
|--------|------------------------------:|------------------------:|-----------|
|
||
| **Cold start → API/web ready** | **0.55 s** | 9.72 s | **18× faster** |
|
||
| **Idle resident memory (RSS)** | **10.1 MB** | 359 MB | **35× leaner** |
|
||
| **Distribution size** | **4.7 MB** (single static binary) | 610 MB (container image) | **130× smaller** |
|
||
| **Idle CPU** | 0.0 % | 0.0 % | tie |
|
||
| **REST latency p50** | 2.13 ms | 2.95 ms | comparable¹ |
|
||
| **REST latency p95** | 22.9 ms | 27.3 ms | comparable¹ |
|
||
| **REST latency p99** | 26.2 ms | 28.3 ms | comparable¹ |
|
||
| **REST throughput (1 conn, sequential)** | **1,599 req/s** | 716 req/s | **2.2×** |
|
||
| **Recorder DB after boot** | 36.9 KB | 4.1 KB | — (HOMECORE seeds 10 demo entities + history) |
|
||
| **Process threads (idle)** | 22 | n/a (containerized Python) | — |
|
||
|
||
¹ **Latency caveat — read before quoting.** The two latency rows are *not* the same endpoint.
|
||
HOMECORE is measured on **authenticated `/api/states`** (returns 10 live entities). Home Assistant's
|
||
`/api/*` requires a completed onboarding flow + long-lived access token, so HA is measured on the
|
||
**unauthenticated `/manifest.json`** served by the same aiohttp stack. Both are single-connection,
|
||
300-sample, sequential. Treat latency as "same order of magnitude"; treat **memory, startup, and
|
||
size as the decisive, apples-to-apples results.** Throughput is endpoint-confounded the same way —
|
||
the 2.2× is directional, not a controlled isolate.
|
||
|
||
### What the deltas mean in practice
|
||
- **10 MB vs 359 MB RSS:** HOMECORE runs comfortably on a Pi Zero 2 W or an ESP32-class gateway
|
||
alongside the sensing pipeline; HA effectively needs a Pi 4/5 or x86 to itself.
|
||
- **0.55 s vs 9.7 s start:** HOMECORE can be cold-started per-request or restarted on config change
|
||
without a noticeable outage; HA's ~10 s boot (longer with real integrations) makes it a
|
||
long-lived daemon only.
|
||
- **4.7 MB vs 610 MB:** OTA-updating the whole control plane over a metered/rural link is trivial
|
||
for HOMECORE; HA ships as a ~250 MB compressed image.
|
||
|
||
## Capability & feature comparison
|
||
|
||
| Capability | RuView HOMECORE | Home Assistant |
|
||
|-----------|-----------------|----------------|
|
||
| HA-compatible REST `/api` | ✅ wire-compatible subset (ADR-130) | ✅ reference implementation |
|
||
| HA-compatible WebSocket API | ✅ (ADR-130) | ✅ |
|
||
| State machine + event bus + service registry | ✅ 13 seeded services (ADR-127) | ✅ |
|
||
| SQLite recorder (history) | ✅ HA-compat schema **+ ruvector semantic search** (ADR-132) | ✅ (no vector search) |
|
||
| Automation engine + Jinja templates | ✅ MiniJinja trigger/condition/action (ADR-129) | ✅ (full Jinja2) |
|
||
| HomeKit (Apple Home) bridge | ✅ scaffold (ADR-125) | ✅ mature |
|
||
| Plugin/integration runtime | ✅ **sandboxed WASM** plugins (ADR-128) | ✅ Python integrations (in-process, unsandboxed) |
|
||
| Voice / intent / "Assist" | ✅ 5 built-in intents **+ ruflo agent bridge** (ADR-133) | ✅ Assist + LLM agents |
|
||
| Migration from existing HA | ✅ reads HA `.storage/` + `automations.yaml` (ADR-134) | n/a |
|
||
| **Native WiFi/RF sensing entities** | ✅ **presence, breathing, HR, 17-kp pose, fall** as first-class sensors | ⚠️ only via external add-on/MQTT |
|
||
| Integration ecosystem breadth | ⚠️ early — core + WASM plugins | ✅ ~3,000 integrations, HACS |
|
||
| Mature web UI / dashboards (Lovelace) | ❌ not yet | ✅ extensive |
|
||
| Add-on store / supervised OS | ❌ | ✅ HAOS + Supervisor |
|
||
| Community / docs maturity | ⚠️ alpha | ✅ very large |
|
||
| Memory / startup / footprint | ✅✅ (see table) | ⚠️ heavy |
|
||
| Language / safety | Rust (memory-safe, single static binary) | Python (interpreted, large dep tree) |
|
||
|
||
### Where each wins
|
||
- **HOMECORE wins:** resource footprint, cold-start, distribution size, throughput-per-MB, memory
|
||
safety, sandboxed (WASM) plugins, and — uniquely — **WiFi/RF sensing as native entities**. Ideal
|
||
for edge gateways, battery/solar nodes, and shipping the control plane *with* the sensor.
|
||
- **Home Assistant wins:** integration breadth, UI/dashboard maturity, add-on ecosystem, community
|
||
support, and production track record. Ideal as a full-house hub on a Pi 4/5+ or x86.
|
||
|
||
## Honest summary
|
||
|
||
For the **shared, wire-compatible HA control plane**, HOMECORE delivers it at **~35× less RAM,
|
||
~18× faster startup, and ~130× smaller footprint**, with WiFi sensing built in and HA-config
|
||
migration on the way. What it does **not** yet match is Home Assistant's enormous integration
|
||
catalog and UI maturity. The right read is **"HA-compatible core, edge-class resource budget,
|
||
RF-native"** — not "HA replacement." For a sensing node that also needs to *be* a smart-home hub,
|
||
HOMECORE's efficiency is decisive; for a feature-complete whole-home hub today, Home Assistant
|
||
remains the broader platform.
|
||
|
||
## Reproduction & method
|
||
|
||
- **HOMECORE:** `v2/target/release/homecore-server.exe` (`0.1.0-alpha.0`), bound to `127.0.0.1:8124`,
|
||
SQLite file recorder, dev-token auth (`Authorization: Bearer …`). Startup = `Popen` → first `200`
|
||
on `/api/`. RSS/CPU via `psutil` after a 2 s settle. 300-sample sequential latency on `/api/states`.
|
||
- **Home Assistant:** `ghcr.io/home-assistant/home-assistant:stable` in Docker, `-p 8125:8123`,
|
||
fresh `/config`. Startup = container start → first `<500` on `/manifest.json`. RSS/CPU via
|
||
`docker stats --no-stream` after a 20 s settle. 300-sample sequential latency on `/manifest.json`.
|
||
- Both runs are single-host, single-connection, no concurrency tuning. Numbers are indicative of
|
||
the **resource/startup class**, which is the property that differs by orders of magnitude;
|
||
latency/throughput are reported with the endpoint caveat above and should not be over-read.
|
||
- Harness scripts: `aether-arena/staging/run_homecore_bench.py`, `aether-arena/staging/run_ha_bench.py`.
|