JARVIS AIO v6.57.0

[6.57.0] — semantic search via Ollama, no ChromaDB

The 6.56.0 approach hit a wall: ChromaDB's embedded mode depends on
onnxruntime, which has no wheel for the Python 3.14 that Home Assistant now
runs on, so the install could never succeed on this platform. Rather than
wait on an upstream wheel, this replaces it with something more in the
JARVIS-AIO spirit — reuse what's already here.

Semantic search now runs on the Ollama server JARVIS already talks to.
Embeddings come from Ollama's /api/embed (nomic-embed-text by default) —
no API key, no Python package, no native wheel to compile, works on any
Python version. Vectors are stored in JARVIS's own jarvis.db SQLite file
alongside the keyword index, and similarity is plain cosine computed in
stdlib Python (no numpy). No new service, no ChromaDB, no 300–500 MB
download.

Enable it in Settings → Document Library: it runs a live Ollama health
check, and once on, re-ingesting embeds your documents so retrieval matches
on meaning instead of keywords. It degrades to keyword (FTS5) search
automatically whenever Ollama or the embed model isn't reachable — the
document tools and panel keep working either way. Requires an Ollama host
(set llm_base_url) and a pulled embed model (ollama pull nomic-embed-text).

New: embeddings.py (Ollama calls + SQLite vector store + cosine search),
a jarvis/semantic_search WS command (status/enable/disable/test), async
ingest_directory_async / search_documents_async in documents.py, and a
reworked search-engine banner. The obsolete ChromaDB vector_backend.py is
removed. 17 new embeddings tests (vector math, store, mocked Ollama
batch/legacy endpoints) and updated panel smoke checks.

Full Changelog: 6.56.1...6.57.0

JARVIS AIO v6.65.1

[6.56.1] — fix ChromaDB install; modernize CI actions

Two fixes surfaced by real deployment of 6.56.0.

Semantic-search install failed with "HA package helper unavailable:
cannot import name 'async_install_package'." There is no
async_install_package in homeassistant.util.package — the real helper
is the synchronous install_package. Now the enable button calls that
through an executor job (it shells out to pip/uv, so it must stay off the
event loop), and semantic search installs as intended. Keyword search was
never affected.

CI Node 20 deprecation warning. actions/checkout@v4 and
actions/setup-python@v5 run on Node 20, which GitHub is retiring in favor
of Node 24 — the Validate workflow was green but annotated with a warning.
Bumped to actions/checkout@v5 and actions/setup-python@v6 (both on Node
24), clearing it. No behavior change to the checks themselves.

Full Changelog: 6.56.0...6.56.1

JARVIS AIO v6.56.0

[6.56.0] — optional ChromaDB: semantic search, one button

JARVIS-AIO leans further into "all-in-one" without punishing small hosts.
Memory and document retrieval have always worked everywhere via the
built-in SQLite FTS5 keyword search; now you can upgrade both to true
semantic vector search by installing ChromaDB from a single button in
Settings → Document Library — no separate add-on, no manual pip, no HA
restart.

It's deliberately opt-in, not a hard requirement: ChromaDB pulls ~300–500 MB
(onnxruntime, tokenizers, etc.) that can be slow or fail to build on a Pi /
HA Green / Yellow. So JARVIS ships light and the panel tells you plainly
what enabling costs and where it's a good idea. The install runs through
Home Assistant's own package helper (lands in the env HA imports from) and
then re-initializes the memory and document stores in place, so vector
search activates immediately. If the host can't build it, the install
fails gracefully and keyword search keeps working — nothing breaks.

New: vector_backend.py (detect / install / re-init), a
jarvis/vector_backend WS command, and a search-engine banner in the
Document Library panel showing KEYWORD vs SEMANTIC with an enable button
and honest host guidance. 7 unit tests (detection, re-init resilience,
install flow with mocked HA helper, graceful failure) and 4 panel smoke
checks.

JARVIS AIO v6.55.0

[6.55.0] — Document RAG: JARVIS reads your manuals

