7.0 KiB
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 to127.0.0.1:8124, SQLite file recorder, dev-token auth (Authorization: Bearer …). Startup =Popen→ first200on/api/. RSS/CPU viapsutilafter a 2 s settle. 300-sample sequential latency on/api/states. - Home Assistant:
ghcr.io/home-assistant/home-assistant:stablein Docker,-p 8125:8123, fresh/config. Startup = container start → first<500on/manifest.json. RSS/CPU viadocker stats --no-streamafter 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.