v3.45.0-beta.3

Pre-release of v3.45.0, for staging validation of #783 (Sentinel autonomy level). HACS offers it only to users who opted into betas. It contains everything on main as of 6fe63f7.

New since beta.2:

• Restarts no longer wait 3 to 4 minutes on the tool index (#811).
• A dismissed "unknown-person rules cannot fire" notice stays dismissed across Sentinel config saves (#810).
• Baseline collection posts one "Baseline established" notice instead of one per entity (#791).
• Change alerts held back at level 1+ by a cooldown, quiet hours or a pending prompt are kept and told later (#801); a late alert names only devices not already told, and a wait on a stopped rule shows on the sentinel_health sensor (#802).

Full notes for v3.45.0 so far:

Added

• Sentinel's autonomy level can now be set in Sentinel's Advanced setup (#783).
  • Before, Sentinel ran at level 1 (notify only) unless sentinel_set_autonomy_level raised it, which lasted only an hour. The setting the engine read for its normal level could not be set anywhere.
  • Autonomy level (0–3, default 1) is now kept across restarts and Basic setup re-runs.
  • Level 0 now silences finding alerts and the daily digest, as documented, and alerts already waiting in a batch are dropped (a warning lists their kinds); change alerts are never held in a batch, so none is dropped this way. Before, it still sent every notification and only skipped triage. Findings are still recorded in the audit, and nothing seen at level 0 is lost: a change (a new device or client, a new admin or token, a public IP or port-mapping change) alerts once the level is raised, one alert per kind of change, even one undone while at 0, such as a port mapping added and removed again or a device paired and removed (#799). That alert starts with when the change was seen and says it may have been undone since, lists every device, client or account seen and not already reported (skipping any you trusted meanwhile) at the highest severity seen, and points to the trust device service instead of a Trust device button. Each public IP or port-mapping change seen is told. A change a cooldown or quiet hours stopped at 0 is owed too, and LLM triage never drops an owed alert. A condition that is still true alerts again once its cooldown ends, without muting other devices meanwhile. An alert being prepared when level 0 is set is not sent. Level 0 in force when Sentinel starts is logged as a warning. Baseline and one-time setup notices still appear.
  • The sentinel_health sensor shows the level in force and when an override ends (autonomy_level, autonomy_override_expires), updated as soon as the service sets a level. A service call that sets level 0 is logged as a warning.
  • Autonomy override duration (default 60 minutes, up to 30 days) sets how long a level from the service lasts, and a Basic setup re-run keeps it. An override now also ends when the configured level changes, so a raised one cannot outlive a lowered setting. A level or duration an older install kept in a different form (a level of 0.0, a duration of "5") is shown and saved as it runs, so saving the form unchanged changes nothing.
  • Levels 2 and 3 are reserved for automatic actions, which are not available yet (#789), and now notify exactly like level 1. Before, they could drop a finding whose device was unavailable. The docs described them as acting on their own, which no setup could do, and now say so.
  • A level an older install stored in its main options is kept on upgrade, and shown in the form.
  • When automatic actions arrive, Sentinel will never run a critical action on its own, whatever is allowed: an unlock, an alarm panel or cover action (also through homeassistant.*), anything a Critical Action PIN rule covers (reaching entities by device class, name and group, as the PIN gate does since v3.44.3), or anything that starts a script, scene or automation. That guard is already in place, and automatic actions stay off even if an older setting enabled them.

Fixed

• Home Assistant no longer waits on the tool index at startup (#811). The background tool-index build was started as an ordinary task, which Home Assistant's startup waits for. With embeddings sent to a remote Ollama it could hold up startup until Home Assistant gave up ("Setup timed out for bootstrap waiting on … hga_tool_index"), so a restart took 3 to 4 minutes instead of about one. It now runs as a background task, and startup no longer waits for it.
• A dismissed "unknown-person rules cannot fire" notice no longer comes back on every Sentinel config save (#810). Saving the config reloads the integration, and the reload deleted the notice, which also forgot your dismissal, before setting it up again. A reload now keeps it; it is still removed once face recognition is set up, or when the integration is disabled or removed.
• Turning on baseline collection no longer floods the notifications panel (#791). Sentinel posted one persistent notification per entity when its baseline was established, and entities that start sampling together are established together: one home got 236 at once. There is now one "Baseline established" notice. Until you dismiss it, each later cycle adds to it rather than replacing it, also across a reload of the integration. It names up to 10 entities, the newest first, and counts the rest; resetting a baseline takes it off the notice. The per-entity notices an older version posted are cleared by the restart that installs this one, since Home Assistant does not keep notices across restarts. The baseline drift notice is batched the same way, but has never been able to fire, because its reference value is never set (#807).
• A Sentinel alert told late no longer names devices already told, and a wait on a stopped rule is visible (#802). A change alert owed from autonomy level 0, or held back by a cooldown (#799, #801), was told later with the wording it was first seen with, so it could name a device a live alert had already reported or that you trusted meanwhile. Now a replay names only the devices, clients or accounts still owed, and still says when one joined while nobody was home. For network clients, an exclusion added since on one client no longer drops the whole alert, and a told client's cooldown no longer holds back the rest. An owed alert whose rule stops running (network checks turned off, an integration broken or removed) waits until the rule runs again, as before, but no longer silently: the sentinel_health sensor shows what is owed (owed_change_alerts) and on how many days Sentinel ran without the rule (owed_rules_idle_days), and a warning is logged every 7 such days. It is never dropped: a security change you never saw matters more than a late one.
• A security change made and undone during a cooldown or quiet hours is no longer lost (#801). At any autonomy level, Sentinel's change alerts (a new admin or token, a new radio device or network client, a public IP or UPnP port-mapping change) held back by a cooldown, quiet hours or a pending prompt were only re-detected while the change was still there. A second admin token created and deleted within the 30 minutes after the first token's alert, or a device paired and removed during quiet hours, was never told. Such a change is now kept, as level 0 keeps one (#799), and told once it can be, starting with when it was seen while its alert was held back. A change still there is told once, by its own alert, and more port mappings counted from the same baseline are told once. A replay skips its kind's cooldown at most once per cooldown window, so a live alert of its kind cannot keep pushing it back, without restarting that cooldown, and still waits out a device cooldown False Alarm lengthened. It has no snooze buttons, since a snooze mutes every alert of its kind. A snoozed kind is not kept, and a held-back change whose live alert triage stops is not sent. At level 1 this can mean one extra "held back" push per kind per cooldown window while changes keep coming. Each kind keeps up to 20 alerts (the first 19 and the latest); devices, clients and accounts past those are counted, up to 500.
• Opening or closing a cover by voice no longer fails when other device tools rank higher (#795). "Open the study shade" could fail with "I couldn't find a suitable tool": the agent offers the model only the few tools that best match the request, and device tools such as a vacuum's start or a media player's unpause could outscore the general "turn on" tool, which is the only one Home Assistant gives an assistant for opening a cover. The model then guessed a tool that does not exist and the call was refused. A request with an English action word ("turn", "open", "close", ...), or a "yes" to the agent offering one ("Want me to open the Study Shade?"), now always offers the turn on and turn off tools, alongside what the ranking chose. Requests in other languages, and replies such as "the left one", still rely on the ranking. A tool you excluded is still never offered.

Changed

• The model-provider libraries are no longer pinned to one exact version each: langchain-openai, langchain-anthropic and langchain-ollama accept any 1.x release (langchain-ollama from 0.3.10), langchain-google-genai any 3.x from 3.1.0, and the anthropic SDK anything from 0.125.0 below 2. When a Home Assistant release moved a library these depend on, such as openai in 2026.10, an exact pin could not be installed next to it and the integration failed to set up for everyone until a new release shipped (#735). Home Assistant can now pick a compatible release on its own. A fresh install, or the reinstall that follows a Home Assistant update, gets the newest release in each range: today langchain-openai 1.7.2, langchain-anthropic 1.7.6 with anthropic 1.15.0, langchain-ollama 1.1.0 and langchain-google-genai 3.2.0. The test suite runs against the newest releases every day.