ha-mcp-dev 8.6.0.dev2941__tar.gz → 8.6.0.dev2945__tar.gz

{ha_mcp_dev-8.6.0.dev2941 → ha_mcp_dev-8.6.0.dev2945}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: ha-mcp-dev
-Version: 8.6.0.dev2941
+Version: 8.6.0.dev2945
 Summary: Home Assistant MCP Server - Complete control of Home Assistant through MCP
 Keywords: mcp,home-assistant,ai,automation,smart-home
 Author: Julien

{ha_mcp_dev-8.6.0.dev2941 → ha_mcp_dev-8.6.0.dev2945}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "uv_build"
 
 [project]
 name = "ha-mcp-dev"
-version = "8.6.0.dev2941"
+version = "8.6.0.dev2945"
 description = "Home Assistant MCP Server - Complete control of Home Assistant through MCP"
 readme = "README.md"
 requires-python = ">=3.13,<3.15"

{ha_mcp_dev-8.6.0.dev2941 → ha_mcp_dev-8.6.0.dev2945}/pyproject.toml.orig

@@ -4,7 +4,7 @@ build-backend = "uv_build"
 
 [project]
 name = "ha-mcp-dev"
-version = "8.6.0.dev2941"
+version = "8.6.0.dev2945"
 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.6.0.dev2941 → ha_mcp_dev-8.6.0.dev2945}/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: "44"
+  version: "45"
 ---
 
 # Home Assistant Best Practices

{ha_mcp_dev-8.6.0.dev2941 → ha_mcp_dev-8.6.0.dev2945}/src/ha_mcp/resources/skills-vendor/skills/home-assistant-best-practices/references/dashboard-guide.md

