Home Generative Agent
A LangGraph agent inside Home Assistant that talks to your home, writes real automations, reads your cameras and watches for anomalies.
- Source repo
- goruck/home-generative-agent
- Stars
- ★ 374
- Last updated
- 1d ago
- License
- MIT
- Primary language
- Python
- FA score
- 51/100 · Major gaps
At a glance
- Works with
- Universal · cross-platformOpenAI API · Claude API
- You'll need
- Typical use
- Home Assistant users who want to describe automations in plain language and have working YAML created, validated and registered for them.
- Main limitation
- Heavy prerequisites: HA 2026.8.0+, HACS, PostgreSQL with pgvector and a model provider; the recommended path needs HA OS or Supervised, so Container and Core users must bring their own database.
- Source review
- 51/100 · Major gaps
What does this agent do, and when should you use it?
Home Generative Agent (HGA) is a Home Assistant integration, distributed through HACS or installed manually, that plugs a LangGraph-based AI agent into the Assist conversation UI. Rather than forwarding prompts to an LLM, the agent uses tools to control Assist-exposed entities, query the HA history database, analyze camera frames and write and register working automation YAML. Long-term semantic memory lives in PostgreSQL with pgvector so preferences survive across conversations, while the Sentinel anomaly engine keeps safety decisions in deterministic rules and lets the LLM advise without actuating. Model backends can be OpenAI, Gemini or Anthropic in the cloud, or Ollama and any OpenAI-compatible server on the local network, so inference can stay entirely at home. The integration also ships its own STT and TTS providers (OpenAI APIs or a local Speaches server) for a complete voice pipeline.
A user asks or commands something in the HA Assist panel; the LangGraph agent reads the state and recorder history of entities exposed to Assist and calls tools to switch devices, summarize energy usage, or analyze a live camera frame (optionally through an external face-service that exposes recognized-people sensors). When asked for an automation, it writes YAML, validates every concrete entity_id and service call against Home Assistant, then registers the automation so it appears in the automation editor; with the Critical Action PIN enabled, automations that would unlock a door or open a garage are held for PIN confirmation. The Sentinel engine applies deterministic rules to unlocked locks, open entries, unknown people and power/battery/environmental sensor anomalies, and runs a Home Assistant and network security audit (new admin accounts, long-lived tokens, exposed add-on ports, UPnP, newly joined devices), pushing findings to phones; optional LLM triage and rule discovery can suggest rules that are inspected, deactivated or repaired through HA services. Responses stream token by token, and on-demand audit requests such as 'is my home secure?' report findings by severity plus any checks that could not run. Extra tools can be supplied through an MCP server or any integration registering a Home Assistant LLM API.
- Home Assistant users who want to describe automations in plain language and have working YAML created, validated and registered for them.
- Households with several cameras that want motion-triggered analysis, recognized people in notifications, and per-camera sensors on a dashboard.
- Security-conscious users who want deterministic alerts for unlocked doors, open entries, unknown people, router-joined devices and weak HA configuration.
- Privacy-focused tinkerers who insist all inference runs on a local Ollama or OpenAI-compatible server on their own hardware.
- Users building a full Assist voice pipeline who want local streaming STT and TTS instead of relying only on cloud assistants.
- Advanced users who want the agent to remember standing preferences such as 'prepare the home for my arrival at night' and reuse them later.
How do you install or deploy this agent?
Requirements: Home Assistant 2026.8.0 or newer, HACS, PostgreSQL with pgvector, and at least one model provider. The recommended path needs Home Assistant OS or Supervised because step one installs a supervisor app.
Step 1 — add the PostgreSQL with pgvector app repository and install the app:
Repository: https://github.com/goruck/addon-postgres-pgvector
Settings → Apps → App Store → ⋮ → Repositories → paste the URL → search and install postgres_pgvectorStep 2 — install the integration through HACS:
HACS → Integrations → Custom repositories → https://github.com/goruck/home-generative-agent → Category: Integration → InstallStep 3 — restart Home Assistant, then go to Settings → Devices & Services → Add Integration, search for Home Generative Agent and complete the initial instruction screen.
Step 4 — on the integration page click '+ Model Provider'. First choose Edge (Ollama, OpenAI Compatible) or Cloud (OpenAI, Gemini, Anthropic), then enter the provider connection details. At least one provider must exist before Setup can run.
Step 5 — click '+ Setup' and pick a mode: Basic enables every feature with recommended defaults and creates the database subentry automatically; Advanced configures each feature individually, including a database step.
How do you use this agent?
Make HGA your conversation agent: Settings → Voice Assistants → select Home Generative Agent, then open the Assist panel and start talking. The agent only sees entities exposed to Assist, so open Settings → Voice assistants → Expose for each device you want to ask about and give it the name and area you will actually use, or the agent will report that no such device exists.
Typical requests:
"Turn on the living room lights"
"When did the front porch light turn on today?"
"How much energy did the fridge use today?"
"Remind me every 30 minutes if the litter box waste drawer is over 90% full"
"Are there any packages at the front gate?"
"Is my home secure?"Automation the agent wrote and registered:
alias: Check Litter Box Waste Drawer
triggers:
- minutes: /30
trigger: time_pattern
conditions:
- condition: numeric_state
entity_id: sensor.litter_robot_4_waste_drawer
above: 90
actions:
- data:
message: The Litter Box waste drawer is more than 90% full!
action: notify.notifyOptional voice in and out: click '+ STT Provider' and '+ TTS Provider' on the integration page, supply an OpenAI API key or point at a reachable Speaches server (OpenAI-compatible /v1/audio/transcriptions and /v1/audio/speech endpoints), then select them in your Assist pipeline.
What are this agent's strengths and limitations?
- A genuine agent, not a prompt passthrough: LangGraph tool calling, context management and streaming produce real automations that are validated against HA before registration.
- Provider freedom: OpenAI, Gemini, Anthropic, Ollama or any OpenAI-compatible server, with optional local STT/TTS so nothing need leave the home network.
- Safety is separated from the model: Sentinel decisions are deterministic rules, the LLM only advises, and Critical Action PIN holds lock/garage automations for confirmation.
- pgvector-backed semantic memory persists preferences across conversations and feeds them back into later automation requests.
- Broad camera support with an optional face-service, plus per-camera recognized-people and last-event sensors you can put on a dashboard.
- On-demand security audit returns findings by severity and explicitly names which checks could not run instead of claiming they passed.
- Heavy prerequisites: HA 2026.8.0+, HACS, PostgreSQL with pgvector and a model provider; the recommended path needs HA OS or Supervised, so Container and Core users must bring their own database.
- Entity exposure is manual — anything not exposed to Assist is invisible to chat and history questions, which is a recurring source of confusion.
- Cloud providers mean per-token cost and data leaving the house; the local alternative requires maintaining Ollama/vLLM-style servers and suitable hardware.
- Face recognition depends on an external face-service, and Sentinel's unknown-person rules never fire without it.
- The feature surface is very large (Sentinel rules, discovery, audits, multiple camera ecosystems, STT/TTS), so configuration and troubleshooting are more involved than with a lightweight chat integration.
- Some audit checks only work when matching router or eero integrations are installed; otherwise those checks are silently absent.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Home Generative Agent This agent | 51 · Major gaps | — | ★ 374 | 1d ago | Python | OpenAI API · Claude API |
| Local OpenAI LLM (Home Assistant Custom Integration) | 66 · Some gaps | Self-hosted serviceFree + model costs | ★ 306 | 1d ago | Python | OpenAI API |
| Tracekit Agent Audit and Policy Guard | 82 · Good | CLIFree | ★ 431 | 1d ago | Python | Claude Code |
| Little Canary Prompt Sensor | 78 · Good | CLIFree | ★ 41 | 15d ago | Python | Claude Code · OpenAI API |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows a Critical Action PIN gate for door/garage actions, deterministic Sentinel rules where the LLM advises but never actuates, and MAC/IP/hostname redaction before model boundaries — all positive. Deductions: the integration runs with Home Assistant administrator-level access and reads all entities and registries, so least privilege rests entirely on HA's own boundary with no finer-grained permission declaration; no lockfile or dependency audit evidence; external effects (writing automations, notifications, service calls) lack a unified rollback mechanism; source attribution is README self-description only and publisher identity is unverified.
Failure paths are documented well (database retry, missing pgvector, table ownership, capability gaps surfaced explicitly), and failure messages are concrete and actionable. Dependency availability evidence is thin: HA 2026.8+, external PostgreSQL+pgvector, optional face-service and local model servers, with no version pinning or dependency audit files. Self-consistency rests on documentation narrative only, with no test or run evidence in the provided files.
Audience and scenarios are well covered (cloud/local models, STT/TTS, cameras, Sentinel), and capability boundaries are stated clearly (no active scanning, no DPI, ZHA permit-join unobservable, zwave_inclusion_active poll-only). Deductions: trigger precision suffers from polling intervals missing short inclusion windows and new devices visible only after registration; environment fit requires HA OS/Supervised for the bundled app, limiting Container/Core users.
Information architecture is clear, install steps and troubleshooting are thorough, examples and community dashboards are plentiful, known limitations are explicit, and MIT license is stated. Deductions: versioning and changelog appear only as scattered in-document mentions (v3.39.0 etc.) with no standalone CHANGELOG file; naming stability cannot be confirmed from the excerpts; maintenance responsibility rests on a single unverified publisher with no governance or support commitment.
Output usability is high: automation YAML is validated against real entity IDs and services before installation, notification severity is explicit, and audit reports give severity-ranked fixes. Marginal value is clearly above prompt-passthrough integrations. Cost-benefit is deducted: PostgreSQL+pgvector, optional GPU edge server and external face service raise operational and hardware cost for ordinary households, and cloud model paths incur ongoing API spend.
The docs do separate fact from inference to a degree (naming which checks could not run and why, flagging fixture-only test paths), which earns credit. Claim traceability is weak: README performance and behavior claims mostly lack code or test references; cross-source corroboration is limited to intra-repository document cross-references with no independent third-party validation; the unverified publisher further limits external corroboration.
- The integration runs with Home Assistant administrator privileges and reads all entities, device registries and auth data; assess whether that permission scope is acceptable before deployment.
- It depends on external PostgreSQL+pgvector, an optional face-service and local model servers, with no dependency pinning or security audit evidence; verify dependency versions yourself before upgrading.
- Publisher identity is unverified and maintenance responsibility and update path are unclear, so long-term use carries follow-up risk you must absorb.
- Sentinel's polling can miss short-lived events (e.g. Z-Wave inclusion windows) and should not be treated as complete security monitoring.
- Cloud model paths send conversation and camera-analysis data to third-party LLM providers; confirm the redaction boundary and privacy policy.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
v3.45.0-beta.5 Pre-release
Release notes excerpt
Pre-release of v3.45.0, for field validation of #866: Sentinel's calls stalling voice on a shared local model. HACS offers it only to users who opted into betas. It contains everything on main as of 3fd752a. #866 step 1: Sentinel no longer stalls a voice turn on a shared local model (#875) On an edge model shared with chat, Sentinel now avoids starting calls rather than cancelling them, since a cancel is what can wedge an Ollama runner: …View on GitHub ↗ -
Release notes excerpt
Fixed - The Critical Action PIN is now asked for a service call however the tool names the service ([#837](https://github.com/goruck/home-generative-agent/issues/837)). The gate read a service-calling tool's domain and service arguments only. A tool that named the service another way ran with no PIN: {"action": "lock.unlock", "entity_id": "lock.front_door"}, {"action": "scene.apply", "entities": {"lock.front_door": "unlocked"}}, a dotted service ("service": "lock.unlock"), a domain with the service under action, or a tool named after the service (lock.unlock, or `sce …View on GitHub ↗ -
Release notes excerpt
Fixed - Turning on an offline group that holds the garage relay now asks for the Critical Action PIN, and switch device actions are held only when they act on the relay ([#804](https://github.com/goruck/home-generative-agent/issues/804)). A switch group helper that was unavailable or not yet loaded showed no members, so turning it on was not held even when it held the relay a garage door is built on (from #794), another wrapper of that relay, or a template switch that switches it; nor was a group listing the relay by its registry id. These groups are now read from their settings and h …View on GitHub ↗