The last un-built agent from the home-agent blueprint. JARVIS can now
answer from the household's own paperwork: drop appliance manuals and
receipts (PDF, .txt, .md) into /config/jarvis/documents, ingest them,
and ask "what's the furnace filter size?" or "when did we buy the
dishwasher?" — it retrieves the relevant excerpt and answers, citing the
source document, instead of guessing.

Built on the same ChromaDB the memory system already runs, but as a
separate collection — a manual isn't a conversation turn, and a furnace
query shouldn't surface old chats. Documents are chunked with overlap on
paragraph/sentence boundaries for good recall, embedded via Chroma's
default function (no extra model dependency), cosine-scored. When ChromaDB
isn't installed it falls back to FTS5 keyword search in the existing
jarvis.db, so retrieval works on a minimal install too. PDF text
extraction degrades honestly across pypdf / pdfplumber / PyPDF2 and, if
none is present, says so and skips the file rather than crashing — plain
text always works. pypdf is now a manifest requirement so PDFs work out
of the box.

Two agent tools (search_documents, ingest_documents), a
jarvis/documents WS command, and a Document Library panel in Settings
with an ingest button, live source list, and a test-search box. 17 unit
tests (the pure chunker, extraction routing, ingest/search through a
simulated collection, honest fallbacks) plus 4 panel smoke checks.

This completes every blueprint agent that belongs inside Home Assistant.

Full Changelog: 6.54.0...6.55.0

JARVIS AIO v6.54.0

[6.54.0] — the floor plan glows from live mmWave

The residence model now lights up room-by-room from genuine mmWave/presence
detection, not just the binary area-occupancy flag. A room whose presence
sensor is actively detecting gets a distinct, punchy aqua-green glow with a
brighter border — visibly the "hottest" room — while a room lit only by
generic area occupancy stays standard cyan, and the dominant room keeps its
mint. At a glance you can now tell where a body actually is versus where
HA merely thinks a zone is active.

Mechanically: _house3dLit() overlays the jarvis/mmwave_overview feed
onto the plan's lit map as a new mmwave state that flows through the
whole 3D builder — floor fill, walls, label, and pulse dot all render it
distinctly. The plan rebuilds when fresh mmWave data lands, so detection
appears live. Verified by rasterizing the plan and eyeballing that the
three presence states are actually distinguishable before shipping.

Full Changelog: 6.53.0...6.54.0

JARVIS AIO v6.53.0

[6.53.0] — mmWave presence overview

The residence tab gains a live mmWave Presence panel: every room with a
presence, motion, or occupancy sensor, showing whether it's occupied right
now, how many of its sensors are detecting, and — when clear — how long
since the last detection. Occupied rooms glow green and pulse; the header
summarizes at a glance ("2/5 OCCUPIED"). It's the ground truth behind the
floor-plan glow, surfaced directly instead of inferred.

This reads genuine sensor state, not the binary area-occupancy flag — a
room lit only by a door contact won't masquerade as mmWave presence here.
A new jarvis/mmwave_overview WS command assembles the per-room breakdown
from the occupancy sensors already mapped to HA areas; outdoor rooms are
tagged so yard sensors don't read as living space. Refreshes live on the
poll while the tab is open. 6 panel smoke checks; verified by rasterizing
the panel and eyeballing it before ship.

[6.52.1] — learned automations for locks and covers are now valid

A latent bug in the pattern generator became reachable the moment 6.52.0
started installing suggestions. Every learned action was built as
{domain}.turn_{state} — fine for lights and switches, but nonsense for
other domains: a learned door-lock routine (the pattern module's own
flagship example, "front door locks after garage closes") would emit
lock.turn_locked, and a garage-cover routine cover.turn_closed —
invalid services that would write a broken automation to automations.yaml.

Actions now resolve through a domain-aware service_for(): locks get
lock.lock/unlock, covers get open_cover/close_cover, on/off domains
keep turn_on/turn_off, and cover transient states (opening/closing)
settle to their end state. Domains that need parameters we can't infer from
a bare state (climate, media_player) return no mapping, so those patterns
become advisory suggestions rather than broken automations. Time routines
were already gated to on/off and unaffected. 6 new tests, including the
end-to-end proof that a lock sequence installs lock.lock, not a
turn_-prefixed impossibility.

