Selora-AI-LLM-1.7B

Selora Homes: selorahomes.com Selora AI Home Assistant Integration: github.com/SeloraHomes/ha-selora-ai

---

Selora AI LLM

Selora AI LLM is an instruction-tuned language model for Home Assistant, the open-source smart home platform. It ships in two forms: five small, single-purpose LoRA specialists — the reference setup the integration hot-swaps between — and a single general model, selora-ollama, that folds all five into one for Ollama and is published separately as selorahomes/Selora-AI-LLM-1.7B-ollama. Each specialist emits one strict, compact JSON "slim envelope" for its intent, and the Selora AI integration executes that envelope against your home — running service calls, resolving live state, or saving an automation (see Specialists for the exact shapes). The five specialists:

• command — control devices ("turn off the kitchen lights")
• automation — author home automations and blueprints
• answer — answer questions about the home's live state
• clarification — ask a follow-up when a request is ambiguous
• utilities — docs-grounded maintenance, troubleshooting, and setup help

The five specialists are LoRA adapters fine-tuned on a shared Qwen3 1.7B base. A 14B variant for 16 GB deployments is published separately as selorahomes/Selora-AI-LLM-14B.

Base: Qwen3 1.7B · Format: GGUF Q6_K base + 5 per-specialist LoRA adapters (F16) · License: Apache-2.0

Selora AI LLM powers the Selora AI Home Assistant integration and runs locally on Apple Silicon, Linux, or Windows via llama-server or Ollama, or in the cloud via vLLM — built for self-hosted IoT deployments that stay private and offline-first.

Use cases

• Chat control of smart-home devices — "turn off the kitchen lights", "set the thermostat to 68", "open the garage door" — resolved against live Home Assistant entity state.
• Natural-language home automation creation — describe an automation in plain English ("when the front door opens after 10pm, turn on the porch light") and Selora returns valid Home Assistant YAML as a draft you review before it's saved.
• Scene and routine orchestration — chain actions across multiple entities ("good night" → lock doors, dim bedroom lights, set thermostat) without hand-writing scripts.
• Q&A about your home — "is the laundry running?", "what's the temperature upstairs?" — the answer adapter returns the entities to check plus a response template, and the integration fills in the live state.
• Docs-grounded help — "why is the living-room sensor unavailable?", "how do I add the Hue integration?", "which integrations have pending updates?" — answered from retrieved Home Assistant documentation, with live state pulled in via entity placeholders and citations back to the source docs.
• Privacy-first home assistant — runs entirely on local hardware (Raspberry Pi 5, Mac mini, NUC-class boxes) with no cloud dependency, so device commands and home telemetry never leave the LAN.

Specialists

Every specialist LoRA emits a compact "slim envelope" — a small JSON object whose high-frequency keys are single characters to save tokens — and that envelope is an intermediate representation, not a finished action. The Selora AI integration's _convert_slim_shape parser turns it into real Home Assistant activity: run a downloaded GGUF on its own and you get the envelope back; it takes the integration (or an equivalent parser) to execute service calls, resolve live state, build YAML, or attach citations. By design the model never fabricates device state — it emits the calls to make, the entities to look up, the question to ask, or the automation to build, and the integration completes the loop against live HA.

Key map, applied once on the HA side: r=response, q=query / entity list, c=calls, s=service, e=entity_id, d=data (service params), o=options.

The integration's selora_local provider classifies each request to one specialist (a regex pre-classifier), then activates the matching adapter — llama-server's /lora-adapters hot-swap on the production hub, or vLLM --enable-lora.

Example envelopes

Real output for each specialist — the raw model emission; the integration then executes or resolves it:

// command — "Turn off the kitchen light and lock the front door"
{"c":[{"s":"light.turn_off","e":"light.kitchen"},{"s":"lock.lock","e":"lock.front_door"}],"r":"Kitchen light off and front door locked."}

// answer — "Is the bedroom light on?"
{"q":["light.bedroom"],"r":"The bedroom light is {light.bedroom}."}

// clarification — "Turn on a light" (when several exist)
{"q":"Which light — kitchen, bedroom, or living room?","o":["kitchen","bedroom","living room"]}

