ha-mcp-dev 7.9.0.dev752__tar.gz → 7.9.0.dev754__tar.gz

{ha_mcp_dev-7.9.0.dev752/src/ha_mcp_dev.egg-info → ha_mcp_dev-7.9.0.dev754}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: ha-mcp-dev
-Version: 7.9.0.dev752
+Version: 7.9.0.dev754
 Summary: Home Assistant MCP Server - Complete control of Home Assistant through MCP
 Author-email: Julien <github@qc-h.net>
 License: MIT

{ha_mcp_dev-7.9.0.dev752 → ha_mcp_dev-7.9.0.dev754}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "ha-mcp-dev"
-version = "7.9.0.dev752"
+version = "7.9.0.dev754"
 description = "Home Assistant MCP Server - Complete control of Home Assistant through MCP"
 readme = "README.md"
 requires-python = ">=3.13,<3.14"

{ha_mcp_dev-7.9.0.dev752 → ha_mcp_dev-7.9.0.dev754}/src/ha_mcp/config.py

@@ -155,6 +155,17 @@ class Settings(BaseSettings):
     # files. Disabled by default; only for YAML-only features with no UI/API path.
     enable_yaml_config_editing: bool = Field(False, alias="ENABLE_YAML_CONFIG_EDITING")
 
+    # Two-step confirmation for ha_config_set_yaml (#1720). When on (the
+    # default), the first edit call returns a unified diff preview plus a
+    # confirm token and writes NOTHING; the edit lands only when repeated
+    # with that token. Sub-toggle of enable_yaml_config_editing (nested
+    # beneath it in the UI). Default ON deliberately: the diff preview is
+    # what lets the calling agent catch collateral changes before they
+    # reach disk. Listed in BETA_FEATURE_FIELDS purely for the addon-mode
+    # override path; the master-off cascade forcing it False is moot
+    # because the yaml tool itself is unregistered then.
+    enable_yaml_edit_confirm: bool = Field(True, alias="ENABLE_YAML_EDIT_CONFIRM")
+
     # Per-key gates for ``automation`` / ``script`` / ``scene`` under
     # ``packages/*.yaml``. The custom component accepts these three
     # PACKAGES_ONLY_YAML_KEYS unconditionally; ha-mcp's UI exposes a