[6.52.0] — the pattern engine closes the loop

The learning pipeline had a dead end: it observed behavior, detected
patterns, generated automation YAML, surfaced suggestions — and approving
one only flipped a database flag to approved. Nothing was ever installed.
The user saw "learned a routine," approved it, and… nothing happened.

Approval now installs the automation into Home Assistant. A new
install_approved_suggestion bridges the gap: it reads the suggestion's
stored automation, normalizes the generator's legacy shape into HA's
current format (translating platform→trigger and service→action),
and writes it live through the existing automation creator — then records
the suggestion as installed. Both approval paths use it: the panel's ✓
button and the voice tool ("JARVIS, approve that suggestion"). Concrete
suggestions (time routines, sequences, presence) install and go live
immediately; advisory-only ones (vague repeated-command notes) are still
acknowledged as approved but honestly reported as needing a human to
design — no fabricated automations. The panel toast and the agent both
relay which outcome occurred, and a LEARN line logs each install.

16 new tests: the normalizer across every pattern shape and malformed
input, plus the installer wiring end-to-end (installs, advisory skip,
missing suggestion, write-failure). Plus a panel smoke check for the
approve→install path.

[6.51.2] — roadmap: local GPU inference shipped

Local GPU inference is done — Ollama on a dedicated GPU box (via a HAOS
GPU AI setup), so the reasoning chain runs templates → cache → local model
→ cloud on your own hardware. Moved it out of the roadmap's "on the
horizon" list into "shipped recently," and updated the Requirements note so
the local GPU server reads as supported now rather than a future item.

[6.51.1] — README visuals, Nest streaming guide, roadmap trim

Documentation pass. The README gains faithful HUD visuals — a hero banner
and a two-up gallery of the Cognitive Core feed and the Camera Watch/DIAG
panel — rendered as SVG from the panel's actual design tokens (real cyan,
real fonts, real layout), so they represent the aesthetic without stale
screenshots to maintain. Added a full "Continuous streaming for Google
Nest cameras" guide: the go2rtc restream setup that defeats Google's
5-minute expiring streams, with the exact nest: source config, where to
find each credential, the optional Frigate hand-off, and the JARVIS
camera_overrides mapping that ties it together. Trimmed the roadmap —
UI Phase 3 (real-time WebSocket subscriptions, sparklines, entity cards,
log/feed search) has shipped, so it moved to a "shipped recently" note;
Document RAG is now called out as the last un-built blueprint agent.

Full Changelog: 6.51.0...6.53.0

JARVIS AIO v6.51.0

[6.51.0] — three new agents, and JARVIS finally sounds like JARVIS

The home-agent blueprint, reconciled against what already existed. Most of
its twelve agents were already here under other names — the Supervisor is
the agentic core, the Memory agent is the Chroma vector store, Vision is
the camera stack, Voice is the Wyoming pipeline. Three were genuinely
missing; two of the twelve (OS control, code execution) are deliberately
NOT built — arbitrary desktop automation and code execution inside the HA
process are security weight a home butler shouldn't carry.

Web Research agent. A new web_research tool: ask about the outside
world and JARVIS looks it up, then relays the gist in its own voice.
DuckDuckGo's Instant Answer API by default (no key, no signup), switchable
to a self-hosted SearXNG. Results are summarized, capped, and sanitized —
never a raw page dump — and a failed lookup returns an honest "couldn't
find that," never an exception.

Communication agent. A new calendar_agenda tool reading the
calendar.* entities HA already exposes: upcoming events plus conflict
detection — overlaps, and back-to-back transitions tighter than a
configurable gap. Email is deliberately untouched; reading an inbox from
inside HA is privacy weight better handled by exposing specific mail as an
entity.

MCU-JARVIS persona. The voice now leans into Stark's JARVIS — dry,
clever, unflappable — with an engineered safety valve: full wit only at
light/neutral register, automatically silenced at urgent/grave. JARVIS
does not quip during a smoke alarm, and that's now structurally guaranteed
(the urgent/grave phrase pools can never gain banter lines — there's a test
that asserts exactly this). A banter level knob (plain / dry / full)
in Settings → JARVIS Character tunes it live, flowing into both the phrase
pools and the LLM's own prompt.