@@ -357,6 +357,19 @@ Cards, sections, and badges all accept `visibility` (a list of conditions, impli
 
 `screen` is the canonical way to show/hide cards by viewport (desktop vs. mobile).
 
+**Automation conditions (2026.10+).** `visibility` also accepts `template`, `sun`, `zone`, `device` and integration-provided conditions, written as in an automation. `trigger` is not accepted. They mix with the types above, also inside `and`/`or`/`not`.
+
+```json
+{
+  "visibility": [
+    {"condition": "sun", "after": "sunset"},
+    {"condition": "screen", "media_query": "(max-width: 767px)"}
+  ]
+}
+```
+
+`state` and `numeric_state` have two shapes since 2026.10: the dashboard one with `entity` (shown above; works on every version) and the automation one with `entity_id`, which the 2026.10 editor writes when a condition is edited. Keep whichever shape a config already has; write `entity` unless the instance runs 2026.10 or later.
+
 ---
 
 ## Custom Cards

{ha_mcp_dev-8.6.0.dev2941 → ha_mcp_dev-8.6.0.dev2945}/src/ha_mcp/resources/skills-vendor/skills/home-assistant-best-practices/references/helper-selection.md

@@ -34,7 +34,7 @@ Several helper integrations — most prominently **`template`**, **`group`**, an
 
 | Helper | Sub-types (pick one first) |
 |--------|---------------------------|
-| `template` | `sensor`, `binary_sensor`, `button`, `switch`, `light`, `cover`, `fan`, `lock`, `select`, `number`, `image`, `vacuum`, `weather`, `alarm_control_panel`, `event`, `update`, `device_tracker` |
+| `template` | `sensor`, `binary_sensor`, `button`, `switch`, `light`, `cover`, `fan`, `lock`, `select`, `number`, `image`, `vacuum`, `weather`, `alarm_control_panel`, `event`, `update`, `device_tracker`, `climate` (2026.10+) |
 | `group` | `binary_sensor`, `button`, `cover`, `event`, `fan`, `light`, `lock`, `media_player`, `notify`, `sensor`, `switch`, `valve` |
 | `random` | `sensor`, `binary_sensor` |
 
@@ -1051,6 +1051,8 @@ is not UI-editable. There is no reason to prefer YAML for this helper.
 
 **Use for:** Turning a switch (or fan) into a thermostat that follows a temperature sensor.
 
+Development is frozen since 2026.10: it gets no new features, but it is not deprecated. For a device exposed as separate switches, sensors and numbers, use [`template` → `climate`](#template) instead.
+
 ```yaml
 # generic_thermostat helper (config-flow submission, TWO steps)
 # --- step 1 (user) ---
@@ -1192,7 +1194,13 @@ sets the entry up, which is why the YAML platform shape shows the key at the top
 
 **template → binary_sensor**
 - Required: `name`, `state` (Jinja template returning truthy/falsy)
-- Optional: `device_class`, `device_id`; `availability` inside `additional_options`
+- Optional: `device_class`, `device_id`; `availability`, `delay_on` and `delay_off` inside `additional_options` (the two delays are durations; in the flow since 2026.10, YAML-only before)
+
+**template → climate** (2026.10+; a thermostat built from other entities)
+- Required: `name`, `hvac_modes` (template returning the list of available modes), `set_hvac_mode` (actions; receive `hvac_mode`)
+- Optional: `hvac_mode`, `hvac_action`, `current_temperature`, `target_temperature` (templates), `set_temperature` (actions), `temperature_unit`, `device_id`; `availability`, `min_temperature` and `max_temperature` inside `additional_options`
+- No `state` field. `target_temperature` without `set_temperature` fails validation
+- **YAML-only:** a dual setpoint (`target_temperature_high` and `target_temperature_low`, set together), `target_temperature_step`, `precision`, and fan, preset and swing modes and humidity
 
 **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)
@@ -1239,7 +1247,7 @@ template:
         device_class: presence
 ```
 
-**YAML-only for template entities** (flow fields verified at 2026.8.3; the 2026.9 notes against core 2026.9.0):
+**YAML-only for template entities** (flow fields verified at 2026.8.3; the 2026.9 notes against core 2026.9.0; `climate` and the binary sensor delays against 2026.10.0b0):
 
 | YAML-only | Why the flow cannot do it |
 |---|---|
@@ -1284,6 +1292,7 @@ See the [Decision Matrix](#decision-matrix) for when the Template Helper is the
 | Throttle update rate | `filter` (`throttle`/`time_throttle`) | Custom automation with delays |
 | Reject out-of-range values | `filter` (`range`) | Template with bounds check |
 | Thermostat from switch + temp sensor | `generic_thermostat` | Automation with hysteresis logic |
+| Thermostat from a device's separate switches, sensors and numbers (2026.10+) | `template` helper → `climate` | Scripts and input helpers kept in sync by automations |
 | Humidifier from switch + humidity sensor | `generic_hygrostat` | Automation with hysteresis logic |
 | Mold/condensation risk from temp + humidity | `mold_indicator` | Dew-point template |
 | Infer an unmeasurable state from several signals | `bayesian` | Template with stacked and/or logic |

{ha_mcp_dev-8.6.0.dev2941 → ha_mcp_dev-8.6.0.dev2945}/src/ha_mcp/resources/skills-vendor/skills/home-assistant-best-practices/references/triggers-and-conditions.md

@@ -42,6 +42,25 @@ for:
   minutes: 5
 ```
 
+**`for` needs one literal state (2026.10+).** A state condition that combines `for` with `attribute`, with a list of two or more states, or with an `input_*` entity ID as `state` fails validation. Before 2026.10 HA accepted these, but `for` is measured from the entity's `last_changed`, which follows neither an attribute nor a set of states.
+
+```yaml
+# WRONG — fails validation since 2026.10: `for` with `attribute`
+condition: state
+entity_id: climate.thermostat
+attribute: hvac_action
+state: "heating"
+for:
+  minutes: 10
+
+# RIGHT — a template binary sensor holds the duration, the condition reads it
+condition: state
+entity_id: binary_sensor.heating_for_10_minutes
+state: "on"
+```
+
+The binary sensor is a `template` helper with `state: "{{ is_state_attr('climate.thermostat', 'hvac_action', 'heating') }}"` and `delay_on` set to 10 minutes (see [helper-selection](helper-selection.md#template-helpers)).
+
 ### Numeric State Condition
 
 For numeric comparisons. Always prefer over template conditions with `| float`.
@@ -780,3 +799,9 @@ automation:
 ```
 
 Access trigger info in templates with `trigger.id`, `trigger.entity_id`, `trigger.to_state`, etc.
+
+**Generated IDs in UI-made automations (2026.10+).** The automation editor no longer has a trigger ID field. Ticking a trigger in a **Triggered by** condition (`condition: trigger`) writes `id: generated-<4 characters>` on that trigger, and the editor removes a `generated-` ID once no trigger condition lists it.
+
+- Editing such an automation: keep each `generated-` ID and the conditions that list it.
+- IDs without the prefix are kept as written, so descriptive IDs set in YAML (as above) still work.
+- The editor does not count `trigger.id` in a template as a reference. Branch on a `generated-` ID with `condition: trigger`, not a template.