feat: expose category on automation, script, and helper config tools - #850
Conversation
Add category parameter to domain-specific config tools, building on homeassistant-ai#677's category CRUD foundation: - ha_config_get_automation: includes category from entity registry - ha_config_set_automation: accepts category parameter, applies via entity registry update after creation (also extracts from config dict to prevent REST API rejection) - ha_config_get_script: includes category from entity registry - ha_config_set_script: same pattern as automations - ha_config_set_helper: adds category alongside existing area_id and labels entity registry updates Categories are stored in the entity registry (not YAML config), so GET tools make a secondary WebSocket call to fetch them, and SET tools apply them via entity_registry/update after the primary create/update succeeds. Closes homeassistant-ai#702 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request extends the Home Assistant configuration tools by introducing support for entity categories. By decoupling the category management from the primary configuration payload, the changes ensure compatibility with the Home Assistant REST API while enabling users to organize automations, scripts, and helpers more effectively through the entity registry. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces category management for Home Assistant automations, scripts, and helpers by updating the respective 'get' and 'set' tools to interact with the entity registry. Key feedback includes ensuring the category parameter is supported in the update path for helpers and using the correct 'helpers' scope for helper categories. Additionally, several broad exception blocks should be replaced with debug logging to improve maintainability, and the efficiency of resolving automation entity IDs from unique IDs should be considered for large installations.
Fixes from Gemini review: - Use "helpers" scope for helper categories (not helper_type) - Add category support to helper UPDATE path (was only on create) - Replace bare except:pass with logger.debug for debuggability Add E2E tests: - test_automation_set_and_get_category: full round-trip - test_script_set_and_get_category: full round-trip - test_automation_category_in_config_dict: category extraction Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
/Gemini review , made changes, do one more review |
There was a problem hiding this comment.
Code Review
This pull request introduces category support for automations, scripts, and helpers across the Home Assistant MCP tools. It updates the configuration tools to allow setting and retrieving categories via the entity registry and includes comprehensive end-to-end tests to verify this functionality. I have provided feedback regarding the use of overly broad exception handling and suggested refactoring the duplicated entity ID resolution logic to improve maintainability.
Include scope='helpers' and mention ha_config_set_category() for consistency across all category-aware config tools. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Deduplicate the entity_id-from-unique_id resolution logic used by both ha_config_get_automation and ha_config_remove_automation into a single helper function. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
state["entity_id"] returns Any from untyped dict; wrap in str() to match the declared str | None return type. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
/Gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces category support for automations, scripts, and helpers, allowing users to organize these entities via the Home Assistant entity registry. The changes include updates to the configuration tools to handle category assignment during creation and retrieval, along with comprehensive end-to-end tests to verify the new functionality. I have provided feedback regarding code duplication in category handling and the naming convention for the removal tool.
- Extract fetch_entity_category() and apply_entity_category() into util_helpers.py, replacing duplicate inline logic in automations and scripts config tools - Restore warning log in ha_config_remove_automation when entity_id resolution fails (was lost during _resolve helper extraction) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
categories.get(scope) returns Any from untyped dict; cast to str to match declared str | None return type. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…homeassistant-ai#836, homeassistant-ai#850, homeassistant-ai#854, dev57 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…homeassistant-ai#836, homeassistant-ai#850, homeassistant-ai#854, dev58 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…homeassistant-ai#850, homeassistant-ai#853, homeassistant-ai#854, dev59 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…homeassistant-ai#850, homeassistant-ai#853, homeassistant-ai#854, dev60 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Check WebSocket success in apply_entity_category before reporting - Upgrade fetch_entity_category error logging from debug to warning - Add else branch for helper create registry update failure - Capture and check config-store-types registry update result - Use None check instead of falsy check for category precedence - Add helper category test (input_boolean with "helpers" scope) - Use wait_for_tool_result polling in GET-after-create tests - Add tests: param precedence, category on update, script config-dict Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Automation update path: entity_id is None in upsert result, so apply_entity_category was silently skipped. Now falls back to identifier when it's an entity_id format. - Helper test: removed invalid `action` param (tool uses helper_id presence to decide create vs update), use ha_config_remove_helper for cleanup. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Some helper types (e.g., input_boolean) don't return entity_id in the WebSocket create result. Derive it from helper_type + result id so that wait_for_entity_registered and category application work. Test updated to handle the same fallback. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…helpers - apply_entity_category: add isinstance guard before .get() on error value, matching pattern in tools_config_helpers.py - helpers: replace three inline category constructions with shared apply_entity_category (create path, config-store-types update, standard update), consistent with automations/scripts Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
We're running 8 automation categories in production and use The scope fix for helpers — "helpers" as the registry key rather than |
sergeykad
left a comment
sergeykad
left a comment
There was a problem hiding this comment.
All review issues addressed. CI green.
🧪 Your changes are now in the dev channel!Your PR has been merged to master and is available for testing in the dev channel. Test your changes before the next stable release (biweekly Wednesday): Quick start# Run dev version
uvx ha-mcp-dev
# Check version
uvx ha-mcp-dev --versionDocker: docker pull ghcr.io/homeassistant-ai/ha-mcp:dev
docker run --rm -i \
-e HOMEASSISTANT_URL=http://your-ha:8123 \
-e HOMEASSISTANT_TOKEN=your_token \
ghcr.io/homeassistant-ai/ha-mcp:devFound an issue? Please open a new bug report and mention this PR for context. |
3 participants
What does this PR do?
Adds
categoryparameter to domain-specific config tools, building on #677's category CRUD foundation. This is the follow-up described in #702 (comment).Changes
ha_config_get_automation— now includescategoryin response when set:config/entity_registry/getha_config_set_automation— newcategoryparameter:categoryfrom config dict before REST API call (preventsextra keys not allowederror)config/entity_registry/updateafter successful creationha_config_get_script/ha_config_set_script— same pattern as automationsha_config_set_helper— addscategoryalongside existingarea_idandlabelsin the entity registry updateBackground
Categories are stored in the entity registry, not in automation/script YAML config. The HA REST API (
/api/config/automation/config/{id}) rejects unknown keys likecategory, which is why these tools need to:categoryfrom the config before sending to the REST APIconfig/entity_registry/updatecallThis follows the same pattern already used by
ha_set_entity(added in #677) andha_config_set_helper(forarea_id/labels).Closes #702
Type of change
Testing
uv run pytest)uv run ruff check)Checklist
🤖 Generated with Claude Code