ha-mcp-dev 8.5.0.dev2721__tar.gz → 8.5.0.dev2722__tar.gz

{ha_mcp_dev-8.5.0.dev2721/src/ha_mcp_dev.egg-info → ha_mcp_dev-8.5.0.dev2722}/PKG-INFO

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

{ha_mcp_dev-8.5.0.dev2721 → ha_mcp_dev-8.5.0.dev2722}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "ha-mcp-dev"
-version = "8.5.0.dev2721"
+version = "8.5.0.dev2722"
 description = "Home Assistant MCP Server - Complete control of Home Assistant through MCP"
 readme = "README.md"
 # Upper bound widened to <3.15 so the package installs on Home Assistant's

{ha_mcp_dev-8.5.0.dev2721 → ha_mcp_dev-8.5.0.dev2722}/src/ha_mcp/resources/skills-vendor/.claude-plugin/marketplace.json

@@ -6,7 +6,7 @@
   },
   "metadata": {
     "description": "Agent skills for Home Assistant: best practices for automations, helpers, templates, scenes, blueprints, device control, dashboards, AppDaemon, and backups",
-    "version": "0.31.0"
+    "version": "0.34.0"
   },
   "plugins": [
     {

{ha_mcp_dev-8.5.0.dev2721 → ha_mcp_dev-8.5.0.dev2722}/src/ha_mcp/resources/skills-vendor/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "home-assistant-skills",
   "description": "Agent skills for Home Assistant: best practices for automations, helpers, templates, scenes, blueprints, device control, dashboards, AppDaemon, and backups.",
-  "version": "0.31.0",
+  "version": "0.34.0",
   "repository": "https://github.com/homeassistant-ai/skills",
   "license": "MIT"
 }

{ha_mcp_dev-8.5.0.dev2721 → ha_mcp_dev-8.5.0.dev2722}/src/ha_mcp/resources/skills-vendor/README.md

@@ -91,7 +91,7 @@ The `home-assistant-best-practices` skill includes:
 | File | Purpose |
 |------|---------|
 | [`SKILL.md`](skills/home-assistant-best-practices/SKILL.md) | Decision workflow, anti-pattern table, and pointers to the reference files below |
-| [`references/safe-refactoring.md`](skills/home-assistant-best-practices/references/safe-refactoring.md) | Safe workflow for renaming entities, replacing helpers, restructuring automations; config-entry and storage-dashboard blind spots |
+| [`references/safe-refactoring.md`](skills/home-assistant-best-practices/references/safe-refactoring.md) | Safe workflow for renaming entities and their display names, replacing helpers, restructuring automations; display-name override, config-entry, and storage-dashboard blind spots |
 | [`references/automation-patterns.md`](skills/home-assistant-best-practices/references/automation-patterns.md) | Purpose-specific and native triggers/conditions, waits, variables, automation modes, control flow (choose, repeat, parallel), disabling automations |
 | [`references/helper-selection.md`](skills/home-assistant-best-practices/references/helper-selection.md) | Built-in helpers vs template sensors (with decision matrix) |
 | [`references/template-guidelines.md`](skills/home-assistant-best-practices/references/template-guidelines.md) | When to use templates, when to avoid them, template sensor best practices, reusable `custom_templates` macros |

{ha_mcp_dev-8.5.0.dev2721 → ha_mcp_dev-8.5.0.dev2722}/src/ha_mcp/resources/skills-vendor/skills/home-assistant-best-practices/SKILL.md

@@ -23,7 +23,7 @@ description: >
   - Existing state changed with no recovery path
   - Jinja copy-pasted between templates
 metadata:
-  version: "31"
+  version: "34"
 ---
 
 # Home Assistant Best Practices
@@ -36,7 +36,7 @@ Follow this sequence when creating any automation:
 
 ### 0. Gate: modifying existing config?
 
-If your change affects entity IDs or cross-component references — renaming entities, replacing template sensors with helpers, converting device triggers, or restructuring automations — read [safe-refactoring](references/safe-refactoring.md) first. That reference covers impact analysis, device-sibling discovery, and post-change verification. Complete its workflow before proceeding.
+If your change affects entity IDs, display names, or cross-component references — renaming entities or devices, replacing template sensors with helpers, converting device triggers, or restructuring automations — read [safe-refactoring](references/safe-refactoring.md) first. That reference covers impact analysis, device-sibling discovery, display-name overrides, and post-change verification. Complete its workflow before proceeding.
 
 Steps 1-5 below apply to new config or pattern evaluation.
 
@@ -134,7 +134,7 @@ Read these when you need detailed information:
 
 | File | When to read |
 |------|--------------|
-| [safe-refactoring](references/safe-refactoring.md) | Renaming entities, replacing helpers, restructuring automations, or any modification to existing config |
+| [safe-refactoring](references/safe-refactoring.md) | Renaming entities or their display names, replacing helpers, restructuring automations, or any modification to existing config |
 | [automation-patterns](references/automation-patterns.md) | Writing triggers, conditions, waits, variables, or choosing automation modes; capturing action responses; documenting/annotating steps; disabling automations; `continue_on_error`, stopping a sequence, repeat, if/then vs choose, parallel, trigger IDs |
 | [helper-selection](references/helper-selection.md) | Deciding whether to use a built-in helper vs template sensor — aggregation, rate of change, thresholds, time-in-state, counting/timing, scheduling, grouping, probabilistic inference, smoothing, climate, domain conversion, decision matrix |
 | [template-guidelines](references/template-guidelines.md) | Confirming templates ARE appropriate for a use case; sharing Jinja logic between templates with `custom_templates` macros |

{ha_mcp_dev-8.5.0.dev2721 → ha_mcp_dev-8.5.0.dev2722}/src/ha_mcp/resources/skills-vendor/skills/home-assistant-best-practices/references/dashboard-guide.md

@@ -386,7 +386,7 @@ Use the HA dashboard resource API to convert inline code to a hosted URL, then r
 ### Custom Card Workflow
 
 1. Write the card JavaScript class (see Minimal Custom Card above)
-2. Register it as a dashboard resource via the HA REST API (`/api/config/lovelace/resources`) with `resource_type: "module"`
+2. Register it as a dashboard resource: `lovelace/resources/create` over WebSocket with `res_type: "module"` and `url`, or the Resources tab under Settings > Dashboards
 3. Use the card in your dashboard config with the `custom:` prefix
 
 ```json
@@ -397,6 +397,12 @@ Use the HA dashboard resource API to convert inline code to a hosted URL, then r
 }
 ```
 
+**Resource caching:** `/local/` is served with `public, max-age=2678400`, a 31-day cache, in desktop browsers as well as the Companion app. Editing a registered `.js` file in place leaves clients on the old copy until it expires or the client clears its cache.
+
+- HACS versions the plugin resource URLs it manages in storage (`?hacstag=<installed version>`), so a card installed through HACS is re-fetched on update. With YAML-mode resources HACS cannot update the URL, so that version string is yours to bump.
+- A resource registered by hand needs the same: bump a version query string on the resource `url`, `/local/quick-status-card.js?v=2.0.0`. Only a changed URL forces every client to re-fetch, so renaming the element tag does not help; the cached module still registers the old tag name.
+- A client already holding a stale copy needs a client-side fix: hard refresh, clear site data for the HA origin, or **Settings** > **Reset frontend cache** in the Companion app.
+
 ---
 
 ## CSS Styling
@@ -541,6 +547,7 @@ Custom cards predating sections views (early 2024) that haven't updated since ar
 | Map card markers show entity-name initials instead of values | `label_mode` is a **per-entity** option, not card-level: `"entities": [{"entity": "sensor.x", "label_mode": "state"}]` |
 | Cards lay out differently in spanned sections | A spanned section's grid widens with it (24 columns in a `column_span: 2` section) but is 12 when collapsed — see [Card Sizing and Responsive Layout](#card-sizing-and-responsive-layout) |
 | Map entities missing from map card | Only entities with `latitude`/`longitude` attributes are plotted — use template sensors carrying coordinates as attributes for fixed locations |
+| Custom card still stale after its file was updated | `/local/` is cached for 31 days: bump a version query string on the resource URL (`/local/my-card.js?v=2.0.0`), see [Custom Card Workflow](#custom-card-workflow). On a client already holding the old copy: hard refresh or **Settings** > **Reset frontend cache** in the Companion app |
 
 ---
 

{ha_mcp_dev-8.5.0.dev2721 → ha_mcp_dev-8.5.0.dev2722}/src/ha_mcp/resources/skills-vendor/skills/home-assistant-best-practices/references/safe-refactoring.md

@@ -23,7 +23,7 @@ Answer three questions before touching anything:
 
 1. **What changes?** Entity ID, automation structure, sensor type, or trigger semantics.
 2. **What sibling entities share the same device?** Query the device to list every entity it owns (battery sensor, update entity, diagnostic button). Plan changes for all siblings together.
-   - Query the device via the HA REST API (`GET /api/states/<entity_id>`) or inspect Settings > Devices.
+   - List the device's entities: `POST /api/template` with `{"template": "{{ device_entities(device_id('sensor.x')) }}"}`, or `config/entity_registry/list` over WebSocket (it takes no filter and returns every entry; keep the ones whose `device_id` matches), or inspect Settings > Devices. `GET /api/states/<entity_id>` returns one entity's state with no device field.
 3. **Rename one entity or all device entities?** Devices bundle 2-6 entities. Renaming the primary but leaving siblings with the old naming scheme creates inconsistency.
 
 ### Step 2: Search ALL consumers
@@ -92,6 +92,20 @@ Dashboard cards reference entities in multiple places. Search all of these:
 - Template card Jinja2 blocks
 - `views[n].badges` — badge rows per view; badges are siblings of the cards array, not children, so any card-focused search will miss them — always search the full dashboard config
 - `views[n].header.card` — sections view only (HA 2025.3+); the view header accepts a Markdown card that supports Jinja2 templates and may contain entity references; it is a sibling of the cards array and is not reachable via card-focused search
+- `views[n].footer.card`: sections view only (HA 2026.3+); the view footer accepts a card that may contain entity references; like the header it is a sibling of the cards array and is not reachable via card-focused search
+
+**Display names are a separate field (Step 3):**
+
+`entity_id` and display name are stored independently, and renaming in the UI writes a *user override* rather than changing the value the integration supplied. The registry keeps both:
+
+| Registry | Integration-supplied | User override |
+|---|---|---|
+| entity | `original_name` | `name` |
+| device | `name` | `name_by_user` |
+
+The override takes precedence for as long as it is set. If the integration later reports a corrected name — the device is renamed in its vendor app, a firmware update fixes a typo — the new value lands in the integration-supplied field and never reaches the UI, so the stale override looks like an integration bug to whoever finds it later.
+
+Rename at the source when the source is what is wrong, and reserve the override for names HA itself owns. To annotate without shadowing — marking an entity unused, grouping for a dashboard — use labels or areas, which live in their own fields and survive a source-side rename. Clearing the override restores the inherited name.
 
 ---
 

{ha_mcp_dev-8.5.0.dev2721 → ha_mcp_dev-8.5.0.dev2722/src/ha_mcp_dev.egg-info}/PKG-INFO

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