v1.7.0

Fixed

• Chat health no longer cries wolf over one old failure. The sensor used to
  read degraded if the add-on's rolling window held any failed chat, and that
  window is trimmed by count (the last 50 chats), never by age — so on a quiet
  install a single blip could keep the sensor red for days. It now reads
  degraded on three failed chats in a row, or when one chat in ten or more is
  failing; and clears again once the clean chats since the last failure outnumber
  the failures behind them, or that failure is over 6 hours old. One failure 19 hours ago with 37 clean chats since now reads ok, with the
  detail still in the attributes — while a fault that keeps recurring stays
  visible instead of being averaged away.

Added

• A live outage shows up immediately. Three failed chats in a row now reads
  degraded on its own, without waiting for the failure rate to climb. A rate
  measured over the last 50 chats can't see a fresh outage until it has diluted
  that window — on a quiet install, potentially days.
• Chat health shows its working. New attributes: recent_ok, failure_rate,
  and — from add-on 1.49.0 — consecutive_ok / consecutive_failed (chats since
  the last failure, and since the last success) plus last_failure,
  window_from and window_to, so you can see when the trouble was, not just
  that there was some. On an older add-on those are null and the sensor judges on
  the rate alone; a missing field neither clears a warning nor invents one.

v1.6.1 — Install from the HACS default store

claude-ha is now listed in the HACS default store, so installing no longer requires adding a custom repository.

Changed

• Installing no longer needs a custom repository. The documented install path is now the Open in HACS button, or a search for claude-ha — searching Claude alone turns up several similarly-named integrations (Claude Chat, Claude Pulse, Claude Usage). A freshly listed repository takes a few hours to reach every HACS install; until it does, the button still works, and adding LayerTM/claude-ha as a custom repository remains documented as a last resort.
• The README now states the Home Assistant OS / Supervised requirement up front, and spells out that the companion add-on still has to be added to the add-on store by repository URL.

Existing installs are unaffected — no functional change. This release exists so the corrected instructions actually reach users: HACS renders a repository's info page from its latest release tag, never from the default branch.

Full changelog: v1.6.0...v1.6.1

v1.6.0 — Active alerts binary sensor

Active alerts binary sensor

A new Active alerts binary sensor (device class problem) turns on whenever the Claude Code add-on's proactive alerts flag anything — a water leak, a device or your internet gateway going offline, low battery, high CO2, and so on — and off when all is clear. Your own automations, dashboards, and history can now react to the alert state, not just the push notification.

Its attributes carry the active count, how many are critical, and the full list of current alerts.

It reads a field the Claude Code add-on serves from v1.39.0 onward, so it stays unavailable on older add-ons and while proactive alerts are turned off — nothing changes until the feature is in use.

Requires the Claude Code add-on v1.39.0+ for the alerts sensor.

v1.5.0 — Payload-aware automation safety

Changed

• Automations Claude creates or edits are bounded by what they actuate, not just the service name. The safety check now inspects each action's target and data: an automation may only act on your own entities in the safe domains (lights, switches, covers, climate, media players, locks, notifications, helpers, …), no matter how the action is phrased. Reaching outside that set — e.g. a scene that disarms an alarm, or targeting a whole area/device (which could later include a lock) — is refused. Targeting must name specific entities (not an area, device, floor, label, template, or "all"). Activating or applying scenes now works whenever the scene only touches safe entities, and the internal list of hard-blocked services shrank because the general rule now covers those cases.

Everyday automations (turn a light on at sunset, notify at 8am) are unaffected. Pairs with Claude add-on ≥ 1.36.2, which drafts automations targeting specific devices.

v1.4.0 — Change automations by describing them

Added

• Change an existing automation by describing it. Say "change my morning-lights automation to 9am" and Claude edits that automation — it's given the automation's real current configuration, so it changes only what you asked and keeps the rest. It shows the updated version, asks you to confirm, and on "yes" updates it in place (same automation, same id — no duplicate). If more than one automation matches it asks which; if none match it says so. The updated config goes through the same safety checks as a newly created one.

Requires the Claude add-on ≥ 1.36.0; with an older add-on a change request is answered normally instead. Completes describe-to-manage automations: create, delete, and now change.

v1.3.0 — Delete automations by describing them

Added

• Delete an automation by describing it. Say "delete my morning-lights automation" and Claude resolves the matching automation, asks you to confirm, and removes it. If more than one automation matches it asks which one; if none match it says so — it never removes something you didn't confirm. Works in English, Ukrainian and Polish. No add-on update needed.

v1.2.0 — Create automations from a description

Added

• Create automations by describing them, with a confirmation. Ask Claude to create an automation — "create an automation that turns on the porch light at sunset" — and it drafts the config, shows it to you, and when you reply yes creates it in Home Assistant (voice gets a short spoken "…say yes to confirm").

  Because the draft is written into your Home Assistant, it goes through a strict safety gate first: it's re-validated against Home Assistant's own automation schema, and it may only call everyday device, helper and notify services. Any draft that reaches for a shell command, a script runtime, a templated service name, a way to reproduce arbitrary states across other domains (e.g. scene.apply), a URL/raw-command passthrough (media_player.play_media, vacuum.send_command), or any service outside that set is refused — not created. Nothing is written unless the whole draft passes, and the created automation always gets a fresh id (a draft can never overwrite one of yours).

Requires the Claude add-on ≥ 1.34.0 to draft the config.

v1.1.1 — CI type-check fix

Fixed

• CI type-check (mypy strict) regression from 1.1.0. The automation-draft rendering added in 1.1.0 tripped strict typing (PyYAML had no type stubs; the drafted-config argument wasn't narrowed from dict | None). Fixed with the types-PyYAML stub and a narrowing at the call boundary. No behavior change — internal/CI only. All CI green.

v1.1.0 — Draft automations from a description (preview)

Added

• Describe an automation in words and see it drafted (preview). Ask Claude to create an automation — "create an automation that turns on the porch light at sunset" — and it now drafts the full Home Assistant config and shows it to you as a YAML block you can read or copy. Read-only: nothing is written yet. On voice the reply stays a short spoken summary (the YAML isn't read aloud).

Requires the Claude add-on ≥ 1.34.0 (which drafts the config); with an older add-on nothing changes. Committing a draft with a confirmation is coming in a later release.

v1.0.1 — Usage dashboard graph fix

Fixed

• Usage dashboard: the cost history was unreadable. The example plotted API cost (USD, ~0–5) and token usage (thousands–millions) on one history graph; because a graph shares a single y-axis, the cost line was flattened to the bottom and effectively invisible. Cost and tokens are now split into two graphs, each auto-scaling to its own range. Also documented that the budget gauge is only meaningful when a daily budget is set on the add-on.

Docs-only — no add-on update or restart required. If you added the dashboard, re-copy the YAML from the README.