// utilities — "Why does the Hue bridge show an update?"
{"r":"The {update.philips_hue} update is pending; install it from Settings → Devices & Services → Updates.","q":["update.philips_hue"],"src":["home-assistant/updates#install"]}

// automation (concrete) — "Lock the front door at 10pm if it's still unlocked"
{"intent":"automation","response":"Created the 10pm auto-lock.","automation":{"alias":"Nightly Auto-Lock","triggers":[{"trigger":"time","at":"22:00:00"}],"conditions":[{"condition":"state","entity_id":"lock.front_door","state":"unlocked"}],"actions":[{"service":"lock.lock","entity_id":"lock.front_door"}]}}

The automation adapter's blueprint mode instead emits a fenced yaml block — a complete HA blueprint with blueprint:, input:, and !input wiring — rather than the concrete JSON shown above.

Why split into specialist LoRAs

The split is what makes high task accuracy attainable on small (1.7B) weights, and it is the reason the model behaves well on the evaluation surfaces below:

• Contract-first, by construction. The slim-envelope schema was designed up front and baked into every training example, so each specialist learns one clean, deterministic output shape — exactly what the integration needs to parse, and what lets the router fire the right adapter.
• One job per adapter. Each LoRA learns a single tightly-constrained output contract (its slim envelope) rather than a general chat distribution, so it can saturate that one task instead of trading off across many.
• Intent, not execution. Execution, live-state lookup, and YAML construction are the integration's responsibility. The model never invents state or device values — it templates them — which removes a whole class of hallucination failures.
• Slim envelopes are short. Single-char-keyed JSON means fewer tokens to mispredict and faster generation, and the rigid shape is trivial for the integration to parse and validate.
• Shared base, hot-swapped adapters. One Q6_K base (~1.6 GB) loads once; the right ~10–40 MB adapter is activated per request, so five specialists cost roughly the memory of a single model and every request is served by the adapter trained for it.
• Multi-state entity context. Per-entity attribute tails in the AVAILABLE ENTITIES block give each specialist richer single-turn grounding.

Results

Measured on the open allenporter/home-assistant-datasets suite — the harness behind the Home Assistant LLM leaderboard — at temperature 0, over the full suite.

Two modes are reported, because they measure different things:

• model only — the integration's deterministic overrides are switched off, so every turn is decided by the model's own output. This is the number a retrain moves.
• net + model — those overrides in the loop. Close to the shipped path, not identical: approval and the safe-command allowlist are off for the run, and questions reads high on calendar cases, whose fixtures supply event data a real Home Assistant does not.

95% Wilson intervals. The floor is a control run with the overrides off and a responder that never acts: read every score against it rather than against zero. questions has a non-zero floor because some expected answers are satisfied by text a stub happens to emit.

automations is four blueprint tasks, five samples each. The harness collects those replies without checking them, so they are scored separately: a reply passes if Home Assistant accepts it as an automation blueprint with every requested input declared and wired. The automation is not run, so a blueprint that loads but leaves out part of the task still passes.

The fused single-model build (selora-ollama) has no measured scores of its own. Merging trades per-task accuracy for single-model deployment — if your runtime can hot-swap adapters, use the adapters.

Retrieval grounding

The utilities specialist is grounded in retrieved Home Assistant docs. Scored with the official benchmark scorers, against the same pipeline answering from entity state alone:

Same base (qwen3_17b_base.Q6_K.gguf), same prompts, same Modelfile.utilities / llama-server --lora flow. The Allen-surface tables above were measured before retrieval grounding landed; re-measurement is in progress.

Quick start

You have a choice in how you start with Selora AI LLM:

• Ready to deploy with Home Assistant? Use llama-server — the runtime the HA integration is built around.
• Want to evaluate the model first? Use Ollama — try each specialist on your machine, smoke-test the LoRAs on your hardware, decide if Selora AI LLM is right for you before committing to the full Home Assistant integration. Fastest taste is a single line, no download: ollama run hf.co/selorahomes/Selora-AI-LLM-1.7B-ollama:selora-ollama.Q6_K.gguf.
• Serving in the cloud? Use vLLM.

