Push the latest changes

[saifdev03-hub]

What does this Ability do?

Suggested Trigger Words

Type

• New community Ability
• Improvement to existing Ability
• Bug fix
• Documentation update

External APIs

• No external APIs
• Uses external API(s):

Testing

• Tested in OpenHome Live Editor
• All exit paths tested (said "stop", "exit", etc.)
• Error scenarios tested (API down, bad input, etc.)

Checklist

• Files are in community/my-ability-name/
• main.py follows SDK pattern (extends MatchingCapability, has register_capability + call)
• README.md included with description, suggested triggers, and setup
• resume_normal_flow() called on every exit path
• No print() — using editor_logging_handler
• No hardcoded API keys — using placeholders
• No blocked imports (redis, connection_manager, user_config)
• No asyncio.sleep() or asyncio.create_task() — using session_tasks
• Error handling on all external calls
• Tested in OpenHome Live Editor

Anything else?

[github-actions]

✅ Community PR Path Check — Passed

All changed files are inside the community/ folder. Looks good!

[github-actions]

🔀 Branch Merge Check

PR direction: add-home-assistant-controller → dev

✅ Passed — add-home-assistant-controller → dev is a valid merge direction

[github-actions]

✅ Ability Validation Passed

📋 Validating: community/home-assistant-controller
  ✅ All checks passed!

[github-actions]

🔍 Lint Results

✅ __init__.py — Empty as expected

Files linted: community/home-assistant-controller/main.py

✅ Flake8 — Passed

✅ All checks passed!

[abubakar4360]

Hi @saifdev03-hub, nice work on get_trigger_context() — pulling the command straight from message history so the user never has to repeat themselves is exactly the right pattern for a single-shot controller, and the alias support in build_entity_summary is a solid touch too. A few things need to be addressed before this can be approved, though:

1. PARSE_COMMAND_PROMPT is Phase 1 scoped to lights only (domain must be "light", service "turn_on" or "turn_off") but the entity summary passed to it includes all QUERYABLE_DOMAINS — switches, locks, climate, vacuums, etc. A user saying "lock the front door" or "turn off the fan" will get a confident-sounding no-match response even though the entity is right there in the summary. Either restrict build_entity_summary to light only for Phase 1, or expand the prompt to handle all controllable domains. Mixing a wide entity list with a narrow instruction is the worst of both options.

2. spoken_confirmation comes directly from LLM output and goes straight into speak() with no guardrails. PARSE_COMMAND_PROMPT has no instruction on how that string should sound — the model could return "The living room lights have been successfully turned off." or a bulleted summary and TTS will read every word. Add to the prompt: "spoken_confirmation must be plain spoken English, no markdown, no lists, one sentence under 10 words. Example: 'Living room lights are off.'"

3. "One sec, connecting to your smart home." and "One sec." are used twice as filler while async calls run. The second one — said right before the LLM parse — will fire every single command and gets old fast. Drop the second speak("One sec.") or replace it with silence; the first one already sets the expectation that things take a moment.

4. "I didn't quite get that. Try again with a specific light, like 'turn off the living room lights.'" — 28 words, and the example is too narrow now that the prompt theoretically handles more than lights. Trim to: "Didn't catch that — try saying something like 'turn off the living room lights'."

5. "I can't reach Home Assistant right now. Check that it's running and your network is connected." — two sentences, 18 words. On a voice device this reads like a troubleshooting doc. Change to: "Can't reach your smart home right now. Check your connection and try again."

6. "Home Assistant isn't configured yet. Ask your developer to set up the connection in the config file." appears twice and "Home Assistant config is invalid. Ask your developer to fix the config file." appears once — all three say "ask your developer" which is developer-facing language leaking into the user-facing voice output. A user shouldn't hear the word "config file" from their speaker. Change all three to something like: "This ability isn't set up yet. Someone needs to configure it before it'll work."

7. "I couldn't find any devices. Check your Home Assistant setup." — same issue, "Home Assistant setup" is implementation language. Change to: "Couldn't find any devices. Your smart home might need to be set up first."

8. "Something went wrong controlling that device. It might be unavailable." — "unavailable" is a Home Assistant state term that means nothing to most users. Change to: "Couldn't control that device — it might be off or disconnected."

9. The fallback confirmation = parsed.get("spoken_confirmation") or "Done." is fine, but "Done." is the only safety net if the LLM returns an empty string. Given point 2 above, add a hard length check before speaking: if len(confirmation.split()) > 20, fall back to "Done." rather than reading out whatever the model returned.

[abubakar4360]

Please share the working demo as well. Thankyou!

[uzair401]

Please address the issues highlighted by @abubakar4360, and then we will proceed further.