New: web_research.py, comms.py, banter valve in persona.py, two agent
tools, four panel-writable config keys, a JARVIS Character settings panel,
26 tests. The HTTP paths can't be exercised from the build sandbox (no
egress to the search endpoints), so they're covered by pure-shaper tests
and run live where HA has normal network access.

Full Changelog: 6.50.0...6.51.0

JARVIS AIO v6.50.0

[6.50.0] — camera management moves to Settings

The ✎ NAME button and its overlay are gone from Command Center — camera
renaming and indoor/outdoor designation now live in a Cameras panel on
the Settings tab, one row per camera: entity id (with the restream
override arrow when one is mapped), a name field (Enter or blur saves,
unchanged blur makes no call, blank reverts — placeholder shows the HA
name), and the AUTO/⌂ INDOOR/▲ OUTDOOR chips with instant save and the
resolved heuristic on AUTO. All cameras visible and editable at once
instead of one-at-a-time through an overlay, and Command Center's Camera
Watch head is back to just DIAG.

Two mechanics worth noting: the Settings tab already skips poll re-renders,
so typing a name is never wiped mid-edit; and the row refresh no longer
depends on CSS.escape, which isn't guaranteed in every embedding (found
by the smoke harness — the chip toggle silently died in its catch).

Same backend as 6.48/6.49 — jarvis/rename_camera and
jarvis/camera_location unchanged.

Full Changelog: 6.49...6.50.0

JARVIS AIO v6.49.0

[6.49.0] — tell JARVIS which side of the walls a camera lives on

The ✎ camera overlay gains a LOCATION row: AUTO / ⌂ INDOOR /
▲ OUTDOOR, saving instantly per click. AUTO shows what the heuristics
currently resolve — "AUTO (outdoor)" — so overriding is an informed choice,
not a guess.

This isn't cosmetic. outdoor.py is the single source of truth the whole
cognitive stack consults — the intrusion investigator (outdoor sensors must
not seed or confirm indoor investigations), the notable-outdoor-event
filter, and the motion scan. Its most-authoritative layer has always been
the user's word (indoor_entities / outdoor_entities); the new chips pin
the exact entity id into those lists via jarvis/camera_location, so a
designation immediately governs everything downstream. AUTO unpins and the
heuristics resume. Hand-written globs in those lists are preserved
untouched and still classify — they just read as AUTO in the picker, since
they aren't a per-camera pin.

Regression-tested end-to-end: an INDOOR pin beats an outdoor name keyword
(camera.backyard_playroom stays inside), an OUTDOOR pin makes a hallway
camera exterior for the whole stack, and unpinning restores heuristics.

JARVIS AIO v6.48.0

[6.48.0] — call your cameras what you actually call them

Cameras can now be renamed inside JARVIS only — HA entity names and
Frigate stream names stay untouched. Useful now that restream twins exist:
eliana_restream can just be "Eliana's Room" on the panel.

A ✎ NAME button in the Camera Watch head opens an inline overlay for
the active camera: type a name, Enter saves, Esc cancels, blank reverts to
the HA name (shown as the placeholder so you always know what blank means).
The name applies everywhere the panel shows a camera — chips, the SRC
strip (including the override-mapping arrow), pickers — via a
camera_names runtime map, persisted through a new jarvis/rename_camera
WS command with a CONFIG line in the activity log.

Server logs and DIAG probes deliberately keep entity ids — display names
are for humans, entity ids are for debugging, and mixing them costs
precision exactly when it matters.

Also in 6.48.0 — config.json can no longer take the panel down. A
hand-edited /config/jarvis/config.json (adding camera_overrides by
hand) that parsed to something other than a JSON object crashed
async_setup_entry before panel registration — the integration never
loaded and the JARVIS tab died with "Unable to load custom panel."
jarvis_config is now self-healing: an unparseable or non-object file is
sidelined (preserved as config.json.corrupt-<timestamp>, never
deleted), defaults load, every accessor guards the cache type, and a
persistent notification explains exactly what happened and where your
edits went. A typo in that file now costs you a notification, not the
integration. Seven regression tests, including the exact live failure.