llama-server (Home Assistant integration runtime)

The reference runtime — what the model was trained against and what the Home Assistant integration uses. llama-server's /lora-adapters endpoint is the in-process LoRA hot-swap that lets the integration pick a specialist per turn without reloading the base.

Download the base and all five LoRA files into a single directory, then:

llama-server \
  --model qwen3_17b_base.Q6_K.gguf \
  --lora-init-without-apply \
  --lora selora-command.f16.gguf,selora-automation.f16.gguf,selora-answer.f16.gguf,selora-clarification.f16.gguf,selora-utilities.f16.gguf \
  --ctx-size 4096

One --lora with comma-separated paths, not one flag per adapter: llama.cpp keeps only the last value when --lora is repeated, so the per-flag form loads a single adapter and silently answers every intent with it. --ctx-size 4096 matches the budget the corpus and manifest.json (runtime.ctx_size) are built to.

POST to /lora-adapters to switch the active LoRA before each /v1/chat/completions call. Build instructions for llama-server are in the llama.cpp build guide.

Ollama (evaluate the model before integrating)

Ollama lets you try Selora AI LLM on your machine and validate the LoRAs work before setting up the full Home Assistant integration. Useful for kicking the tyres on each specialist, smoke-testing the model on your hardware, or driving it from a script.

Selora requires Ollama 0.30 or later (for LoRA inference) installed locally. Pick whichever fits your machine:

• macOS / Linux / Windows: official installer (single download per platform)
• macOS via Homebrew: brew install ollama
• Linux via shell: curl -fsSL https://ollama.com/install.sh | sh
• Windows via Winget: winget install Ollama.Ollama

Download the base, the LoRAs, and the Modelfiles from this repo into one directory, then from that directory:

ollama create selora-qwen-command       -f Modelfile.command
ollama create selora-qwen-automation    -f Modelfile.automation
ollama create selora-qwen-answer        -f Modelfile.answer
ollama create selora-qwen-clarification -f Modelfile.clarification
ollama create selora-qwen-utilities     -f Modelfile.utilities

Each Modelfile pins the per-specialist system prompt and generation parameters, so no extra configuration is needed. The Q6_K base is stored once in Ollama's blob store and shared across all the specialists; only the ~10–40 MB LoRA adapter is added per slot — but ollama list will show one named entry per specialist.

Ollama 0.30+ does not support in-process LoRA hot-swap, so each specialist runs as its own named model. This path is best for direct chat or scripting use; for the Home Assistant integration use llama-server above.

Single general model — selora-ollama

If you'd rather not manage five separate models, selora-ollama folds all five specialists into one self-routing model — one model, all five intents, no hot-swap. It lives in its own repo, selorahomes/Selora-AI-LLM-1.7B-ollama: the merged Q6_K weights (~1.3 GB) alongside the unified router system prompt, chat template, and generation parameters, so Ollama pulls and runs it straight from Hugging Face — no manual download, no Modelfile step:

ollama run hf.co/selorahomes/Selora-AI-LLM-1.7B-ollama:selora-ollama.Q6_K.gguf

Prefer to build it locally — to tweak the system prompt or parameters first? Download that repo and create it from its Modelfile instead:

ollama create selora-ollama -f Modelfile

Either path gives you the same model. Per-surface scores for both runtimes are in the Results section above.

vLLM (cloud)

python -m vllm.entrypoints.openai.api_server \
  --model ./qwen3_17b_hf \
  --enable-lora --max-loras 5 --max-lora-rank 32 \
  --lora-modules \
    selora-command=/path/to/peft/command \
    selora-automation=/path/to/peft/automation \
    selora-answer=/path/to/peft/answer \
    selora-clarification=/path/to/peft/clarification \
    selora-utilities=/path/to/peft/utilities

vLLM activates the matching LoRA based on the request's model field; no extra routing layer needed.

Getting started in Home Assistant

A walk-through from zero to "Selora AI LLM is answering me in Home Assistant." If you already have HA running and just want to plug in the model, skip to step 4.

1. Create a Selora Homes Connect account

Sign up at selorahomes.com/connect. The account ties your local install to:

