ha-mcp-dev 8.4.3.dev2588__tar.gz → 8.4.3.dev2592__tar.gz

{ha_mcp_dev-8.4.3.dev2588/src/ha_mcp_dev.egg-info → ha_mcp_dev-8.4.3.dev2592}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: ha-mcp-dev
-Version: 8.4.3.dev2588
+Version: 8.4.3.dev2592
 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.4.3.dev2588 → ha_mcp_dev-8.4.3.dev2592}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "ha-mcp-dev"
-version = "8.4.3.dev2588"
+version = "8.4.3.dev2592"
 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.4.3.dev2588 → ha_mcp_dev-8.4.3.dev2592}/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.26.0"
+    "version": "0.31.0"
   },
   "plugins": [
     {

{ha_mcp_dev-8.4.3.dev2588 → ha_mcp_dev-8.4.3.dev2592}/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.26.0",
+  "version": "0.31.0",
   "repository": "https://github.com/homeassistant-ai/skills",
   "license": "MIT"
 }

{ha_mcp_dev-8.4.3.dev2588 → ha_mcp_dev-8.4.3.dev2592}/src/ha_mcp/resources/skills-vendor/.github/ISSUE_TEMPLATE/skill-rca.md

@@ -29,9 +29,13 @@ INSTRUCTIONS FOR THE AGENT
 A skill in this repository misled you, and your user saw the result.
 
 BEFORE FILING:
-- Search existing issues for the same skill and failure. If a matching
-  issue exists, react with thumbs-up or comment with additional context.
-  Open a new issue only when the failure is unreported.
+- Do not re-run any step that changed the user's config. Decide from
+  evidence you already have whether the failure is HA's or your tool's:
+  what your tool sent against what HA stored, HA's own log line, the state
+  the entity actually holds, and the core file or docs page that would
+  produce the behaviour. If the evidence points at the tool, there is no
+  skill gap: do not file. If you cannot tell, say so in 3b and file only
+  if the skill's guidance would still have changed what you did.
 - Did the skill actually load? If it never triggered, this is a triggering
   failure, not a content failure: write "Skill did not trigger" in 3a, keep
   the user's request verbatim apart from redactions (it is the prompt that
@@ -39,6 +43,16 @@ BEFORE FILING:
 - Did you follow the skill's guidance? If you skipped guidance that would
   have prevented the failure, that is not a skill bug. Report only what the
   skill got wrong or left out.
+- Did your fix break a rule? A step you marked Success that does what the
+  Critical Anti-Patterns table in the skill's SKILL.md forbids is not a
+  fix. The test is what was written where, not which tool wrote it. Mark
+  that row Failure, keep it in this report, and in 3c give the supported
+  path or say you did not find one.
+- One failure per report. If your timeline has two unrelated [GAP] rows,
+  file two reports.
+- Search existing issues for the same skill and failure. If a matching
+  issue exists, react with thumbs-up or comment with additional context.
+  Open a new issue only when the failure is unreported.
 - Redact before filing: tokens, URLs, IP addresses, email addresses, names,
   and anything from the user's setup the public need not see — replace each
   with [REDACTED] and keep the wording otherwise. Show the user the finished
@@ -62,6 +76,8 @@ List each action you took. For each, record what you did, what resulted, and its
 
 Mark the first failing step with **[GAP]** in the `Status` column.
 
+One change per row. If one step changed several things, keep them in one row and write "not attributed" in Result.
+
 | Step | Action | Result | Status |
 |------|--------|--------|-----|
 | 1 | | | |
@@ -92,8 +108,13 @@ and tie it to the skill content you quoted in 3a.
 ### 3c. What should the skill have told you instead?
 
 <!--
-Describe the guidance the skill should have included
-to prevent this failure.
+State the HA behaviour the skill should carry, not the fix that worked for
+your setup. Cite the core file or docs page for each claim; an uncited
+claim is a hypothesis, so label it as one. Details of your installation
+stay out unless the behaviour is specific to that integration
+(CONTRIBUTING.md, Guiding Principles: skills apply to any HA installation).
+If you cannot phrase it without them, write "No skill gap:
+instance-specific" here and tell the user before filing.
 -->
 
 ## 4. Impact

{ha_mcp_dev-8.4.3.dev2588 → ha_mcp_dev-8.4.3.dev2592}/src/ha_mcp/resources/skills-vendor/README.md

@@ -104,7 +104,7 @@ The `home-assistant-best-practices` skill includes:
 | [`references/examples.yaml`](skills/home-assistant-best-practices/references/examples.yaml) | Compound examples combining multiple best practices |
 | [`references/appdaemon.md`](skills/home-assistant-best-practices/references/appdaemon.md) | AppDaemon apps: when to use vs. native HA, app structure, actions, scheduling, error handling, safe refactoring impact |
 | [`references/blueprint-guide.md`](skills/home-assistant-best-practices/references/blueprint-guide.md) | Blueprint authoring: metadata & `source_url`, inputs & selectors, `target` vs `entity`, defaults, `!input` templating, versioning |
-| [`references/backups.md`](skills/home-assistant-best-practices/references/backups.md) | Full instance backups vs rolling one object back, when an operation needs a backup first, what an archive contains, encryption keys, restore verification, backup deletion |
+| [`references/backups.md`](skills/home-assistant-best-practices/references/backups.md) | Full instance backups vs rolling one object back, when an operation needs a backup first, what an archive contains, encryption keys, restore verification, backup deletion, why a git config repo does not replace a full backup |
 
 ## Contributing
 

{ha_mcp_dev-8.4.3.dev2588 → ha_mcp_dev-8.4.3.dev2592}/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: "26"
+  version: "31"
 ---
 
 # Home Assistant Best Practices
@@ -100,6 +100,7 @@ See [device-control #buttonremote-patterns](references/device-control.md#buttonr
 | `condition: template` with `float > 25` | `condition: numeric_state` | Validated at load, not runtime | [automation-patterns #native-conditions](references/automation-patterns.md#native-conditions) |
 | `wait_template: "{{ is_state(...) }}"` | `wait_for_trigger` with state trigger | Event-driven, not polling; waits for *change* (see [safe-refactoring #trigger-restructuring](references/safe-refactoring.md#trigger-restructuring) for semantic differences) | [automation-patterns #wait-actions](references/automation-patterns.md#wait-actions) |
 | `device_id` in triggers | `entity_id` (or `device_ieee` for ZHA) | device_id breaks on re-add | [device-control #entity-id-vs-device-id](references/device-control.md#entity-id-vs-device-id) |
+| `numeric_state` trigger driving a costly action, unguarded | Condition rejecting `unavailable`/`unknown` in `trigger.from_state` | A restart or blip re-arms the trigger, so an unchanged value fires with no crossing (the guard also drops real crossings) | [automation-patterns #unavailable-arms-a-numeric-state-trigger](references/automation-patterns.md#unavailable-arms-a-numeric-state-trigger) |
 | `mode: single` for motion lights | `mode: restart` | Re-triggers must reset the timer | [automation-patterns #automation-modes](references/automation-patterns.md#automation-modes) |
 | `enabled: false` as a top-level key in `automations.yaml` | `automation.turn_off` (temporary) or entity registry disable (permanent) | Not a valid top-level key — rejected during schema validation; automation loads as `unavailable` | [automation-patterns #disabling-automations](references/automation-patterns.md#disabling-automations) |
 | Template sensor for sum/mean | `min_max` helper | Declarative, handles unavailable states | [helper-selection #numeric-aggregation](references/helper-selection.md#numeric-aggregation) |
@@ -146,4 +147,4 @@ Read these when you need detailed information:
 | [examples.yaml](references/examples.yaml) | Need compound examples combining multiple best practices |
 | [appdaemon](references/appdaemon.md) | AppDaemon apps: when to use vs. native HA, app structure, actions, scheduling, error handling, safe refactoring impact |
 | [blueprint-guide](references/blueprint-guide.md) | Authoring reusable blueprints: metadata & `source_url`, inputs & selectors, `target` vs `entity`, defaults, input sections, `!input` templating, versioning |
-| [backups](references/backups.md) | Deciding whether an operation needs a backup first; choosing between a full restore, a partial restore, and rolling one object back; what an archive actually contains; encryption keys and the emergency kit; restore verification; what HA does and does not protect when deleting a backup |
+| [backups](references/backups.md) | Deciding whether an operation needs a backup first; choosing between a full restore, a partial restore, and rolling one object back; what an archive actually contains; encryption keys and the emergency kit; restore verification; what HA does and does not protect when deleting a backup; whether a git config repo replaces a full backup |

{ha_mcp_dev-8.4.3.dev2588 → ha_mcp_dev-8.4.3.dev2592}/src/ha_mcp/resources/skills-vendor/skills/home-assistant-best-practices/references/automation-patterns.md

@@ -276,7 +276,13 @@ conditions:
 | `climate.target_temperature` (condition) | `climate.is_target_temperature` |
 | `climate.target_humidity` (condition) | `climate.is_target_humidity` |
 
-**Discovering what exists:** every purpose-specific trigger and condition (and every action) has a dedicated documentation page covering its config shape, options, and examples — fetch it on demand instead of guessing keys; see [domain-docs #fetching-trigger-condition-and-action-docs](domain-docs.md#fetching-trigger-condition-and-action-docs). The trees span 50+ domains (~190 trigger and ~150 condition pages, generic types included): battery, motion, occupancy, door/window/gate/garage_door, climate, media_player, sun, timer, schedule, vacuum, lawn_mower, zone, event, vibration, moon, and more. The catalog grows every release — 2026.7 added the sun family (`sun.dawn`, `sun.dusk`, `sun.solar_noon`, `sun.solar_midnight`, elevation triggers); 2026.8 added the moon family (`moon.phase_changed` trigger; `moon.is_phase` / `moon.is_waning` / `moon.is_waxing` conditions) and the vibration family (`vibration.detected` / `vibration.cleared` triggers; `vibration.is_detected` / `vibration.is_not_detected` conditions) — both are new in 2026.8, so don't emit them for an instance on 2026.7. Check the doc tree rather than this list when a domain you need isn't named here.
+**Discovering what exists:** every purpose-specific trigger and condition (and every action) has a dedicated documentation page covering its config shape, options, and examples — fetch it on demand instead of guessing keys; see [domain-docs #fetching-trigger-condition-and-action-docs](domain-docs.md#fetching-trigger-condition-and-action-docs). The trees span 50+ domains (~190 trigger and ~150 condition pages, generic types included): battery, motion, occupancy, door/window/gate/garage_door, climate, media_player, sun, timer, schedule, vacuum, lawn_mower, zone, event, vibration, moon, and more. The catalog grows every release, so check the doc tree rather than this list when a domain you need isn't named here.
+
+| Version | Added to the catalog |
+|---|---|
+| 2026.7 | Sun family: `sun.sunrise`, `sun.sunset`, `sun.dawn`, `sun.dusk`, `sun.solar_noon`, `sun.solar_midnight`, elevation triggers |
+| 2026.8 | Moon family (`moon.phase_changed` trigger; `moon.is_phase` / `moon.is_waning` / `moon.is_waxing` conditions) and vibration family (`vibration.detected` / `vibration.cleared` triggers; `vibration.is_detected` / `vibration.is_not_detected` conditions). Do not emit either on 2026.7 |
+| 2026.9 | Sun family again: `sun.golden_hour_started` / `_ended` and `sun.blue_hour_started` / `_ended`, each taking `options.period`: `any` (default) / `morning` / `evening`, plus `sun.midnight_sun_started` / `_ended` and `sun.polar_night_started` / `_ended` for polar latitudes; conditions `sun.is_golden_hour` / `sun.is_blue_hour` with the same `options.period`, and `sun.is_midnight_sun` / `sun.is_polar_night` |
 
 Since 2026.7, `options.for` durations on **conditions** are primed from recorded history, so a freshly created or reloaded condition does not restart its duration clock from zero. Trigger `for:` clocks still reset as described in [`for:` duration resets](#for-duration-resets-on-restart-and-on-unavailable).
 
@@ -389,6 +395,48 @@ that was a restart re-stamp, not a real state change.
 > history, so those don't restart from zero on creation/reload. The resets described here still
 > apply to trigger `for:` clauses and to `last_changed`-based template math.
 
+### `unavailable` arms a numeric state trigger
+
+The trigger tracks each entity as *armed* or not, judged on the **new** state alone. An entity
+becomes armed when it evaluates as **not matching**, and a fire needs an armed entity to then
+match. On the plain-state path, `unavailable` and `unknown` count as not matching rather than
+raising, so they arm the trigger instead of being ignored. Any *other* non-numeric value (a text
+state such as `idle`, or an entity absent from the state machine) raises instead, which logs a
+warning and returns, leaving the armed flag as it was. A text state therefore neither arms nor
+disarms: `unavailable`, then `idle`, then a matching number still fires.
+
+Two consequences, neither involving a threshold being crossed:
+
+- **After a restart.** The trigger builds its armed set when it attaches, and HA writes
+  `unavailable` for every registry entity that has no state yet, so the entity is armed. Its first
+  real reading past the threshold then fires.
+- **After a blip.** An entity that flicks to `unavailable` and back is re-armed, so the same
+  unchanged value fires again.
+
+`for:` does not prevent either case. The re-armed entity matches, the unchanged value keeps
+matching for the whole window, so the trigger fires late rather than not at all.
+
+**A guard costs real crossings.** Rejecting a non-numeric `from_state` also drops genuine
+crossings that passed through `unavailable` (1400 to `unavailable` to 1600), and with `for:` a blip
+inside the window cancels the timer and re-arms, so that crossing never fires at all. Guard only
+where a false fire costs more than a missed one, such as switching a high-power load. As with
+[`trigger.event`](#event-trigger), `trigger.from_state` is `LoggingUndefined` for non-state
+triggers, so short-circuit on `trigger.platform` first:
+
+```yaml
+# WRONG — raises UndefinedError when a non-state trigger fires the same automation
+conditions:
+  - "{{ trigger.from_state.state not in ['unavailable', 'unknown'] }}"
+
+# RIGHT — platform check first; is_number also rejects text states such as `idle`
+conditions:
+  - condition: template
+    value_template: >
+      {{ trigger.platform == 'numeric_state'
+         and trigger.from_state is not none
+         and is_number(trigger.from_state.state) }}
+```
+
 ### Time Trigger
 
 Fires at specific times.

{ha_mcp_dev-8.4.3.dev2588 → ha_mcp_dev-8.4.3.dev2592}/src/ha_mcp/resources/skills-vendor/skills/home-assistant-best-practices/references/backups.md

@@ -68,10 +68,11 @@ The test is reversibility, not how risky something feels: **back up before an op
 
 "It's just an action" is not a reversibility argument — the inverse depends on the action and the target, and a reversible state change is not always a reversible event.
 
-Two things this test depends on:
+Three things this test depends on:
 
 - **Timing is the whole point.** A backup taken *after* the destructive step captures the damage. It must precede the operation.
 - **An existing schedule does not substitute.** On an instance with nightly automatic backups, the newest one can be almost a day stale — fine for reversible edits, not for an irreversible operation about to run now.
+- **A git config repo does not substitute.** A `/config` directory tracked in git conventionally excludes the recorder database, along with `.storage` and `secrets.yaml`, which carry credentials and long-lived tokens in cleartext. Such a repo holds tracked files only, and the irreversible operations above destroy registry, config-entry, or install state that it does not hold. A repo that does track `.storage` carries those credentials into every clone, so it must not go anywhere the user has not chosen, and writing `.storage` back over a running instance is a direct edit of HA's internal state rather than a restore.
 
 ## What a Full Backup Contains
 

{ha_mcp_dev-8.4.3.dev2588 → ha_mcp_dev-8.4.3.dev2592}/src/ha_mcp/resources/skills-vendor/skills/home-assistant-best-practices/references/dashboard-guide.md

@@ -31,6 +31,7 @@ Patterns and decisions for designing Home Assistant Lovelace dashboards.
   "title": "My Home",
   "icon": "mdi:home",
   "config": {
+    "background": {"image": "/local/background.jpg", "opacity": 30, "size": "cover"},
     "views": [
       {
         "title": "Overview",
@@ -88,7 +89,7 @@ Section `title` is soft-deprecated (frontend source marks it `@deprecated Use he
 }
 ```
 
-`background.image` is a plain path or media-source reference (the `url(...)` wrapper belongs only to the legacy string form of `background`); `opacity` is an integer 0–100. Badges also accept full objects: `{"type": "entity", "entity": "person.jane", "show_name": true, "color": "accent", "visibility": [...]}`.
+`background.image` is a plain path or media-source reference (the `url(...)` wrapper belongs only to the legacy string form of `background`); `opacity` is an integer 0–100. The same shape works at dashboard level, next to `views`, and each view that sets its own `background` overrides it. Badges also accept full objects: `{"type": "entity", "entity": "person.jane", "show_name": true, "color": "accent", "visibility": [...]}`.
 
 A `sections` view also supports a `header` (a markdown card plus badge positioning) and a `footer`:
 
@@ -243,8 +244,8 @@ Quick controls available on tile, area, humidifier, and thermostat cards.
 
 | Domain | Feature types |
 |--------|--------------|
-| Climate | `climate-hvac-modes`, `climate-fan-modes`, `climate-preset-modes`, `climate-swing-modes`, `climate-swing-horizontal-modes`, `target-temperature`, `target-humidity` |
-| Light | `light-brightness`, `light-color-temp`, `light-color-favorites` |
+| Climate | `climate-hvac-modes`, `climate-fan-modes`, `climate-preset-modes`, `climate-swing-modes`, `climate-swing-horizontal-modes`, `target-temperature`, `target-humidity` (humidifier entities, and climate entities that support it since 2026.9) |
+| Light | `light-brightness`, `light-color-temp`, `light-color-favorites`, `light-effect` (`effects:` filter list) |
 | Cover/Valve | `cover-open-close`, `cover-position`, `cover-position-favorite`, `cover-tilt`, `cover-tilt-position`, `cover-tilt-favorite`, `valve-open-close`, `valve-position`, `valve-position-favorite` |
 | Fan | `fan-speed`, `fan-preset-modes`, `fan-direction`, `fan-oscillate` |
 | Media | `media-player-playback` (configurable `controls`), `media-player-volume-slider`, `media-player-volume-buttons`, `media-player-source`, `media-player-sound-mode` |
@@ -252,7 +253,7 @@ Quick controls available on tile, area, humidifier, and thermostat cards.
 | Generic display | `trend-graph` (history sparkline; `hours_to_show`), `bar-gauge` (`min`/`max`) |
 | Generic control | `toggle`, `button` (run an action), `numeric-input` (`style`: `"buttons"`/`"slider"`), `select-options`, `counter-actions`, `date-set` |
 | Area card | `area-controls` |
-| Domain-specific | `alarm-modes`, `lock-commands`, `lock-open-door`, `vacuum-commands`, `lawn-mower-commands`, `humidifier-modes`, `humidifier-toggle`, `update-actions`, `water-heater-operation-modes` |
+| Domain-specific | `alarm-modes`, `lock-commands`, `lock-open-door`, `vacuum-commands`, `vacuum-fan-speed` (`fan_speeds:` filter list), `lawn-mower-commands`, `humidifier-modes`, `humidifier-toggle`, `update-actions`, `water-heater-operation-modes` |
 
 Mode-list features accept `style`: `"dropdown"` or `"icons"`. Tile cards also support `features_position`: `"bottom"` (default) or `"inline"`.
 
@@ -552,7 +553,7 @@ Custom cards predating sections views (early 2024) that haven't updated since ar
 - Use **area** cards with navigation for hierarchical organization
 - Start sections with **heading** cards (`title`/`subtitle` styles); subtitle headings work well for inline caveats
 
-### Recent Dashboard Features (2026.2–2026.6)
+### Recent Dashboard Features (2026.2–2026.9)
 
 | Feature | Version | Details |
 |---------|---------|---------|
@@ -565,6 +566,10 @@ Custom cards predating sections views (early 2024) that haven't updated since ar
 | **Media player tile features** | 2026.5 | `media-player-source`, `media-player-sound-mode`, configurable playback `controls` |
 | **Weather forecast features** | 2026.6 | `temperature-forecast`, `precipitation-forecast` tile features |
 | **Per-entity graph color** | 2026.6 | `color` on each entity of `history-graph` / `statistics-graph` |
+| **Light effect feature** | 2026.9 | `light-effect` tile feature, for lights that report effects |
+| **Vacuum fan speed feature** | 2026.9 | `vacuum-fan-speed` tile feature |
+| **Climate target humidity** | 2026.9 | `target-humidity` now works on climate entities that support it |
+| **Dashboard background editor** | 2026.9 | A Background tab in the dashboard detail dialog edits the dashboard-level `background` key, which applies to every view that sets none of its own. The key itself predates 2026.9 |
 
 **Legacy patterns to avoid:**
 - Single-view dashboards with all cards in one long scroll

{ha_mcp_dev-8.4.3.dev2588 → ha_mcp_dev-8.4.3.dev2592}/src/ha_mcp/resources/skills-vendor/skills/home-assistant-best-practices/references/device-control.md

@@ -294,6 +294,21 @@ actions:
       tilt_position: 75
 ```
 
+**Speed (2026.9+):** `cover.open_cover`, `cover.close_cover` and `cover.set_cover_position`
+take an optional `speed`. The values are per entity: read its `supported_speeds` attribute and
+pass one of those strings. A value outside that list raises a validation error. A cover with no
+`supported_speeds` ignores the option and moves at its normal speed.
+
+```yaml
+actions:
+  - action: cover.set_cover_position
+    target:
+      entity_id: cover.living_room_blinds
+    data:
+      position: 50
+      speed: fast          # one of the entity's supported_speeds
+```
+
 ### Media Players
 
 ```yaml

{ha_mcp_dev-8.4.3.dev2588 → ha_mcp_dev-8.4.3.dev2592}/src/ha_mcp/resources/skills-vendor/skills/home-assistant-best-practices/references/helper-selection.md

@@ -60,7 +60,7 @@ have none, so a YAML change needs `homeassistant.restart` — confirm with the u
 `threshold`, `tod`, `integration`, `mold_indicator`, `random`, `switch_as_x`,
 `generic_hygrostat`, and `utility_meter` (whose services are `reset`/`calibrate` only).
 
-**`YAML-only:` lines are verified against core 2026.8.3.** Those keys exist on the YAML
+**`YAML-only:` lines are verified against core 2026.8.3** (2026.9 notes against core 2026.9.0). Those keys exist on the YAML
 platform schema and have no config-flow field, so needing one is a reason to write YAML.
 A helper with no `YAML-only:` line has no such keys. Where the two shapes differ or the flow
 cannot express a case (`trend`, `tod`, `bayesian`, `filter`, `template`), both are shown.
@@ -132,11 +132,14 @@ Note the key is `round_digits` here — `derivative` and `integration` spell the
 - Ignores `unknown` states (except `sum` which goes to unknown)
 - Returns error if unit of measurement differs between sensors
 - For spiky values, filter with statistics sensor first
+- Always `state_class: measurement`, so the recorder compiles `mean`/`min`/`max` and never `sum` (`DEFAULT_STATISTICS` in `sensor/recorder.py`)
+- Energy Dashboard consequence: a `sum` of energy (kWh) sensors plots nothing and is flagged `entity_state_class_measurement_no_last_reset`. Adding `last_reset` silences that issue but still plots nothing; energy sources need `total` or `total_increasing`. Add each energy sensor as its own dashboard source instead, which the dashboard sums for display. The grid `stat_rate` slot is the opposite case: it requires `measurement` with `device_class: power`, which a `sum` of power sensors satisfies (gas and water `stat_rate` take `volume_flow_rate` instead)
+- Since 2026.3, `device_class` is inherited only when every entity in `entity_ids` carries the same one, evaluated once at setup
 
 **Common uses:**
 - Average house temperature from multiple room sensors
 - Maximum power consumption across circuits
-- Sum of all solar panel production sensors
+- Sum of solar power (W) across arrays; for kWh use [integration](#integration-riemann-sum)
 
 ---
 
@@ -625,6 +628,10 @@ name: "Doorbell"         # required
 icon: mdi:bell
 ```
 
+**Trigger on a press:** since 2026.9, `trigger: button.pressed` accepts an `input_button`
+helper as its target. On 2026.8 and earlier it only accepts `button` entities, so a helper
+press needs a state trigger on the helper entity.
+
 **Common uses:**
 - Manual triggers for automations
 - Dashboard buttons
@@ -1188,8 +1195,8 @@ sets the entry up, which is why the YAML platform shape shows the key at the top
 **template → device_tracker** (the native replacement for the legacy `device_tracker.see` action)
 - Required: `name`, and **either** `in_zones` (a list of zone entity_ids the device is considered in) **or** both `latitude` and `longitude` (templates)
 - Optional: `device_id`; `availability` and `location_accuracy` inside `additional_options`
-- **YAML-only:** `icon`, `picture` (and `unique_id`, as everywhere)
-- Not valid here in **either** shape: `attributes`. Nor: `location_name`, `battery_level`, `source_type`, `host_name`, `mac_address`, `gps_accuracy`
+- **YAML-only:** `icon`, `picture`, and `attributes` for extra attributes of your own (added in 2026.9, YAML-only), plus `unique_id`, as everywhere. `attributes` cannot set the entity's own: `source_type`, `in_zones`, `tracking_type`, `latitude`, `longitude` and `gps_accuracy` are rejected there
+- Not valid as config keys in **either** shape: `location_name`, `battery_level`, `source_type`, `host_name`, `mac_address`, `gps_accuracy`
 
 Other sub-types follow the same shape — a `state` template plus domain-appropriate metadata.
 
@@ -1230,12 +1237,12 @@ template:
         device_class: presence
 ```
 
-**YAML-only for template entities** (verified against the Template Helper flow at 2026.8.3):
+**YAML-only for template entities** (flow fields verified at 2026.8.3; the 2026.9 notes against core 2026.9.0):
 
 | YAML-only | Why the flow cannot do it |
 |---|---|
-| **Trigger-based templates** (`triggers:` / `action:` / `variables:` on the block) | The flow has no trigger step. Its per-sub-type action fields (`press`, `turn_on`, `set_value`, …) are entity *commands*, not a trigger block's `actions:` |
-| `attributes:` (extra state attributes) | No field in the flow |
+| **Trigger-based templates** (`triggers:` / `action:` / `variables:` on the block, and per-entity `conditions:` since 2026.9) | The flow has no trigger step. Its per-sub-type action fields (`press`, `turn_on`, `set_value`, …) are entity *commands*, not a trigger block's `actions:` |
+| `attributes:` (extra state attributes; on every platform since 2026.9) | No field in the flow |
 | Several entities in one block | One entity per config entry |
 
 (`unique_id` is not in this table: the flow assigns one. See the note at the top of this file.)
@@ -1255,6 +1262,7 @@ See the [Decision Matrix](#decision-matrix) for when the Template Helper is the
 |------|--------|-----|
 | Average of multiple sensors | `min_max` (type: mean) | Template with math |
 | Sum of multiple sensors | `min_max` (type: sum) | Template with math |
+| Sum of energy (kWh) sensors for the Energy Dashboard | Add each sensor as its own dashboard source | `min_max` (type: sum): `measurement` never compiles `sum` statistics |
 | Average over time | `statistics` | Template tracking history |
 | Rate of change | `derivative` | Template calculating delta |
 | On/off at threshold | `threshold` | Template binary sensor |

{ha_mcp_dev-8.4.3.dev2588 → ha_mcp_dev-8.4.3.dev2592}/src/ha_mcp/resources/skills-vendor/skills/home-assistant-best-practices/references/template-guidelines.md

@@ -290,6 +290,36 @@ template:
 **Trigger-based blocks are YAML-only** — the Template Helper flow has no trigger step, and
 no `attributes:` field. This example uses both.
 
+**Two 2026.9 additions to the YAML shape:**
+- `attributes:` works on every template platform, trigger-based or not. Before 2026.9 only
+  `sensor`, `binary_sensor`, `image`, `event` and `vacuum` took it. It accepts a map of
+  templates, as above, or one template that renders a whole map. You cannot set an attribute
+  the entity already owns, such as `brightness` on a template light or `latitude` on a template
+  device_tracker: most platforms reject the config, the rest drop it at runtime with a logged
+  error.
+- `conditions:` can sit on a single entity, gating that entity's update after the block's
+  triggers fire. The older block-level `conditions:` gates every entity in the block. Put both
+  on a trigger block only: HA refuses a per-entity `conditions:` when the block has no trigger.
+
+```yaml
+# Per-entity conditions: this sensor updates only while someone is home
+template:
+  - triggers:
+      - trigger: state
+        entity_id: sensor.power_meter
+    sensor:
+      - name: "Power While Home"
+        unique_id: power_while_home
+        conditions:
+          - condition: state
+            entity_id: binary_sensor.occupancy
+            state: "on"
+        state: "{{ trigger.to_state.state }}"
+        unit_of_measurement: "W"
+        device_class: power
+        state_class: measurement
+```
+
 **Use trigger-based when you need:**
 - The `trigger` variable — which entity fired, `from_state` / `to_state`, event data
 - A value captured at an instant rather than recomputed (timestamps, "last X")

{ha_mcp_dev-8.4.3.dev2588 → ha_mcp_dev-8.4.3.dev2592}/src/ha_mcp/resources/skills-vendor/skills/home-assistant-best-practices/references/yaml-only-integrations.md

@@ -6,6 +6,7 @@ This does NOT apply to:
 
 - Automations/scripts/scenes (use config APIs)
 - `.storage/` files (use REST/WebSocket APIs)
+- `http` (2026.8+): moved to a storage-backed store with a WebSocket API (`http/config/configure`), managed from Settings → System → Network. A `configuration.yaml` `http:` block is imported once and then ignored, and HA raises a repair issue asking the user to remove it
 - UI-configured integrations and helpers (config flow): `input_*` helpers, the UI Group Helper (Settings → Devices & Services → Helpers → Group), and most modern notify integrations — **unless the helper's flow has no field for the config you need**, which is a real and common case: see the `YAML-only:` lines in [helper-selection](helper-selection.md)
 
 Old-style YAML `group:` blocks are still YAML-only and appear in the table below — only the UI Group Helper is excluded.

{ha_mcp_dev-8.4.3.dev2588 → ha_mcp_dev-8.4.3.dev2592/src/ha_mcp_dev.egg-info}/PKG-INFO

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