@@ -604,6 +615,7 @@ FEATURE_FLAG_FIELDS: tuple[FeatureFlagField, ...] = (
     # are name-disjoint per _validate_registries()).
     FeatureFlagField("enable_mandatory_bps", "ENABLE_MANDATORY_BPS", bool),
     FeatureFlagField("enable_yaml_config_editing", "ENABLE_YAML_CONFIG_EDITING", bool),
+    FeatureFlagField("enable_yaml_edit_confirm", "ENABLE_YAML_EDIT_CONFIRM", bool),
     # Per-key sub-gates beneath enable_yaml_config_editing. Nested in
     # the UI, dimmed when the parent is off. Also listed in
     # BETA_FEATURE_FIELDS so they follow the same master-gate +
@@ -660,6 +672,7 @@ _FEATURE_FLAG_INT_BOUNDS: dict[str, tuple[int, int]] = {
 # gate, never by the per-field iteration.
 BETA_FEATURE_FIELDS: tuple[str, ...] = (
     "enable_yaml_config_editing",
+    "enable_yaml_edit_confirm",  # Default-ON safety sub-toggle; see field comment.
     # Per-key sub-gates of enable_yaml_config_editing. Included here so
     # they ride the same master gate + addon-mode override path as the
     # other beta flags. Without this, the addon-mode short-circuit in

{ha_mcp_dev-7.9.0.dev752 → ha_mcp_dev-7.9.0.dev754}/src/ha_mcp/resources/skills-vendor/.claude-plugin/marketplace.json

@@ -2,7 +2,7 @@
   "name": "home-assistant-skills",
   "owner": {
     "name": "homeassistant-ai",
-    "email": ""
+    "email": "homeassistant-mcp@qc-h.net"
   },
   "metadata": {
     "description": "Agent skills for Home Assistant: best practices for automations, helpers, templates, device control, and dashboards",

{ha_mcp_dev-7.9.0.dev752 → ha_mcp_dev-7.9.0.dev754}/src/ha_mcp/resources/skills-vendor/AGENTS.md

@@ -30,6 +30,8 @@ description: >
 Constraints from CONTRIBUTING.md:
 - Max **500 lines** per SKILL.md
 - `metadata.version` must be `0` on new skills (do not edit manually)
+- `name` must match `[a-z0-9-]+` and be ≤64 characters
+- `description` frontmatter must be **≤1024 characters** (CI enforces this via `skills-ref validate`)
 - Reference files must be **one level deep** only (e.g. `references/example.yaml`)
 - Use **forward slashes** in all file paths
 - Optional subdirectories: `references/` (additional docs), `scripts/` (utility scripts), `assets/` (static resources)

{ha_mcp_dev-7.9.0.dev752 → ha_mcp_dev-7.9.0.dev754}/src/ha_mcp/resources/skills-vendor/CLAUDE.md

@@ -30,6 +30,8 @@ description: >
 Constraints from CONTRIBUTING.md:
 - Max **500 lines** per SKILL.md
 - `metadata.version` must be `0` on new skills (do not edit manually)
+- `name` must match `[a-z0-9-]+` and be ≤64 characters
+- `description` frontmatter must be **≤1024 characters** (CI enforces this via `skills-ref validate`)
 - Reference files must be **one level deep** only (e.g. `references/example.yaml`)
 - Use **forward slashes** in all file paths
 - Optional subdirectories: `references/` (additional docs), `scripts/` (utility scripts), `assets/` (static resources)

{ha_mcp_dev-7.9.0.dev752 → ha_mcp_dev-7.9.0.dev754}/src/ha_mcp/resources/skills-vendor/README.md

@@ -31,7 +31,7 @@ Run each command separately inside Claude Code:
 /plugin marketplace add homeassistant-ai/skills
 ```
 ```
-/plugin install home-assistant-skills@homeassistant-ai-skills
+/plugin install home-assistant-skills@home-assistant-skills
 ```
 
 Run `/reload-plugins` or restart Claude Code for the skill to take effect.
@@ -57,10 +57,12 @@ The `home-assistant-best-practices` skill includes:
 | `references/template-guidelines.md` | When to use templates, when to avoid them, and sensor best practices |
 | `references/yaml-only-integrations.md` | YAML-only integration types, post-edit actions (reload vs restart) |
 | `references/device-control.md` | Service calls, entity_id vs device_id, Zigbee buttons |
+| `references/scenes.md` | Scene authoring: config shape, snapshot/restore, snapshot-vs-script distinction |
 | `references/dashboard-guide.md` | Dashboard layout, view types, sections, custom cards, CSS styling |
 | `references/dashboard-cards.md` | Card type lookup and card-specific documentation |
 | `references/domain-docs.md` | Integration and domain documentation for service calls, entity attributes |
 | `references/examples.yaml` | Compound examples combining multiple best practices |
+| `references/appdaemon.md` | AppDaemon apps: when to use vs. native HA, app structure, service calls, scheduling, error handling, safe refactoring impact |
 
 ## Contributing
 

{ha_mcp_dev-7.9.0.dev752 → ha_mcp_dev-7.9.0.dev754}/src/ha_mcp/resources/skills-vendor/skills/home-assistant-best-practices/SKILL.md

@@ -1,27 +1,28 @@
 ---
 name: home-assistant-best-practices
 description: >
-  Best practices for HA automations, helpers, scripts, device controls, and dashboards.
+  Best practices for HA automations, helpers, scripts, controls, and dashboards.
 
   TRIGGER THIS SKILL WHEN:
-  - Creating/editing automations, scripts, scenes, or dashboards
+  - Creating or editing automations, scripts, scenes, or dashboards
   - Choosing between template sensors and built-in helpers
-  - Writing or restructuring triggers, conditions, or automation modes
-  - Setting up Zigbee button/remote automations (ZHA or Zigbee2MQTT)
+  - Restructuring triggers, conditions, or automation modes
+  - Setting up Zigbee button/remote automations
   - Renaming entities or migrating device_id to entity_id
-  - Configuring dashboard cards or picking helpers to feed them
-  - Looking up card types or domain-specific documentation
+  - Configuring dashboard cards or selecting helpers
+  - Looking up card types or domain docs
+  - Writing or reviewing AppDaemon apps
 
   SYMPTOMS:
-  - Agent uses Jinja2 templates where native conditions/triggers/helpers exist
+  - Agent uses Jinja2 templates where native options exist
   - Agent uses device_id instead of entity_id
-  - Agent modifies entity IDs without checking consumers
-  - Agent chooses wrong automation mode (e.g., single for motion lights)
-  - Agent hard-codes values or picks raw sensor over derived helper
-  - Agent edits `.storage/` files, writes raw YAML, or generates YAML snippets
-  - Agent tells user to edit configuration.yaml for UI-configured integrations
+  - Agent changes entity IDs without checking consumers
+  - Wrong automation mode
+  - Agent hard-codes values or uses raw sensor over helper
+  - Agent edits .storage, writes YAML, or generates YAML snippets
+  - Agent tells user to edit configuration.yaml for UI integrations
 metadata:
-  version: 5
+  version: 12
 ---
 
 # Home Assistant Best Practices
@@ -88,7 +89,7 @@ See `references/device-control.md#zigbee-buttonremote-patterns`.
 ## Critical Anti-Patterns
 
 | Anti-pattern | Use instead | Why | Reference |
-|---|---|---|---|
+|--------------|-------------|-----|-----------|
 | `condition: template` with `float > 25` | `condition: numeric_state` | Validated at load, not runtime | `references/automation-patterns.md#native-conditions` |
 | `wait_template: "{{ is_state(...) }}"` | `wait_for_trigger` with state trigger | Event-driven, not polling; waits for *change* (see `references/safe-refactoring.md#trigger-restructuring` for semantic differences) | `references/automation-patterns.md#wait-actions` |
 | `device_id` in triggers | `entity_id` (or `device_ieee` for ZHA) | device_id breaks on re-add | `references/device-control.md#entity-id-vs-device-id` |
@@ -108,6 +109,10 @@ See `references/device-control.md#zigbee-buttonremote-patterns`.
 | `vacuum.send_command` with vendor room IDs | `vacuum.clean_area` with HA `area_id` (if segments are mapped) | Uses native HA areas, works across integrations — but requires segment-to-area mapping in entity settings first | `references/device-control.md#vacuum-control` |
 | Using `color_temp` (mireds) in light service calls | Use `color_temp_kelvin` | The `color_temp` parameter was removed in 2026.3; only Kelvin is supported | `references/device-control.md#lights` |
 | Person/Device Tracker `entered_home`/`left_home` device triggers or `is_home`/`is_not_home` conditions | `state` trigger `to: home` / `to: not_home`, or `state` condition | These were removed in 2026.5 — state triggers and conditions are the correct replacements | `references/automation-patterns.md#presence-and-person-triggers-and-conditions-removed-in-20265` |
+| Registering callbacks or calling `self.turn_on()`/`self.get_state()` in `__init__()` | Register everything in `initialize()` | Plugin connection not established during `__init__` — calls fail silently | `references/appdaemon.md#app-structure-and-lifecycle` |
+| Calling `run_in` on repeated triggers without cancelling the previous handle | `cancel_timer(self._off_handle)` before each new `run_in` | Every trigger stacks an independent timer — devices toggle unpredictably | `references/appdaemon.md#scheduling-and-timers` |
+| Storing persistent state in instance variables | Use HA `input_number`, `input_boolean`, or `input_text` helpers | Instance variables reset on app reload or daemon restart | `references/appdaemon.md#state-management-and-inter-app-communication` |
+| Hardcoding entity IDs inside the class body | Pass entity IDs via `self.args` in `apps.yaml` | Hardcoded IDs prevent reuse and require code edits per installation | `references/appdaemon.md#appsyaml-configuration` |
 
 ---
 
@@ -118,12 +123,14 @@ Read these when you need detailed information:
 | File | When to read | Key sections |
 |------|--------------|--------------|
 | `references/safe-refactoring.md` | Renaming entities, replacing helpers, restructuring automations, or any modification to existing config | `#universal-workflow`, `#entity-renames`, `#helper-replacements`, `#trigger-restructuring`, `#config-entry-data--blind-spots-for-entity-registry-renames`, `#storage-mode-dashboards-storagelovelace` |
-| `references/automation-patterns.md` | Writing triggers, conditions, waits, or choosing automation modes; disabling automations | `#native-conditions`, `#trigger-types`, `#wait-actions`, `#automation-modes`, `#continue-on-error`, `#repeat-actions`, `#ifthen-vs-choose`, `#trigger-ids`, `#disabling-automations` |
-| `references/helper-selection.md` | Deciding whether to use a built-in helper vs template sensor | `#menu-based-helpers`, `#numeric-aggregation`, `#rate-and-change`, `#time-based-tracking`, `#counting-and-timing`, `#scheduling`, `#entity-grouping`, `#data-smoothing`, `#random-values`, `#climate-control`, `#domain-conversion`, `#template-helpers`, `#decision-matrix` |
+| `references/automation-patterns.md` | Writing triggers, conditions, waits, variables, or choosing automation modes; capturing action responses; documenting/annotating steps; disabling automations | `#native-conditions`, `#trigger-types`, `#wait-actions`, `#automation-modes`, `#continue-on-error`, `#stopping-a-sequence`, `#variables`, `#capturing-action-responses`, `#repeat-actions`, `#ifthen-vs-choose`, `#parallel-actions`, `#trigger-ids`, `#documenting-automations--scripts`, `#disabling-automations` |
+| `references/helper-selection.md` | Deciding whether to use a built-in helper vs template sensor | `#how-helpers-are-created`, `#menu-based-helpers`, `#numeric-aggregation`, `#rate-and-change`, `#time-based-tracking`, `#counting-and-timing`, `#scheduling`, `#entity-grouping`, `#probabilistic-inference`, `#data-smoothing`, `#random-values`, `#climate-control`, `#domain-conversion`, `#template-helpers`, `#decision-matrix` |
 | `references/template-guidelines.md` | Confirming templates ARE appropriate for a use case | `#when-templates-are-appropriate`, `#when-to-avoid-templates`, `#template-sensor-best-practices`, `#common-patterns`, `#error-handling` |
 | `references/yaml-only-integrations.md` | Creating or editing YAML-only integrations that have no config flow (e.g. `command_line`, platform-based `mqtt`, `rest`) | `#yaml-only-integration-types`, `#post-edit-actions` |
 | `references/device-control.md` | Writing service calls, Zigbee button automations, or using target: | `#entity-id-vs-device-id`, `#service-calls-best-practices`, `#zigbee-buttonremote-patterns`, `#domain-specific-patterns` |
-| `references/dashboard-guide.md` | Designing or modifying Lovelace dashboards — layout, view types, sections, custom cards, CSS styling, HACS | `#dashboard-structure`, `#view-types`, `#built-in-cards`, `#features`, `#custom-cards`, `#css-styling`, `#common-pitfalls` |
+| `references/scenes.md` | Authoring or activating scenes; snapshot/restore patterns; snapshot-vs-script distinction | `#scene-config-shape`, `#activating-a-scene`, `#snapshot--restore-scenecreate`, `#apply-states-without-storing-sceneapply` |
+| `references/dashboard-guide.md` | Designing or modifying Lovelace dashboards — layout, view types, strategies, sections, cards, badges, CSS styling, HACS | `#dashboard-structure`, `#view-types`, `#dashboard-strategies`, `#built-in-cards`, `#features`, `#badges`, `#custom-cards`, `#css-styling`, `#common-pitfalls` |
 | `references/dashboard-cards.md` | Looking up available card types or fetching card-specific documentation | — |
 | `references/domain-docs.md` | Looking up integration or domain documentation for service calls, entity attributes, or configuration | — |
 | `references/examples.yaml` | Need compound examples combining multiple best practices | — |
+| `references/appdaemon.md` | AppDaemon apps: when to use vs. native HA, app structure, service calls, scheduling, error handling, safe refactoring impact | — |