• Cloud-side OAuth flows (needed by integrations that require external authentication — e.g. some appliance providers)
• Optional remote-access tunnels so you can reach your home from outside the LAN
• Configuration sync between multiple HA installs in the same household

The local model runs without an account — Connect is for cloud-bridged features and remote access. If you only want offline-only local AI, you can skip this step and revisit later.

2. Set up Home Assistant

Install HA on a Pi, NUC, NAS, or x86 server using the official installation guide. HA OS is the recommended path for new users; Docker is fine for power users.

Confirm you can reach the HA web UI at http://homeassistant.local:8123 before continuing.

3. Install the Selora AI integration

The custom component lives at github.com/SeloraHomes/ha-selora-ai. Two install paths:

Via HACS (recommended). HACS — the Home Assistant Community Store — handles updates automatically.

1. Install HACS itself if you don't have it: HACS install guide
2. In HA: HACS → Integrations → ⋮ → Custom repositories
3. Add https://github.com/SeloraHomes/ha-selora-ai as type Integration
4. Search for Selora AI, click Install, restart Home Assistant

Manual install. Clone directly into HA's custom_components folder:

cd /config/custom_components
git clone https://github.com/SeloraHomes/ha-selora-ai.git selora_ai
# Restart Home Assistant

4. Download the model files

From this HuggingFace repo, get:

• qwen3_17b_base.Q6_K.gguf (the shared base, ~1.6 GB)
• selora-command.f16.gguf
• selora-automation.f16.gguf
• selora-answer.f16.gguf
• selora-clarification.f16.gguf
• selora-utilities.f16.gguf
• The Modelfile.* files (for Ollama users; skip for llama-server users)

Put them all in a single directory on the machine that'll run the model. Many users put this on the same box as HA; others run it on a dedicated GPU machine and point HA at it over the LAN.

5. Run the model locally

Pick one runtime — both are covered in the Quick start section above:

• Ollama 0.30+ — simpler if you already use Ollama. One model per specialist; the HA integration treats each as a separate provider.
• llama-server — the reference runtime, full LoRA hot-swap support. Best for the HA integration because it lets the integration pick the right specialist per turn.

Either way, the model needs to be reachable from wherever HA is running. Confirm with curl http://<host>:8080/v1/models (llama-server) or ollama list (Ollama).

6. Connect HA to Selora AI Local

In Home Assistant: Settings → Devices & Services → Add Integration → Selora AI. From the provider dropdown, pick Selora AI Local.

The integration auto-discovers a running llama-server (or Ollama) on the standard ports. If discovery fails, enter the host manually in the config flow.

7. Verify it works

Type one of these into the Selora AI chat panel that appears after setup:

• turn on the kitchen light — should flip a light
• what lights are on? — should list them
• create an automation that turns on the porch light at sunset — should produce an automation card
• turn on a light — should ask which one (if you have several)
• why is the living-room sensor unavailable? — should give docs-grounded troubleshooting steps

If they all work, you're done. If any fail, see Troubleshooting at the bottom of this page.

Design notes

The utilities specialist (slot 4)

A fifth specialist handles docs-grounded help — maintenance (pending updates, version conflicts), troubleshooting (why a device is unavailable / offline / not responding), and setup help (how to add or configure an integration). It is given the user question, the AVAILABLE ENTITIES list, and a RELEVANT DOCS list of retrieved Home Assistant documentation chunks, and returns a compact envelope:

{"r":"<advice with {entity_id} placeholders>","q":["<entity_id>",…],"src":["<doc_chunk_id>",…]}

r is advice grounded in the retrieved docs with {entity_id} placeholders for any live-state references; q lists the entities whose live state the advice depends on (so the consumer substitutes current values); src cites the doc chunks the advice is drawn from. The fix is grounded in the docs, never in entity state alone — the state is the signal, the docs supply the explanation.

Slot order

