I was able to build OpenCode into the HA Terminal. I then linked it to Anthropic’s Sonnet 4.5. Since OC is running onboard it has full access to use all the CLI/API tools of HA to create automations, scripts, scenes, etc… I can’t imagine configuring HA without this tool anymore… To begin with I have the Advanced SSH & Web Terminal Add On installed with protection mode disabled.
apk add build-base go git sqlite-dev bun
git clone https://github.com/sst/opencode.git
cd opencode
curl -fsSL https://bun.sh/install | bash
bun install
bun run dev
If that all works, you need to run the full build:
bun run build
the muse builds are what you’ll need depending on your architecture: x64 or arm64. The likely path for these two directories are /root/opencode/packages/opencode/dist
copy the opencode “binary” to /config/bin/ and add it to your path.
just being able to use agentic “vibe” coding in the configuration of home assistant. For example I used it to build a trip tracking system with choose prompts upon arrival to categorize trips: business, personal, medical, etc… for tax tracking purposes. I’ve also used it to diagnose why I’m seeing oddities. It’s been able to identify the root cause of the issues, make a plan to correct the configuration, then apply the correction and then restart ha… It’s more like a power tool for construction and configuration.
Ok then I would strongly urge everyone reading this (and don’t take it as as slight on you please) that vibe coding HA is problematic at BEST because of the lack of good grounding data in HA. Your mileage may vary.
Oh absolutely no slight taken, and your caution is well warranted. I have found success, but as you stated and with most things “your mileage may vary.” What makes this approach different, IMO, than from just using an agentic process with an attached config drive is that the TUI/Agent has access to the complete configuration including the database behind HA so it does have more context than just mapping into the config directory. Also, I’m running HA virtualized and I’m taking a full snapshot before I start vibing (mucking about…) just in case something goes terribly wrong.
@NathanCu to your point and to help answer the question what am I trying to accomplish. Based on your point about the lack of grounding for HA, I used agentic methods to develop a grounding approach. Attached is the session (redacted as necessary) where the output is a grounding layer that I can tell the agent to make use of before the next work item.
This is the prompt I fed it:
You are tasked with building a grounding layer for Home Assistant agentic sessions.
Your goal is to provide structured, reliable context that prevents hallucinations and
makes AI-driven automation generation reproducible and verifiable.
Requirements:
1. **Entity Registry Normalization**
- Enumerate all entities, integrations, and devices.
- Capture attributes, supported services, and capabilities in a consistent schema.
- Annotate each entity with metadata: room, type, purpose, relationships.
2. **Context Tracking**
- Maintain session-level context: which entities have been referenced,
which automations are active, and what constraints apply.
- Provide a queryable state snapshot for the agent at each step.
3. **Ontology & Relationships**
- Build a lightweight ontology linking entities (e.g., lights → rooms → automations).
- Include parent-child relationships (device → entity → service).
- Track dependencies (automation A requires sensor B).
4. **Validation Hooks**
- For every AI-suggested automation, validate against the grounding layer:
- Does the entity exist?
- Are the services supported?
- Are required attributes present?
- Return structured error messages if validation fails.
5. **Observability**
- Log all grounding lookups and validation checks.
- Provide a diff view when automations are modified, showing what changed and why.
Deliverables:
- A reproducible grounding schema (JSON/YAML) that can be regenerated from HA state.
- Helper functions for querying context (e.g., `get_entities_by_room("kitchen")`).
- Validation routines that reject or correct AI-generated configs when they conflict
with actual HA capabilities.
Objective:
Create a grounding layer that transforms Home Assistant’s fragmented entity data
into a reliable, structured context model. This layer should enable agentic AI sessions
to reason with accuracy, minimize config drift, and prevent vibe-based coding errors.
The outcome was a set of tools. Here’s the session.
I think the biggest difference is the target (tool and audience). My target is a TUI (OpenCode) running inside the Advanced SSH & Web Terminal while your target appears to be the voice assistant usable by the actual end user of HA. My intent was just to speed up my own development, not to enable outside interaction (which is amazingly cool that you got it to do all of that). What makes OpenCode a little more feasible in these projects is the session compaction it does (summarizing) to keep the token window in check without losing context. Anyway. Thank you again for engaging.