The specialist slot contract is 0=command, 1=automation, 2=answer, 3=clarification, 4=utilities. Backends that hot-swap LoRAs (llama-server's /lora-adapters, vLLM --enable-lora) load all five at startup.

Entity-block format reconciled with the integration

format_entities_block in scripts/gen_utils.py emits the per-line shape produced by _format_entity_line in custom_components/selora_ai/llm_client/sanitize.py:

AVAILABLE ENTITIES:
  - entity_id=light.kitchen; state=off; friendly_name=Kitchen Lights
  - entity_id=sensor.sun; state=below_horizon; friendly_name=Sun

Note that the local provider builds its own block in providers/selora_local/runtime/request_build.py, which differs in detail — no leading indent, and the friendly name quoted (friendly_name="Kitchen Lights"). The specialists tolerate both in practice, but the two are not byte-identical and only the form above is what training emits.

Inference

The manifest carries runtime.cache_prompt = true so the hub starts llama-server with system-prompt KV caching enabled, amortizing the per-specialist system prompt across requests.

Prompt format

Training and inference must match byte-for-byte. The chat template is ChatML with a /no_think prefix on the user turn, which suppresses Qwen3's reasoning block so output is bare JSON:

<|im_start|>system
{system prompt}<|im_end|>
<|im_start|>user
/no_think {user message}<|im_end|>
<|im_start|>assistant
<think>

</think>

The empty <think></think> block is part of the prompt, not the output, and training includes it (masked). The chat template embedded in these GGUFs always emits it, whatever the client asks for, so any runtime that applies it — llama.cpp's /v1/chat/completions, Ollama — supplies it at inference. A model trained without it generates as though the envelope's opening {" had already been written, and emits q=[...] instead of {"q":[...]} — unparseable, with no error anywhere.

The user message body has four sections, in this order and nothing else: USER REQUEST, EXISTING AUTOMATIONS, IMPORTANT (the untrusted-data warning), AVAILABLE ENTITIES. The utilities specialist appends a fifth, RELEVANT DOCS. Any drift — reordered sections, extra whitespace, different per-entity attribute keys — puts the model out of distribution.

Generation parameters

{
  "temperature": 0.0,
  "repeat_penalty": 1.0,
  "repeat_last_n": 256,
  "max_tokens": 384,
  "stop": ["<|im_end|>", "<|endoftext|>"]
}

Bump max_tokens to 1536 for automation requests (longer JSON output).

Training

Base: Qwen3 1.7B fine-tuned with PEFT on CUDA. Each specialist has its own LoRA (rank 8–24, scale 20) trained on a synthetic HA-domain corpus generated from curated home specifications and a service matrix — no scraped forum or user data. System prompts trained per-specialist; see prompts/. The answer adapter is trained to emit the slim {r,q} shape — a q list of entities to look up alongside its {entity_id}-templated response — which the integration resolves against live state; see prompts/answer_system_prompt.txt and the Modelfile.answer SYSTEM block. The utilities adapter is trained on docs-grounded maintenance / troubleshooting / setup examples with retrieved-doc context and citation provenance.

Training examples

Every specialist trains on the same wrapper — its system prompt, then a user turn carrying USER REQUEST and the AVAILABLE ENTITIES block (plus RELEVANT DOCS for utilities) — with the target slim envelope as the completion. One real pair per specialist (entity / doc lists trimmed; requests and target envelopes verbatim):

# command
USER REQUEST: resume the living room TV
AVAILABLE ENTITIES:
  - entity_id=media_player.living_room_tv; state=paused; friendly_name="living room TV"
→ {"c":[{"s":"media_player.media_play","e":"media_player.living_room_tv"}],"r":"Playing on living room TV."}

# answer
USER REQUEST: are hallway light and coffee maker on
AVAILABLE ENTITIES:
  - entity_id=light.hallway; state=off; friendly_name="hallway light"
  - entity_id=switch.coffee_maker; state=on; friendly_name="coffee maker"
→ {"q":["light.hallway","switch.coffee_maker"],"r":"Hallway light: {light.hallway}, coffee maker: {switch.coffee_maker}."}

# clarification
USER REQUEST: can you do something
AVAILABLE ENTITIES:
  - entity_id=light.entry; state=off; friendly_name="entry light"
  - entity_id=media_player.living_room_tv; state=idle; friendly_name="living room TV"
→ {"q":"Could you tell me what you'd like to do?"}

# automation
USER REQUEST: activate movie night every day at 7pm
AVAILABLE ENTITIES:
  - entity_id=scene.movie_night; friendly_name="movie night"
→ {"intent":"automation","response":"At **7pm** every day, this activates **movie night**. Want me to skip weekends?","description":"Activate scene scene.movie_night at 7pm.","automation":{"alias":"Auto-Movie Night","description":"Activate movie night at 7pm daily.","triggers":[{"trigger":"time","at":"19:00:00"}],"conditions":[],"actions":[{"service":"scene.turn_on","target":{"entity_id":"scene.movie_night"},"data":{}}]}}

# utilities
USER REQUEST: guide me through adding HACS
RELEVANT DOCS:
  - [hacs] Setting up the HACS integration (https://hacs.xyz/docs/use/configuration/basic/) — "Follow these steps to set up the HACS integration and authenticate it with GitHub…"
AVAILABLE ENTITIES:
  - entity_id=light.entry; state=off; friendly_name="entry light"
→ {"r":"To add HACS, go to Settings > Devices & Services > Add Integration and search for it, then follow the config flow. The integration's documentation page covers the prerequisites and step-by-step setup.","src":["hacs:https://hacs.xyz/docs/use/configuration/basic/#2","hacs:https://hacs.xyz/docs/use/configuration/options/#2"]}

Evaluation

Selora AI LLM is evaluated on the open allenporter/home-assistant-datasets suite — the harness behind the Home Assistant LLM leaderboard, so its results are comparable to other models' conversation agents. The headline numbers are in Results at the top of the card; what matters here is what each surface actually grades — each scores a different slice of the stack:

• The LoRA adapter — each specialist is a small LoRA trained on the slim-envelope schema: one strict, compact output contract per intent (the service calls to run, the entities to read, the question to ask, or the blueprint to build), designed up front and baked into every training example. Learning that single fixed shape per intent is what lets the adapter emit it reliably — and a malformed envelope is a miss on every surface, so this training is what every number ultimately grades.
• The integration is in the loop for assist, assist-mini, and questions. The adapter emits the envelope; _convert_slim_shape runs the command calls as real Home Assistant service calls and resolves the answer entity list into live-state answers; the metric then grades the resulting device state / produced answer. So those three are end-to-end scores — the adapter plus the integration's parser and routing, exactly how a user experiences it.
• automations is scored here, not by the harness. The harness's automation tool ends at model_output_writer.write(output) with no assertion, so this repo checks the automation adapter's blueprint YAML itself: Home Assistant must accept it as an automation blueprint with every requested input declared and wired. The automation is not run, so a blueprint that loads but leaves out part of the task still passes.

Files in this bundle

The full-precision (f16) base and HF safetensors set used by vLLM / TGI / SageMaker live separately in the cloud bundle and are not yet mirrored to Hugging Face.

First-run verification

Five prompts — one per specialist — let you confirm every slot loaded cleanly. Type them into HA's Selora AI panel (or hit the selora_ai/chat_stream WebSocket directly):

A clean run on all five = LoRAs loaded, classifier routing correctly, and the trained prompt format reaching the model. If any prompt returns garbage or empty output, check Troubleshooting below.

Troubleshooting

For deeper issues, the integration's debug log (logger: custom_components.selora_ai: debug in configuration.yaml) prints the full classifier decision, the request payload sent to llama-server, and the raw model response — enough to diagnose any reproducible case.

Versioning

main is the latest release. Each release is also tagged v<x.y.z>, so a specific one is reachable by revision:

from transformers import AutoTokenizer

AutoTokenizer.from_pretrained("selorahomes/Selora-AI-LLM-1.7B", revision="v<x.y.z>")

manifest.json records the version, per-file checksums and the training recipe for whatever revision you are on. Git tags are the only source of truth for it — there is no VERSION file.

Citation

@misc{selora-ai-2026,
  title  = {Selora AI LLM: Qwen3 1.7B + LoRA Specialists for Home Assistant},
  author = {{Selora Homes}},
  year   = {2026},
  url    = {https://huggingface.co/selorahomes/Selora-AI-LLM-1.7B}
}

License

Apache-2.0